credential signing device and credential signing program

Abstract

To make it possible to verify the qualifications held by contracting parties from an electronically signed electronic contract.SOLUTION: For an electronic contract, a qualification signature device 1 performs a witness-type electronic signature (qualification signature) on the electronic contract not using a private key of a contracting party or the like, but instead using a qualification signature key and an electronic certificate issued for each qualification to the qualification signature device 1. The electronic certificate corresponding to each qualification signature key includes description of qualification information (for example, the name of the qualification) indicating that the contracting party is a holder of the qualification corresponding to the qualification signature key. When performing the electronic signature, qualification information that enables verification of the contractor's qualification is also included in attribute information. Thus, the contracting party or a third party can verify, through the electronic certificate or the attribute information of the qualification signature key, that the electronic contract subjected to qualification signature processing by the qualification signature device 1 is a contract made by at least one qualified person.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to an apparatus and a program for performing an electronic signature on an electronic contract.

Background Art

[0002] An electronic contract in which an electronic signature is made on an electronic contract document (including an electronic consent form) electronically recording the contract content between parties is being used, and depending on the processing content of the contract, a party-type electronic signature and a business operator-type (witness-type) electronic signature are made on the electronic contract document. An electronically signed electronic contract document is guaranteed to be a contract by the contractor himself / herself and that the content has not been tampered with. In the case of a party-type electronic signature, an electronic signature of an electronic contract document is made using a private key and an electronic certificate (hereinafter referred to as a private key, etc.) owned by the contracting party. On the other hand, in the case of a witness-type electronic signature, as described in Patent Document 1, an electronic signature of an electronic contract document is made using a private key, etc. of an electronic signature business operator serving as a witness. In such a witness-type electronic signature, generally, since a private key, etc. of the witness rather than a private key, etc. of the contractor himself / herself is used, after strict identification of the contractor (for example, confirmation of ID (identification number) and PW (password)) by the service provider, an email address, etc. identifying the contractor is included in the attribute information as the target of the electronic signature.

[0003] By the way, not only is the content of the electronic contract document diverse, but there are also various parties who conclude the contract. For example, a qualified person such as a doctor or an architect may conclude an electronic contract under his / her qualification. In such a case, it is preferable that a third party including the contractor himself / herself can confirm that the electronically signed electronic contract document has been made by a predetermined qualification holder. However, in the case of a witness-type electronic signature, the qualification of the electronic contractor could not be known from the electronically signed electronic contract document.

Prior Art Documents

Patent Documents

[0004] [Patent Document 1] Japanese Patent Publication No. 2013-114641 [Overview of the project] [Problems that the invention aims to solve]

[0005] The present invention aims to make it possible to verify the qualifications of the contracting parties in an electronically signed electronic contract. [Means for solving the problem]

[0006] The present invention is a qualified signature device that performs witness-type electronic signatures on electronic contracts by contracting parties, A signature key storage means that stores a signature key, which is a private key issued for each of the multiple predetermined qualifications, and an electronic certificate that stores specific information that identifies the said qualification. An electronic contract acquisition means for acquiring an electronic contract that is the subject of an electronic contract by the aforementioned contracting parties, A means for determining whether the aforementioned contracting party is a qualified person with the prescribed qualifications, If the aforementioned contracting party is a qualified person, the electronic contract will be subject to the qualifications of the said qualified person. The above An electronic signature means that performs an electronic signature using a credential signing key and an electronic certificate in which the credential identification information is recorded, The present invention provides a qualification signature device characterized by being equipped with the following: [Effects of the Invention]

[0007] In this invention, when a contracting party is a qualified person, the electronic contract is handled as follows: A signature key storage means that stores a private key, which is a qualification signing key, and an electronic certificate that records specific information identifying the qualification, which are issued for each of the multiple pre-determined qualifications, Corresponds to the qualifications of the qualified person in question. do Since electronic signatures are performed using a qualified signing key and an electronic certificate that records information identifying the qualifications, it is possible to verify the qualifications held by the contracting parties in the electronically signed electronic contract. [Brief explanation of the drawing]

[0008] [Figure 1] This is an explanatory diagram illustrating the configuration of a credential signing system, including a credential signing device. [Figure 2] It is an explanatory diagram showing the configuration of the qualification signature device. [Figure 3] It is an explanatory diagram conceptually showing the content of the account DB stored in the storage device of the qualification signature device. [Figure 4] It is an explanatory diagram conceptually showing the content of the qualification DB stored in the storage device of the qualification signature device. [Figure 5] It is a flowchart showing the flow of the account registration process by the qualification signature system. [Figure 6] It is a flowchart showing a part of the flow of the qualification signature process by the qualification signature system. [Figure 7] It is a flowchart showing the continuation of the flow of the qualification signature process by the qualification signature system. [Figure 8] It is an explanatory diagram showing the display screen of the electronic contract document (surgery consent form) file displayed on the user terminal. [Figure 9] It is an explanatory diagram showing the electronic signature selection screen displayed on the user terminal. [Figure 10] It is an explanatory diagram conceptually showing the structure of the qualified signature electronic contract document signed by the qualification signature system. [Figure 11] It is a flowchart showing the flow of the verification process for the qualified signature electronic contract document for which the qualified signature has been performed. [Figure 12] It is an explanatory diagram conceptually showing the structure of the qualified signature electronic contract document according to the modification example. [Figure 13] It is an explanatory diagram showing the configuration of the qualification signature system corresponding to FIG. 1 in the modification example. [Figure 14] It is an explanatory diagram conceptually showing the content of the qualification DB corresponding to FIG. 4 in the modification example. [Figure 15] It is a flowchart showing the flow of the account registration process corresponding to FIG. 5 in the modification example.

Mode for Carrying Out the Invention

[0009] Hereinafter, preferred embodiments and modifications of the eligibility signature device 1 of the present invention will be described in detail with reference to FIGS. 1 to 15. (1) Outline of the embodiment When at least one of the contracting parties (users) of the eligibility signature device 1 is a person having a predetermined eligibility (eligible person), for an electronic contract signed with an electronic signature at the request of an eligible person having any eligibility, the contracting parties and third parties can later confirm it in a way that the witnessing type electronic signature for the electronic contract is performed. The confirmable eligibilities include various eligibilities defined by the state or the private sector, eligibilities due to joining social insurance or national health insurance, and further various eligibilities such as Japanese nationality and resident status. However, whether the contractor (user) performs an eligibility signature based on his / her own eligibility is another matter, and the eligibility signature process is performed when the contractor wishes and designates his / her own eligibility.

[0010] Specifically, for an electronic contract including an electronic consent form (hereinafter referred to as an electronic contract), the eligibility signature device 1 uses an eligibility signature key (private key) issued for each eligibility to the eligibility signature device 1 and an electronic certificate, rather than the private key of the contractor or consentor (hereinafter referred to as the contracting party) himself / herself, to perform a so-called witnessing type electronic signature (eligibility signature) for the electronic contract. In the electronic certificate of each eligibility signature key, eligibility information (for example, eligibility name, eligibility code, etc.) indicating that the requester of the electronic signature (contracting party) is the holder of the eligibility corresponding to the eligibility signature key is described by subject, subject alias, or policy OID (Object Identifier). [[ID=]14]

[0011] Furthermore, when performing an electronic signature, the eligibility signature device 1 includes eligibility information that can confirm the eligibility of the contractor in the attribute information (reason for electronic signature), obtains a hash value together with the electronic contract, and performs an electronic signature using an eligibility signature key etc. (eligibility signature key and electronic certificate) corresponding to the contractor's eligibility. Note that the attribute information (reason for electronic signature) is a part of the format of the eligibility signature process and is an area where any text information can be entered and is included in the encryption target range. This allows contracting parties and third parties to verify, through the electronic certificate and attribute information of the qualified signing key, that the electronic contract processed by the qualified signing device 1 is a contract by at least one qualified person.

[0012] In the qualified signature processing of this embodiment, an electronic signature is performed each time a signature request is received from a party to a contract, corresponding to multiple contracting parties. If the party requesting the signature is qualified, a qualified signature is performed using a private key corresponding to that qualified person's qualifications. If the person is not qualified, an electronic signature (general signature) is performed using a common signing key (a private key used in common by all non-qualified parties) that does not correspond to any qualifications. Furthermore, regarding identity and qualification verification of the contracting parties (qualified and unqualified persons), the Qualification Signature Device 1 may perform the verification itself, or it may request an external device, such as an identity verification organization 75 (functioning as a third-party organization), such as My Number Portal or an identity verification service provider, to perform the verification.

[0013] (2) Details of the embodiment Figure 1 is a diagram showing the system configuration of a qualified signature system for witness-type electronic signatures on electronic contracts, including the qualified signature device 1 in this embodiment. As shown in Figure 1, the credential signing device 1 forms a credential signing system together with user terminals 91, 92, 93, ... used by contracting parties and users who act as verifiers, a list publishing server 6, a certification authority 7, and a timestamp server 8. The credentials signing device 1 is connected to user terminals 91, 92, and 93, and the list publishing server 6 via the internet or telephone lines, and is connected to the timestamp server 8 and the certification authority 7 via a VPN (Virtual Private Network), etc.

[0014] List publishing server 6 publishes the qualification comparison table 61 via the internet and other means. This qualification comparison table 61 is used to verify the validity of the qualifications of the contracting parties in an electronically signed contract (qualified-signed electronic contract (TS)), and is configured to display a list of qualification codes, qualification names, and methods for verifying the identity of qualified persons for each qualification. The qualification comparison table 61 is generated from the qualification DB 56 of the qualification signing device 1, which will be described later. The URI of this qualification comparison table 61 is stored in the qualification database of the qualification signing device 1 (described later) and is also recorded in the attribute information during qualification signing. The qualification comparison table 61, published on the list publication server 6, is used to verify the validity of the qualifications of the contracting parties. In addition, other electronic signature service providers can use the qualification comparison table 61 to adopt the same standards as the qualification signature device 1. Although the list publishing server 6 is operated by an external organization of the credential signing device 1, it may also be operated by the same entity that operates the credential signing device 1.

[0015] A Certification Authority (CA) is an organization that verifies the identity of those who perform electronic signatures. It verifies the identity of users based on their applications and various certificates, generates private and public keys for users, and issues electronic certificates that link the public key to the owner (user) of the corresponding private key. In this embodiment, the credential signing device 1, as a user of the certification authority 7, has in advance received a credential signing key (private key), public key, and digital certificate (hereinafter referred to as "credential signing key, etc.") for each of the multiple existing credential types, and has stored them in the signing key DB. In addition, the credential signing device 1 has also in advance stored in the signing key DB a common signing key, public key, and digital certificate (hereinafter referred to as "common signing key, etc.") that are commonly used for digital signatures for uncredential users.

[0016] The timestamp server 8, based on a request from the credential signing device 1, assigns a timestamp to the credential signed electronic contract after it has undergone credential signing processing.

[0017] User terminals 91, 92, 93, ... are terminals used by contracting parties who enter into electronic contracts using witness-type electronic signatures provided by the qualified signature device 1, or by persons who verify the qualified signature electronic contracts. Furthermore, the following explanations common to user terminals 91, 92, and 93 will be collectively referred to as user terminal 9. The user terminal 9 is a computer that can connect to a communication network wirelessly or via a wired connection, and consists of, for example, a personal computer, smartphone, mobile phone, or game console. The user terminal 9 is equipped with a browser, a display device for displaying electronic contracts and the like provided by the credential signing device 1, and is configured to allow the use of short message service (SMS) and / or email using a telephone number. The user terminal 9 is also equipped with a touch panel and keyboard for performing various input operations in the credential signing process.

[0018] In Figure 1, user terminals 9 are shown as user terminal (qualified person) 91, user terminal (unqualified person) 92, and user terminal (verifier) ​​93. However, in reality, there are multiple terminals corresponding to the number of contracting parties who have accounts for electronic contracts with the qualified signature device 1, such as user terminal (administrator / qualified identity verifier) ​​94 shown in Figure 5. However, provided that at least one user (contracting party) has completed the registration of a qualified account, it is possible to perform qualified signature processing for electronic contracts where an unregistered party who has not registered an account is a contracting party.

[0019] The credential signing device 1 comprises a credential signing processing unit 2, a signature verification unit 3, an account registration unit 4, and a storage device 5, all of which are function implementation units. The storage device 5 stores various programs and data for implementing the functions of each of these function implementation units 2 to 4, such as a template DB 54 and an account DB 55 (details will be described later). The account registration unit 4 registers and updates user accounts (such as qualified and unqualified contracting parties, verifiers, and qualified administrators) in the account database 55 based on various registration information transmitted from user terminals 91 and above. The qualified signature processing unit 2 performs a witness-type qualified signature processing on the target electronic contract based on signature requests from, for example, a user (qualified person) on user terminal 91 and a user (unqualified person) on user terminal 92. The signature verification unit 3 receives verification requests for electronic contracts that have undergone qualified signature processing (hereinafter referred to as qualified signed electronic contracts) from, for example, a user terminal (verifier) ​​93 or a user terminal of a contracting party, and performs verification of the non-tampering of the qualified signed electronic contract and verification of the validity period of the qualifications of the contracting parties. Each device in Figure 1 that forms the credential signing system is capable of communicating via a communication network such as the Internet, while encrypted using SSL or TLS.

[0020] Figure 2 shows the hardware configuration that implements each function of the credential signing device 1 described in Figure 1. As shown in Figure 2, the credential signing device 1 consists of a CPU 11, ROM 12, RAM 13, storage device 5, communication control unit 14, and other devices connected by a bus line. The CPU 11 is a central processing unit that operates according to various programs stored in the storage device 5 and performs communication processing with external devices such as the list publishing server 6, the certification authority 7, the timestamp server 8, and the user terminal 9. Furthermore, CPU 11 functions as the credential signature processing unit 2 shown in Figure 1 by executing the credential signature processing PG (program) 50, functions as the signature verification unit 3 by executing the signature verification PG 51, and functions as the account registration unit 4 by executing the account registration PG 52.

[0021] ROM12 is a read-only memory that stores the basic programs and parameters necessary for the CPU11 to operate. RAM13 is a read / write memory that serves as working memory for the CPU11 when it performs electronic contract processing in this embodiment. For example, in the qualified signature processing, RAM13 stores the login ID of the qualified party to the contract, and the electronic contract at each processing stage until the qualified signature processing is completed. The communication control unit 14 performs communication processing with external devices such as the user terminal 9.

[0022] The storage device 5 is configured using one or more large-capacity storage media, such as a hard disk, and stores various programs such as the credential signature processing PG50, signature verification PG51, and account registration PG52 for the CPU 11 to perform the functions of this embodiment, as well as various data such as the template DB (database) 54, account DB 55, credential DB 56, and signature key DB 57. As mentioned above, the credential signature processing PG50, signature verification PG51, and account registration PG52 are programs that function as the credential signature processing unit 2, signature verification unit 3, and account registration unit 4, respectively, and the details of each process will be described later.

[0023] Template DB54 is used for electronic contracts involving dummy figures and stores templates for various contracts (including consent forms, oaths, pledges, etc.) that are subject to the qualified signature processing of this embodiment. The templates stored in Template DB54 include original electronic contract templates usable in various fields such as healthcare, architecture and civil engineering, public institutions, the judiciary, finance, and other situations. In this embodiment, template DB54 stores templates for various electronic contracts, categorized and saved according to predetermined industry types. However, it is also possible to store them according to other classifications, such as the Japan Standard Industrial Classification. Electronic contract templates are stored not only when created, collected, and stored by the operator of Qualified Signature Device 1, but also when created and uploaded by registered users, administrators, etc.

[0024] The various templates stored in template DB54 can be downloaded from the user terminal 91 of an account-registered user who has logged into the credential signing device 1. Furthermore, registered users can use electronic contracts stored in template DB54, as well as electronic contracts stored in external devices other than the Qualified Signature Device 1, or in their own devices, and have them authenticated by the Qualified Signature Device 1. In this case, the user terminal 9 uploads the electronic contract to be used to the Qualified Signature Device 1, which performs the authenticated signature process on it and, if necessary, saves the electronic contract before electronic signing to template DB54.

[0025] The signature key DB57 stores various credentials and common signature keys issued by Certification Authority 7. Multiple credentials (credentials and digital certificates) and common signature keys are managed using a predetermined signature key number. Each digital certificate for a qualified signing key records the subject, subject alias, or policy OID. This allows the digital certifier to verify that the user (contractor) entering into an electronic contract with the dummy possesses the necessary qualifications, such as a doctor or architect, and that the electronic signature is based on those qualifications.

[0026] Account DB55 stores various information about users and others through the account registration process. Account registration is required of users such as contracting parties and verifiers in order to have the authority to use the credential signing service provided by credential signing device 1. Figure 3 conceptually represents the contents stored in account DB55. As shown in Figure 3, the account DB 55 stores an account table 551, a qualified / identity verification information table 552, and a file table 553 for each user, and is managed by an ID set for each user.

[0027] The account table 551 stores basic information necessary to identify accounts of users who have the required qualifications (register their qualifications) and users who do not have the qualifications (do not register), including a user ID, a password (PW) required along with the ID when logging into the qualification signing device 1, the user's name, the name of their affiliated organization (optional item if applicable), an email address, and a phone number used for short message service (SMS).

[0028] Table 552 of the Eligibility and Identity Verification Information Table stores identity verification information 5521 and identity verification document data 5522, qualification verification information 5523 and qualification verification document data 5524, and qualification code 5525. Identity verification information 5521 and identity verification document data 5522 are data that identifies the user and data about the documents used for identity verification. The qualification verification information 5523 and qualification verification document data 5524 are data that indicates (identifies) the qualification if the user is a qualified person (only if they wish to register that qualification (including at the time of electronic signature as well as registration)) and data about the documents used for qualification verification.

[0029] Identity verification information 5521 contains information used to identify (verify) the user who has registered an account, and includes address, name, gender, date of birth, place of origin, age, telephone number, identity verifier ID, and identity verification method. It is also possible to include other information such as the user's email address and data stored in the IC chip used to verify their identity in identity verification information 5521. The identity verification ID is the ID of the person who verified the user's identity according to the identity verification document data 5522, and the identity verification method indicates how that verification was performed. This identity verification ID functions as identifying information for the person who verified the identity. The person who verified the identity (identity verifier) ​​may be the operator of the Qualified Signature Device 1, the organization to which the individual belongs (for example, the corporation to which the individual belongs), or a third-party auditing organization, and the identifying information for the verifier includes the ID and name of the qualified signature device.

[0030] Identity verification document data 5522 is data related to the documents used (requested for submission) by the identity verifier when verifying the user's identity. Examples of identification documents used include resident registration certificates, driver's licenses, and My Number cards. The identity verification document data 5522 stores information such as the document name, scanned image, category, identification number, and expiration date (next scheduled verification date) of the identity verification document. The expiration date is the one specified (stated) on the identification document. If no expiration date is specified, an expiration date (the next scheduled verification date) calculated from the date and time of this action may be set as necessary.

[0031] Eligibility verification information 5523 is used to confirm that a user who has registered an account is eligible, and it stores the user's address, name, gender, date of birth, place of origin, age, telephone number, eligibility verifier ID, and eligibility verification method. The Qualification Verifier ID is the identification number of the person who verified that the user possesses valid qualifications according to the qualification verification document data 5524. This Qualification Verifier ID functions as identifying information for the person who verified the qualifications of the qualified person. The person who verified the qualifications (Qualification Verifier) ​​may be the operator of the Qualification Signature Device 1, the organization to which the qualified person belongs (for example, the hospital to which the qualified doctor belongs), or a third-party auditing organization, and the identifying information includes the ID and name of the Qualification Verifier. The qualification verification method indicates how the qualification verifier performed the verification. The specific method of qualification verification is carried out in accordance with the regulations for each qualification predetermined in the qualification DB56 qualification verification method shown in Figure 4 below, or in accordance with the regulations if they are stipulated in laws or guidelines. The qualifications subject to verification include national and private certifications, enrollment in social insurance or national health insurance, and having nationality or residence status. The qualifications that can be registered are specified in Qualification DB56 shown in Figure 4.

[0032] Qualification verification document data 5524 contains data related to the documents used (requested to be submitted) by the qualification verifier when verifying the user's qualifications. Examples of documents that can be used to verify qualifications include, for example, copies of medical license certificates, copies of nursing license certificates, driver's licenses, and IC chips on My Number cards that record qualifications.

[0033] While each qualified individual may submit their own qualification verification documents, a qualification verification list created by a representative of multiple qualified individuals, such as a hospital director or other administrator, after verifying the qualifications of qualified individuals (doctors, nurses, etc.) belonging to that hospital (which must include the administrator's signature and seal, and a record of the verification date) is also acceptable. Furthermore, it includes a qualification verification list that compiles multiple different qualifications, such as those of lawyers, patent attorneys, and administrative scriveners belonging to a designated general practice firm. In this case, the qualification verification list should, in principle, be submitted in writing, but it is also possible to submit it as electronic data with the administrator's electronic signature in lieu of a signature and seal.

[0034] The qualification verification document data 5524 stores the document name, scanned image, category, identification number, and expiration date (next scheduled verification date) of the qualification verification document. The expiration date is the one specified (stated) in the qualification verification document. If no expiration date is specified, an expiration date (the next scheduled verification date) calculated from the date and time of this action may be set as necessary.

[0035] Qualification code 5525 stores the qualification code corresponding to the qualification name of the qualified person who registered the account, and is read and stored from qualification DB56 (described later in Figure 4). If a user has multiple qualifications, multiple qualification codes will be stored.

[0036] File table 553 stores files to be digitally signed and digitally signed files, associated with the ID of each account. A file subject to digital signature is a file to which a certified signature or similar process is performed. For digitally signed files stored here, it is possible to grant different permissions for operation, viewing, and access to each ID within the same organization (for example, the hospital, company, or workplace to which the user of that ID belongs). The electronically signed file stores the electronic contract file (certified electronic contract) after the certified signature processing (and timestamping) according to this embodiment has been performed. In other words, when certified signature processing according to this embodiment is performed between user A and user B, the certified electronic contract is stored in the electronic signature target file associated with user A's ID, and also in the electronic signature target file associated with user B's ID. Electronic contracts that have undergone the credential signing process and are saved in the electronically signed file include not only electronic contracts read from template DB54, but also electronic contracts read by contracting parties from other devices.

[0037] Of the specific information that identifies the user and their qualifications, stored in the account table 551 and the qualified / identity verification information table 552, the following data (a) to (g) are recorded as attribute information to be hashed in the qualification signature process. (a) ID, email address, and phone number (SMS) from account table 551 (b) Identity verification information 5521: Identity verification ID and identity verification method (c) Document name, category, identification number, and expiration date of identity verification document data 5522 (d) Qualification verification information 5523: Qualification verifier ID, qualification verification method, (e) Document name, category, identification number, and expiration date of qualification verification document data 5524 (f) Qualification code for qualification code 5525 (g) The qualification name, location of the qualification comparison table, and method of verifying the identity of the qualified person, which are stored in the qualification DB56 corresponding to the qualification code. However, of these specific pieces of information, other than (a) the ID, email address, and phone number (SMS) in account table 551, it is not necessary to record all of the credential information that can verify the user's (qualified person's) qualifications in the attribute information (reason for electronic signature); it is sufficient to record at least one. For example, one such piece of information could be the qualification code 5525 or the qualification name. This allows contracting parties and third parties to verify, through attribute information, that an electronic contract that has been processed with a qualified signature by the qualified signature device 1 is a contract made by at least one qualified person. Furthermore, the attribute information for the credential signature may store either the verifier ID and the verification method from (b), and either the credential verifier ID and the verification method from (d).

[0038] Furthermore, for electronic signatures for users who do not possess the necessary qualifications (non-qualified individuals) or users who possess the qualifications but do not wish to use their own qualifications for their signature, (a) the ID, email address, and telephone number (SMS) from account table 551 will be recorded in the attribute information (reason for electronic signature).

[0039] Returning to Figure 2, the qualification DB56 is a database of qualifications specified as targets for qualification signing processing according to this embodiment. Figure 4 conceptually represents the contents stored in the qualification DB56. As shown in Figure 4, the qualification DB56 stores information such as the qualification name, qualification code, method of verifying the identity of the qualified person, location of the qualification comparison table, and location of the qualification signing key, etc. The qualification name is a name that represents the qualification, and examples include doctor, financial planner, and Japanese citizen. The qualification code is a regular set of letters, numbers, symbols, and signs uniquely assigned to each qualification, and is subject to storage for qualification code 5525.

[0040] The method for verifying the identity of qualified individuals is specified for each qualification code. The following (a) to (d) and other various methods are stipulated as examples of specific methods prescribed in the Act on Verification of the Identity of Qualified Persons. For each qualification, one or more verification methods are specified for the verification of the identity of qualified persons. The method used when actually verifying the identity of a qualified person is stored in the qualification verification method section of the qualification verification information 5523 in the qualification / identity verification information table 552. (i) In person, the required documents (copy of professional license (medical license in the case of a doctor), copy of resident registration, email address, telephone number / professional license and photo ID) will be presented. (b) Conduct official personal authentication remotely using eKYC (electronic Know Your Customer). (h) The organization's representative (for example, the hospital director) shall verify the qualifications and identities of the qualified persons belonging to the organization, and submit a list containing the personal information and qualification information (name, address, gender, date of birth, qualification name, qualification code, etc.) of the qualified persons, along with a copy of their qualification certificate, on paper. (ii) The operator of the Qualification Signature Device 1 (verification officer) verifies the documents submitted by the qualified person (copy of qualification certificate and copy of identification card). During verification, the "qualification verification information" is read from the identification card, etc., and introduced to an external database to confirm that the qualified person actually exists.

[0041] The location of the qualification comparison table is the URI (Uniform Resource Identifier) ​​of the qualification comparison table 61 that is made publicly available on the internet by the list publication server 6. The location of the credential signing keys, etc., is the address where the credential signing key and its digital certificate used for digital signatures corresponding to each credential code are stored, and the address where the common signing key and its digital certificate are stored. In this embodiment, the list publishing server 6 classifies the qualification comparison table 61 according to a predetermined qualification (for example, medical-related, legal-related, construction-related, etc.), and publishes the qualification comparison table 61 for each classification. For this reason, different URIs are defined for each classification in the qualification DB 56 where the qualification comparison table is located. However, it is also possible to combine all qualifications into one qualification comparison table 61, and accordingly define the same URI for the location of the qualification comparison table in the qualification DB 56.

[0042] Next, we will explain the various processing operations performed by the credential signing system using the credential signing device 1. Figure 5 is a flowchart illustrating the flow of the account registration process using the credential signing system. This account registration process is a process that registers each user's account as a prerequisite for performing the credential signing process according to this embodiment. In the credential signing device 1, this is done by the CPU 11 executing the account registration PG52 in the storage device 5. In the following description, the processes performed by the CPU 11 executing various programs will be described as the operation of the credential signing device 1 (the same applies to the user terminal 9). Figure 5 illustrates an example of account registration, specifically the account registration process for hospitals. It describes the account registration process from the user terminal 91 of a physician (qualified person) belonging to a designated hospital, the user terminal 94 of the hospital administrator (qualified identity verifier), and the user terminal 92 of a patient (unqualified person).

[0043] As shown in Figure 5, when a patient who is not qualified registers an account, the patient submits their identification document, such as a resident registration certificate, My Number card, or driver's license, as registration information to the qualified signature device 1 from the patient's user terminal 92 (step 921).

[0044] On the other hand, when a qualified physician registers an account, they submit their physician's license, which serves as proof of their qualifications, along with identification documents such as a resident registration certificate, My Number card, or driver's license, as registration information to the qualification signature device 1 or the administrator (step 911). Furthermore, if registration information is submitted to the administrator instead of the qualification signature device 1, the physician's account will be submitted to the qualification signature device 1 from the user terminal 94 along with other qualified individuals, based on an identity verification list created by the administrator, rather than from the physician's own user terminal 91.

[0045] In other words, the administrator receives the qualification certificates and identification documents from doctors, nurses, physical therapists, occupational therapists, etc., who belong to the organization they manage (in this case, the hospital), and verifies their qualifications and identity (Step 941). Then, the administrator's user terminal 94 collects all submitted qualification certificates and identity verification documents to create a list of qualified and identity verification information, and saves it to the database of the user terminal 94 or the hospital to which the user belongs (step 942). The list of qualified and verified information created here is a list of the contents of account table 551 and qualified and verified information table 552, excluding the ID.

[0046] The administrator then records their own signature and seal, the verification date, etc., on the created list of qualified and verified information, and submits it to the qualified signature device 1 (step 943). In addition to submitting the list of qualified and personal identification information as a PDF file attached to an email, submission is possible through various other methods. Details will be explained in the processing section for user terminal 92.

[0047] When registration information is submitted by the user terminal 9 or its user, the credentials signing device 1 acquires it (step 101). Here, there are various patterns for submitting and obtaining registration information, as follows: (i) When a non-qualified person, a qualified person, or an administrator submits registration information in physical media (copies, printed materials) or data (by mail, email attachment, upload, etc.) and the qualification signature device 1 receives it. (b) When the user accesses the account registration screen of the credential signing device 1 from the user terminal 9 and enters each item of registration information.

[0048] If the acquired registration information includes a qualification such as a qualification name, the qualification signing device 1 refers to the qualification comparison table 61 on the list publishing server 6 and obtains the qualification code corresponding to the qualification (step 102). The qualification signature device 1 then determines whether a qualification code corresponding to the qualification included in the registration information exists (step 103). If the qualification code does not exist (step 103; N), it sends an error in the registration information to the corresponding user terminal 9 (step 104). If the registration information is submitted by mail or other means instead of from the user terminal 9, the device notifies the user who sent the information of the postal error.

[0049] If the registration information is for an unqualified person, or if a qualification code corresponding to the qualification included in the registration information exists (step 103; Y), the qualification signing device 1 verifies the contents of the registration information (including identity verification), assigns an ID to each account, and saves it to the account DB 55 (step 105). In other words, if the registration information is for an unqualified person, the operator of the qualification signature device 1 checks the contents of the registration information obtained and saves it to the account table 551. On the other hand, if the registration information is from a qualified individual, the operator of the qualification signature device 1 verifies the contents of the registration information (including identity verification and qualification verification) and stores it in the account table 551 and the qualified / identity verification information table 552. Furthermore, if the information is registration information from the administrator (eligible person / identity verification information list), the details for each eligible person listed are checked, and an ID is assigned to each eligible person before saving them in account table 551 and eligibility / identity verification information table 552. Furthermore, for qualification code 5525 in the qualified / identity verification information table 552, the qualification code obtained in step 102 will be stored.

[0050] The following methods can be used to verify and save registration information. In other words, the operator of the credentials signing device 1 verifies, inputs, and saves the contents of the submitted physical media. In addition, users may enter information into an account registration input form provided by the credential signing device 1 from their user terminal 9, and the operator may verify and save that information. In this case, it is possible to automatically register an account using only online identity verification (eKYC).

[0051] The above describes how to register an account in the credential signing device 1. The process is similar when updating (modifying or adding) an already registered account. However, when updating, since an account already exists, the user must submit registration information that includes the account and any information to be corrected or added. If the acquired registration information contains an account, the credential signing device 1 determines it to be an update request and updates the contents of that account.

[0052] Once account registration / renewal is complete, the credential signing device 1 notifies the user of the account of the registration / renewal (step 106) and terminates the process.

[0053] Next, we will explain the process of authorized signing of electronic contracts by registered users. Figure 6 is a flowchart showing a portion of the credential signing process by the credential signing system, and Figure 7 is a flowchart showing the continuation of that process. Figures 6 and 7 illustrate an example of an electronic contract using a dummy for a qualified person (doctor) and an unqualified person (patient), where the user terminals 91 and 92 and the qualified signature device 1 perform the qualified signature processing on the consent form (electronic contract). It is assumed that both the doctor and the patient have completed account registration.

[0054] As shown in Figure 6, the doctor logs in to the electronic signature service provided by the credential signing device 1 from the user terminal 91 (step 912). In other words, the doctor opens the login screen for the electronic signature service on the user terminal 91, enters their account ID and password (PW), and sends them to the credential signing device 1.

[0055] When the credential signing device 1 receives the ID and PW sent from the user terminal (doctor) 91, it checks whether they are already registered in the account DB 55 and performs login authentication (step 110). Furthermore, once login authentication is complete, the credentials signing device 1 notifies the user terminal (doctor) 91 of this fact and temporarily stores the ID of the logged-in doctor in RAM 13. On the other hand, if at least one of the ID or password is not registered, a login error is returned to the user terminal (doctor) 91.

[0056] Once the user (doctor) has logged into the electronic signature service, the user terminal (doctor) 91 uploads or retrieves the consent form (electronic contract) that is the subject of the electronic contract and displays it on the screen (step 913). In other words, the user terminal (doctor) 91 reads the consent form stored in its own device or a designated storage device managed by the hospital, and uploads it to the credentials signing device 1 as the consent form subject to this credentials signing process. The user terminal (doctor) 91 accesses the template DB 54 stored in the storage device 5 of the credentials signing device 1 and retrieves the desired consent form.

[0057] When a consent form is uploaded from a user terminal (doctor) 91, the authentication signature device 1 saves the consent form to the electronically signed file in the file table 553 corresponding to the doctor's ID. Alternatively, with the doctor's consent, it may be saved to the template DB 54. Meanwhile, when a consent form is requested, the qualified signature device 1 reads the corresponding consent form template (electronic contract) from the template DB 54 and provides it to the user terminal (doctor) 91 (step 111).

[0058] Figure 8 shows the display screen of the surgical consent form file as it appears on the user terminal (doctor) 91. The surgical consent form file shown in Figure 8 was not retrieved from the template DB54 of the qualified signature device 1, but rather was a surgical consent form file that had been created and saved in advance within the hospital where the physician works. As shown in Figure 8, the display screen for the surgical consent form file shows fields such as the format field 801, thumbnail field 802, internal management field 803, recipient field 804, and signature selection button 809. Form field 801 records the file name "Surgical Consent Form 11.pdf," along with its expiration date, date and time of transmission, and sender. In the example in Figure 8, the sender field indicates that it was created by "Takumi Fuko," an office worker at the Memorial Hospital. Thumbnail field 802 displays a thumbnail image linked to the "surgical consent form" that is subject to the qualified signature processing. The contracting parties, such as the doctor or patient, will click on this thumbnail image to review the contents of the surgical consent form displayed and then consent to the electronic signature by the qualified signature device 1.

[0059] Internal management section 803 is where the management information created within the hospital is recorded. The recipient field 804 records the names of the contracting parties under this surgical consent form (Dr. Itataro, Outpatient Masao) and the address to which each surgical consent form will be sent. The signature selection button 809 displays a screen for selecting the type of electronic signature (general, qualified, etc.) for the surgical consent form. This signature selection button 809 can only be selected by the user after selecting the thumbnail field 802 to view and confirm the linked surgical consent form.

[0060] Figure 9 shows the electronic signature selection screen that appears when the signature selection button 809 is selected. As shown in Figure 9, the electronic signature selection screen displays the signature qualification selection field 901, the qualified signature request button 909, and other elements. The signature qualification selection field 901 specifies the following forms of electronic signatures that can be selected in relation to the contract (surgical consent form): a general signature without a qualified signature, a qualified signature (Japanese national), a qualified signature (physician), a qualified signature (dentist), etc. The qualified signature request button 909 is a button that requests the qualified signature device 1 to provide an electronic signature corresponding to one of the selected signature formats.

[0061] Returning to Figure 6, the user terminal (doctor) 91 designates a user other than a doctor (patient) for the surgical consent form (step 914). In other words, the doctor enters the name, recipient, patient's name, and recipient's name in the recipient field 804. However, this step 914 can be omitted if it has already been filled in by the creator of the file, as shown in the surgical consent form file in Figure 8.

[0062] Next, on the user terminal (doctor) 91, the doctor clicks on the thumbnail image in the thumbnail column 802 to display the "Surgical Consent Form." The doctor then reviews the displayed content and enters their name in the signature field within the surgical consent form (or confirms the name if it has already been entered by the creator). Subsequently, the doctor selects the signature selection button 809 displayed on the screen to display the electronic signature selection screen and selects the type of qualified signature to request from the qualified signature device 1 (in this case, qualified signature (doctor)). As a result, the user terminal (doctor) 91 transmits to the credential signing device 1 that "credential signing (doctor)" has been selected (step 915).

[0063] When "Qualified Signature (Physician)" is notified from the user terminal (physician) 91, the qualified signature device 1 queries the qualified code associated with the ID (step 112). In other words, the credential signing device 1 reads the ID stored in RAM 13 in step 110, determines whether the qualification identified by the credential code 5525 (see Figure 3) associated with this ID matches the qualification based on the notified signature format (in this case, a doctor), and returns confirmation information to the user terminal (doctor) 91 if they match, and mismatch information if they do not match. If the user terminal (doctor) 91 receives confirmation information, it will enable the selection of the credential signature request button 909 shown in Figure 9. If mismatched information is returned, a message to that effect will be displayed on the screen, and the user will need to change to a different credential signature format.

[0064] When the physician selects the now-selectable qualified signature request button 909, the user terminal (physician) 91 sends a request for an electronic signature by that qualified person to the qualified signature device 1 (step 916), and the qualified signature device 1 receives the request for an electronic signature (step 113).

[0065] The qualification signing device 1 then checks the expiration date of the qualification corresponding to the physician's ID stored in RAM 13 (step 114). In other words, the credentials signing device 1 determines that the document is still valid if the expiration date stored in the credentials verification document data 5524 corresponding to the ID is later than the current date. Furthermore, the system may be configured to consider the item as still valid if the expiration date is at least a predetermined period T away from the current date. While the predetermined period T is arbitrary, a default period of, for example, one month is set. If the qualification has expired (step 114; N), the qualification signing device 1 sends an error screen (expired) to the user terminal (doctor) 91 (step 115), and the user terminal (doctor) 91 notifies the doctor that the qualification has expired based on the error screen.

[0066] On the other hand, if the qualification is still valid (Step 114; Y), the qualification signing device 1 creates attribute information to be attached to the surgical consent form (Step 116). In other words, the qualified signature device 1 refers to the account DB 55 corresponding to the ID of the doctor to whom the signature request has been made, reads each of the above-mentioned data (a) to (g) from the account table 551 and the qualified / identity verification information table 552, and creates attribute information to be attached to the surgical consent form.

[0067] Subsequently, the qualified signing device 1 performs qualified signing to create a "primary signed electronic contract" (step 117). In other words, the credential signing device 1 looks up the location of the credential signing key etc. from the credential code 5525 of the credential (doctor) corresponding to the signature format notified by the user terminal (doctor) 91 in step 915, reads the credential signing key etc. for the credential (doctor) (credential signing key and digital certificate) from the signing key DB 57, temporarily stores it in RAM 13, and performs credential signing using the credential signing key etc.

[0068] Figure 10 is a conceptual diagram illustrating the structure of an electronically signed contract after it has been signed by a qualified professional. Note that Figure 10 does not represent a specific surgical consent form, but rather a more general representation of the structure of an electronic contract (including a surgical consent form) between parties A and B after it has been signed by a qualified professional. The following describes the process of performing credential signing using the credential signing key, etc., in Step 117, with reference to Figure 10. The Qualified Signature Device 1 attaches the attribute information 122 of Contractor A (Doctor) created in step 116 to the "Electronic Contract (Original) 120" (Surgical Consent Form) to create the "First Electronic Contract" 123, and calculates the hash value 124 of this First Electronic Contract.

[0069] Furthermore, the credential signing device 1 uses the credential signing key (private key) corresponding to the signature format (credential signing (doctor)) notified by the user terminal (doctor) 91 in step 915, and calculates a signature value 125 by encrypting the calculated hash value 124. The qualified signature device 1 creates a "primary signed electronic contract" 127 based on the request of party A (qualified signature (doctor)) by embedding the calculated signature value 125 and the "electronic certificate" 126 corresponding to the qualified signature key used into the "first electronic contract" 123. Note that while the "Primary Signature Electronic Contract" 127 embeds an electronic certificate, it is also acceptable to embed both the electronic certificate and its revocation information. If the revocation information is not embedded, it will be necessary to check whether the electronic certificate has expired from the revocation information of the certification authority 7, which issued the electronic certificate.

[0070] Returning to Figure 6, after the qualification signature (step 117) based on the user's (doctor's) request is completed, the qualification signature device 1 sends a qualification signature completion screen to the user terminal (doctor) 91 that requested the qualification signature (step 118). Meanwhile, the user terminal (doctor) 91 displays the received qualification signature completion screen to notify the user (doctor) (step 917).

[0071] Next, as shown in Figure 7, the qualified signature device 1 presents the "Primary Signature Electronic Contract" 127 to the user terminal (patient) 92 of the user (patient), who is an unsigned contracting party (step 119), and the user terminal 92 displays this on its screen (step 922). In other words, the qualified signature device 1 sends an SMS to the user's (patient's) phone number containing a URL where the "primary signed electronic contract" 127 is stored, prompting the user to confirm it and request an electronic signature. Here, the phone number used for the SMS is that of Masao Nagai, the user (patient) specified in the recipient field 804 in Figure 8. If this recipient field 804 is not specified, the phone number of the user, etc., specified by the user terminal (doctor) 91 in step 914 is used.

[0072] Upon receiving a request for an electronic signature via SMS, the user (patient) accesses the specified URL from their terminal (patient) 92 to display the "Primary Signature Electronic Contract" 127 on the screen (step 922). For the "Primary Signature Electronic Contract" 127 displayed on the screen, the user (patient), like the user (doctor), clicks the thumbnail image in the thumbnail column 802 (Figure 8) to display the "Surgical Consent Form," confirms its contents, and enters the patient's name in the signature field within the surgical consent form (confirming the name if it has already been entered by the creator). Furthermore, the patient selects the signature selection button 809 to display the electronic signature selection screen (Figure 9) and selects the type of qualified signature (in this case, a general signature) (step 923). If this general signature is selected, the qualified signature device 1 does not need to verify the qualification code (step 112), so the qualified signature device 1 makes the qualified signature request button 909 selectable. When the user (patient) selects the credential signature request button 909, the user terminal (patient) 92 requests a general signature from the credential signature device 1 (step 924).

[0073] When the qualified signature device 1 receives an electronic signature request from the user terminal (patient) 92, it creates attribute information to be attached to the "primary signature electronic contract" 127, which includes the surgical consent form (step 120). In other words, since the request for an electronic signature is a general signature, the qualified signature device 1 refers to the account DB 55 corresponding to the user's (patient's) ID, reads the ID, email address, and phone number (SMS) from the account table 551, and creates attribute information.

[0074] Then, the credential signing device 1 reads the common signing key from the common key DB 58 and performs a general signature (step 121). In other words, as shown in Figure 10, the qualified signature device 1 attaches the attribute information (attribute information of contractor B) created to the "primary signed electronic contract" 127 to create the "second electronic contract" 132, calculates the hash value 133 of this "second electronic contract" 132, and encrypts it with a common signing key to calculate the signature value 134. The qualified signature device 1 embeds the calculated signature value 134 and the "electronic certificate" 135 corresponding to the common signing key into the "second electronic contract" 132, thereby creating a "qualified signature electronic contract" 136 based on the requests of the doctor (party A) and the patient (party B). In addition, revocation information can also be embedded along with the electronic certificate 135, similar to the case of qualified signatures.

[0075] At this stage, the authorized signature device 1 sends a general signature completion screen to the user terminal (patient) 92 indicating that the general signature based on the patient's request has been completed (step 122), and the user terminal (patient) 92 displays the received general signature completion screen to notify the user (patient) (step 925).

[0076] The qualified signing device 1 further requests the timestamp server 8 to apply a timestamp to the "qualified signed electronic contract" 136, thereby creating a "qualified signed electronic contract (TS)" 138 (step 123). Then, the "Qualified Signature Electronic Contract (TS)" 138 is saved with a predetermined signature management number attached to the electronically signed file in the file table 553 of the two parties in the account DB 55 associated with the ID of the user (doctor) who performed the qualified signature and the ID of the user (patient), and is transmitted to the user terminal (doctor) 91 and the user terminal (patient) 92 (step 124), thus ending the qualified signature process. Meanwhile, the user terminal (doctor) 91 and the user terminal (patient) 92 display the received "certified electronic contract (TS)" 138 on their screens. After the doctor and patient confirm it, they save it to a designated storage device according to the save processing operation (steps 918 and 926), and then the process ends.

[0077] Next, we will explain the verification process for certified electronic contracts (TS). Figure 11 is a flowchart illustrating the verification process for a certified electronic contract (TS) that has been signed by a qualified person. Furthermore, since the verification of the Qualified Signature Electronic Contract (TS) is performed not only by the parties to the contract but also by qualified administrators and other verifiers, this is indicated on the user terminal 95 used by these individuals. As shown in Figure 11, the user terminal (verifier) ​​95 displays the designated qualified electronic contract (TS) on the screen based on the verifier's operation (step 951). Then, when the verifier selects the verify button, the signature management number attached to the qualified electronic contract (TS) is sent to the qualified signing device 1 to request verification (step 952).

[0078] The qualified signature device 1 reads the qualified electronic contract (TS) with the specified signature management number and performs checks for non-tampering and expiration (step 131). In other words, the credential signing device 1 obtains the hash value 133 of the second electronic contract 132 by decrypting the signature value 134 using the public key contained in the electronic certificate 135 embedded in the credential signed electronic contract (TS). This hash value 133 is the value calculated during the credential signing process. Furthermore, the credential signing device 1 obtains a new verification hash value from the second electronic contract 132 (see Figure 10) and verifies that it matches the hash value 133.

[0079] Furthermore, the credential signing device 1 obtains the hash value 124 of the first electronic contract 123 by decrypting the signature value 125 using the public key described in the electronic certificate 126, and verifies that it matches the hash value of the first electronic contract 123 calculated for verification purposes. Then, the credential signing device 1 verifies that the electronic contract (original) is unaltered (not tampered with) if the hash values ​​133 and 124 both match.

[0080] Furthermore, as part of the validity period check, the qualification signature device 1 verifies that the validity period recorded based on the qualification verification document data 5524 is later than the date and time of the qualification signature on the qualification-signed electronic contract (TS) being verified. This verification proves that the electronic contract was made by a qualified person with valid credentials. Alternatively, the timestamp acquisition date and time can be used instead of the qualification signing date and time. In this case, the qualification signing device 1 verifies that the qualification's expiration date is later than the timestamp acquisition date and time.

[0081] In this way, in addition to verifying the non-tampering of a qualified electronic contract (TS), by including the expiration date of the qualification in the attribute information that is to be signed (hashed), it is possible to verify that the electronic contract was signed by a qualified person at the request of a qualified person who has valid qualifications.

[0082] After the authentication signature device 1 has finished checking for non-tampering and expiration date, it presents the verification results to the user terminal (verifier) ​​95 (step 132), and the user terminal (verifier) ​​95 displays the verification results on its screen (step 953). The user (verifier) ​​can confirm from the verification results displayed on the screen that the qualified signature electronic contract (TS) has not been tampered with and that the qualified signature device 1 has verified that it was signed by the qualified person within the validity period of the qualification.

[0083] Based on the actions of the verifier who requests further specific qualification verification, the user terminal (verifier) ​​95 displays the qualification comparison table on the screen (step 954). In other words, the user terminal (verifier) ​​95 reads the location (URI) of the qualification comparison table recorded in the attribute information 122 of contractor A (qualified person) in the qualified electronic contract (TS) 138, accesses the list publication server 6 to read the qualification comparison table 61 and displays it on the screen. The user terminal (verifier) ​​95 also displays attribute information and the contents of the electronic certificate in accordance with the verifier's operations, along with the qualification comparison table.

[0084] The verifier can confirm the following (A) to (E) by referring to and comparing the qualification comparison table and the contents of the qualification signature (attribute information 122, 131, electronic certificates 126, 135, etc.) displayed on the user terminal (verifier) ​​95 (step 955). (A) It can be confirmed that the qualification name that the qualification signature device 1 determines the contractor possesses is listed in the attribute information 122 of the qualification signature electronic contract (TS) 138. Alternatively, you can verify the common name of the electronic certificate used for the signature. (B) Refer to the qualification comparison table 61 to confirm the qualification code corresponding to the qualification name. Alternatively, it can be confirmed that the common name of the electronic certificate in (A) above corresponds to the qualification name.

[0085] (C) You can verify whether the qualification name recorded in attribute information 122 of the qualified electronic contract (TS) 138 matches the qualification comparison table 61. This allows us to verify that the signature was performed by the appropriate entity. (D) It can be confirmed that the expiration date stated in attribute information 122 is later than the date and time of the authorized signature recorded in authorized signature electronic contract (TS) 138. This allows us to confirm that the user's (qualified person's) account has been registered and provided after proper eligibility verification has been carried out. (E) By referring to the "Identity Verification Method" and "Qualification Verification Method" in the Qualification Comparison Table 61, it is possible to confirm whether the qualification verification and identity verification for the qualified person in question have been carried out appropriately. Furthermore, third parties can also verify the "identity verification method" and "qualification verification method" policies established by the qualification signature device 1 and the organization (company, hospital, etc.) to which the qualified person belongs.

[0086] As explained above, in electronic contracts using witness-type electronic signatures, the qualified signature device 1 performs prior qualification verification and party verification before registering an account if the contracting parties are qualified individuals with prescribed qualifications such as doctors or architects. Furthermore, electronic contracts such as surgical consent forms are electronically signed (certified signatures) using a different certified signing key for each qualification and an electronic certificate that describes the qualification information indicating that the person is the holder of the qualification corresponding to that certified signing key. Therefore, the qualifications held by the contracting parties can be confirmed from the certified electronic contract (certified electronic contract 136, or certified electronic contract (TS) 138) (referred to as the first certified verification configuration). Furthermore, when performing a qualified signature, at least one piece of qualification verification information is recorded in the attribute information 122 of the qualified person (contractor A), which is the target of the hash value calculation. Therefore, the qualification information of the contracting parties can also be confirmed from the attribute information 122 of the electronically signed electronic contract (referred to as the second qualification verification configuration). Furthermore, each qualified person's account records the verifier of their qualification and the expiration date, and since this information is recorded in the attribute information, it is possible to verify that the electronic contract was made by a qualified person with valid qualifications.

[0087] Although an embodiment of the credential signing device 1 has been described, it is also possible to modify it as follows. For example, in the embodiments and modifications described, the description explains a case in which the credential signature device 1 acquires registration information including identity verification information and credential verification information, performs identity verification (confirming the existence of a qualified person) and credential verification (confirming that the person is a qualified person and that the qualification is valid) based on the acquired registration information, and registers the information in the account DB 55 if both verifications are successful. In contrast, in this modified version, the identity and qualification verification of qualified persons based on registration information is requested from a third-party organization outside the qualification signature device 1, namely an identity verification organization (for example, My Number Portal or an identity verification service provider). If identity and qualification verification is successful based on the verification results received from the identity verification organization, the received registration information and tokens are saved in the qualified / identity verification information table 552 of the account DB 55. The following describes a case where an identity verification agency performs both identity verification and qualification verification, but it is also possible for separate third-party organizations to perform identity verification and qualification verification.

[0088] The following description focuses on the differences between the qualification signature device 1 in this modified example and the embodiment described above. Figure 13 shows the configuration of the credential signing system in a modified example and corresponds to Figure 1 of the embodiment. Identity verification agencies (75) are external organizations that perform identity verification for both qualified and unqualified individuals, as well as qualification verification for qualified individuals. They function as third-party organizations, and examples include My Number Portal and identity verification service providers. As shown in Figure 13, the credential signing device 1 of this modified example is further connected to an identity verification authority 75 via the internet or VPN.

[0089] Identity Verification Authority 75 has an Authority Database 76. Authority Database 76 stores registration information (identity verification information, qualification verification information) submitted by non-qualified persons, qualified persons, administrators, and qualified identity verifiers. The identity verification authority 75 performs identity and qualification verification by querying the authority DB 76 based on the transmission of registration information and verification request from the qualification signature device 1, and transmits a token confirming that the user is the person in question and the holder of the qualification as the verification result (identity verification result, qualification verification result) to the qualification signature device 1. Here, the token transmitted by the identity verification authority 75 is a unique code indicating that a verification query has been made. Furthermore, regarding identity and qualification verification of the contracting parties (qualified and unqualified persons), the Qualification Signature Device 1 may perform the verification itself, or it may request an external device, such as an identity verification organization 75 (functioning as a third-party organization), such as My Number Portal or an identity verification service provider, to perform the verification.

[0090] In the embodiment shown in Figure 3, the identity verification information 5521 in account DB 55 stores the "identity verifier ID" and the "identity verification method" (see Figure 3), whereas in this modified example, the "institutional DB 76 token" and the "query to institutional DB 76" (indicating that a query to institutional DB 76 was made as a method of verifying eligibility) are stored. In this modified example, the "token of Institution DB 76" refers to the token received from the Identity Verification Authority 75 as a verification result (identity verification result, eligibility verification result) in response to a request for verification from the Identity Signature Device 1 to the Identity Verification Authority 75's Institution DB 76 by sending registration information. In addition, the contents of the identity verification document data 5522 and qualification verification document data 5524 stored in account DB 55 are the same as in the embodiment shown in Figure 3. However, if there are items that overlap with the contents stored in institutional DB 76, they can be excluded from storage in account DB 55.

[0091] The token obtained as a result of the verification is included, along with the URL of the authentication site, the identity verification authority 75, in the attribute information 122 attached to the electronic contract (original) when the qualified person signs it using the qualified signing device 1, or in the form portion that is subject to hashing, and serves as the basis for calculating the hash value. This allows the qualifications of the qualified person to be verified by the contracting parties or verifiers in the verification process of the electronic contract with the qualified signature at a later date. This allows users to verify their credentials by accessing the authentication site, Identity Verification Authority 75, and entering their token.

[0092] Note that institutional DB76 may not always return tokens; for example, it may only return registration information, or the results may only be displayed on a web screen. In such cases, the response to the web request or a screenshot of the web screen obtained from the institutional DB76 may be stored in the identity verification document data 5522, and a hash value may be calculated from this identity verification document data 5522 and used in place of the token from the institutional DB76. In this way, by using the responses to web requests and web screen screenshots obtained from the institutional DB76 as the basis for calculating hash values, it becomes possible to verify the qualifications of qualified individuals by checking whether they match the hash value recalculated from the identity verification document data 5522, rather than having to access the authentication site, identity verification institution 75, and enter a token. In practice, each of the 75 identity verification agencies is defined as a qualified method of verifying the identity of its members.

[0093] Figure 14 conceptually represents the contents of qualification DB56 in a modified example and corresponds to Figure 4 of the embodiment. In the embodiment of the qualification DB56, the methods for verifying the identity of a qualified person, which are defined for each qualification code, are described as "Qualified Person Identity Verification Methods" (see Figure 4), specifically (a) to (d). In contrast, this modified version adds (e) as a method for verifying the identity of qualified persons: "Upon inquiry to Institution DB 76, an identity verification institution 75 returns a token as a verification result." As a result, as shown in Figure 14, the "Method of verifying the identity of qualified person" column for qualification names such as physician, dentist, pharmacist, etc., is set to (a) to (e).

[0094] Figure 15 is a flowchart illustrating the account registration process in a modified example, corresponding to Figure 5 of the embodiment. In this modified example, the account registration process is performed by the identity verification authority 75, so the processing by the user terminal 94 in the embodiment is unnecessary. Furthermore, as a prerequisite for the account registration process using this modified example, it is assumed that documents and data (registration information) necessary for identity verification and qualification verification have been submitted to the Identity Verification Authority 75 by non-qualified persons, qualified persons, qualified administrators, qualified identity verifiers, etc., and are registered in the Authority DB 76.

[0095] As shown in Figure 15, the user sends registration information (identity verification information, eligibility verification information), including, for example, a certificate of qualification or a resident registration certificate, as required by the institution DB 76 of the identity verification authority 75, from the user terminal 91 to the eligibility signature device 1, and requests account registration (step 911). When the credential signing device 1 obtains registration information from the user terminal 91, it temporarily stores it in RAM 13 (step 101), and then transmits the received registration information as information related to identity verification and credential verification requested by the identity verification authority 75's organization DB 76 to request verification (step 1011).

[0096] When an inquiry for verification is received from the institution DB76, the identity verification institution 75 performs identity verification and qualification verification, and sends a token that confirms the identity of the person and the holder of the relevant qualification as the verification result (identity verification result, qualification verification result) to the qualification signature device 1. As a result, the credentials signature device 1 obtains a token from the identity verification authority 75 as the result of the verification inquiry (identity verification result, credentials verification result). Since the identity verification and qualification verification are completed upon receipt of the token in response to the verification inquiry, the qualification signature device 1 creates an account for the qualified person from the contents of the registration information temporarily stored in RAM 13 and the token, and saves it to the qualification / identity verification information table 552 of account DB 55 (step 1012).

[0097] Next, the credential signing device 1 obtains the credential code corresponding to the credential of the credential holder of the user terminal 91 by referring to the credential comparison table 61 on the list publishing server 6 (step 102). The following processes (steps 103 onwards) are the same as those in the embodiment.

[0098] As another variation, for example, the embodiment described above describes the case where credential signing is performed using both the first credential configuration and the second credential configuration, as described above. Alternatively, the qualification signature may be performed using only one of the two qualification configurations, either the first or the second. The structure of the qualified electronic contract 136(138) in these cases will be explained with reference to Figure 10.

[0099] When using only the first qualification verification configuration, the qualification signing device 1 includes the information described in (a) above in the attribute information 122 of contractor A (qualified person), similar to the attribute information 131 of contractor B (unqualified person), but does not include the information described in (b) to (g). Then, the qualification signing device 1 performs an electronic signature (qualified signature) using a qualification signing key corresponding to the qualification and an electronic certificate that describes the qualification information indicating that the person is the holder of the qualification corresponding to the qualification signing key, similar to the embodiment.

[0100] When using only the second credential verification configuration, the credential signing device 1 includes the information (a) to (g) in the attribute information 122 of contractor A (qualified person) in the same manner as in the embodiment, and performs an electronic signature (general signature) on its hash value 124 using a common signing key and an electronic certificate. Furthermore, when using only the second qualification verification configuration, the qualification signing device 1 may, as shown in Figure 12, attach the attribute information of all contracting parties (qualified parties should include (a) to (g), and unqualified parties should include (a)) to the first electronic contract 123 and perform a general signature using the common signing key and electronic certificate. In this case, each attribute information item will include (a) to (g) for qualified parties and (a) for unqualified parties.

[0101] Furthermore, the embodiments and modifications described above describe a case in which the qualified signature device 1 performs qualified signature processing based on confirmation and signature requests for surgical consent forms from two individuals: a physician from user terminal (physician) 91 and a patient from user terminal (patient) 92. In addition, the qualified signature device 1 can perform qualified signature processing even when there are three or more contracting parties, such as a qualified physician, a patient, and the patient's guarantor. In this case, the qualified signature device 1 performs qualified signature processing using a qualified signature key, etc., for the qualified physician's signature request, a general signature using a common key, etc., for the patient's signature request, and a general signature using a common key, etc., for the guarantor's signature request.

[0102] Furthermore, the embodiments and modifications described above describe a case where, after a qualified signature is obtained from a qualified person (physician), a general signature is obtained in response to a request for a general signature from a non-qualified person (patient). In contrast, the order in which signature requests are made does not matter, with qualified or unqualified individuals signing first. If the request comes first from an unqualified individual, the first electronic contract (corresponding to the first electronic contract 123 in Figure 10) will be signed by general signatory, including the ID, email address, and phone number (SMS) in the attribute information of contractor B (unqualified), and then signed by qualified signatory, including the qualification information (a) to (g) in the attribute information of contractor A (qualified).

[0103] Furthermore, two or more of the multiple contractors may be qualified, and in this case, their qualifications may be the same or different. For example, in the case of a hospital construction contract, the construction contract between a qualified person (doctor) and a qualified person (architect) may be signed using a qualified signature key corresponding to the doctor and a qualified signature key corresponding to the architect.

[0104] Furthermore, if there are multiple qualified and unqualified parties to the contract, for example, in the case of N contracting parties, instead of performing a total of seven separate qualified or general signatures, qualified and unqualified parties with the same qualification may be grouped together to perform either a qualified or unqualified signature. For example, in the case of an electronic contract involving a total of seven people: qualified individuals a1-a3 (qualified under qualification A), b1-b2 (qualified under qualification B), and two unqualified individuals x1-x2, the attribute information (including qualification information) of each qualified individual a1-a3 is attached together and signed using the signing key for qualification A; the attribute information (including qualification information) of each qualified individual b1-b2 is attached together and signed using the signing key for qualification B; and the attribute information (excluding qualification information) of each unqualified individual x1-x2 is attached together and signed using the common signing key. This allows for the completion of the qualification signature process with a number of electronic signatures corresponding to the number of qualified and unqualified individuals (3 signatures), rather than a number of electronic signatures corresponding to the total number of subscribers N (7 signatures).

[0105] Furthermore, in the embodiments and modified examples described, the qualified signature device, etc., when the contract type is an electronic contract using a witness-type electronic signature can be configured as follows. (Configuration 11) A qualified signature device that performs witness-type electronic signatures on electronic contracts by contracting parties, An electronic contract acquisition means for acquiring an electronic contract that is the subject of an electronic contract by the aforementioned contracting parties, A means for determining whether the aforementioned contracting party is a qualified person with the prescribed qualifications, If the contracting party is a qualified person, the electronic signature means performs an electronic signature on the electronic contract using a qualified signing key, which is a private key created in accordance with the qualifications of the qualified person, and an electronic certificate on which the specific information of the qualifications is recorded. A qualification signature device characterized by being equipped with the following. (Configuration 12) The electronic signature means, upon receiving a request from the qualified person, performs an electronic signature using the qualified signing key and the electronic certificate. A qualification signature device according to configuration 11, characterized by the above. (Configuration 13) The electronic signature means is In response to a request for signature from the aforementioned qualified contracting party, the qualified signature is performed using the aforementioned qualified signing key and the aforementioned electronic certificate. In response to a signature request from a contracting party who is not qualified, a general signature is performed using a common signing key (a private key that does not correspond to qualifications) and an electronic certificate that does not contain information identifying the qualifications. A qualification signature device according to configuration 11 or configuration 12, characterized by the above. (Configuration 14) The account of the qualified person is provided with an account DB in which identity verification information and qualification verification information are stored, and the account of the unqualified person is provided with an account DB in which identity verification information is stored. The qualification determination means determines whether the contracting party is a qualified person or not using the account database. A qualification signature device according to configuration 11, configuration 12, or configuration 13, characterized by the above. (Configuration 15) The account DB stores login identification numbers and passwords for each qualified and unqualified user. The aforementioned qualification determination means determines whether the contracting party is qualified or ineligible based on the identification number used when logging in. A qualification signature device according to configuration 14, characterized by the above. (Configuration 16) A means for obtaining registration information, which includes personal identification information and qualification verification information, from the qualified person, A verification means that, based on the registration information obtained, performs identity verification to confirm the existence of the qualified person and qualification verification to confirm that the qualifications held by the qualified person are valid. If the aforementioned identity verification and qualification verification are successful, a registration means for registering the acquired registration information to the account of the qualified person in the account database, A qualification signature device according to configuration 14, characterized by comprising the following: (Configuration 17) The qualification signature device according to Configuration 16, characterized in that the verification means requests identity verification based on the acquired identity verification information and qualification verification based on the acquired qualification verification information to the same or separate third-party organizations, and obtains an identity verification result indicating that the qualified person exists and a qualification verification result indicating that the qualifications held by the qualified person are valid. (Configuration 18) If the contracting party is a qualified person, the electronic signature means attaches attribute information recording the qualification information identifying the qualified person's qualifications to the electronic contract and performs an electronic signature using the qualified signing key and electronic certificate. A qualification signing device according to any one of the configurations 11 to 17, characterized by the above. (Configuration 19) A qualified signature program that enables a computer to function as a qualified signature device that performs witness-type electronic signatures on electronic contracts by contracting parties, An electronic contract acquisition function that acquires electronic contracts that are subject to electronic contracts by the aforementioned contracting parties, A qualification determination function that determines whether the aforementioned contracting party is a qualified person with the prescribed qualifications, If the contracting party is a qualified person, the electronic signature function performs an electronic signature on the electronic contract using a qualified signing key, which is a private key created in accordance with the qualifications of the qualified person, and an electronic certificate on which the specific information of the qualifications is recorded. A credential signing program characterized by enabling a computer to perform the following actions.

[0106] It is also possible to configure it as follows: (Configuration 21) A qualified signature device that performs witness-type electronic signatures on electronic contracts by contracting parties, An electronic contract acquisition means for acquiring an electronic contract that is the subject of an electronic contract by the aforementioned contracting parties, A means for determining whether the aforementioned contracting party is a qualified person with the prescribed qualifications, If the aforementioned contracting party is a qualified person, the electronic signature means attaches personal information that identifies the qualified person and attribute information recording the qualification information that identifies the qualification to the electronic contract and performs an electronic signature. A qualification signature device characterized by being equipped with the following. (Configuration 22) The electronic signature means, upon receiving a request from the qualified person, attaches the attribute information containing the personal information and the qualification information to the electronic contract and performs an electronic signature. A qualification signature device according to configuration 21, characterized by the above. (Configuration 23) If the contracting party is an unqualified person who does not possess the necessary qualifications, the electronic signature means attaches attribute information containing personal information that identifies the unqualified person to the electronic contract and performs the electronic signature. A qualification signature device according to configuration 21 or configuration 22, characterized by the above. (Configuration 24) The account of a qualified person is provided with an account DB in which personal information and qualification information are stored, and personal information and qualification information are stored in the account of an unqualified person. The qualification determination means determines whether the contracting party is a qualified person or not using the account database. A qualification signing device according to configuration 21, configuration 22, or configuration 23, characterized by the above. (Configuration 25) The account DB stores login identification numbers and passwords for each qualified and unqualified user. The aforementioned qualification determination means determines whether the contracting party is qualified or ineligible based on the identification number used when logging in. A qualification signature device according to configuration 24, characterized by the features described above. (Configuration 26) A means for obtaining registration information, which includes personal identification information and qualification verification information, from the qualified person, A verification means that, based on the registration information obtained, performs identity verification to confirm the existence of the qualified person and qualification verification to confirm that the qualifications held by the qualified person are valid. If the aforementioned identity verification and qualification verification are successful, a registration means for registering the acquired registration information to the account of the qualified person in the account database, A qualification signature device according to configuration 24, characterized by comprising the following: (Configuration 27) The qualification signature device according to Configuration 26, characterized in that the verification means requests identity verification based on the acquired identity verification information and qualification verification based on the acquired qualification verification information to the same or separate third-party organizations, and obtains an identity verification result indicating that the qualified person exists and a qualification verification result indicating that the qualifications held by the qualified person are valid. (Configuration 28) If the contracting party is a qualified person, the electronic signature means attaches attribute information to the electronic contract that further records at least one of the identification information of the person who verified the qualification of the qualified person and the method of verifying the qualification, and then performs an electronic signature. A qualification signing device according to configuration 2 of any one of configurations 21 to 27, characterized by the following: (Configuration 29) A qualified signature program that enables a computer to function as a qualified signature device that performs witness-type electronic signatures on electronic contracts by contracting parties, An electronic contract acquisition function that acquires electronic contracts that are subject to electronic contracts by the aforementioned contracting parties, A qualification determination function that determines whether the aforementioned contracting party is a qualified person with the prescribed qualifications, If the aforementioned contracting party is a qualified person, the electronic signature function attaches personal information that identifies the qualified person and attribute information that records the qualification information identifying the qualification to the electronic contract and performs an electronic signature. A credential signing program characterized by enabling a computer to perform the following actions. [Explanation of symbols]

[0107] 1. Qualified Signature Device 2. Qualified Signature Processing Unit 3. Signature Verification Department 4. Account Registration Section 5 Storage device 6. List publishing servers 7. Certificate Authority 8 Timestamp Server 9, 91-95 User terminals 11 CPU 12 ROM 13 RAM 14. Communication Control Unit 50 Qualified Signature Processing PG 51 Signature Verification PG 52 Account Registration PG 54 Template DB 55 Account DB 56 Qualification DB 57 Signing key DB 61. Qualification Comparison Table 75 Identity Verification Organizations 76 Institutional Databases 122 Attribute information 123 Electronic Contract 124, 133 hash values 125 Signature Value 126 Electronic Certificates 131 Attribute information 132 Electronic Contracts 134 Signature Value 135 Electronic Certificates 136. Electronic Contract with Qualified Signature 551 Account Table 552 Qualification and Identity Verification Information Table 5521 Identity Verification Information 5522 Identity Verification Document Data 5523 Qualification Verification Information 5524 Qualification Verification Document Data 5525 Qualification Code 553 File Table 801 Formatting field 802 Thumbnail section 803 Internal Management Section 804 Recipient field 809 Signature Selection Button 901 Signature Qualification Selection Field 909 Request for Qualification Signature Button

Claims

1. A qualified signature device that performs witness-type electronic signatures on electronic contracts by contracting parties, A signature key storage means that stores a private key, which is a qualification signing key, issued for each of the multiple predetermined qualifications, and an electronic certificate that stores specific information that identifies the said qualification. An electronic contract acquisition means for acquiring an electronic contract that is the subject of an electronic contract by the aforementioned contracting parties, A means for determining whether the aforementioned contracting party is a qualified person with the prescribed qualifications, If the contracting party is a qualified person, the electronic signature means performs an electronic signature on the electronic contract using the qualified signing key corresponding to the qualified person's qualification and an electronic certificate on which the specific information of the qualification is recorded. A qualification signature device characterized by being equipped with the following.

2. The electronic signature means, upon receiving a request from the qualified person, performs an electronic signature using the qualified signing key and the electronic certificate. The qualification signature device according to feature 1.

3. The aforementioned electronic signature means is In response to a request for signature from the aforementioned qualified contracting party, the qualified signature is performed using the aforementioned qualified signing key and the aforementioned electronic certificate. In response to a signature request from a contracting party who is not qualified, a general signature is performed using a common signing key (a private key that does not correspond to qualifications) and an electronic certificate that does not contain information identifying the qualifications. The qualification signature device according to claim 1 or claim 2.

4. The account of the qualified person has an account database that stores personal identification information and qualification verification information, and the account of the unqualified person has an account database that stores personal identification information. The qualification determination means determines whether the contracting party is a qualified person or not using the account database. The qualification signature device according to claim 1 or claim 2.

5. The aforementioned account database stores login identification numbers and passwords for each qualified and unqualified user. The aforementioned qualification determination means determines whether the contracting party is qualified or ineligible based on the identification number used when logging in. The qualification signature device according to feature 4.

6. A means for obtaining registration information, which includes identity verification information and qualification verification information, from the aforementioned qualified person, A verification means that, based on the registration information obtained, performs identity verification to confirm the existence of the qualified person and qualification verification to confirm that the qualifications held by the qualified person are valid. If the aforementioned identity verification and qualification verification are completed, a registration means for registering the acquired registration information to the account of the qualified person in the account database, The qualification signature device according to claim 4, characterized by comprising the above.

7. The qualification signature device according to claim 6, characterized in that the verification means requests identity verification based on the acquired identity verification information and qualification verification based on the acquired qualification verification information to the same or separate third-party organizations, and obtains an identity verification result indicating that the qualified person exists and a qualification verification result indicating that the qualifications held by the qualified person are valid.

8. The electronic signature means, if the contracting party is a qualified person, attaches attribute information recording the qualification information identifying the qualified person's qualifications to the electronic contract and performs an electronic signature using the qualified signing key and electronic certificate. The qualification signature device according to claim 1 or claim 2.

9. A qualified signature program that enables a computer to function as a qualified signature device that performs witness-type electronic signatures on electronic contracts by contracting parties, An electronic contract acquisition function that acquires electronic contracts that are subject to electronic contracts by the aforementioned contracting parties, A qualification determination function that determines whether the aforementioned contracting party is a qualified person with the prescribed qualifications, If the contracting party is a qualified person, the electronic contract is provided with a signature key storage means that stores a qualification signing key, which is a private key issued for each of the predetermined multiple qualifications, and an electronic certificate that stores specific information identifying the qualification, the qualification signing key corresponding to the qualified person's qualification, and an electronic signature function that performs an electronic signature using the electronic certificate that stores specific information identifying the qualification. A credential signing program characterized by enabling a computer to perform the following actions.

Images