JP7350825B2 - Verification server and verification program - Google Patents

Description

The present invention relates to a verification server and a verification program, and is directed to, for example, an electronic contract concluded using an electronic document.

Electronic contracts using so-called electronic contracts have become widely used, and many electronic contract companies have begun to provide electronic contract services that mediate the conclusion of electronic contracts to contract parties. (For example, Patent Document 1).
Each electronic contract provider provides various electronic contract services that allow, for example, the selection of an electronic seal stamp, electronic signature, selection of a party-type electronic contract or witness-type electronic contract, and selection of time stamping.
Various electronic contracts created by electronic contracts concluded using electronic contract services provided by electronic contract providers are stored and managed by the relevant contract parties and electronic contract providers.

However, even if the same witness-type electronic contract service is available, the method of verifying the identity of the contracting party, the storage status of the process leading to the conclusion of the contract (log information, etc.), the certification authority of the electronic signature, etc. Timestamp providers may differ, and their reliability may also differ.
For the parties to the contract, which electronic contract provider and electronic contract service to use is determined by the relationship with the contracting party. For example, in the case of an order contract, the electronic contract provider selected by the company that placed the order for the contract is likely to be used in many cases.

In this way, the electronic contracts concluded will be a mixture of those created by various business operators, various services, and with different levels of trust, so if you store electronic contracts in-house, , it may be difficult to confirm the validity of a signed electronic contract.
In particular, in the case of electronic contracts that have been signed for a long time, the electronic contract services that were in place at the time of the contract signing or the content of the services may have changed, and the person responsible for storing and managing the electronic contracts. In some cases, the person in charge may have changed, making it difficult to check the current status of the electronic contract.

In addition, there are cases where the electronic contract provider stops part of the electronic contract service or the entire business midway through.
Furthermore, if the electronic contract service provider terminates the service, the operational status of the service up to that point (confirmation of log information of various processes leading to the contract, method of confirming parties, etc.) becomes unclear, and the electronic contract service provider ends the service. There are problems such as the reliability of the contract is lost and it becomes impossible to continue signing the electronic contract for a long period of time.
Furthermore, if the storage of electronic contracts is outsourced to an electronic contract provider, it is necessary to take over the subsequent storage in-house.

In this way, contracting parties who have concluded electronic contracts using the services of electronic contract providers may find it difficult to evaluate the reliability of previously concluded electronic contracts based on unified standards. In some cases, the evaluation itself was not possible.

Japanese Patent Application Publication No. 2019-144749

The present invention aims to verify the reliability of a concluded electronic contract.

(1) In the invention described in claim 1, evaluation information storage means collects evaluation information necessary for determining the reliability of electronic contract services provided by a plurality of electronic contract providers and stores the collected evaluation information for each electronic contract service. , a verification reception means that accepts a verification request for an electronic contract concluded using an electronic contract service provided by a predetermined electronic contract provider, and a plurality of predefined methods for the electronic contract for which the verification request has been accepted. a verification means for verifying the reliability of the electronic contract by determining the reliability of the electronic contract service according to the determination conditions; a creation means for creating a verification result recording the determination result for each of the determination conditions; result presentation means for presenting the created verification results to the requester of the verification request; The verification means stores information such as whether the electronic contract has been made public and whether it has been certified by an external certification body. To provide a verification server characterized in that, if there is any item that does not satisfy any one item of the evaluation information for a service, it is determined that reliability of a certain level or higher is not recognized.
(2) In the invention according to claim 2, when the verification receiving means receives a verification request for an electronic contract of a witness type electronic contract, the verification means performs verification of the reliability of the contents of the electronic contract. , if the signature value of the electronic contract does not include information about the actual signer, or if information that confirms the actual signer is not included, reliability above a certain level cannot be recognized. There is provided a verification server according to claim 1, wherein the verification server determines that.
(3) In the invention according to claim 3, evaluation information regarding electronic contract services provided by the plurality of electronic contract providers is periodically collected, and evaluation information stored in the evaluation information storage means is updated. There is provided a verification server according to claim 1 , further comprising: updating means for updating the verification server.
(4) In the invention as set forth in claim 4, when accepting the verification request, the verification receiving means receives a signed electronic contract and an original electronic contract having contract ancillary information; There is provided a verification server according to any one of claims 1 to 3 , characterized in that the reliability of the contents of the electronic contract is verified based on the original electronic contract.
(5) The invention according to claim 5 is characterized in that the result presenting means presents a verification result with an electronic signature and a time stamp attached. Provide the verification server described.
(6) In the invention as set forth in claim 6, the verification reception means is provided by a contracting party who has concluded an electronic contract, a successor who has inherited the contract from the contracting party, or an electronic contract business operator used in the contract. There is provided a verification server according to any one of claims 1 to 5 , characterized in that the verification server receives a verification request.
(7) The invention according to claim 7 is characterized by comprising a contract storage means for storing the received electronic contract original based on a request from the requester of the verification request . Provides the verification server described in .
(8) In the invention as set forth in claim 8, the contract storage means stores the electronic contract original to which a time stamp has been added after the verification by the verification means is completed. The verification server described in 7 is provided.
( 9 ) In the invention described in claim 9 , evaluation information necessary for determining the reliability of electronic contract services provided by a plurality of electronic contract providers is collected and stored in the evaluation information storage means for each electronic contract service. Regarding the evaluation information storage function to store, the verification reception function to accept verification requests for electronic contracts concluded using electronic contract services provided by predetermined electronic contract providers, and the electronic contracts for which the verification requests have been accepted. , a verification function that verifies the reliability of the electronic contract service by determining the reliability of the electronic contract service according to multiple predefined determination conditions, and creates a verification result that records the determination results for each of the determination conditions. and a result presentation function to present the created verification results to the requester of the verification request. whether or not the operation policy has been made public, and whether or not the certification from an external certification body has been obtained are stored in the evaluation information storage means; If there is any item in the evaluation information for the electronic contract service for which the accepted electronic contract was concluded, it will be determined that the reliability above a certain level is not recognized. The present invention provides a verification program that is realized by a computer.

According to the present invention, the reliability of an electronic contract for which a verification request has been accepted is determined according to a plurality of predetermined criteria, thereby verifying the reliability of the electronic contract and presenting the verification results to the requester. can do.

FIG. 2 is a diagram showing the system configuration of a verification system that concludes and verifies an electronic contract. FIG. 2 is an explanatory diagram showing the configuration of a verification server. FIG. 2 is an explanatory diagram of an electronic contract provider determination list. It is an explanatory diagram about a data judgment item list. FIG. 2 is an explanatory diagram showing a time chart for electronic contract processing, which is a part of electronic contract verification processing. FIG. 7 is an explanatory diagram showing a time chart for verification processing, which is another part of the electronic contract verification processing. It is an explanatory diagram showing a verification request screen. It is an explanatory view showing a part of an example of a contract verification judgment result certificate. It is an explanatory view showing the remainder of an example of a contract verification judgment result proof.

Hereinafter, a preferred embodiment of the verification server 10 of the present invention will be described in detail with reference to FIGS. 1 to 9.
(1) Overview of the Embodiment The verification server 10 of this embodiment provides information to the parties who made the electronic contract and the electronic contract provider regarding electronic contracts concluded using electronic contract services provided by various electronic contract providers. Instead, the reliability of the created electronic contract is verified.
Specifically, each judgment condition uniformly stipulated in the electronic contract provider judgment list 144 is judged regarding the reliability of the electronic contract provider and the electronic contract services provided by the electronic contract provider. . Furthermore, the reliability of the contents of the concluded electronic contract is determined based on each determination condition uniformly defined in the data determination item list 145.
The verification server 10 creates a verification result (contract verification judgment result certificate) that reflects the judgment results of each judgment condition, gives it an electronic signature and a time stamp, and stores it. Report to Person X.
In this embodiment, evaluation information necessary for determining the reliability of the electronic contract provider and the electronic contract service provided by the electronic contract provider is regularly collected and the provider/service DB 142 is updated. This makes it possible to verify the reliability of electronic contracts created in the past.
In response to a request from a verification requester, the verification server 10 adds a time stamp to the original electronic contract and stores it on the cloud. The original electronic contract to be stored will be linked by managing the verification results and verification number.

(2) Details of Embodiment FIG. 1 shows the system configuration of a verification system 1 that creates an electronic contract by concluding an electronic contract and verifies it.
As shown in FIG. 1, the verification system 1 includes electronic contract provider terminals 2a, 2b, ..., user terminals 4a, 4b, ..., a signature server 6, a time stamp server 7, and the verification server of this embodiment. It is composed of 10 mag. Each component of the verification system 1 is configured to be able to communicate encrypted with SSL (Secure Sockets Layer) or TLS (Transport Layer Security) via a communication network such as the Internet.

The electronic contract operator terminal 2a is a server operated by electronic contract operator A, and provides electronic contract services A, B, . . . for concluding electronic contracts, as an example. The electronic contract operator terminal 2b is a server operated by the electronic contract operator B, and provides electronic contract services a, b, . . . for concluding electronic contracts, for example.
Here, electronic contract services provided by electronic contract providers mainly include various services such as party-type electronic contracts and witness-type electronic contracts. , the presence or absence of electronic signatures, the presence or absence and frequency of time stamps, the recording method of the contract process, etc. are determined for each electronic contract provider.

The user terminals 4a and 4b are terminals of contract parties who conclude an electronic contract using electronic contract services provided by electronic contract providers A, B, etc., respectively.
The following is common to all electronic contract provider terminals and all user terminals 4, except when specific terminals are specified for electronic contract provider terminals 2a, 2b, ... and user terminals 4a, 4b, ... In such cases, the numbers 2 and 4 will be used to designate them.

The signature server 6 generates a public key and a private key for performing an electronic signature, and transmits an electronic certificate (public key certificate) obtained from a certification authority (not shown) to a contract party or an electronic contract provider. Further, based on a request from an electronic contract provider, the signature server 6 applies an electronic signature to an electronic contract (a hash value of the electronic contract, etc.) using a private key, and returns the signature value to the request source.
The electronic signature performed by the signature server 6 here uses the private key of the electronic contract provider in the case of a witness-type electronic contract, and the private key of the party (or the parties and the verification server 10) in the case of a party-type electronic contract. be done.

The time stamp server 7 attaches a time stamp to various data such as an electronic contract that has been electronically signed based on a request from an electronic contract provider.
Although FIG. 1 shows only one signature server 6 and one time stamp server 7, there are multiple businesses that provide electronic signatures and time stamps, and each electronic contract business has a different signature server and time stamp server. A stamp server has been determined.
Note that the signature server 6 and the time stamp server 7 shown in FIG. 1 represent servers that cooperate when the verification server 10 signs an electronic signature and attaches a time stamp. Although not shown, there are various other signature servers and time stamp servers, and the signature server and time stamp server with which the electronic contract provider 4 cooperates are determined.

The verification server 10 is a server that performs verification of electronic contracts concluded by users X and others. The verification server 10 functions as a cloud server, and determines the reliability of the contents of the electronic contract service provided by each electronic contract provider, and determines the reliability of the concluded electronic contract, and displays the determination results. We will create a contract verification judgment result certificate that reflects the above, add a time stamp to the original electronic contract that has been requested for verification, and save it.

FIG. 2 shows the hardware configuration of the verification server 10.
As shown in FIG. 2, the verification server 10 includes a CPU 11, a ROM 12, a RAM 13, a storage device 14, a communication control unit 15, and other devices, each of which is connected via a bus line.
The CPU 11 is a central processing unit, and performs various processes related to verification of the electronic contract according to various programs such as the basic program (OS) stored in the ROM 12 and the verification program 141 stored in the storage device 14.

The ROM 12 is a read-only memory and stores basic programs, parameters, etc. for the operation of the CPU 11.
The communication control unit 15 performs communication processing with external devices such as the electronic contract provider terminal 2, the user terminal 4, the time stamp server 7, and the signature server 6.

The RAM 13 is a readable and writable memory, and is a working memory used when the CPU 11 performs verification processing of an electronic contract. In this embodiment, the RAM 13 stores contract information 131, verification results 132, and other various data. Memorized temporarily.
In the contract information 131, contract information (such as the electronic contract original and optional information to be described later) uploaded from the user terminal 4 is stored with a management verification number assigned at the time of the verification request. Ru.
The verification result 132 stores the results (recorded information) of evaluating the electronic contract based on the contract information using the judgment conditions shown in FIGS. 3 and 4, which will be described later. The verification results 132 are managed for each verification number of the contract information.

The storage device 14 is configured using one or more large-capacity storage media such as a hard disk, and stores a verification program 141 for making the CPU 11 perform the functions of this embodiment, a business/service evaluation DB 142, and user registration. A DB 143, an electronic contract provider determination list 144, a data determination item list 145, a verification result DB 146, a contract storage DB 147, and other information are stored.

In the verification process of this embodiment, the verification program 141 verifies the reliability of the electronic contract (the reliability of the electronic contract provider, the electronic contract service, and the contents of the electronic contract) requested by the contracting party or the electronic contract provider. This is a program that verifies the contract, creates a contract verification judgment result certificate, and presents it to the client.

The operator/service evaluation DB 142 stores evaluation information necessary for evaluating electronic contract operators and the content and operational status of the electronic contract services provided by the electronic contract operator. This is a database stored for each electronic contract service.
The evaluation information stored in the operator/service evaluation DB 142 is periodically updated at predetermined intervals, for example, every n days, such as the business operation status of each electronic contract operator, changes in the content of each electronic contract service, whether or not new services have been established, etc. are searched and updated if there are any changes or new additions.
The evaluation information that will be saved includes the service type (participant type, witness type, presence or absence of electronic signature, unclassifiable, etc.), presence or absence of registration, service continuity status, service operation period, service reliability (terms of service, operational policy, etc.). publication status, certification by an external certification body, etc.), and corresponds to a service provider determination list 144 (see FIG. 3), which will be described later.

The user registration DB 143 stores user information for identifying the operating entity of the electronic contract provider terminal 2 and the user of the user terminal 4, who are registered as users in the verification server 10 of this embodiment in advance. As user information, various types of information such as account IDs, company IDs, addresses, company names, user names, HP addresses, e-mail addresses, and telephone numbers of business operators and users are stored.
The verification service provided by the verification server 10 of this embodiment can be used not only by users or electronic contract providers (hereinafter referred to as users) who have been registered in advance, but also by unregistered users. It is. However, as will be described later, if the verification server 10 stores the original electronic contract (a set of electronic contracts) to be verified, user registration is required for use.

The electronic contract provider determination list 144 is a list that defines items (examples of determination conditions) for determining the reliability of electronic contract providers and the electronic contract services provided by the electronic contract providers.
The data judgment item list 145 is a list that defines items (example of judgment conditions) for judging the reliability of the contents of the concluded electronic contract.
Details of the electronic contract provider determination list 144 and the data determination item list 145 will be described later.

In the verification result DB 146, contract verification judgment result certificates (verification results) that summarize the results of the verification processing for each item of the electronic contract provider judgment list 144 and the data judgment item list 145 are saved with a time stamp attached. It is a database that exists on the cloud.
The verification result after the time stamp has been added is to be transmitted to the verification requester (user terminal 4).
Details of the electronic contract provider determination list 144, the data determination item list 145, and the contract verification determination result certificate stored in the verification result DB 146 will be described later using FIGS. 3, 4, and 5, respectively.

The contract verification judgment result certificate (verification result) is managed by a verification number assigned to each verification request for an electronic contract, and is saved together with the request date, the name of the electronic contract, the requester's ID, etc.
An electronic signature of the operator of the verification server 10 or the verifier is added to the verification result, and a time stamp can be added to the verification result. In addition, the verification results can be included in the contract file as verification information when the timestamp is extended, and in this case, a hash value including the verification results is calculated and a timestamp is added.

The contract storage DB 147 is a database existing on the cloud that stores the original electronic contract when a verification request and a request to store the electronic contract are made.
The original electronic contract to be saved here is a set of electronic contracts sent from the requestor (user or electronic contract provider) when a request for verification is received.
A set of electronic contracts includes, for example, a signed electronic contract (an electronic contract in which an electronic signature and time stamp have been added to the original electronic contract before entering the electronic contract procedure), and a signed electronic contract. There is contract information etc. that accompanies the contract.
The content of the contract accompanying information varies depending on the electronic contract provider that provided the service for the electronic contract, but for example, the contract number (NO), account ID (used by the electronic contract provider to identify the user), etc. contract name, physical file name (actual file name), electronic contract file size, business partner company name, business partner address, recipient email address, comment, sending (distribution) date and time, approval date and time, conclusion date and time, There is operation log information etc. created in the process of concluding an electronic contract.
Further, the contract-attached information may include electronic contract service terms and conditions, materials on identity verification methods, log information at the time of identity verification, operational reports, etc.

The electronic contract original stored in the contract storage DB 147 is managed by a verification number assigned to each verification request, and is stored linked to the contract verification judgment result certificate stored in the verification result DB 146.
In response to a request, the electronic contract original stored in the contract storage DB 147 is stored with a time stamp added if the verification is successful.
Note that the time stamp may be applied not to the original electronic contract but to the signed electronic contract, or to both the original electronic contract and the signed electronic contract.

Other information stored in the storage device 14 includes the electronic certificate (public key certificate) of the verification server 10 that the verification server 10 acquired from the signature server 6. Note that this electronic certificate includes a public key paired with a private key used by the verification server 10 when signing, a signature on the electronic certificate by a certification authority, and the like.

FIG. 3 shows an example of the contents of the electronic contract provider determination list 144.
The electronic contract provider determination list 144 defines, for example, the following examples of determination conditions as items for determining the reliability of an electronic contract provider and the electronic contract services provided by the electronic contract provider. .
That is, as shown in FIG. 3, "service type", "registered service", "continuing service", "reliable service operation condition", etc. are defined as examples of determination conditions.
For each of these examples of judgment conditions, "example of check", "rejection condition", "warning condition", and "recorded information" are defined. "Example of check" shows examples of items to check, "Rejection conditions" shows conditions when it cannot be determined that the electronic contract provider has a certain level of reliability, and "Warning conditions" shows examples of items to check. Conditions are exemplified when there is a certain level of reliability or higher, but there are doubts about higher reliability, and "recorded information" includes items to be recorded in the contract verification judgment result certificate regarding the results of checking the electronic contract. is exemplified.

Specifically, as shown in FIG. 3, for example, in the case of the judgment condition example "conditions for reliable service operation", the following is defined.
In other words, "examples of checks" include whether "the terms and conditions are made public", whether "the operational policy is made public", and whether "certification by an external certification body has been obtained". A check is made to determine whether or not "sample data is being provided."
If any one of these check items is not met, it will be determined that reliability above a certain level is not recognized (=rejection conditions are met), and the electronic contract will be rejected. Targeted. For verification requests that are subject to rejection, the creation of verification results (contract verification judgment result certificates) that are deemed to be highly reliable and the storage of the requested original electronic contract will be refused.

Note that there is no recorded information to be recorded in the verification results when all of the example judgment conditions "conditions for reliable service operation" are met, but in order to make it clear that it is the subject of the check, the target of the recorded information is You can also use it as In other words, the fact that the terms and conditions and operational policy are open to the public may be recorded in the verification results.
In addition, in this embodiment, if even one of the rejection conditions for any of the judgment conditions is met, a contract verification judgment result certificate is not created, but if the requester allows it, the certificate is not created at the verified level. Verification results corresponding to the reliability of the test are created. Although the original electronic contract in this case is not to be saved by the verification server 10, it is also possible to save it together with the verification results.
If the electronic contract provider meets the warning conditions, the verification results will be created and the original electronic contract will be saved, but the verification result "WARNING" will be displayed on the contract verification judgment result certificate. is displayed, and a description of the content that satisfies the warning conditions is included.

FIG. 4 shows a data judgment item list 145 for evaluating the contents of an electronic contract.
The data determination item list 145 defines, for example, the following example of determination conditions as items for determining the reliability of the contents of a concluded electronic contract.
That is, as shown in FIG. 4, "certificate authority", "witness certificate", "signature value verification", "archive time stamp verification", etc. are defined as examples of determination conditions.
For each of these examples of judgment conditions, "example of check", "rejection condition", "warning condition", and "recorded information" are defined as in FIG. The contents of these items are the same except that in FIG. 3, the data determination item list 145 in FIG. 4 is targeted at electronic contract providers, whereas the data determination item list 145 in FIG. 4 is targeted at electronic contracts.

Specifically, as shown in FIG. 4, for example, in the case of the determination condition example "certificate authority", the following is true.
That is, it is checked whether the certificate authority is listed on the list of trusted certificate authorities, and if it is not trusted (not included on the list), it is rejected. On the other hand, if the certificate authority is listed in the certificate authority list, the certificate authority name is reflected in the verification results as recorded information.
Also, it is checked whether the public key certificate (electronic certificate) issued by the certification authority is successfully verified, and if the public key verification fails, it is rejected. On the other hand, if the public key verification is successful, the public key certificate is reflected in the verification result as recorded information.
A public key certificate is electronic data that is digitally signed by a certification authority on data that includes a public key and specific information (name, email address, etc.) of the owner of the public key, and is used to prove identity. Verification of this public key certificate (public key verification) is performed by checking whether it can be verified using the public key of the certification authority, whether it has not been revoked by the certification authority, and whether the certificate is within its validity period. Verified. In addition, in the case of witness signatures, it may be confirmed whether the certificate owner information is listed on a list indicating that the certificate is a trusted business provided by a party other than the certificate authority.

In FIG. 4, the "signature time stamp" checked in the judgment condition example "signature value verification" is a time stamp attached to the electronic signature (ES), and is a time stamp for the signature value of the electronic contract that has been electronically signed.
In addition, the archive timestamp in the judgment condition example "archive timestamp verification" refers to the electronic signature (electronic certificate) and timestamp (archive A timestamp that is added to a document created according to the long-term signature format before the expiration date (including timestamp).

In the verification based on the data judgment item list 145 in FIG. 4, the handling when the rejection conditions and warning conditions are met is the same as the handling (including modified examples) explained in the electronic contract provider judgment list 144 in FIG. 3. be.

Regarding each judgment condition example, its check example, conditions subject to refusal or warning, and recorded information shown in the electronic contract provider judgment list 144 and data judgment item list 145 in FIGS. 3 and 4, the requested electronic This is an example of verifying contracts based on unified standards.
Therefore, it is also possible to specify other conditions as the rejection condition and the warning condition. However, regarding the specified conditions (including other items), it is necessary to continue verifying the same content and recording the results.
If new judgment condition examples and their check examples are added or changed, it is preferable to make it possible to confirm when the additions or changes were made and their contents (for example, by recording them in the verification results). .

Next, contract verification processing by the verification system 1 configured as described above will be explained.
In this contract verification process, electronic contract processing and verification processing are performed.
Electronic contract processing is a process in which user X concludes an electronic contract with user Y using, for example, electronic contract service A provided by electronic contract provider A. Processed by a program corresponding to the service provided.
The verification process is a process performed by the verification server 10 according to a verification program, and is based on a request from the user This is a process that evaluates reliability, including validity, using uniform standards.
In the contract verification process described below, user X (user terminal 4a) communicates with user Y using electronic contract service A provided by electronic contract operator An example will be explained in which an electronic contract is concluded (electronic contract processing), and then, upon receiving a request from user X, the verification server 10 performs verification to convert the electronic contract into an electronic contract (verification processing). do.

FIG. 5 is a time chart showing the electronic contract processing of the contract verification processing.
First, the user X uses the user terminal 4a to request an electronic contract from the electronic contract provider terminal 2a of the electronic contract provider A (step 11). Here, user Request processing for the process of concluding a transaction contract).

Based on a request from client X (user terminal 4a), electronic contract operator terminal 2a concludes an electronic contract between client X and client Y according to the contents of the selected electronic contract service A ( Step 12).
That is, the electronic contract provider terminal 2a transmits and receives information between the client X's user terminal 4a and the client Y's user terminal 4b to determine the content of the selected service A (for example, identity verification processing, The conclusion of the electronic contract between users X and Y is processed according to the electronic signature, time stamp, etc. of the created electronic contract.

The electronic contract provider terminal 2a transmits a set of electronic contracts related to the completed electronic contract to the user terminals 4a and 4b (step 13).
Further, the electronic contract operator terminal 2a stores a set of created electronic contracts when requested by the user X (or the user Y).
Here, the complete set of electronic contracts depends on the contents of the electronic contract service, but for example, the signed electronic contract with an electronic signature etc. attached to the original electronic contract before entering the electronic contract procedure, the signed electronic contract, etc. There is contract information that accompanies the completed electronic contract.

On the other hand, when the user terminals 4a and 4b receive a set of electronic contracts from the electronic contract provider terminal 2a, they store them in a storage location such as a predetermined storage device (step 14).
As described above, various electronic contract services A, B, a, b, etc. provided by electronic contract providers A, B, etc. selected by users X and Y or designated by the contracting party, etc. An electronic contract is concluded and a set of created electronic contracts is continuously stored and managed by users X, Y, etc., and electronic contract providers A, B, etc.

On the other hand, the verification server 10 periodically (for example, every day, every n days, every week, every month) collects information about the electronic contract service contents provided by each electronic contract provider A, B, etc. (step 21). .
That is, the verification server 10 collects various information corresponding to each judgment condition of the electronic contract operator determination list 144 explained in FIG. 3 for all collectable electronic contract operators that provide electronic contract services. .
Then, the verification server 10 checks each judgment condition for each collected electronic contract provider, and stores and updates the judgment results (recorded information) in the provider/service evaluation DB 142 (step 22). . If there is a change in the content (judgment result) of the electronic contract service during the periodic collection and judgment process, the changed content and the date and time of the change are also recorded. The change date and time is collected by checking with the relevant electronic contract provider, but if the change date and time cannot be confirmed, the date and time when the verification server 10 confirmed the change is recorded.

In this way, the verification server 10 periodically collects information about electronic contract providers and the contents of the electronic contract services they provide, and saves and updates the determination results. It is possible to verify the service content at the time the agreement was concluded.
In addition, by collecting and evaluating verification information in advance, it is possible to check (verify) each judgment condition during the verification process without checking with the electronic contract provider that provided the electronic contract service. , verification can be performed smoothly.

FIG. 6 is the remaining explanatory diagram showing a time chart for the verification process, which is another part of the electronic contract verification process.
In cases where User If necessary, the verification server 10 is requested to verify the electronic contract.

When user X makes a verification request, he first logs in from the user terminal 4a to the verification service page provided by the verification server 10 (step 31).
In addition, when logging in, if User Log in by entering your user information. After this login, it becomes possible to request verification according to this embodiment.

When the user logs into the verification service page, the verification server 10 presents a verification request screen to the logged-in user terminal 4a (step 32).
FIG. 7 shows a verification request screen 40 presented by the verification server 10 and displayed on the user terminal 4a.
As shown in FIG. 7, the verification request screen 40 displays an upload section 41, a comment input section 42, a service/system selection section 43, a timestamp request section 44, a storage request section 45, and the like.
The upload section 41 is an area for specifying an original electronic contract (a set of electronic contracts) to be uploaded to the verification server 10 and requested for verification. The upload target is specified by dragging and dropping a file of the original electronic contract stored in the storage area of the user terminal 4a or by selecting the file onto the upload unit 41.
Up to 30 files can be specified and verified at one time from the upload section 41.

The comment input section 42 is a field in which arbitrary comments such as comments regarding the verification request and comments regarding individual files to be uploaded are entered. This comment input section 42 allows input of a maximum of n characters (for example, 1000 characters).

The service/system selection unit 43 is an input unit for selecting an electronic contract service for which a contract has been created. When the pull-down button (black downward pointing triangle button) displayed on the left side of the service/system selection section 43 is selected, a pull-down menu shown in FIG. 7(b) is displayed.
This pull-down menu displays each electronic contract service provided by each electronic contract provider, and User . The selection of the electronic contract service used can be specified for each file (original electronic contract) to be uploaded from the upload unit 41.
Selection by the service/system selection section 43 is a user's option.
In other words, since the user This is an item that user X inputs within a known range. An example of a case where the electronic contract service used is unknown is when a right holder (assignee) who has been assigned a claim under a debt transfer contract requests verification of the electronic contract (PDF, etc.) that has been assigned.

The time stamp request section 44 and the storage request section 45 are check boxes for making an optional request in case the verification is successful. When making a request, check each checkbox by clicking on it with a mouse or the like.
The time stamp request section 44 is a check box for requesting that a time stamp be added to the original electronic contract.
The storage request section 45 is a check box for requesting that the original electronic contract be stored in the cloud of the verification server 10.

When the specification and input from the verification request screen are completed by user , a verification request is made (step 33).
Upon receiving contract information uploaded in response to a verification request, the CPU 11 of the verification server 10 assigns a management verification number to each uploaded original electronic contract and stores it in the contract information 131 of the RAM 13 until verification is completed. Temporarily save (step 34).

Thereafter, the CPU 11 verifies each piece of contract information 131 stored in the RAM 13.
The CPU 11 determines from the contract information 131 whether the electronic contract to be verified is the electronic signature of the contracting party (step 35).

If it is not the electronic signature of the contracting party, that is, if the electronic contract uses an electronic contract service provided by an electronic contract provider (step 35; Y), the CPU 11 sends the signature of the electronic contract provider (and the electronic contract service). A determination is made regarding the reliability of (step 36).
That is, the CPU 11 executes an electronic contract with the electronic contract provider used to conclude the electronic contract based on the original contract in the contract information 131 and the service selected by the user on the verification request screen (FIG. 7). Identify the service. Regarding the specified electronic contract service, the CPU 11 uses the evaluation information already collected in the business/service evaluation DB 142 to determine whether the rejection conditions and warning conditions are satisfied for each of the judgment condition examples explained in FIG. At the same time, recording information (judgment result) for each example of the determination condition is determined and stored in the verification result 132 of the RAM 13.

After the determination regarding the electronic contract provider (step 36), or if the electronic contract does not use an electronic contract service (step 35; N), the CPU 11 determines the reliability of the original electronic contract (step 37). ).
That is, the CPU 11 checks each of the judgment condition examples explained in FIG. Record information that is the determination result for each example is determined and stored in the verification result 132 of the RAM 13.

Next, the CPU 11 determines whether or not there is one or more determination conditions that satisfy the rejection condition in the determination results regarding the business operator and the electronic contract original (steps 36 and 37) (step 38).
If there is one or more judgment conditions that satisfy the rejection conditions (step 38; Y), the CPU 11 creates a rejection result certificate (step 39). This rejection result certificate includes information such as the fact that the reliability of the requested electronic contract is not ensured and examples of the criteria for rejection.
For example, it may say something like, ``As a result of verifying the requested electronic contract, the rejection conditions were met in terms of judgment condition XX, so the reliability of the contents of the electronic contract was not ensured.'' Ru. Note that the rejection result certificate may also include verification results (recorded information) for items other than the judgment conditions that satisfy the rejection conditions.

On the other hand, if there is no judgment condition that satisfies the rejection condition (step 38; N), the CPU 11 creates a contract verification judgment result certificate based on the verification result (recorded information) 132 stored in the RAM 13 (step 40).
The created contract verification judgment result certificate is managed by a verification number assigned to each verification request for an electronic contract, and is stored together with the request date, electronic contract name, requester's ID, etc. That is, the CPU 11, in cooperation with the signature server 6 and the time stamp server 7, attaches the electronic signature and time stamp (TS) of the verification server 10 (operator or verifier) to the created contract verification judgment result certificate. and stores it in the verification result DB 146 (step 41).
Note that the contract verification judgment result certificate can be included in the contract file as verification information when extending the timestamp, and in this case, a hash value including the verification result is calculated and a timestamp is added.

The CPU 11 causes the verification server 10 to cooperate with the timestamp server 7 to add a timestamp to the original contract according to the optional content of the verification request (addition of timestamp to the original, cloud storage) present in the contract information. At the same time, the original contract with the time stamp added is stored in the contract storage DB 147 (step 42).
Note that the original contract stored in the contract storage DB 147 is managed using the verification number assigned at the time of the verification request.
After the verification server 10 completes the verification, the verification server 10 adds a timestamp to the original electronic contract, regardless of the expiration date of the timestamp given when the electronic contract was concluded. The verification server 10 can perform existence proof and extension processing using a timestamp.

Although a time stamp is attached to the contract verification judgment result certificate in step 41, the time stamp is added to the contract verification judgment result certificate that has been electronically signed by the verification server 10 together with the electronic contract original. A stamp may also be added.
As a result, by extending the time stamp deadline by the verification server 10, the reliability of the original electronic contract is continuously guaranteed by the current verification result (contract verification judgment result certificate) within the deadline. .

When the above verification is completed, the CPU 11 transmits the verification result (contract verification judgment result certificate or rejection result certificate) to the requesting user terminal 4a (step 43), and sends the electronic contract corresponding to the verification information. Finish verifying the document.
In addition, when sending the rejection result certificate created in step 39 to the requesting user terminal 4a, the storage of the original electronic contract is refused (if it is an option), and the original electronic contract is sent to the user terminal 4a that is the requester. The certificate is sent to the requesting user terminal 4, etc. together with the certificate.

If multiple pieces of verification information have been uploaded, the electronic contract will be verified using the next verification information.
In this case, a contract verification judgment result certificate corresponding to all the verification information may be created and then sent to the user terminal 4 all at once.

On the other hand, when the user terminal 4a that requested the verification receives the verification result from the verification server 10, it stores the verification result in a predetermined storage area with a link to the corresponding electronic contract (step 44), and ends the process. do.
The contract verification judgment result certificate is used to verify the reliability of the electronic contract services provided by various electronic contract providers at the time of the contract and the content of the electronic contract concluded by User X. Regarding reliability, it is created according to unified standards (electronic contract provider judgment list 144, data judgment item list 145).
For this reason, User .
In other words, if the electronic contract was concluded using various businesses or services, or if the content of the electronic contract service has changed, the in-house person in charge of managing the electronic contract may Even if the person in charge has changed, the validity can be easily confirmed using the electronic contract verification judgment result certificate.

8 and 9 illustrate an example of a contract verification judgment result certificate created by the verification process of this embodiment.
The contract verification judgment result certificate shown in Figures 8 and 9 includes "verifier client information,""verificationresult,""verificationtime,""contractinformation,""service provider verification," and "electronic signature." Information such as "signer information 1", "electronic signer information 2", "archive time stamp verification information", "time stamp extension", etc. is recorded.

"Verifier requester information" displays information about user be done.
The request date and time is displayed in Japan Standard Time (JST), but it is also possible to display it in Universal Coordinated Time (UTC).

The name of the user X who made the verification request is written in the requester name of "verifier requester information." Usually, the name of one of the parties to the contract or the electronic contract provider is listed.
However, in the example in Figure 8, the name of the client other than the two parties to the electronic contract listed in electronic signer information 1 and 2 (see Figure 9) is written in the client name. This applies to cases where the verification request is from a third party who inherited the contract from one of the parties.
In this way, the verification service according to the present embodiment also supports verification requests from parties other than the parties to the contract, for example, verification requests from an assignee who has received the contents of the contract through transfer of a claim.

In the "verification results" shown in FIG. 8, since there were no items that met the rejection conditions or warning conditions during the verification, VALID (reliable) is displayed.
If even one warning condition is satisfied, WARNING is displayed in the "verification result".
In addition, in the rejection result certificate created in step 39, INVALID (unreliable) is displayed in the "verification result".

“Contract information” and “Service provider verification” contain the verification results 132 (recorded information) determined according to the electronic contract provider judgment list 144 (Figure 3) regarding the reliability of the electronic contract service used at the time of contract. Displayed.
The "contract information" includes the name of the contract service provider (electronic contract provider name) and the service type (electronic contract service). In the example of FIG. 8, witness type electronic signature is shown as the service type, but as explained in FIG. 3, party type and no electronic signature are also displayed. Note that "unclassifiable" is displayed as the service type when the rejection conditions are met, so it is displayed in the rejection result certificate created in step 39, which will be described later.

The service status at the time of verification of "Service provider verification" describes the operational status of the electronic contract service used to conclude the electronic contract at the time of verification.
The reliability at the time of verification and the reliability at the time of signature are described as to whether or not the contract is registered in the business operator/service evaluation DB 142 of the verification server 10 when the electronic contract is concluded during verification by the verification server 10. There is.
The service registration information at the time of signature includes information on how to confirm the identity (existence confirmation by a third party), how to identify the individual (SMS notification), disclosure of operational policy (disclosure of terms and conditions), and authentication (ISMS acquisition).
Here, the SMS notification indicates that the parties to the contract have been confirmed using the short mail service.
Furthermore, ISMS certification indicates that the electronic contract provider has obtained ISMS certification (ISO27001) based on the evaluation system (ISMS conformity evaluation system) established by the Japan Information Processing Development Association.

On the other hand, "electronic signer information 1", "electronic signer information 2", "archive timestamp verification information", and "time stamp extension" indicate the reliability of the contract data (contents of the signed electronic contract). Verification results 132 (recorded information) determined according to the data determination item list 145 (FIG. 4) are displayed.

"Electronic signer information 1" is a description about the electronic signature of Signature Taro, who is a party to the contract, and "electronic signer information 2" is a description about the electronic signature of Signature Jiro, who is another contracting party.
The "Signature Confirmation" column shows the method used to confirm the identity when signing electronically, and in Figure 8, it shows that the confirmation was done using SMS (Short Mail Service) and the phone number. has been done.

The contents of the "time stamp service" described in "Archive timestamp verification information" and "Time stamp extension: execution" are based on the timestamp server used by the electronic contract provider involved in the contract and its reliability. It is written about.

"Verifier information" describes information about the verification server 10 that provides the verification service according to this embodiment.
“Verifier electronic signature/time stamp” describes the electronic signature by the verification server 10 and the time stamp server 7 with which the verification server 10 cooperates.

Although the verification system 1 using the verification server 10 of the present invention has been described above, the present invention is not limited to the described embodiments, and various modifications can be made within the scope of each claim. It is.
For example, in the described embodiment, the verification server 10 receives and verifies a set of electronic contracts based on requests from users X, Y, etc.; It is also possible to conduct verification based on a request from Party B.
In other words, electronic contract business operator A, etc., which stores a set of electronic contracts created in connection with the conclusion of electronic contracts, will continue to provide electronic contract services, but will not provide services for storing the set of electronic contracts created. In the event of termination, or in the event of terminating all business related to electronic contracts, we will conduct verification upon request. In this case, if there is an option to store the original electronic contract, it will be processed in the same way as a request from the user.

If the electronic contract provider only requests verification without requesting the storage option from the verification server 10, upon terminating the provision of electronic contract services, as a service for users (contract parties) who have used electronic contracts, There are cases in which a contract verification judgment result certificate created by the verification server 10 is sent to the parties to the contract.
In this case, it is considered that the original electronic contract is often kept by the user (contracting party) and not by the electronic contract provider.
On the other hand, if the electronic contract provider stores the original electronic contract, it is considered that the storage option is often given in order to transfer the storage continuation to the verification server 10.

Furthermore, a case has been described in which the verification server 10 transmits only the verification result (contract verification judgment result certificate) to the requesting user terminal 4a after the verification is completed (step 43).
On the other hand, regardless of whether the original electronic contract is stored in the contract storage DB 147 (regardless of whether or not there is a storage option), the verification server 10 stores the electronic contract after the verification server 10 has attached a time stamp. The original document may be sent to the requesting user terminal 4a together with the verification result.

In addition, as described above as a modified example, when the verification server 10 adds a time stamp to the contract verification judgment result certificate that has been digitally signed by the verification server 10 and the electronic contract original, The contract verification judgment result certificate with a time stamp and the original electronic contract may be sent to the user terminal.

Furthermore, in the described embodiment, when creating a rejection result certificate (step 39), the verification server 10 refuses to store the original electronic contract, and sends the original electronic contract to the requesting user along with the rejection result certificate. Sending to terminal 4 etc.
On the other hand, even when a rejection result certificate is sent to the user terminal 4 etc., the verification result is sent along with a rejection result certificate with an electronic signature and a time stamp by the verification server 10, as in the case where the verification result is not a rejection. The original electronic contract with a time stamp added by the server 10 may be stored. In this case, the original electronic contract may be stored in a database exclusively for rejection.

2 Electronic contract operator terminal 4 User terminal 6 Signature server 7 Time stamp server 10 Verification server 11 CPU
12 ROM
13 RAM
131 Contract information 14 Storage device 141 Verification program 142 Business/service evaluation DB
143 User registration DB
144 Electronic contract operator judgment list 145 Data judgment item list 146 Verification result DB
147 Contract storage DB
15 Communication control section

Claims (9)

an evaluation information storage means for collecting evaluation information necessary for determining the reliability of electronic contract services provided by a plurality of electronic contract providers and storing the collected evaluation information for each electronic contract service;
a verification reception means for accepting a verification request for an electronic contract concluded using an electronic contract service provided by a predetermined electronic contract provider;
a verification means for verifying the reliability of the electronic contract for which the verification request has been accepted, by determining the reliability of the electronic contract service according to a plurality of predefined determination conditions;
Creation means for creating a verification result that records the determination result for each of the determination conditions;
result presenting means for presenting the created verification results to the verification requester;
Equipped with
The evaluation information storage means stores, as the evaluation information, whether "the terms and conditions are disclosed" or not, "the operational policy is disclosed" or not, and "certification by an external certification body has been obtained". Remember whether or not
If there is any item in the evaluation information for the electronic contract service with which the electronic contract for which the verification request has been accepted is concluded, the verification means determines that the reliability is above a certain level. It is determined that the
A verification server characterized by: When the verification receiving means accepts a verification request for an electronic contract of a witness type electronic contract, the verification means adds an actual signature value to the signature value of the electronic contract as a verification of the reliability of the contents of the electronic contract. If signer information is not listed or if information confirming the actual signer is not listed, it is determined that reliability above a certain level is not recognized.
The verification server according to claim 1, characterized in that: updating means for periodically collecting evaluation information for electronic contract services provided by the plurality of electronic contract providers and updating evaluation information stored in the evaluation information storage means;
The verification server according to claim 1 , characterized in that it comprises: When accepting a verification request, the verification receiving means receives an original electronic contract having a signed electronic contract and contract accompanying information;
The verification means verifies the reliability of the contents of the electronic contract based on the received original electronic contract.
The verification server according to any one of claims 1 to 3 , characterized in that: The result presenting means presents a verification result with an electronic signature and a time stamp attached.
The verification server according to any one of claims 1 to 4 , characterized in that: The verification reception means receives a verification request from a contracting party who has concluded an electronic contract, a successor who has inherited the contract from the contracting party, or an electronic contract business operator used in the contract.
The verification server according to any one of claims 1 to 5 , characterized in that: contract storage means for storing the received electronic contract original based on a request from the verification request requester;
5. The verification server according to claim 4 , further comprising a verification server. The contract storage means stores the electronic contract original to which a time stamp has been added after the verification by the verification means has been completed.
8. The verification server according to claim 7 . an evaluation information storage function that collects evaluation information necessary for determining the reliability of electronic contract services provided by a plurality of electronic contract providers, and stores the evaluation information in an evaluation information storage means for each electronic contract service;
a verification reception function that accepts a verification request for an electronic contract concluded using an electronic contract service provided by a predetermined electronic contract provider;
a verification function that verifies the reliability of the electronic contract for which the verification request has been accepted by determining the reliability of the electronic contract service according to a plurality of predefined determination conditions;
a creation function that creates a verification result that records the determination result for each of the determination conditions;
a result presentation function that presents the created verification results to the requester of the verification request;
Equipped with
The evaluation information storage function stores, as the evaluation information, whether "terms and conditions have been made public", whether "operation policy has been made public", and whether "certification from an external certification body has been obtained". whether or not it is stored in the evaluation information storage means,
If there is any item in the evaluation information for the electronic contract service with which the electronic contract for which the verification request has been accepted is concluded, the verification function determines that the reliability is above a certain level. It is determined that the
A verification program that allows a computer to perform certain tasks .

Images