Witness system
A witness system using EDI (electronic data interchange) to perform efficient distribution and account settlement processes between selling and buying companies. A buying company makes documents according to delivery or order vouchers, and electronically sends the documents to a selling company via a notarization authority. The selling company compares the authentication documents with delivery or order vouchers the selling company issued, and, after determining that the documents are correct, executes a confirmation response to the notarization authority. The notarization authority registers the documents in the witness server's receipts detail table and notifies the buying and selling companies that the notarization authority authenticated the documents. This structure enables the making of accurate detailed payment statements when, for example, a detailed payment statement is made or a funds transfer is executed based on confirmed data. Furthermore, checking the detailed payment statement is made simpler through reference to the witness system server.
Latest FUJITSU LIMITED Patents:
This application is a divisional of prior U.S. patent application Ser. No. 09/184,587, filed Nov. 3, 1998, which claimed priority to Japanese Patent Application No. 10-121295, filed Apr. 30, 1998, the entire contents of which are incorporated herein by reference.
BACKGROUND OF THE INVENTION1. Field of the Invention
The present invention relates to a Witness system that, using EDI (electronic data exchange), supports account settlement (accounting) and distribution systems among sellers and buyers.
2. Description of the Related Art
Today's distribution systems are manifold and, through complex distribution media, carry out the distribution of large quantities of goods. As a result, accounting processes undertaken between sellers and buyers are equally complex.
The system disclosed in
The buyer thereafter consolidates and aggregates detailed vouchers according, illustratively, to payment date, and makes a detailed payment statement. The detailed payment statement so made is the result of the above-described consolidation and aggregation of each detailed voucher. Minute details otherwise recorded in a detailed voucher are omitted from the detailed payment statement. By way of illustration, payment date and total price are reflected in the detailed payment statement; more particularized details (e.g., delivery date, description of delivered items, unit price, and quantity), however, are commonly omitted.
As between a buyer and seller trading daily many goods with a payment cycle of one payment per month, for example, detailed vouchers corresponding to delivered volumes are reduced to a single detailed payment statement, and only the aggregated total price is established according to the detailed payment statement.
The buyer, using the above described detailed payment statement, requests that its bank transfer funds in favor of the seller. The bank then makes a deposit for the amount specified in the detailed payment statement in favor of the Seller, with respect to whom the request for funds transfer was made, utilizing, illustratively, an inter-bank exchange system. As a result, a seller thus receiving payment learns, through notification from the bank, the amount of money received in the seller's bank account from the buyer.
The following problems are inherent in a conventional system like that described above. Specifically, the detailed payment statement used in the conventional system is a document that compiles in the aforesaid manner multiple delivery vouchers in establishing a total payment amount. A seller is thus unable unilaterally to ascertain which delivery vouchers are reflected in the total amount paid to it by the buyer. This is the result of the omission of delivery date, description of delivered goods, unit price, quantity, and like information, for discrete transactions, from the detailed payment statement.
In such instances, the seller must confirm substantive details with the buyer, in order to verify the amount of money received. Where, for example, the amount of money paid to the seller does not agree with the total amount invoiced, the seller's accounting representative must either confirm with the buyer the contents of the detailed vouchers or make discrete inquiries regarding payment amounts. This work places a significant burden on the accounting departments and constitutes a material impediment to enhancing the efficiency of account settlement processing.
Specifically, where a single account settlement for a large transaction is undertaken according to the detailed payment statement, a great deal of time and human effort are required to confirm substantive details recorded therein. And, in settling accounts with high-volume customers, a seller must undertake account settlement in terms of the smallest transaction, i.e., by voucher, in order to set receivables off against payables.
On the other hand, with the popularization of the internet, the construction of EDI-implemented (electronic data interchange) information exchange systems is being tested in all functional disciplines. It is anticipated that use of the system contemplated by the present invention will, particularly as between companies, facilitate more efficient account settlement processing and distribution in complex distribution channels.
SUMMARY OF THE INVENTIONUtilizing EDI (electronic data interchange), the present invention provides a Witness system that ensures information safety, and further provides account settlement processes making use of said Witness system, in order to perform efficient account settlement processing and distribution.
Specifically, the present invention achieves these objectives by providing a Witness system consisting of: Document making means for making confirmation documents based on records prepared by and sent from a seller for each seller record; forwarding means for forwarding to a notarization authority documentation made according to said confirmation document making means and, further, for forwarding said documentation from the aforementioned notarization authority to the aforementioned seller; confirmation means for confirming whether the content of the aforementioned documents forwarded by the aforementioned forwarding means agree with the content of the aforementioned seller records; a Witness for confirming that the aforesaid documents are correct, upon establishing the aforesaid substantive agreement according to said confirmation means; and memory means for storing in memory documents confirmed by said Witness.
Records prepared by and sent from a seller include, by way of illustration, delivery vouchers, written estimates, invoices, and like records. These records are used to identify brand names, quantities, unit prices, and money amounts, when making details concerning goods received by a buyer. “Buyer” and “seller” comprise both public and private enterprises. The system contemplated by the present invention draws no distinction between incorporated and unincorporated entities.
A notarization authority (1) receives details prepared by a buyer based, among other things, on delivery vouchers, (2) transmits these details to the seller, and (3) solicits from the seller confirmation that substantive details are in agreement with the content of the delivery vouchers. The Witness receives notification that the seller confirms substantive agreement, whereupon the Witness certifies the aforesaid details as correct documents and confirms said details to the aforesaid buyer and seller.
By constructing the system in this way, details for discrete deliveries prepared by a buyer are confirmed between buyer and seller, as well as by the third-party Witness. These details can be used effectively as accurate data in account settlement processing.
The preferred embodiments of the present invention are hereunder explained using accompanying figures.
First, buying company 1 sends to the Witness 3 data that buying company 1 wishes to have confirmed by the Witness 3. Exemplary data include that which is recorded on a delivery voucher (see FIG. 2(1)). Having received this data, the Witness first makes record only of the fact that it has received a request, and then sends the request, as is, to selling company 2 (see FIG. 2(2)). Having received the confirmation request, selling company 2 confirms the contents recorded in the aforementioned data and then executes, with respect to the Witness 3, a confirmation response indicating whether selling company 2 agrees with said data (see FIG. 2(3)). The Witness 3 receives the confirmation response and, if selling company 2 agrees with the recorded contents, transmits to buying company 1 and selling company 2 a confirmation response representing that both parties have verified the aforementioned data (see FIG. 2(4)).
The Witness 3 is thus possessed of faculties for undertaking simple recordation of the fact that it has received data from the buying company 1 and for proceeding further to confirm data (confirmation documents) exchanged between the buying and selling companies. The Witness 3 manages data and performs account settlement (accounting) processes relating, for example, to detailed payment statement making and funds transfers.
The Witness server 9 comprises: Delivery detail table 20, which preserves in memory documentation relating, by way of illustration, to delivery vouchers confirmed by monitoring system PC 9; payment terms table 21, which is described hereinafter; and detail group table 22. The above-mentioned computers 5 and 6 can access directly the monitoring system 9 and can refer, illustratively, to the aforesaid confirmation documents.
Additionally, as disclosed in
As disclosed in
The specification next describes processing in a Witness system constructed as described above.
To begin processing for buying company 1, the user powers up computer 5, enters network user name and password, displays the icon corresponding to this system by, for example, clicking the [OK] indication on the screen, and double-clicks said icon to start the system. The same procedure is followed to start the selling company's computer 6, as well as the Witness PC 9.
The above-described process causes a login screen, as represented in
By entering a user I.D. and network password and activating the login button from this screen, computer 5 (computer 6), for example, checks the user I.D. and password and, if they match, shifts to menu display to display the menu screen. If the cancel button is pressed, the display returns to the previous OS start screen.
First, each button on the start menu is explained. Button 27a is used when directing the system to perform a confirmation request. Button 27b is used when directing the system to perform a payment list inquiry. Button 27c is used to direct the system to look at confirmed data. Button 27d is used to close the program described in the illustrative embodiment. Each button is activated, for example, by manipulating a mouse so as to position the cursor at any one of the buttons 27a-27d, and then double-clicking the mouse button.
As disclosed above, among the processes that buyer company's computer 5 performs are processes J and K, and among those performed by selling company's computer 6 are processes L and M. These processes are specifically explained below.
Confirmation Request Process (Process J):This process is performed by buying company 1 and is carried out based on either a delivery voucher, order voucher, or invoice, any of which serves as a seller record. Specifically, the buying company 1 produces confirmation documents based on a voucher sent to it by selling company 2 and then sends the documents to the monitor.
As
Here, the aforesaid detail button 40b is pressed, and the detail screen depicted in
If, on the other hand, it is determined that the aforesaid delivery voucher, or similar document, and the confirmation document X1 differ substantively (S11 is N (no)), selling company 2 presses NG button 41b, shown in
When this NG response is available (S5 in
The process described above is performed each time a delivery voucher is sent between buying company 1 and selling company 2, and several authentication documents are registered in the delivery receipt detail table 20 shown in
Where selling company 2 determines that there are no substantive errors as between its delivery voucher and the confirmation document X1, and selling company 2 sends a confirmation response to the Witness PC 9, the Witness PC 9 confirms the content of the input data (S5 and S6, shown in
To refer in this state to data that have been confirmed and registered in the receipt detail table 20, the user presses the confirmed data list button 7c, thereby shifting the display from the start menu configuration to the confirmed data screen represented in
The specification next explains office administration processing. Office administration processing (process L) includes payment corrections, payment detail display, and like varieties of administrative processing. The payment correction process involves the correction of price or description of goods, pursuant to an indication of discrepancy made by selling company 2. Price establishment processes comprise, illustratively, responsive processes that are performed by confirming a detailed payment statement made by the Witness 3, and processes for outputting detailed payment statements that buying company 1 itself has made. These processes are specifically explained below.
Displayed on this detailed list screen are the delivery date recorded on the payment voucher, voucher number, store name, wholesale price, and discount rate. An operator can specify another payment voucher about which information is desired, and, by pressing detail button 44a, can shift to the detail screen shown in
The illustration in
In this case, the system would refer to registered confirmation data residing in the receipts detail table 20. Specifically, by pushing the confirmed data button 7c from the start menu shown in
Making of the detailed payment statement is undertaken, for example, by the Witness 3, and completed by referring to the payment terms table 21. According to prior arrangement between buying company 1 and the Witness 3, or between selling company 2 and the Witness 3, information such as closing date, payment date, and deposit account number are for each company registered in the payment terms table. Additionally, each detail is numbered, and, to make data checking more convenient for buying company 1 and selling company 2, a detail group table 22, which groups the detail numbers, is provided.
Next, the Witness 3 specifies the deposit account of the accounting department (i.e., a designated bank) and makes a request for deposit, based on the aforesaid detailed payment statement (see FIG. 9(7)). Here, using
Documents authenticated in the above-described manner are registered in the Witness server 8. First, the Witness 3 makes the detailed payment statement based on data registered in the receipts detail table 20 and then requests confirmation from buying company 1 (see FIG. 21(1)). Buying company 1 confirms the detailed payment statement sent to it and returns the statement as its request for funds transfer (see FIG. 21(2)). At this time, a delivery voucher index corresponding to the detailed payment statement is assigned to said statement.
The aforesaid funds transfer request is delivered to the Witness 3 and forwarded to a bank (not shown in the instant drawing) (see
By undertaking processing as described above, neither buying company 1 nor selling company 2 is required to hold several vouchers or invoices. Additionally, it is possible to perform efficient account settlement using data shared with the Witness server 9,
First Alternate EmbodimentThe specification next describes the first alternate embodiment of the present invention. If buying company 1 and selling company 2 were to change places, processing efficiency would be impaired if respective detailed payment statements were made in the same manner as that contemplated in the preferred embodiment. This illustrative embodiment performs set-off processing and makes a detailed payment statement (suitable to the aforesaid contingency).
Accordingly, the system structure disclosed in
The payment amount relating to mutual trade between buying company 1 and selling company 2 is thus set-off according to the above calculation, and, in the preceding illustration, if the total money amount carries a positive (+) value, buying company 1 pays to selling company 2 the resultant money amount (ST4 is Y (yes), ST5). If, on the other hand, the total money amount carries a negative (−) value, selling company 2 pays to buying company 1 the resultant total money amount (ST4 is N (no), ST6).
The money amount thus derived is reduced to a detailed payment statement, and, as described above, the Witness 3 specifies the accounting department (i.e., a designated bank) receiving account and executes a funds transfer request based on the aforesaid detailed payment statement (see
Set-off for payment amounts as between buying company 1 and selling company 2 is not limited to the foregoing illustrative embodiment, but is amenable to other methods as well.
Second Alternate EmbodimentThe specification next describes the second alternate embodiment of the present invention.
The second alternate embodiment is an invention for safely performing account settlement in an account settlement system utilizing the Witness. This illustrative embodiment performs processing in accordance with authentication numbers after authenticating buying company 1 and selling company 2 in advance. Furthermore, the illustrative embodiment encodes data sent and received between buying company 1 and the Witness, or, alternatively, between selling company 2 and the Witness, and ensures the protection of data. This illustrative embodiment is explained below.
The Witness server 8 consists, among other things, of: detailed receipts table 20, which stores notarization documents, illustratively comprising delivery receipts notarized by the Witness PC 9; payment terms table 21; and detailed group table 22. The aforesaid computer 5 and computer 6 can access directly the Witness server 8, to refer to the above-mentioned notarization documents and like documents.
As disclosed in
The authentication authority 24 executes authentication of certification requests issued in regard to the corporate certificate acquisition processes (viz., process A and E) undertaken by buying company's and selling company's computers (computer 5 and computer 6, respectively). Similarly, the notarization authority 7 performs notarization of certificate issue registration requests issued in regard to company registration processing (viz., process B and F) carried out by buying company's and selling company's computers (computers 5 and 6, respectively).
In this illustrative embodiment, computers 5 and 6 and the Witness PC 9 are powered up, and the Witness system program is started.
Through this process, a login screen, represented in
As shown in
As described above, buying company's computer 5 performs processes A through D, and selling company's computer 6 performs processes E through H. These processes are described specifically below.
Company Certificate Acquisition Processes (Processes A Through E)
These are processes for admission to the system and must be performed initially when, for example, this system is adopted. Designation of these processes is accomplished by selecting the company certificate acquisition bar in the menu screen shown in
Next, if there are no problems with respect to the entered company registration I.D., authentication authority's URL, or server name, the certificate request button 12a is pressed, producing the confirmation number display screen. When the quit button 12b is pressed, the display restores the initial menu shown in
Company registration processing is performed after company certificate acquisition processing is completed as described above.
Next, if there is no problem with, illustratively, the designated company registration I.D., the notarization authority 7 URL, and server name, registration number button 16a is pushed, producing the terms screen for the notarization authority 7. Pressing the quit button 16b restores the start menu screen.
The notarization authority 7 registers companies with the Witness server, pursuant to the above-described process.
Company List DisplayOnce each company has, as described above, executed registration with the notarization authority 7 and the authentication authority 8, registration data for a plurality of companies are registered in the Witness server 9. Then, pursuant to user designations, the system is capable of displaying a list of registered companies.
This company list is displayed by pressing the company information bar 11c from the start menu.
When the authentication process for companies participating in the system (e.g., buying company 1 and selling company 2) is completed, an encoding process is next performed.
Notarization Request Process (Process C)This is a process performed by buying company 1 and is carried out based on such seller records as a delivery voucher, an order voucher, or an invoice. Specifically, it is a process wherein buying company 1 makes notarization documents, based on any one of the vouchers sent to it by selling company 2, and seeks notarization from the Witness 3.
It is
First, store A delivers foodstuffs to supermarket B, the buying company, and contemporaneously sends (or tenders on site) a delivery voucher. Selling company 1 (supermarket B in this example) prepares data for use as a notarization document Y. Included in the notarization document Y are the deliverer's name (selling company 2 in this example), delivery date, description of delivered goods, and delivery price. Illustrative entries are as follows: deliverer's name/“store A”; delivery date/“Feb. 10, 1998”; description of delivered goods/“tuna”; delivery price/“15,000 yen”. The notarization document Y is transmitted from buying company 1 to the Witness 3 (see FIG. 40(1)). The notarization document Y sent from buying company 1 to selling company 2 is first encoded.
The totality of transmission data sent from company U to company V is secured by locking with company U's secrecy key (SKU) a (message) to which a hash function (SHA) has been applied. This is further locked by DEK, which, in turn, is further secured by locking DEK corresponding to DES with company V's public access key (PVK). Locking with company V's public access key (PKV) ensures that the body of transmission data is susceptible of deciphering by company V only. Specifically, the body of transmission data is sent from buying company 1 to selling company 2.
Notarized Data Confirmation Process (Process G)Next, the Witness 3 sends the aforesaid notarization document Y to selling company 2, the sender of the delivery voucher, and executes a confirmation request (see FIG. 40(3)). Selling company 2 compares the content of the notarization document Y transmitted from the Witness 3 with, illustratively, the content of a delivery voucher that selling company 2 itself issued, checking for errors. The above-described data is unlocked by means of the aforesaid public access key.
Selling company 2, which has received the totality of transmission data, first unlocks the data with the secrecy key (SKV) corresponding to the public access key (PKA), obtains the DEK, unlocks the DES by means of the DEK, and then, as described above, utilizes buying company's public access key.
The confirmation task is, as above explained, performed by selling company 2. A buying company to which selling company 2 delivers goods is, however, not limited to the company prescribed above (buying company 1). (Accordingly, when performing the aforesaid confirmation task, selling company 2 presses the notarization request confirmation button 10a in the computer 6 start menu (see
When the detail button 20b is thus pressed and the detail screen displayed, the detail screen depicted in
The confirmation response sent by selling company 2 to the Witness 3 corresponds to that which is designated “b” in
If it is determined that the content of the notarization document Y1 is not in accord with, illustratively, the content of a delivery voucher, confirmation NG button 21b shown in
Once the Witness 3 has a confirmation response from selling company 2, it transmits to selling company 2 and buying company 2 a confirmed certificate relating to the notarization document Y1 (see FIG. 9(6)).
The certificate that selling company 2 sends at this time to the Witness 3 corresponds to that which is designated as “c” in
Thus, decoded information sent from the Witness 3 constitutes a certificate that has been confirmed mutually by buying company 1 and selling company 2, and further constitutes a notarization document certifying that there are no substantive errors in the authentication document based, illustratively, on a delivery voucher. As the notarization process is thus completed, a plurality of certificates are registered in the receipts detail table 20.
System users can consult notarized, registered data residing in the receipts detail table 20 by pressing start menu (see
Office Administrations Processes (Processes D and H)
Next, the specification describes the office administration processes. Among the office administration processes (process D) are payment correction, payment detail display, and various varieties of like processes. Payment correction facilitates correction, for example, to the price or description of goods appearing in the authentication document, pursuant to notification of error received from selling company 2. Price settlement includes, for example, a response process executed by confirming detailed payment statements prepared by the Witness 3, and a process wherein detailed payment statements prepared by buying company 1 itself are output. These processes are explained specifically below.
The delivery date relating to the payment voucher, voucher number, store name, wholesale price, and discount rate, are displayed on this detailed list screen. By specifying a payment voucher about which more information is desired and pressing detail button 24a, the operator can shift to the detail screen represented in
In this case, the operator would review the notarized, registered data residing in the receipts detail table 20. Specifically, the operator displays the aforesaid list screen shown in
The detailed payment statement, which, by way of illustration, can be prepared by the Witness 3, is produced with reference to the payment terms table 21. Due date, payment date, receiving account, and like information are for each company registered in the payment terms table 21, by prior arrangement between buying company 1 and the Witness, or between selling company 2 and the Witness 3. Furthermore, each detail is assigned a detail number in the receipts detail table 20, and, for convenient review by either buying company 1 or selling company 2, a group table 22, grouping detail numbers, is prepared.
Based on the aforesaid detailed payment statement, the Witness 3 next specifies the accounting department (i.e., a designated bank) receiving account and executes a funds transfer request (see FIG. 40(′)).
The Witness 3 prepares the detailed payment statement based on the data registered in the receipts detail table 20 and requests confirmation from buying company 1 (see FIG. 49(1)). Buying company 1 confirms the detailed payment statement sent to it by the Witness 3 and returns said detailed payment statement as a funds transfer request (see FIG. 49(2)). At this time, a delivery voucher index corresponding to the detailed payment statement in question is assigned to said detailed payment statement.
The above-described funds transfer request is delivered to the Witness 3, via the notarization authority 7 (see
By performing processing as described above, buying company 1 and selling company 2 are not required to hold several delivery vouchers and invoices and can execute efficient account settlement processing by sharing and using information provided by the Witness server 9.
Data transmitted (sent and received) among buying company 1, selling company 2, the notarization authority 7, and the Witness, are encoded and prepared as necessary to suit their respective transmission purposes. The illustrative data shown in
Although the explanation of this illustrative embodiment does not touch upon the set-off process, said process can be implemented as set forth in the description of the previous illustrative embodiment.
Third Alternate EmbodimentThis portion of the specification describes the third alternate embodiment.
This illustrative embodiment is directed particularly to account settlement by means of check or draft (note), and can be implemented through systems based on both the above-described preferred and first alternate embodiments. Each contingency, viz., check and draft (note), is explained below.
First, buying company 2 (payor) issues a check. In the illustrative case, buying company 3 (payor), wishing to issue a check in payment for goods, must obtain a check by requesting that its transacting bank X issue a check (see FIG. 51(1)). Bank X examines the applicant's eligibility and, when it is determined that a check ought to issue, the bank registers with the administration center 50 the issuance of a check to buying company 1 (see FIG. 51(2) and simultaneously authorizes buying company 1 to issue a check (see FIG. 51(3)).
Having so obtained the check, buying company 1 uses the check in payment for goods and tenders the check, on which are recorded the payee's name and the money amount, to selling company 2 (payee) (see FIG. 51(4)). Selling company 2 takes the check it has received to the aforesaid transacting bank X and requests payment (see FIG. 51(5)).
Transacting bank X inquires of the administration system regarding the check presented to it and, in addition to confirming its validity, registers said check as paid by means of a payment notification (see FIG. 51(6)). Transacting bank X thereafter utilizes an inter-bank system to move funds to the specified account at the designated transacting bank (bank Y in this illustration), and bank Y then dispatches to selling company 2 notification of collection (see FIG. 51(7)).
In this illustrative embodiment, the administration center is composed of a notarization authority and a Witness (system). The system undertakes check administration in the above-described network. Selling company 2 is the entity requesting that funds be transferred to bank Y.
Processing of Drafts (Notes)This portion of the specification explains the embodiment in the case of drafts (notes).
First, buying company 1 receives from transacting bank X authorization to issue a draft (note) (see FIG. 52(1)). Next, buying company 2 registers issuance of a draft with the administration center 53, at the time buying company desires to issue said draft (see FIG. 52(2)). The administration center 53 registers this information and notifies buying company 1 of the registration number (see FIG. 52(3)).
Buying company 1 adds to the registration number it has received a draw date, a drawee (payor), and a drawer (payee), and sends this information to selling company 2 (drawer) (see
Bank Y confirms the information in said draft (note) with the administration center 53 and, further, registers with the administration center 53 the fact that bank Y itself is to be the drawer (payee) (see FIG. 52(6)). Also, bank Y pays a discounted amount to selling company 2 (see FIG. 52(7)).
Lastly, as the (payment) date approaches and the draft (note) is converted into currency, a settlement demand is tendered to the issuing bank (see FIG. 52(8)), and bank X, which receives the settlement demand, uses the aforesaid inter-bank exchange system to move funds to the account at bank Y. Bank Y then provides notification of completion to the administration center 53 (see FIG. 52(9)).
The administration center 53 for processes executed in this illustrative embodiment comprises a notarization authority 54 and a Witness 55. The draft (note) administration flow for this illustrative embodiment, also, is performed as described above. The Witness system can be used for this illustrative embodiment, as well.
The following benefits are derived from the present invention. Through means of a single invention, the Witness stores (stores in memory/holds in memory) and manages data relating, illustratively, to order vouchers and delivery vouchers, thus facilitating the preparation of accurate detailed payment statements. Additionally, because both Buyer and Seller can freely review detailed payment statements so prepared, it is not particularly necessary for Buyer or Seller to hold order vouchers and delivery vouchers. It is therefore unnecessary to perform the complicated task of arranging (organizing) various vouchers.
In contrast to conventional settlement methods wherein Buyer prepares payment details while confirming order vouchers or delivery vouchers, it is no longer necessary for Seller to undertake the difficult task of confirming said payment details. Furthermore, system safety is ensured because eligibility to participate in the system is verified, and because the exchange (transfer) of information is executed with encoded data.
Claims
1. A method of exchanging sales data between a buyer and a seller using a witness system, comprising:
- transmitting a confirmation document to the witness system from a buyer in response to receipt of seller records corresponding to sold items delivered by a seller, the confirmation document indicating a selected sale and corresponding sales data among seller records received by the buyer;
- automatically determining delivery vouchers of the seller corresponding to the selected sale of the seller records included in the confirmation document; and
- authenticating the confirmation document with the delivery vouchers of the seller via the witness system.
2. A method of exchanging sales data between a buyer and a seller using a witness system, comprising:
- enabling the buyer to select a single sale record including corresponding sales data of at least one item from seller records of sold items delivered by the seller and creating a confirmation document including the single sale record; and
- automatically determining delivery vouchers of the seller corresponding to the selected single sale record in the confirmation document and authenticating the confirmation document based on a comparison of the delivery vouchers with the confirmation document via the witness system.
Type: Application
Filed: Jul 10, 2008
Publication Date: Mar 5, 2009
Applicant: FUJITSU LIMITED (Kanagawa)
Inventors: Hajime Kojima (Kanagawa), Toshihiko Kaji (Kanagawa), Yasuharu Ito (Kanagawa)
Application Number: 12/216,793
International Classification: G06Q 10/00 (20060101); G06Q 30/00 (20060101);