JP4554590B2 - Transaction proving apparatus and method in network environment - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To guarantee the security of transaction to be performed among users, by utilizing a communications network. <P>SOLUTION: A transaction document M, describing the contents of transaction between users A and B, is created and an electronic signature SA(M) of user A and an electronic signature SB(M) of user B for the document are created. Then, the signatures are sent to the notary equipment of notary public N, together with the transaction document M, and the users A and B and the notary public N share the information. Thus, the notary public N, who is the third-party, can objectively prove the contents and the like of the transaction. <P>COPYRIGHT: (C)2007,JPO&amp;INPIT

Description

  The present invention relates to a transaction proving apparatus and method for objectively proving matters relating to transactions such as the contents of transactions performed between two or more parties using a communication network.

  Today, with the spread of the Internet and personal computers, various transactions are being performed between computers via a communication network. However, since basically anyone can freely access the Internet, it is difficult to verify the identity of the communication partner, and transmission data may be stolen or falsified.

For this reason, in order to conduct full-scale business transactions in a network environment, it is indispensable to devise such measures to prevent fraud. Conventional fraud prevention methods include, for example, the following.
(A) Electronic transaction method (Patent Document 1)
When the signer creates his / her own electronic signature (electronic seal), date data indicating the grace period of the electronic signature is added to a predetermined position of the authentication data. As a result, the time limit of the response is clearly indicated to the certifier who has received the electronic signature, and if there is no response before the time limit, the transaction is canceled and the transmitted electronic signature is invalidated.

If the signer does not get a response after the grace period, the signer can revoke the electronic signature by delivering the fact to the notary with the electronic signature. Thereby, even when the authenticator of the electronic signature takes away without returning a response or when the authenticator transmits an illegal signature, the misuse of the electronic signature can be prevented.
(B) Electronic notarization method and apparatus (Patent Document 2)
When data is supplied to the electronic notary device from a party that wishes to prove that the data is authentic, the date generator generates date information that specifies a point in time that the party cannot change. Then, the data contents and date / time information are encrypted by an encryption device, and authenticity data on which the date / time is printed is output from the notary device. Thereby, it can be confirmed that the document or electronically recorded data has not been changed since the date and time of printing, and the authenticity of the document can be notarized electronically.
JP-A-62-056043 Japanese Patent Laid-Open No. 06-014018

However, the conventional fraud prevention methods as described above have the following problems.
According to the electronic transaction method, the expiration date of the electronic signature can be notified to the trading partner to prevent its abuse. However, this makes it impossible to confirm the trading partner or prevent tampering of the transaction contents.

Also, according to the electronic notary method, the notarization apparatus can notarize the authenticity electronically by adding date and time information to the document. However, since this notarization device proves the authenticity of data input by a single party, it cannot determine whether the data has been tampered with before input. Therefore, in the case of a transaction document or the like between two parties, as a result, there is a possibility that illegal contents are output as genuine data.

Accordingly, there is a possibility that a malicious user may misrepresent the contents of the transaction, and there is a problem that the commercial transaction using the network is not always performed safely.
By the way, the management form of the transaction at the merchandise office is as follows. All transactions for futures and other commodities are conducted at merchandise stores. The party of the transaction becomes a member of the transaction office and holds a fixed amount of deposit in advance. And if fraud is done, the deposit will be confiscated.

However, transactions at merchandise stores are different from general business transactions, and it is difficult to directly apply to business transactions on a network.
An object of the present invention is to provide a transaction certifying apparatus and method for assuring the safety of a transaction performed between two or more parties using a communication network.

  FIG. 1 is a principle diagram of the transaction proof system of the present invention. The transaction proof system in FIG. 1 includes a transaction proof device 1, a first user terminal device 2, and a second user terminal device 3, and performs information processing related to transactions performed between a plurality of users. The transaction certifying device 1 and the terminal devices 2 and 3 are coupled to each other by a communication network 4.

  The terminal device 2 creates the electronic signature data 8 of the first user for the transaction document data describing matters relating to the transaction between the first user and the second user, and the terminal device 3 generates the transaction document data for the transaction document data. The electronic signature data 9 of the second user is created. These electronic signature data 8 and 9 are transmitted to the transaction certification apparatus 1 via the network 4.

  The transaction certifying device 1 corresponds to a third party information processing device, and includes a communication unit 5, a processing unit 6, and a storage unit 7. The communication means 5 is connected to the network 4 and receives the electronic signature data 8 of the first user and the electronic signature data 9 of the second user from the network 4.

  The processing means 6 verifies the electronic signature data 8 of the first user and the electronic signature data 9 of the second user, and the storage means 7 stores the electronic signature data 8 of the first user and the electronic signature of the second user. Data 9 is stored.

  The electronic signature is information created by encrypting data by some method using a secret key known only to the sender of the data. Here, the electronic signature data 8 of the first user is created using the private key of the first user, and the electronic signature data 9 of the second user is created using the private key of the second user. The

  Since the user's electronic signature can only be created by the user himself / herself, when the user's electronic signature is applied to the transaction document data, it is considered that the transaction content has been approved by the user.

  When the processing means 6 receives these electronic signature data 8 and 9 via the communication means 5, the processing means 6 decrypts the electronic signature data 8 and 9 using the public key of the first user and the public key of the second user, respectively. And verify their contents.

If both contents are the same, it is considered that both the first and second users have agreed to the transaction, and the electronic signature data 8 and 9 are stored in the storage means 7 as evidence thereof. If the two contents are different, the transaction is regarded as unsuccessful, and an error notification is sent to the terminal devices 2 and 3.

  In this way, if the third party transaction certifying apparatus 1 different from the party of the transaction keeps the electronic signature data 8 and 9, the fact that the transaction has been established and its contents can be communicated to others at any time. It becomes possible to prove. Therefore, it becomes impossible for the first and second users who are parties of the transaction to fake matters relating to the transaction, and the safety of the transaction in the network environment is objectively guaranteed.

  For example, the transaction certifying device 1 in FIG. 1 corresponds to the notarization device 11 in FIG. 3 of the embodiment, the communication means 5 corresponds to the network connection device 27 in FIG. 4, and the processing means 6 is a CPU 21 (central processing unit). Corresponding to the memory 22, the storage means 7 corresponds to the memory 22 or the external storage device 25.

  Another transaction proving apparatus of the present invention includes a communication unit, a processing unit, a first storage unit, and a second storage unit, and performs information processing related to a transaction performed between a plurality of users. The communication means is connected to a communication network, and is encrypted data for transaction document data describing matters relating to a transaction between the first user and the second user. The user's electronic signature data is received from the network. The first storage means stores the received electronic signature data of the first user and the electronic signature data of the second user. The processing means decrypts the electronic signature data of the first user and the electronic signature data of the second user, respectively, and determines the validity of the electronic signature data of those users. The second storage means stores the electronic signature data of the first user determined to be valid and the electronic signature data of the second user.

  Still another transaction proving apparatus according to the present invention includes a communication unit, a processing unit, a first storage unit, and a second storage unit, and performs information processing related to a transaction performed between a plurality of users. The communication means is encrypted data created for the electronic signature data of the first user corresponding to the transaction document data that is connected to the communication network and describes matters relating to the transaction between the first user and the second user. The electronic signature data of a second user is received from the network. The first storage means stores the received electronic signature data of the second user. The processing means decrypts the electronic signature data of the second user and determines the validity of the electronic signature data. The second storage means stores the electronic signature data of the second user determined to be valid.

  Still another transaction proving apparatus according to the present invention includes a communication unit, a processing unit, a first storage unit, and a second storage unit, and performs information processing related to a transaction performed between a plurality of users. The communication means is connected to the communication network, and receives from the network the transaction information of the first user and the transaction information of the second user describing matters relating to the transaction between the first user and the second user. . The first storage means stores the received first user transaction information and second user transaction information. The processing means determines whether or not the contents of the first user's transaction information and the second user's transaction information match. When the contents of the transaction information match, the second storage means stores the transaction information.

Another terminal device of the present invention includes a communication unit, a processing unit, a first storage unit, and a second storage unit, and performs information processing related to a transaction performed between a plurality of users. The first storage means stores transaction document data describing matters relating to transactions between the first user and the second user. The processing means encrypts the transaction document data and creates electronic signature data of the first user for the transaction document data. The communication means is connected to a communication network, transmits the created electronic signature data of the first user to the transaction certification apparatus via the network, and is the electronic signature data of the second user for the transaction document data. Electronic signature data determined to be valid by the certification device is received from the transaction certification device via the network. The second storage means stores the created electronic signature data of the first user and the received electronic signature data of the second user.

  Still another terminal device according to the present invention includes a communication unit, a processing unit, a first storage unit, and a second storage unit, and performs information processing related to transactions performed between a plurality of users. The first storage means stores transaction document data describing matters relating to transactions between the first user and the second user. The processing means encrypts the transaction document data and creates electronic signature data of the first user for the transaction document data. The communication means is connected to the communication network, receives the electronic signature data of the second user for the transaction document data from the second user via the network, and receives the generated electronic signature data of the first user and the received second user signature data. The electronic signature data of the first user is transmitted to the transaction certification apparatus that determines the validity of the electronic signature data of the first user and the electronic signature data of the second user via the network. The second storage means stores the created electronic signature data of the first user and the received electronic signature data of the second user.

  Still another terminal device according to the present invention includes a communication unit, a processing unit, a first storage unit, and a second storage unit, and performs information processing related to transactions performed between a plurality of users. The first storage means stores the transaction contents between the first user and the second user, and date / time information received from the transaction certification apparatus via the communication network. The processing means creates transaction information for the first user by linking the transaction contents and date information. The communication means is connected to the network, transmits the created first user transaction information to the transaction certification device via the network, and the transaction certification device determines that the content matches the transaction information of the second user. The transaction information of one user is received from the transaction certification apparatus via the network. The second storage means stores the received transaction information.

  Still another terminal device according to the present invention includes a communication unit, a processing unit, a first storage unit, and a second storage unit, and performs information processing related to transactions performed between a plurality of users. The first storage means stores the transaction contents between the first user and the second user, and date / time information received from the transaction certification apparatus via the communication network. The processing means creates transaction information for the first user by linking the transaction contents and date information. The communication means is connected to the network, receives transaction information of the second user from the second user via the network, and creates the generated transaction information of the first user and the received transaction information of the second user, It is sent to the transaction certifying device via the network. The second storage means stores the created transaction information of the first user.

  According to the present invention, in a network environment in which a plurality of information processing apparatuses are connected to each other, a third party objectively proves matters relating to the transaction such as the contents, date and time, and the identity of the other party of the transaction performed between users. be able to. Therefore, the safety of the transaction in the network environment is automatically guaranteed.

The best mode for carrying out the present invention will be described below in detail with reference to the drawings.
A commercial transaction is generally based on an agreement between two parties. However, in order to objectively prove that the parties have agreed, a “trusted third party” is required. This is because in a transaction between only two parties, one side can fake the fact.

  In this embodiment, this “trusted third party” is referred to as “notary public” or “notarization authority”, and the transaction certificate guarantees that the notary can safely conduct business transactions in the network environment. The system will be called a transaction notary system.

In order to conduct secure business transactions in a network environment, the transaction notary system needs to provide the following services.
(1) Identity guarantee service The notary guarantees the identity of the other party. As a result, a false trading partner can be detected.
(2) Date / Time Guarantee Service Guarantees the date and time the notary trades. As a result, the date and time of the transaction cannot be falsified.
(3) Uniqueness guarantee service The notary guarantees the uniqueness of the transaction. This prevents confusion with other transactions.
(4) Delivery guarantee service Notary guarantees that the transaction information is delivered reliably. As a result, it is not false that the sender of the transaction information has transmitted the information, and the receiver of the transaction information is also not false to have received the information. Further, when the transaction information is not delivered, it is possible to detect where it was not delivered.
(5) Content Guarantee Service The notary guarantees the contents of the transaction. Thereby, it can be detected that the content has been tampered with. In addition, the contents of the transaction can be referred to whenever necessary.
(6) Transaction Guarantee Service A notary guarantees that a particular party has traded. This prevents the parties from misrepresenting the transaction.

  FIG. 2 shows a business transaction environment between two parties on a network. In FIG. 2, for example, party A is the first sender of the transaction information, and party B is the receiver of the transaction information. The parties A and B exchange transaction information such as sales contracts and the like using a communication network such as the Internet, and perform business transactions. The notary public N individually exchanges transaction information with the parties A and B, confirms them, and guarantees the safety of the transaction.

  FIG. 3 is a configuration diagram of a transaction notary system for realizing the business transaction environment as shown in FIG. The transaction notary system of FIG. 3 includes a notary device 11 which is an information processing device of a notary N, and computer terminals 12A, 12B, 12C, 12D,... Of users A, B, C, D,. The notary device 11 and the terminals 12A, 12B, 12C, 12D,... Are coupled to each other via the communication network 13.

  FIG. 4 is a configuration diagram of an information processing device used as the notary device 11 and the user terminals 12A, 12B, 12C, and 12D. 4 includes a CPU 21, a memory 22, an input device 23, an output device 24, an external storage device 25, a medium drive device 26, and a network connection device 27, and these devices are coupled to each other by a bus 28. Yes.

  The CPU 21 executes the program while using the memory 22 to realize the above-described services. As the memory 22, for example, a ROM (read only memory), a RAM (random access memory), or the like is used. The memory 22 stores the above-described program and data necessary for processing.

  The input device 22 corresponds to, for example, a keyboard, a pointing device, and the like, and is used for inputting requests and instructions from the user. The output device 24 corresponds to a display device, a printer, or the like, and is used to output transaction information.

  The external storage device 25 is, for example, a magnetic disk device, an optical disk device, a magneto-optical disk device, or the like. The above-described program and data can be stored in the external storage device 25 and can be loaded into the memory 22 and used as necessary. The external storage device 25 is also used as a database for storing transaction information.

  The medium driving device 26 can drive the portable recording medium 29 and access the stored contents. As the portable recording medium 29, any computer-readable recording medium such as a memory card, a floppy (registered trademark) disk, a CD-ROM (compact disk read only memory), an optical disk, or a magneto-optical disk can be used. . The above-described program and data are stored in this portable recording medium 29, and can be loaded into the memory 22 and used as necessary.

  The network connection device 27 is connected to the communication network 13 and performs data conversion associated with communication. The information processing apparatus can transmit and receive transaction information and the like via the network connection apparatus 27. Further, the information processing apparatus can communicate with an external information provider database 30 or the like as necessary to receive the above-described program and data from the database 30 and load them into the memory 22 for use. .

  By the way, among the above-mentioned services, the identity guarantee service corresponds to a seal certification service in today's society. The seal certification service is a service that guarantees the identity of the parties to the transaction. The parties register their seals at the government office, and prove their identity by stamping red on the transaction document.

  In order to implement this service on the network, the notary public N verifies the validity of the electronic signature. The electronic signature is information created by encrypting data by some method using a secret key known only to the sender of the data. Since this information can only be generated by the person himself / herself, it plays the same role as the seal stamp on the network environment.

  Specifically, ITU (International Telecommunication Union) X. The certificate authority framework recommended in 509 can be used. According to this framework, in order to confirm the identity of the parties, it is only necessary to decrypt the electronic signature using the public key in the certificate issued by the certificate authority and verify the contents. . The private key used for generating the electronic signature is paired with the public key described in the certificate, and data encrypted with the private key can be decrypted with the public key.

  Further, the notary public N provides a date / time guarantee service by issuing date / time information representing the date and time of the transaction to the parties. This guarantees the date and time of the transaction and avoids confusion with past transaction contents between the same parties.

  Further, the notary public N provides a uniqueness guarantee service by issuing a transaction ID as a transaction identifier to the parties. Thereby, each transaction is correctly identified, and confusion with other transaction contents can be avoided.

The delivery guarantee service can be realized by using a non-repudiation mechanism standardized by ISO (International Standardization Organization) / IEC (International Electrotechnical Commission) CD13888-1,2,3. This non-repudiation mechanism certifies that the message has been delivered by issuing token information as evidence of delivery and confirming it according to the user's request. Hereinafter, this delivery guarantee service will not be described in detail.

Next, an embodiment of the content guarantee service will be described with reference to FIGS.
In order to guarantee the contents of transaction information exchanged between two parties, the following service requirements can be considered.
[1] In order to ensure that the sender confirms the transaction contents, an electronic signature of the sender is added to the transaction contents.
[2] In order to ensure that the receiver confirms the transaction content, an electronic signature of the receiver is added to the transaction content.
[3] In order to guarantee that the sender and the recipient have finally confirmed the contents of the transaction, transaction information with the electronic signature of the sender and the recipient is sent to the sender, the recipient, and the notary N. Share.
[4] In order to ensure that the transaction contents can be referred to at any time, the notary public N stores the transaction contents.

  In order to satisfy the above requirements, the sender, the receiver, and the notary N need to share the transaction information with the electronic signatures of the sender and the receiver. In FIG. 5, the transaction document M in which the transaction contents are described, the electronic signature SA (M) of the user A and the electronic signature SB (M) of the user B are the users A, B, and the notary public N. Shared by.

  FIG. 6 shows an example of the transaction document M shown in FIG. The transaction document M in FIG. 6 includes date and time information T and transaction ID issued by the notary N in addition to the plaintext P describing the transaction details such as the parties involved in the transaction, the target of the transaction, the transaction amount, the transaction date and time. include. Here, “199960808142356” corresponds to the date / time information T and represents “August 8, 1996 14:23:56”. “4567” indicates that the transaction ID is “0x4567 (hexadecimal number)”.

  The electronic signature SN (T, ID) of N represents the electronic signature of the notary N for the data obtained by concatenating the date / time information T and the transaction ID. Instead of the SN (T, ID), the notary N's electronic signature SN (T) for only the date / time information T and the notary N's electronic signature SN (ID) for only the transaction ID may be added.

As an embodiment of such a content guarantee service, four basic models as shown in FIGS.
In these models, a transaction document M as shown in FIG. 6 is used, and information exchanged between the users A and B and the notary public N is accompanied by the sender's electronic signature. The receiver can verify the identity of the sender by verifying the electronic signature. Accordingly, these models include an identity guarantee service, a date and time guarantee service, and a uniqueness guarantee service.

  FIG. 7 shows a first model of the content guarantee service. In the first model, after the users A and B exchange the transaction contents P online or offline, each transmits the transaction information to the notarization apparatus 11. The processing flow in FIG. 7 is as follows.

P0: User A's terminal 12A receives date and time information T and transaction ID from the notary device 11.
To get.
P0 ′: The terminal 12B of the user B acquires the date information T and the transaction ID from the notarization apparatus 11.

In the processes P0 and P0 ′, the notary device 11 issues the same date and time information T and transaction ID to the users A and B who are parties to the transaction.
P1: The terminal 12A connects the date / time information T, the transaction ID, and the transaction content P to create a transaction document M. Next, the private key SA of the user A is taken out, and an electronic signature SA (M) for the transaction document M is created using it. Then, the data {M, SA (M)} is transmitted to the notarization apparatus 11.

  Any method can be used to create the electronic signature SA (M). For example, there is a method of reducing the amount of data by compressing or hashing the transaction document M with a predetermined compression algorithm and encrypting the obtained data with the secret key SA. Of course, the transaction document M may be encrypted with the secret key SA as it is.

  P1 ′: The terminal 12B connects the date / time information T, the transaction ID, and the transaction content P to create a transaction document M ′. Next, the private key SB of the user B is extracted, and an electronic signature SB (M ′) for the transaction document M ′ is created using the user B's private key SB. Then, the data {M ′, SB (M ′)} is transmitted to the notarization apparatus 11.

  P2: The notary device 11 receives the data {M, SA (M)} and the data {M ′, SB (M ′)}. Then, the public keys PA and PB of the users A and B are taken out, SA (M) is verified with the public key PA, and SB (M ′) is verified with the public key PB.

  For example, when the data amount of the transaction documents M and M ′ in the electronic signatures SA (M) and SB (M ′) is reduced by the compression process and the hash process, the notary apparatus 11 receives the received transaction document. Similar data reduction processing is performed on M and M ′. Then, the obtained data is compared with data obtained by decrypting SA (M) and SB (M ′) with public keys PA and PB, respectively, and the validity of SA (M) and SB (M ′) is compared. To verify.

  If compression processing or hash processing is not performed, it is only necessary to compare the received transaction documents M and M ′ with the decrypted data of SA (M) and SB (M ′). If SA (M) or SB (M ′) is not correct, an error notification is sent to the terminals 12A and 12B, and the process is terminated.

  Next, the notary apparatus 11 confirms whether or not the transaction documents M and M ′ are the same. Specifically, the date / time information T, the transaction ID, and the transaction content P described in these transaction documents are respectively compared to confirm that they match. Also, it is confirmed whether the date / time information T and the transaction ID in the transaction document M match the issued one.

If the transaction documents M and M ′ do not match, or if the date / time information T or the transaction ID is incorrect, an error notification is sent to the terminals 12A and 12B, and the process is terminated.
Next, the notary device 11 concatenates the transaction document M and the electronic signatures SA (M) and SB (M ′) to create data {M, SA (M), SB (M ′)}, save.

P3: The notary device 11 transmits data {M, SA (M), SB (M ′)} to the terminal 12A.
P3 ′: Notarization apparatus 11 transmits data {M, SA (M), SB (M ′)} to terminal 12B.

  P4: The terminal 12A receives the data {M, SA (M), SB (M ′)}. Then, the public keys PA and PB of the users A and B are taken out, SA (M) is verified with the public key PA, and SB (M ′) is verified with the public key PB. Here, if SA (M) or SB (M ′) is not correct, an error is notified to the notary device 11 and the terminal 12B, and the process is terminated.

  Next, the terminal 12A confirms whether or not the transaction document M received from the notarization apparatus 11 is the same as the transaction document M created by the terminal 12A. If the received transaction document M is not correct, an error notification is sent to the notary device 11 and the terminal 12B, and the process is terminated. If it is correct, the data {M, SA (M), SB (M ′)} are saved and the process is terminated.

  P4 ′: The terminal 12B receives the data {M, SA (M), SB (M ′)}. Then, the public keys PA and PB of the users A and B are taken out, SA (M) is verified with the public key PA, and SB (M ′) is verified with the public key PB. Here, if SA (M) or SB (M ′) is not correct, an error notification is sent to the notary device 11 and the terminal 12A, and the process is terminated.

  Next, the terminal 12B confirms whether or not the transaction document M ′ received from the notarization apparatus 11 is the same as the transaction document M ′ created by the terminal 12B. If the received transaction document M ′ is not correct, an error notification is sent to the notary device 11 and the terminal 12A, and the process is terminated. If it is correct, the data {M, SA (M), SB (M ′)} are saved and the process is terminated.

  In such a first model, both the users A and B independently send the transaction information to the notary N, so it can be said that the user A and the user B are in an equal position. In addition, users A and B can receive services simply by attaching their electronic signatures. On the other hand, the notary device 11 must verify the identity of the transaction documents M and M ′ in addition to verifying the electronic signatures of the users A and B.

  However, in this model, when the notary apparatus 11 fails to verify the identity of the transaction documents M and M ′, it cannot be specified which of the users A and B has altered the contents. In addition, there is a possibility that the transaction information is not sent to the notary devices 11 of the user A and the user B at the right time, and the notary device 11 cannot verify them.

  FIG. 8 shows a second model of the content guarantee service. In the second model, after the users A and B exchange the transaction contents P online or offline, only the user A sends the transaction information to the notarization apparatus 11. The processing flow in FIG. 8 is as follows.

P10: The terminal 12A of the user A acquires the date / time information T and the transaction ID from the notarization apparatus 11.
P11: The terminal 12A connects the date / time information T, the transaction ID, and the transaction content P to create a transaction document M. Next, the private key SA of the user A is taken out, and an electronic signature SA (M) for the transaction document M is created using it. Then, data {M, SA (M)} is transmitted to terminal 12B.

  P12: The terminal 12B receives the data {M, SA (M)}. Then, the public key PA of the user A is taken out and used to verify SA (M). Here, if SA (M) is not correct, an error notification is sent to the notary device 11 and the terminal 12A, and the process is terminated.

  Next, the private key SB of the user B is extracted, and an electronic signature SB (M) for the transaction document M is created using the private key SB. Then, data {M, SA (M), SB (M)} is created and stored.

P13: The terminal 12B transmits data {M, SA (M), SB (M)} to the terminal 12A.
P14: The terminal 12A receives the data {M, SA (M), SB (M)}. Then, the public key PB of the user B is taken out and used to verify SB (M). If SB (M) is not correct, an error notification is sent to the notary device 11 and the terminal 12B, and the process is terminated. If it is correct, the data {M, SA (M), SB (M)} is stored.

P15: The terminal 12A transmits the data {M, SA (M), SB (M)} to the notary device 11.
P16: The notary device 11 receives the data {M, SA (M), SB (M)}. Then, the public keys PA and PB of the users A and B are taken out, SA (M) is verified with the public key PA, and SB (M) is verified with the public key PB. If SA (M) or SB (M) is not correct, an error notification is sent to the terminals 12A and 12B, and the process is terminated.

  Next, the notary apparatus 11 confirms whether the date / time information T and the transaction ID in the transaction document M match the issued one. If the date / time information T or the transaction ID is not correct, an error notification is sent to the terminals 12A and 12B, and the process is terminated.

  If the electronic signatures SA (M), SB (M), date / time information T, and transaction ID are correct, the notary device 11 stores the data {M, SA (M), SB (M)} and ends the process. To do.

  In such a second model, since only the user A sends the transaction information to the notary N, the user A can finally decide whether or not to receive the content guarantee service. Therefore, it can be said that the user A is in an advantageous position.

  Further, the user B cannot receive the service unless the transaction document M has the information with the electronic signature of the user A. On the other hand, the user A cannot receive the service without the electronic signature of the user B, but can send the information with the electronic signature of the user B created in the past to the notary public N.

  FIG. 9 shows a third model of the content guarantee service. In the third model, after the users A and B exchange the transaction contents P online or offline, only the user B sends the transaction information to the notarization apparatus 11. The processing flow in FIG. 9 is as follows.

P20: The terminal 12A of the user A acquires the date / time information T and the transaction ID from the notarization apparatus 11.
P21: The terminal 12A creates the transaction document M by connecting the date / time information T, the transaction ID, and the transaction content P. Next, the private key SA of the user A is taken out, and an electronic signature SA (M) for the transaction document M is created using it. Then, data {M, SA (M)} is transmitted to terminal 12B.

  P22: The terminal 12B receives the data {M, SA (M)}. Then, the public key PA of the user A is taken out and used to verify SA (M). Here, if SA (M) is not correct, an error notification is sent to the notary device 11 and the terminal 12A, and the process is terminated.

  Next, the private key SB of the user B is extracted, and an electronic signature SB (M) for the transaction document M is created using the private key SB. Then, data {M, SA (M), SB (M)} is created and stored.

P23: The terminal 12B transmits the data {M, SA (M), SB (M)} to the notary device 11.
P24: The notary apparatus 11 receives the data {M, SA (M), SB (M)}. Then, the public keys PA and PB of the users A and B are taken out, SA (M) is verified with the public key PA, and SB (M) is verified with the public key PB. If SA (M) or SB (M) is not correct, an error notification is sent to the terminals 12A and 12B, and the process is terminated.

  Next, the notary apparatus 11 confirms whether the date / time information T and the transaction ID in the transaction document M match the issued one. If the date / time information T or the transaction ID is not correct, an error notification is sent to the terminals 12A and 12B, and the process is terminated.

If the electronic signatures SA (M), SB (M), date / time information T, and transaction ID are correct, the notary device 11 stores the data {M, SA (M), SB (M)}.
P25: The notary device 11 transmits data {M, SA (M), SB (M)} to the terminal 12A.

  P26: The terminal 12A receives the data {M, SA (M), SB (M)}. Then, the public keys PA and PB of the users A and B are taken out, SA (M) is verified with the public key PA, and SB (M) is verified with the public key PB. Here, if SA (M) or SB (M) is not correct, an error notification is sent to the notary device 11 and the terminal 12B, and the process ends. If they are correct, the data {M, SA (M), SB (M)} are saved and the process is terminated.

  In such a third model, since only the user B sends the transaction information to the notary N, the user B can finally decide whether or not to receive the content guarantee service. Therefore, it can be said that the user B is in an advantageous position. However, the user B cannot receive the service unless the transaction document M has information with the electronic signature of the user A. On the other hand, if the user A does not receive the transaction information from the notary public N, it is not known whether or not the user B has approved.

  FIG. 10 shows a fourth model of the content guarantee service. In the fourth model, the notary device 11 mediates the transaction between the user A and the user B. The processing flow in FIG. 10 is as follows.

P30: The terminal 12A of the user A acquires the date / time information T and the transaction ID from the notarization apparatus 11.
P31: The terminal 12A connects the date / time information T, the transaction ID, and the transaction content P to create a transaction document M. Next, the private key SA of the user A is taken out, and an electronic signature SA (M) for the transaction document M is created using it. And data {M, SA (M
)} To the notarization apparatus 11.

  P32: The notary device 11 receives the data {M, SA (M)}. Then, the public key PA of the user A is taken out and used to verify SA (M). If SA (M) is not correct, an error notification is sent to the terminal 12A and the process is terminated. If it is correct, data {M, SA (M)} is transmitted to terminal 12B.

  P33: The terminal 12B receives the data {M, SA (M)}. The user B looks at the transaction contents P in the received transaction document M. If the transaction cannot be accepted, the user B notifies the terminal 12A to that effect and ends the processing of the terminal 12B. When responding to the transaction, the terminal 12B is instructed to continue the process.

  Next, the terminal 12B takes out the public key PA of the user A and uses it to verify SA (M). Here, if SA (M) is not correct, an error notification is sent to the notary device 11 and the terminal 12A, and the process is terminated.

  Next, the terminal 12B takes out the secret key SB of the user B and uses it to create an electronic signature SB (M) for the transaction document M. Then, data {M, SA (M), SB (M)} is created and stored.

P34: The terminal 12B transmits the data {M, SA (M), SB (M)} to the notary device 11.
P35: The notary device 11 receives the data {M, SA (M), SB (M)}. Then, the public keys PA and PB of the users A and B are taken out, SA (M) is verified with the public key PA, and SB (M) is verified with the public key PB. If SA (M) or SB (M) is not correct, an error notification is sent to the terminals 12A and 12B, and the process is terminated.

  Next, the notary apparatus 11 confirms whether the date / time information T and the transaction ID in the transaction document M match the issued one. If the date / time information T or the transaction ID is not correct, an error notification is sent to the terminals 12A and 12B, and the process is terminated.

If the electronic signatures SA (M), SB (M), date / time information T, and transaction ID are correct, the notary device 11 stores the data {M, SA (M), SB (M)}.
P36: The notary device 11 transmits the data {M, SA (M), SB (M)} to the terminal 12A.

  P37: The terminal 12A receives the data {M, SA (M), SB (M)}. Then, the public keys PA and PB of the users A and B are taken out, SA (M) is verified with the public key PA, and SB (M) is verified with the public key PB. Here, if SA (M) or SB (M) is not correct, an error notification is sent to the notary device 11 and the terminal 12B, and the process ends. If they are correct, the data {M, SA (M), SB (M)} are saved and the process is terminated.

  In such a fourth model, since the notary N mediates the transaction between the user A and the user B, the notary N determines which of the user A and the user B has been tampered with when the transaction contents have been tampered with. Can be identified.

Among the models described above, in the second and third models, since transaction information is exchanged between the user A and the user B, it is necessary to use a public key in order to verify the electronic signature of the sender. Therefore, a public key system such as RSA (Rivest-Shamir-Adleman) encryption is assumed.

  On the other hand, in the first and fourth models, transaction information is exchanged between the user A and the notary N or between the user B and the notary N, and the transaction information is exchanged between the user A and the user B. Not. In this case, the identity guarantee service can be realized even with a secret key system such as DES (Data Encryption Standard) encryption. However, the notary N needs to know the secret keys of the user A and the user B.

Next, an embodiment of the transaction guarantee service will be described with reference to FIGS. In order to guarantee the fact that user A and user B have traded, the following service requirements can be considered.
<1> In order for user A to prove to third party C the fact that he / she traded with user B, an electronic signature of notary public N is attached to information obtained by attaching electronic signature of user B to the transaction document.
<2> In order for the user B to prove to the third party C the fact that he / she traded with the user A, the electronic signature of the notary N is attached to the information obtained by attaching the electronic signature of the user A to the transaction document.
<3> The notary public N and the user B hold the electronic signature of the notary public N with respect to the information obtained by attaching the electronic signature of the user A to the transaction document so that the user A cannot deny the fact of dealing with the user B.
<4> The notary public N and the user A hold the electronic signature of the notary public N for the information obtained by attaching the electronic signature of the user B to the transaction document so that the user B cannot deny the fact of dealing with the user A.

  In order to satisfy the above requirements, the notary N's electronic signature for the information obtained by attaching the electronic signatures of the user A and the user B to the transaction document may be finally shared by the users A, B, and the notary N. . In FIG. 11, the electronic signature SN (M, SA (M), SB) of the notary N for the information obtained by concatenating the transaction document M, the electronic signature SA (M) of the user A, and the electronic signature SB (M) of the user B (M)) is shared by users A and B and notary N.

  Since this transaction guarantee service is closely related to the above-described content guarantee service, it is realized based on the embodiment of the content guarantee service. Corresponding to the four basic models shown in FIGS. 7, 8, 9, and 10, the basic model of the transaction guarantee service is the four models shown in FIGS. 12, 13, 14, and 15.

  In these models, similarly to the content guarantee service, a transaction document M as shown in FIG. 6 is used, and information exchanged between the users A and B and the notary public N is accompanied by an electronic signature of the sender. ing. The receiver can verify the identity of the sender by verifying the electronic signature. Accordingly, these models include an identity guarantee service, a date and time guarantee service, a uniqueness guarantee service, and a content guarantee service.

  FIG. 12 shows a first model of the transaction guarantee service. In the first model, after the users A and B exchange the transaction contents P online or offline, each transmits the transaction information to the notarization apparatus 11. The processing flow in FIG. 12 is as follows.

P40: The terminal 12A of the user A acquires the date / time information T and the transaction ID from the notarization apparatus 11.
P 40 ′: Terminal 12 B of user B acquires date / time information T and transaction ID from notarization apparatus 11.

  P41: The terminal 12A creates the transaction document M by connecting the date / time information T, the transaction ID, and the transaction content P. Next, the private key SA of the user A is taken out, and an electronic signature SA (M) for the transaction document M is created using it. Then, the data {M, SA (M)} is transmitted to the notarization apparatus 11.

  P41 ′: The terminal 12B connects the date / time information T, the transaction ID, and the transaction content P to create a transaction document M ′. Next, the private key SB of the user B is extracted, and an electronic signature SB (M ′) for the transaction document M ′ is created using the user B's private key SB. Then, the data {M ′, SB (M ′)} is transmitted to the notarization apparatus 11.

  P42: The notary device 11 receives the data {M, SA (M)} and the data {M ′, SB (M ′)}. Then, the public keys PA and PB of the users A and B are taken out, SA (M) is verified with the public key PA, and SB (M ′) is verified with the public key PB. If SA (M) or SB (M ′) is not correct, an error notification is sent to the terminals 12A and 12B, and the process is terminated.

  Next, the notary apparatus 11 confirms whether or not the transaction documents M and M ′ are the same. Also, it is confirmed whether the date / time information T and the transaction ID in the transaction document M match the issued one. If the transaction documents M and M ′ do not match, or if the date / time information T or the transaction ID is incorrect, an error notification is sent to the terminals 12A and 12B, and the process is terminated.

  Next, the notarization apparatus 11 concatenates the transaction document M and the electronic signatures SA (M) and SB (M ′) to create data {M, SA (M), SB (M ′)}. Next, the notary N's private key SN is extracted, and using it, the electronic signature SN (M, SA (M), SB (M ′)) for the data {M, SA (M), SB (M ′)} is used. Create Then, the data {M, SA (M), SB (M ′), SN (M, SA (M), SB (M ′))} are stored.

P43: The notary apparatus 11 transmits data {M, SA (M), SB (M ′), SN (M, SA (M), SB (M ′))} to the terminal 12A.
P43 ′: Notarization apparatus 11 transmits data {M, SA (M), SB (M ′), SN (M, SA (M), SB (M ′))} to terminal 12B.

  P44: The terminal 12A receives the data {M, SA (M), SB (M ′), SN (M, SA (M), SB (M ′))}. Then, the public key PN of the notary N is taken out, and the electronic signature SN (M, SA (M), SB (M ′)) is verified using the public key PN. Further, the public keys PA and PB of the users A and B are taken out, and SA (M) is verified with the public key PA, and SB (M ′) is verified with the public key PB. Here, if any one of SN (M, SA (M), SB (M ′)), SA (M), and SB (M ′) is not correct, an error is notified to the notary device 11 and the terminal 12B. Exit.

  Next, the terminal 12A confirms whether or not the transaction document M received from the notarization apparatus 11 is the same as the transaction document M created by the terminal 12A. If the received transaction document M is not correct, an error notification is sent to the notary device 11 and the terminal 12B, and the process is terminated. If it is correct, the data {M, SA (M), SB (M ′), SN (M, SA (M), SB (M ′))} are saved, and the process is terminated.

P44 ′: The terminal 12B receives the data {M, SA (M), SB (M ′), SN (M, SA (M), SB (M ′))}. Then, the public key PN of the notary N is taken out, and the electronic signature SN (M, SA (M), SB (M ′)) is verified using the public key PN. Further, the public keys PA and PB of the users A and B are taken out, and SA (M) is verified with the public key PA, and SB (M ′) is verified with the public key PB. Here, if any of SN (M, SA (M), SB (M ′)), SA (M), and SB (M ′) is not correct, an error is notified to the notary device 11 and the terminal 12A for processing. Exit.

  Next, the terminal 12B confirms whether or not the transaction document M ′ received from the notarization apparatus 11 is the same as the transaction document M ′ created by the terminal 12B. If the received transaction document M ′ is not correct, an error notification is sent to the notary device 11 and the terminal 12A, and the process is terminated. If it is correct, the data {M, SA (M), SB (M ′), SN (M, SA (M), SB (M ′))} are saved, and the process is terminated.

  FIG. 13 shows a second model of the transaction guarantee service. In the second model, after the users A and B exchange the transaction contents P online or offline, only the user A sends the transaction information to the notarization apparatus 11. The processing flow in FIG. 13 is as follows.

P50: The terminal 12A of the user A acquires the date / time information T and the transaction ID from the notarization apparatus 11.
P51: The terminal 12A connects the date / time information T, the transaction ID, and the transaction content P to create a transaction document M. Next, the private key SA of the user A is taken out, and an electronic signature SA (M) for the transaction document M is created using it. Then, data {M, SA (M)} is transmitted to terminal 12B.

  P52: The terminal 12B receives the data {M, SA (M)}. Then, the public key PA of the user A is taken out and used to verify SA (M). Here, if SA (M) is not correct, an error notification is sent to the notary device 11 and the terminal 12A, and the process is terminated.

  Next, the private key SB of the user B is extracted, and an electronic signature SB (M) for the transaction document M is created using the private key SB. Then, data {M, SA (M), SB (M)} is created and stored.

P53: The terminal 12B transmits data {M, SA (M), SB (M)} to the terminal 12A.
P54: The terminal 12A receives the data {M, SA (M), SB (M)}. Then, the public key PB of the user B is taken out and used to verify SB (M). If SB (M) is not correct, an error notification is sent to the notary device 11 and the terminal 12B, and the process is terminated. If it is correct, the data {M, SA (M), SB (M)} is stored.

P55: The terminal 12A transmits the data {M, SA (M), SB (M)} to the notary device 11.
P56: The notary apparatus 11 receives the data {M, SA (M), SB (M)}. Then, the public keys PA and PB of the users A and B are taken out, SA (M) is verified with the public key PA, and SB (M) is verified with the public key PB. If SA (M) or SB (M) is not correct, an error notification is sent to the terminals 12A and 12B, and the process is terminated.

Next, the notarization apparatus 11 receives the date / time information T and the transaction ID in the transaction document M as follows:
Check if it matches with the one issued. If the date / time information T or the transaction ID is not correct, an error notification is sent to the terminals 12A and 12B, and the process is terminated.

  Next, the notary device 11 takes out the private key SN of the notary N and uses it to use the electronic signature SN (M, SA (M), SB () for the data {M, SA (M), SB (M)}. M)). Then, data {M, SA (M), SB (M), SN (M, SA (M), SB (M))} are created and stored.

P57: The notary device 11 transmits the electronic signature SN (M, SA (M), SB (M)) to the terminal 12A.
P57 ′: The notary device 11 transmits the electronic signature SN (M, SA (M), SB (M)) to the terminal 12B.

  P58: The terminal 12A receives the electronic signature SN (M, SA (M), SB (M)). Then, the public key PN of the notary N is taken out and used to verify SN (M, SA (M), SB (M)). Here, if SN (M, SA (M), SB (M)) is not correct, an error notification is sent to the notary device 11 and the terminal 12B, and the process is terminated. If it is correct, the electronic signature SN (M, SA (M), SB (M)) is saved, and the process ends.

  P58 ′: The terminal 12B receives the electronic signature SN (M, SA (M), SB (M)). Then, the public key PN of the notary N is taken out and used to verify SN (M, SA (M), SB (M)). Here, if SN (M, SA (M), SB (M)) is not correct, an error notification is sent to the notary device 11 and the terminal 12A, and the process is terminated. If it is correct, the electronic signature SN (M, SA (M), SB (M)) is saved, and the process ends.

  FIG. 14 shows a third model of the transaction guarantee service. In the third model, after the users A and B exchange the transaction contents P online or offline, only the user B sends the transaction information to the notarization apparatus 11. The processing flow in FIG. 14 is as follows.

P60: The terminal 12A of the user A acquires the date / time information T and the transaction ID from the notarization apparatus 11.
P61: The terminal 12A connects the date / time information T, the transaction ID, and the transaction content P to create a transaction document M. Next, the private key SA of the user A is taken out, and an electronic signature SA (M) for the transaction document M is created using it. Then, data {M, SA (M)} is transmitted to terminal 12B.

  P62: The terminal 12B receives the data {M, SA (M)}. Then, the public key PA of the user A is taken out and used to verify SA (M). Here, if SA (M) is not correct, an error notification is sent to the notary device 11 and the terminal 12A, and the process is terminated.

  Next, the private key SB of the user B is extracted, and an electronic signature SB (M) for the transaction document M is created using the private key SB. Then, data {M, SA (M), SB (M)} is created and stored.

P63: The terminal 12B transmits the data {M, SA (M), SB (M)} to the notary device 11.
P64: The notary device 11 receives the data {M, SA (M), SB (M)}. Then, the public keys PA and PB of the users A and B are taken out, SA (M) is verified with the public key PA, and SB (M) is verified with the public key PB. If SA (M) or SB (M) is not correct, an error notification is sent to the terminals 12A and 12B, and the process is terminated.

  Next, the notary apparatus 11 confirms whether the date / time information T and the transaction ID in the transaction document M match the issued one. If the date / time information T or the transaction ID is not correct, an error notification is sent to the terminals 12A and 12B, and the process is terminated.

  Next, the notary device 11 takes out the private key SN of the notary N and uses it to use the electronic signature SN (M, SA (M), SB () for the data {M, SA (M), SB (M)}. M)). Then, data {M, SA (M), SB (M), SN (M, SA (M), SB (M))} are created and stored.

P65: The notary device 11 transmits data {M, SA (M), SB (M), SN (M, SA (M), SB (M))} to the terminal 12A.
P65 ′: The notary device 11 transmits the electronic signature SN (M, SA (M), SB (M)) to the terminal 12B.

  P66: The terminal 12A receives the data {M, SA (M), SB (M), SN (M, SA (M), SB (M))}. Then, the public keys PA, PB, and PN of the users A and B and the notary N are taken out, SA (M) is verified with the public key PA, SB (M) is verified with the public key PB, and SN with the public key PN. (M, SA (M), SB (M)) is verified.

  Here, if any one of SA (M), SB (M), SN (M, SA (M), SB (M)) is not correct, an error notification is sent to the notary device 11 and the terminal 12B, and the process is terminated. To do. If they are correct, the data {M, SA (M), SB (M), SN (M, SA (M), SB (M))} are saved, and the process ends.

  P66 ′: The terminal 12B receives the electronic signature SN (M, SA (M), SB (M)). Then, the public key PN of the notary N is taken out and used to verify SN (M, SA (M), SB (M)). Here, if SN (M, SA (M), SB (M)) is not correct, an error notification is sent to the notary device 11 and the terminal 12A, and the process is terminated. If it is correct, the electronic signature SN (M, SA (M), SB (M)) is saved, and the process ends.

  FIG. 15 shows a fourth model of the transaction guarantee service. In the fourth model, the notary device 11 mediates the transaction between the user A and the user B. The processing flow in FIG. 15 is as follows.

P70: The terminal 12A of the user A acquires the date / time information T and the transaction ID from the notarization apparatus 11.
P71: The terminal 12A creates the transaction document M by connecting the date and time information T, the transaction ID, and the transaction content P. Next, the private key SA of the user A is taken out, and an electronic signature SA (M) for the transaction document M is created using it. Then, the data {M, SA (M)} is transmitted to the notarization apparatus 11.

P72: The notary apparatus 11 receives the data {M, SA (M)}. Then, the public key PA of the user A is taken out and used to verify SA (M). If SA (M) is not correct, an error notification is sent to the terminal 12A and the process is terminated. If it is correct, data {M, SA (M)} is transmitted to terminal 12B.

  P73: The terminal 12B receives the data {M, SA (M)}. The user B looks at the transaction contents P in the received transaction document M. If the transaction cannot be accepted, the user B notifies the terminal 12A to that effect and ends the processing of the terminal 12B. When responding to the transaction, the terminal 12B is instructed to continue the process.

  Next, the terminal 12B takes out the public key PA of the user A and uses it to verify SA (M). Here, if SA (M) is not correct, an error notification is sent to the notary device 11 and the terminal 12A, and the process is terminated.

  Next, the terminal 12B takes out the secret key SB of the user B and uses it to create an electronic signature SB (M) for the transaction document M. Then, data {M, SA (M), SB (M)} is created and stored.

P74: The terminal 12B transmits the data {M, SA (M), SB (M)} to the notary device 11.
P75: The notary apparatus 11 receives the data {M, SA (M), SB (M)}. Then, the public keys PA and PB of the users A and B are taken out, SA (M) is verified with the public key PA, and SB (M) is verified with the public key PB. If SA (M) or SB (M) is not correct, an error notification is sent to the terminals 12A and 12B, and the process is terminated.

  Next, the notary apparatus 11 confirms whether the date / time information T and the transaction ID in the transaction document M match the issued one. If the date / time information T or the transaction ID is not correct, an error notification is sent to the terminals 12A and 12B, and the process is terminated.

  Next, the notary device 11 takes out the private key SN of the notary N and uses it to use the electronic signature SN (M, SA (M), SB () for the data {M, SA (M), SB (M)}. M)). Then, data {M, SA (M), SB (M), SN (M, SA (M), SB (M))} are created and stored.

P76: The notary apparatus 11 transmits data {M, SA (M), SB (M), SN (M, SA (M), SB (M))} to the terminal 12A.
P76 ': The notary device 11 transmits the electronic signature SN (M, SA (M), SB (M)) to the terminal 12B.

  P77: The terminal 12A receives the data {M, SA (M), SB (M), SN (M, SA (M), SB (M))}. Then, the public keys PA, PB, and PN of the users A and B and the notary N are taken out, SA (M) is verified with the public key PA, SB (M) is verified with the public key PB, and SN with the public key PN. (M, SA (M), SB (M)) is verified.

  Here, if any one of SA (M), SB (M), SN (M, SA (M), SB (M)) is not correct, an error notification is sent to the notary device 11 and the terminal 12B, and the process is terminated. To do. If they are correct, the data {M, SA (M), SB (M), SN (M, SA (M), SB (M))} are saved, and the process ends.

P77 ′: The terminal 12B receives the electronic signature SN (M, SA (M), SB (M)).
Then, the public key PN of the notary N is taken out and used to verify SN (M, SA (M), SB (M)). Here, if SN (M, SA (M), SB (M)) is not correct, an error notification is sent to the notary device 11 and the terminal 12A, and the process is terminated. If it is correct, the electronic signature SN (M, SA (M), SB (M)) is saved, and the process ends.

  Next, processing of the notary device 11 and the terminals 12A and 12B in the first model of the transaction guarantee service shown in FIG. 12 will be described again with reference to the flowcharts of FIGS.

  FIG. 16 is a flowchart corresponding to the processes P40 and P41 of the terminal 12A or the processes P40 ′ and P41 ′ of the terminal 12B. When the process is started in FIG. 16, the terminal 12A (or terminal 12B) first acquires the date information T and the transaction ID from the notarization apparatus 11 via the network 13 (step S1).

  Next, the transaction information M (or M ′) as shown in FIG. 6 is created by connecting the date / time information T, the transaction ID, and the transaction content P (step S2). Next, the user's private key SA (or SB) is taken out (step S3), and the electronic signature SA (M) (or SB (M ')) of the user for the transaction document M is created using it (step S4). .

  Then, the transaction document M (or M ′) and the user's electronic signature SA (M) (or SB (M ′)) are transmitted to the notarization apparatus 11 via the network 13 (step S5), and the process ends.

  17 and 18 are flowcharts corresponding to the processes P42, P43, and P43 ′ of the notarization apparatus 11. When the processing is started in FIG. 17, the notary apparatus 11 first receives the transaction document M and the electronic signature SA (M) from the terminal 12A of the user A via the network 13, and receives the transaction document from the terminal 12B of the user B. M ′ and the electronic signature SB (M ′) are received (step S11).

  Next, public keys PA and PB of users A and B are extracted (step S12), SA (M) is verified with public key PA (step S13), and it is determined whether SA (M) is valid (step S13). S14). Here, when the data obtained by decrypting the electronic signature SA (M) with the public key PA is regarded as the same as the transaction document M, the SA (M) becomes valid. If SA (M) is not valid, an error notification is sent to the terminals 12A and 12B (step S19), and the process is terminated.

  If SA (M) is valid, SB (M ′) is verified with the public key PB (step S15), and it is determined whether SB (M ′) is valid (step S16). If SB (M ′) is not valid, an error notification is sent to the terminals 12A and 12B (step S19), and the process is terminated.

  If SB (M ′) is valid, it is next checked whether or not the transaction documents M and M ′ match (step S17). If they do not match, an error notification is sent to the terminals 12A and 12B (step S19), and the process ends.

  If the transaction documents M and M ′ match, then it is confirmed whether the date / time information T and the transaction ID in the transaction document M match those issued (step S18). If the date / time information T or the transaction ID is not correct, an error notification is sent to the terminals 12A and 12B (step S19), and the process is terminated.

  If these are correct, the transaction document M and the electronic signatures SA (M) and SB (M ′) are connected to create data {M, SA (M), SB (M ′)} (FIG. 18). Step S20).

  Next, the private key SN of the notary N is extracted (step S21), and the electronic signature SN (M, SA (M, SA) of the notary N for the data {M, SA (M), SB (M ')} is used by using it. , SB (M ′)) is created (step S22). Then, the transaction document M, the electronic signature SA (M), SB (M ′), and SN (M, SA (M), SB (M ′)) are stored (step S23).

  Then, these data M, SA (M), SB (M ′), SN (M, SA (M), SB (M ′)) are transmitted to the terminals 12A and 12B via the network 13 (step S24), the process is terminated.

  FIG. 19 is a flowchart corresponding to the process P44 of the terminal 12A or the process P44 ′ of the terminal 12B. When the processing is started in FIG. 19, the terminal 12A (or terminal 12B) first sends the transaction document M, the electronic signature SA (M), SB (M ′), SN (M) from the notarization apparatus 11 via the network 13. , SA (M), SB (M ′)) are received (step S31).

  Next, the public key PN of the notary N is extracted (step S32), and the electronic signature SN (M, SA (M), SB (M ′)) of the notary N is verified using the public key PN (step S33). It is determined whether it is valid (step S34). Here, the data obtained by decrypting the electronic signature SN (M, SA (M), SB (M ′)) with the public key PN is regarded as the same as the data {M, SA (M), SB (M ′)}. SN (M, SA (M), SB (M ′)) becomes effective.

  If the electronic signature of the notary N is not valid, an error notification is sent to the notary device 11 and the terminal 12B (or terminal 12A) (step S43), and the process is terminated. If the notary N's electronic signature is valid, then the public key PB (or PA) of the user B (or user A) who is the trading partner is extracted (step S35), and the electronic signature SB of the other party is used by using it. (M ') (or SA (M)) is verified (step S36), and it is determined whether it is valid (step S37). If the electronic signature of the other party is not valid, an error notification is sent to the notary device 11 and the terminal 12B (or terminal 12A) (step S43), and the process is terminated.

  If the other party's electronic signature is valid, next, our public key PA (or PB) is extracted (step S38), and our electronic signature SA (M) (or SB (M ')) is used by using it. It verifies (step S39) and determines whether it is effective (step S40). If our electronic signature is not valid, an error notification is sent to the notary device 11 and the terminal 12B (or terminal 12A) (step S43), and the process is terminated.

  If our electronic signature is valid, it is next checked whether or not the transaction document M received from the notarization apparatus 11 is correct (step S41). Here, if the received transaction document M is the same as the transaction document M (or M ′) created by us, it is determined that it is correct. If the received transaction document M is not correct, an error notification is sent to the notary apparatus 11 and the terminal 12B (or terminal 12A) (step S43), and the process is terminated.

  If the received transaction document M is correct, the transaction document M, the electronic signature SA (M), SB (M ′), and SN (M, SA (M), SB (M ′)) are stored (step S42). The process ends.

  16, 17, 18, and 19, the transaction document, the electronic signature of user A, the electronic signature of user B, and the electronic signature of notary N are converted into user A, B, notary N Will be shared between. Similar flowcharts can be created for other models of transaction guarantee services and content guarantee services.

  When the notary device 11 receives a transaction information reference request from a terminal of an arbitrary user whose transaction content is to be confirmed, the notary device 11 returns the stored transaction document together with the notary N's electronic signature to the requesting terminal. Thus, the requester can refer to the contents of the transaction document guaranteed by the notary N.

  As described above, the identity guarantee service, the date / time guarantee service, the uniqueness guarantee service, the delivery guarantee service, the content guarantee service, and the transaction guarantee service have been described as services in the transaction notary system. A preferred embodiment of the transaction notary system is shown in FIG. From this, it can be considered to be composed of the four basic models shown in FIG. As application models of transaction notarization systems based on these, there are an encryption model, a multiple signature model, and a bidirectional model.

  The encryption model is an embodiment in which the entire information exchanged on the network in each basic model is encrypted with the recipient's public key and transmitted. The receiver performs the same process as the basic model after decrypting the information with his / her private key. By encrypting the information in this way, the possibility that the transaction information is stolen by a person other than the users A and B and the notary public N is reduced.

  In the basic model, the users A and B create the electronic signatures SA (M) and SB (M) based on the transaction document M. In the multiple signature model, the other user creates an electronic signature based on information obtained by concatenating the transaction document M and the electronic signature of one user. For example, when the user A creates the electronic signature SA (M) first, the user B creates the electronic signature SB (M, SA (M)) for the transaction document M and the electronic signature SA (M). The notary N further connects the electronic signature SB (M, SA (M)) and the transaction document M to create an electronic signature SN (SB (M, SA (M))).

  According to this multiple signature model, it is possible to clarify which user A or B has approved the transaction document M first. An encryption model in which information created by this multiple signature model is encrypted with the recipient's public key is also conceivable.

  In the second, third, and fourth models shown in FIGS. 13, 14, and 15, the user A is the first sender of the transaction document M, and the user B responds based on the received transaction document M. It was only.

  In the interactive model, in these basic models, the transaction document M ′ is also transmitted from the user B as in the first model shown in FIG. Thus, by making the information flow bidirectional, the positions of the user A and the user B become equal. In this case, the notary device 11 verifies and registers information from both sides.

  Enumerating the four basic models and the application models derived from them, the model variations of the transaction notarization system are as shown in FIG. In FIG. 20, for example, “multiple signature + encryption” represents a composite model in which a multiple signature model and an encryption model are used together. “◯” indicates that the combination of the basic model of the corresponding column and the application model of the corresponding row (excluding the first row) is possible, and “×” indicates that the combination is impossible. Represents that.

  As can be seen from FIG. 20, there are 23 models in the transaction notary system. Furthermore, there are a content non-disclosure model and an agreement signature model as modified models of the transaction notary system.

  The content non-disclosure model is a model for registering the transaction content without disclosing it to the notary public N. Specifically, in each basic model and application model, it is realized by deleting the plaintext P of the transaction contents from the transmission information to the notarization apparatus 11. Even in this case, since the electronic signatures created by the users A and B are sent to the notary device 11, the notary device 11 can verify / register it.

  The agreement signature model is a model in which the electronic signature of an agreement party other than the users A and B and the notary public N is attached to the stored transaction information. By adopting this model, it becomes possible to prove that users other than the parties to the transaction have given approval to the facts and contents of the transaction.

  FIG. 21 shows an example of shared information to which such an agreement signature is added. In FIG. 21, in addition to the electronic signatures SA (M) and SB (M) of the users A and B, the electronic signature SC (M) of the users C, D,. , SD (M),... Are also added, and the electronic signature SN (SA (M), SB (M), SC (M), SD (M),.・ ・) Has been created.

  In such an agreement signature model, when users C, D, etc. are parties to a transaction, the transaction notarization system automatically proves matters relating to a transaction between three or more parties.

It is a principle diagram of the present invention. It is a figure which shows the business transaction environment on a network. It is a figure which shows a transaction notary system. It is a block diagram of information processing apparatus. It is a figure which shows the shared information in a content guarantee service. It is a figure which shows the example of a transaction document. It is a figure which shows a 1st content guarantee service. It is a figure which shows a 2nd content guarantee service. It is a figure which shows the 3rd content guarantee service. It is a figure which shows a 4th content guarantee service. It is a figure which shows the shared information in a transaction guarantee service. It is a figure which shows the 1st transaction guarantee service. It is a figure which shows the 2nd transaction guarantee service. It is a figure which shows the 3rd transaction guarantee service. It is a figure which shows the 4th transaction guarantee service. It is a flowchart of the 1st process of a user terminal. It is a flowchart (the 1) of a process of notarization apparatus. It is a flowchart (the 2) of a process of notarization apparatus. It is a flowchart of the 2nd process of a user terminal. It is a figure which shows the model of a transaction notary system. It is a figure which shows the shared information to which the agreement signature was added.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Transaction certification | authentication apparatus 2, 3, 12A, 12B, 12C, 12D User's terminal device 4, 13 Communication network 5 Communication means 6 Processing means 7 Storage means 8, 9 User's electronic signature data 11 Notary apparatus 21 CPU
22 Memory 23 Input device 24 Output device 25 External storage device 26 Medium drive device 27 Network connection device 28 Bus 29 Portable recording medium 30 Database

Claims (2)

A terminal device that performs information processing related to transactions performed between a plurality of users,
First storage means for storing transaction document data describing matters relating to transactions between the first user and the second user;
Processing means for encrypting the transaction document data and creating electronic signature data of a first user for the transaction document data;
A second user's electronic signature data corresponding to the transaction document data is received from the second user via the network, and the generated first user's electronic signature data and the received second user signature data are connected to a communication network. Communication means for transmitting the electronic signature data of the user to the transaction certification apparatus for determining the validity of the electronic signature data of the first user and the electronic signature data of the second user via the network;
A terminal device comprising: the created first electronic signature data of the first user and second storage means for storing the received electronic signature data of the second user. A recording medium that records a program for a computer that performs information processing related to transactions performed between a plurality of users,
A function for storing transaction document data describing matters relating to a transaction between the first user and the second user in the first storage means;
A function of encrypting the transaction document data and creating electronic signature data of a first user for the transaction document data;
The electronic signature data of the second user for the transaction document data is received from the second user via the communication network, and the generated electronic signature data of the first user and the received electronic signature data of the second user are received. A function of transmitting the electronic signature data of the first user and the electronic signature data of the second user to the transaction certification apparatus for determining the validity of the electronic signature data of the second user via the network;
A computer readable record recording a program for causing the computer to realize the created electronic signature data of the first user and a function of storing the received electronic signature data of the second user in a second storage means. Medium.

Images