WO2014103663A1 - 電子契約システム - Google Patents

電子契約システム Download PDF

Info

Publication number
WO2014103663A1
WO2014103663A1 PCT/JP2013/082798 JP2013082798W WO2014103663A1 WO 2014103663 A1 WO2014103663 A1 WO 2014103663A1 JP 2013082798 W JP2013082798 W JP 2013082798W WO 2014103663 A1 WO2014103663 A1 WO 2014103663A1
Authority
WO
WIPO (PCT)
Prior art keywords
electronic
approval
electronic contract
transaction entity
document
Prior art date
Application number
PCT/JP2013/082798
Other languages
English (en)
French (fr)
Inventor
周作 平山
Original Assignee
株式会社日立システムズ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立システムズ filed Critical 株式会社日立システムズ
Publication of WO2014103663A1 publication Critical patent/WO2014103663A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/40—User authentication by quorum, i.e. whereby two or more security principals are required
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • the present invention relates to an electronic commerce technology, and more particularly to a technology effective when applied to an electronic contract system that supports an electronic commerce contract between companies.
  • Electronic transactions using electronic certificates have become widespread in transactions involving various contracts such as sales contracts associated with ordering of products, etc., especially continuous transactions between companies.
  • a company, a user, a terminal, a document, or the like, which is the subject of an electronic commerce contract, is authenticated or certified by an electronic certificate (or an electronic signature using the electronic certificate).
  • Patent Document 1 discloses a terminal certificate issued in common to a plurality of terminal devices and a service certificate that enables provision of a predetermined service. Contract information associated with a contract identification code that can individually identify a contract for providing a predetermined service is stored in advance, and a service certificate corresponding to the contract identification code received from the terminal device authenticated by the terminal certificate is stored in the terminal device.
  • Patent Document 2 discloses that each contract information including contract contents is transmitted from the service providing apparatus to the service receiving apparatus of each service receiver who is the contractor, and the contract information is received.
  • the service receiving device creates one-party signed contract information in which the service receiver's signature is added to the contract information and transmits the contract information to the service providing device.
  • the service providing device transmits the one-party signed contract information transmitted from each service receiving device.
  • E-commerce in an open network environment by creating and storing service provider-signed contract information signed by the service provider, storing it, and sending it to each service receiving device. Describes the technology to realize the authentication and notarization services required for.
  • Accredited certificate authority refers to a certificate authority that has been certified by the certification business certification system under the so-called Electronic Signature Act.
  • the security and reliability of the electronic certificate itself is relatively high, but the certificate acquisition procedure is complicated, expensive, and the burden on the acquirer is high, making it difficult to spread widely. is there.
  • safety and reliability may be inferior. Although it depends on the operating company, it is relatively easy, so it is superior in terms of ease of use.
  • an object of the present invention is to provide an electronic contract system that reduces the operational load on companies that introduce electronic contract services and business partners, and that enables business partners to securely conclude electronic contracts with service introduction companies. It is to provide.
  • An electronic contract system is a system that supports the conclusion of an electronic contract between a first transaction entity and a second transaction entity in an electronic commerce transaction.
  • an electronic signature unit that electronically signs a document related to an electronic contract for the first business entity, and an electronic signature for the document for the first business entity
  • a signature application processing unit that performs an approval process, and a document recording device that holds the document for each of the first transaction entities.
  • the signature application processing unit accepts an application for an electronic signature for the document from the first transaction entity, and for each one or more first approval rights holders in the first transaction entity included in the application Generating a first one-time password, creating a first e-mail containing information identifying the first one-time password and the document, and sending the first e-mail to each first authorized person; Content that matches the first one-time password assigned to the corresponding first approval authority in a response received from the first approval authority for the first e-mail Is included, the electronic signature unit corresponding to the first transaction entity performs an electronic signature on the document.
  • the operation load of a company that introduces an electronic contract service and a business partner is reduced, and the business partner securely concludes an electronic contract with the service introduction company. Is possible.
  • FIG. 11 is a diagram showing an outline of a configuration example of an electronic contract service using a certified certificate authority in the prior art.
  • a service introduction company (“Company A (300a ')” in the figure) that has concluded a basic transaction contract for performing electronic commerce by an electronic contract and a customer ("Customer 2 (402'" in the figure)).
  • Customer 2 (402'" in the figure)
  • the service introduction company and the customer individually apply for an electronic certificate acquisition to the authorized certificate authority 201, and acquire an electronic certificate for use in the electronic contract service.
  • another company such as “Company B (300b ′)”, “Business Partner 1 (401 ′)”, “Business Partner 3 (403 ′)”, etc.
  • newly uses the electronic contract service Enters into a contract for using an electronic contract service with a service vendor that individually operates the electronic contract system 101, and obtains an electronic certificate from the authorized certificate authority 201.
  • a service vendor that individually operates the electronic contract system 101
  • obtains an electronic certificate from the authorized certificate authority 201 In this way, it is necessary for service introduction companies and business partners using the electronic contract service to individually perform electronic certificate acquisition processing, which is a heavy burden in terms of costs and procedures.
  • FIG. 12 is a diagram showing an outline of a configuration example of an electronic contract service using a non-certified certificate authority in the prior art.
  • a service introduction company (“Company A” to "C Company” in the figure) that introduces an electronic contract service and conducts an electronic commerce by electronic contract is individually developed by the system vendor 101 '.
  • Each of the business partners (“Business Partner 1 (401 '” in the figure) that has concluded a basic transaction contract by the contract system ("Company A Electronic Contract System (100a)", “Company B Electronic Contract System (100b)” in the figure). ) ”To“ Business Partner 3 (403 ′) ”) to conclude an electronic contract and conduct electronic commerce.
  • the electronic certificate used for the electronic contract is acquired from the non-certified certificate authority 200 by each service introduction company (electronic contract system). It is also possible to adopt a configuration in which a registration operation is performed in which an electronic certificate used by each business partner that has concluded a basic transaction contract is acquired and issued.
  • FIG. 13 is a diagram showing an outline of another configuration example of the electronic contract service using a non-certified certificate authority in the prior art.
  • the functions of the electronic contract systems (“Company A electronic contract system (100a)", “Company B electronic contract system (100b)" individually owned by each service introduction company in the configuration of FIG. Is configured so that the system vendor 101 ′ provides it as a service via the network as an ASP (Application Service Provider).
  • ASP Application Service Provider
  • the system operation load of the service introduction company (“Company A (300a ')” and “Company B (300b')” in the figure)
  • Business Partner 2 (402 ') is the electronic contract system.
  • the necessity for proper use is the same as in the example of FIG.
  • the electronic contract system performs a certificate registration operation (identification and certificate issuance request and distribution) with respect to a non-certified certificate authority. This reduces the system operation load of service-introducing companies by carrying out all of the services on behalf of the business partners. Further, by configuring the system as a system that can be used in common by all service introduction companies, it is not necessary for the customer to use the electronic contract system separately regardless of the service introduction company of the other party of the transaction. In addition, when a service-introducing company or a business partner uses a digital certificate to digitally sign documents such as contracts stored in the electronic contract system, approval must be made based on the intention of the approval authority. By having an electronic signature application process that guarantees the above, it is possible for a business partner to securely conclude an electronic contract with a service introduction company.
  • FIG. 1 is a diagram showing an outline of a configuration example of an electronic contract system that is Embodiment 1 of the present invention.
  • the electronic contract system 100 is an information processing system that is operated by, for example, a company such as a system vendor that provides an electronic contract service, and includes a server device and a virtual server in a cloud computing environment.
  • This electronic contract system 100 is an individual service introduction company that is an individual system of a non-certified certificate authority 200 or a service introduction company ("Company A” to "Company C” in the figure) via a network such as the Internet (not shown).
  • System 300 (collectively “Company A's individual system (300a)” to “Company C's individual system (300c)” in the figure), business partners of each service introduction company (“Customer 1" to "Customer” in the figure) 5 ”), which is an individual system, can be connected by communication with a customer system 400 (collectively referred to as“ customer 1 system (401) ”to“ customer 5 system (405) ”in the figure).
  • the electronic contract system 100 includes, for example, an interface unit 110, signature application, which is implemented as a software program that runs on middleware such as an OS (Operating System), a DBMS (DataBase Management System), and a Web server program (not shown).
  • processing unit 120 electronic signature unit 130 (collectively referring to “Company A electronic signature unit (130a)” to “C company electronic signature unit (130c)”), certificate registration processing unit 140, supplier management unit 150 , A user management unit 160, a document management unit 170, and the like. Note that these units may be implemented as a subsystem of the electronic contract system 100 or as an independent system.
  • the interface unit 110 has a function of providing a user interface such as an operation screen for the user of the electronic contract service by the electronic contract system 100. For example, a screen is displayed on a Web browser on an information processing terminal used by a user using a Web server program (not shown).
  • the signature application processing unit 120 accepts an application for an electronic signature for a document stored in the electronic contract system 100 from a service introduction company, a business partner system, or a person in charge, and requests an approval from a designated approval authority. It has a function of performing a series of signature application processes in which an electronic signature is applied to a target document by an electronic signature unit 130, which will be described later, when approved by all approval rights holders.
  • the approval status such as the approval request and approval result for each approval authority is recorded in the approval status table (TB) 123 implemented by a database or file table. Details of the signature application process will be described later.
  • the signature application processing unit 120 further includes a one-time password (OTP) processing unit 121 having a function of generating a one-time password used in the signature application processing, and a document designated for a designated mail address.
  • OTP one-time password
  • general known servers, programs, libraries, and the like can be used as appropriate.
  • the electronic signature unit 130 is a target service introducing company when the document application related to the electronic contract for each introducing company of the electronic contract service is approved by each approval authority by the signature application processing unit 120 described above. It has a function to automatically perform electronic signatures. For this purpose, each electronic signature unit 130 receives an electronic certificate from the non-certified certificate authority 200 by the certificate registration processing unit 140 described below prior to the start of service provision for the target service introduction company. This shall be retained. In this embodiment, the electronic signature unit 130 is individually implemented for each service introducing company. However, if the electronic signature can be individually provided for each service introducing company, the electronic signature unit 130 should be implemented collectively. Is also possible.
  • the certificate registration processing unit 140 receives a request for issuing an electronic certificate from a service introducing company, and performs a registration operation for requesting the non-certified certification authority 200 to issue an electronic certificate for the service introducing company or its business partner. It has the function of.
  • the certificate registration processing unit 140 may further include a form creation unit 141 that creates and outputs a form in a predetermined format required when making a certificate issuance request to the non-certified certificate authority 200. Good.
  • the supplier management unit 150 holds, in the supplier table (TB) 151, information on suppliers that each service introduction company that uses the electronic contract service by the electronic contract system 100 has concluded a basic transaction contract and registers. And a function for managing updates and the like.
  • the electronic contract system 100 is used to conclude an electronic contract only between each service introducing company and a business partner that has concluded a basic business contract with them. Control can be performed so that a commercial transaction can be performed.
  • the user management unit 160 stores attribute information such as name and company, authentication information such as a user ID and password, and information such as access authority in the user table (TB) 161. In addition to holding, it has a function of managing registration and updating.
  • the users here include, in addition to the administrator of the electronic contract system 100, etc., each service introduction company, the person in charge of the business partner, the approval right holder at the time of electronic signature, and the like.
  • the document management unit 170 stores in the document table (TB) 171 an original document related to the electronic contract concluded through the electronic contract system 100 and permits reference to an access request from a user having access authority. It has a document management function. For this function as well, general known document management systems and programs can be used as appropriate.
  • the non-certified certificate authority 200 is, for example, a JCAN (registered trademark) root certificate authority that issues a public certificate of the JCAN (registered trademark) specification operated by JIPDEC (registered trademark: Japan Information Economy and Society Association). By using it, it is possible to issue an electronic certificate at a low cost. At this time, it is also possible for the operating company of the electronic contract system 100 to receive an authorization (LRA authorization) from JIPDEC (registered trademark) and register an electronic certificate of JCAN (registered trademark) specifications. Instead of using such a public certificate, the operating company of the electronic contract system 100 may construct the non-certified certificate authority 200 and issue a private electronic certificate.
  • JCAN registered trademark
  • JIPDEC registered trademark: Japan Information Economy and Society Association
  • Each service introduction company individual system 300 (“Company A individual system (300a)” to “C Company individual system (300c)” in the figure), for example, presents an estimate request and contract with a business partner from reception of an estimate request. It is an information processing system such as a core cooperation system that carries out a series of electronic commerce transactions from the conclusion to the transaction.
  • an estimate request can be obtained from a service introduction company.
  • This is an information processing system that carries out a series of electronic commerce transactions from receipt, contract conclusion, and transaction.
  • business partners for example, not only suppliers of products etc. for service introduction companies, but also sales partners such as customers and consignees such as maintenance companies, etc., companies that are counterparties to conclude electronic contracts, etc. included.
  • FIG. 2 is a diagram showing an outline of a configuration example of an electronic contract service using a non-certified certificate authority in the present embodiment.
  • the electronic contract system 100 receives a request from a service introducing company (“Company A (300a ′)”, “Company B (300b ′)” in the figure) and performs certificate registration for the non-certified CA 200.
  • a service introducing company (“Company A (300a ′)”, “Company B (300b ′)” in the figure)
  • the service introduction company and the business partner in the figure, “business partner 1 (401 ′)” to “business partner 3 (403 ′)”
  • business partner 1 (401 ′) to “business partner 3 (403 ′)
  • each service introduction company can perform processing related to the electronic contract by the electronic contract system 100 by concluding the use contract of the electronic contract service with the operating company of the electronic contract system 100. It becomes possible to reduce the system operation load. Further, by adopting a configuration for centrally managing information on business partners who have concluded business basic contracts for each service introduction company in the business partner TB 151, a business partner ("business partner 2 (402 ')" in the figure). ), The same electronic contract system 100 can be used regardless of the service introduction company of the other party.
  • FIG. 3 is a flowchart showing an outline of an example of a processing flow until the service introduction company can use the electronic contract service.
  • the service introduction company applies for the use contract of the electronic contract service to the operating company of the electronic contract system 100 (S01), and if the predetermined requirement is satisfied, the contract is concluded (S02).
  • the above processing has been described as being performed manually by the service introducing company and the operating company of the electronic contract system 100. However, the processing is systematically performed between the individual system 300 of the service introducing company and the electronic contract system 100. May be.
  • the company information such as the attributes of the target service introducing company is manually or automatically by the administrator or the like, a table such as a service introducing company master (not shown), the customer TB 151, etc. (S03).
  • a service introducing company master not shown
  • the customer TB 151 etc.
  • the information may be registered in the business partner TB 151 at this time.
  • the corresponding electronic signature unit 130 is mounted for the target service introducing company (S04). For example, a program, a module, a server, etc. for the target service introducing company are appropriately installed.
  • the service introduction company uses the electronic contract system based on an instruction (for example, an instruction made by accessing the electronic contract system 100 using a Web browser or the like) via the information introduction terminal of the service introduction company individual system 300 or a person in charge.
  • An application for issuing an electronic certificate for the service introducing company is made to 100 (S05).
  • the certificate registration processing unit 140 creates an application form by the form creation unit 141 as necessary, and then issues an electronic certificate to the non-certified certification authority 200.
  • a request is made (S06).
  • the non-certified certificate authority 200 that has received the issue request issues a predetermined determination process for the application contents, issues an electronic certificate (S07), and sends it to the electronic contract system 100 (S08).
  • the electronic contract system 100 stores the received electronic certificate so that the electronic signature unit 130 corresponding to the target service introducing company can use it (S09).
  • An electronic certificate may be sent to a service introduction company so that the service introduction company can independently sign an electronic signature.
  • FIG. 4 is a diagram showing an overview of an example of the flow of processing when a service introduction company receives an estimate request from a potential business partner.
  • a potential business partner based on an instruction (for example, an instruction made by accessing the service introducing company individual system 300 using a Web browser or the like) via the information processing terminal such as the business partner system 400 or a person in charge
  • an instruction for example, an instruction made by accessing the service introducing company individual system 300 using a Web browser or the like
  • the information processing terminal such as the business partner system 400 or a person in charge
  • S11 the introduced company individual system 300
  • an estimate is created automatically or manually by the person in charge based on the contents of the request (S12), and this is automatically sent to the electronic contract system 100 or based on an instruction via the information processing terminal of the person in charge.
  • Upload and request registration (S13).
  • the document management unit 170 registers the uploaded estimate in the document TB 171 (S14).
  • An electronic signature application process which is a process for obtaining the above, is performed (S15). The contents of the electronic signature application process will be described later.
  • the electronic contract system 100 uses the electronic signature unit 130 corresponding to the target service introduction company to An electronic signature is given to the estimate (S16), and access authority etc. are set so that it can be viewed from the target customer system 400 or a person in charge (S17). At this time, the customer system 400 or the person in charge may be notified by e-mail or the like that the estimate with the electronic signature is registered and can be viewed.
  • an electronic signature is applied to the estimate (S16), which can be viewed (S17), but the estimate is registered (S14).
  • An electronic signature may be provided in advance so that the electronic signature can be viewed (access restriction is released) when the electronic signature application process is completed.
  • the person in charge of the supplier makes a browse request for the estimate stored in the electronic contract system 100 using the information processing terminal (S18).
  • a browsing request can be made to the electronic contract system 100 via the Web site of the service introducing company individual system 300 using a Web browser or the like on the information processing terminal.
  • the requested estimate is obtained from the document TB 171 and output (step S19), and the person in charge of the supplier browses it using the information processing terminal (step S20). .
  • FIG. 5 is a diagram showing an outline of an example of the flow of processing when a service introducing company concludes a basic transaction contract with a new business partner.
  • a service introduction company and a business partner conclude a basic contract for the transaction (S21).
  • the contract here is made in writing, etc., but if possible, the service introduction company or the person in charge of the business partner accesses the service introduction company individual system 300 or the customer system 400 using the information processing terminal. This may be done systematically.
  • the service introduction company makes an agreement about the target supplier with respect to the electronic contract system 100 based on an instruction via the information introduction terminal such as the service introduction company individual system 300 or the person in charge.
  • An information registration request is made (S22).
  • the business partner management unit 150 registers the information of the target business partner with the target service introduction company in the business partner TB 151 (S23).
  • the service introducing company applies to the electronic contract system 100 for issuing an electronic certificate for the target business partner based on the instruction through the information processing terminal of the service introducing company individual system 300 or the person in charge.
  • Perform (S24).
  • the electronic contract system 100 receives an issuance of an electronic certificate from the non-certified certification authority 200 by the same process as the process in steps S06 to S09 in the example of FIG. This is sent to the supplier (or supplier system 400) (S26).
  • the supplier system 400 stores the received electronic certificate so that it can be used for electronic signatures (S27). Note that the above certificate distribution process is only performed for the first time when a service-introducing company enters into a basic contract with a new business partner, and is not required after the electronic certificate has been distributed to the business partner. .
  • FIG. 6 is a diagram showing an outline of an example of the flow of processing when an individual transaction contract is concluded between a service introduction company and a business partner.
  • the supplier applies for a contract to the service introducing company individual system 300 based on an instruction via the information processing terminal such as the supplier system 400 or a person in charge, as in the case of the request for quotation (S31). ).
  • the service introduction company individual system 300 a contract is created automatically or manually by the person in charge based on the contents of the application and the estimate (S32), and the information processing terminal of the person in charge is automatically or electronically connected to the electronic contract system 100.
  • the registration request is made by uploading based on the received instruction (S33).
  • document management is performed after confirming whether the target business partner is registered with reference to the business partner TB 151, that is, after confirming whether the target business partner can use the electronic contract service.
  • the uploaded contract is registered in the document TB 171 by the unit 170 (S34). Further, in the service introducing company individual system 300, in order to electronically sign the uploaded contract document to the electronic contract system 100 automatically or based on an instruction from the person in charge, similar to step S15 in the example of FIG.
  • the electronic signature application process is performed (S35).
  • the electronic contract system 100 uses the electronic signature unit 130 corresponding to the target service introduction company to An electronic signature is given to the contract (S36), and access authority etc. are set so that the contract can be viewed from the target customer system 400 or a person in charge (S37). At this time, the customer system 400 or the person in charge may be notified by e-mail or the like that the contract with the electronic signature has been registered and can be viewed.
  • the person in charge of the business partner is stored in the electronic contract system 100 via the website of the service introducing company individual system 300 using the information processing terminal.
  • a browsing request for the contract is made (S38).
  • the document management unit 170 extracts and presents a list of documents for which the target business partner has access authority from the document TB171.
  • the electronic contract system 100 that has received the browsing request obtains the requested contract from the document TB 171 and outputs it (S39), and the person in charge of the supplier uses the information processing terminal to present it.
  • the contents are browsed and contents are added as necessary (S40).
  • step S41 In order to electronically sign the contract for the electronic contract system 100 based on an instruction through the information processing terminal of the person in charge or automatically, the same as step S15 in the example of FIG.
  • Electronic signature application processing is performed (S41).
  • the supplier system 400 performs an electronic signature on the target contract (S42) and electronically converts the signed contract.
  • the contract system 100 is requested to upload and store it as an original (S43).
  • the received contract document is stored in the document TB 171 as an original (S44).
  • the electronic signature processing (S42) by the supplier is executed on the electronic contract system 100 in the same manner as in step S36, and is executed in cooperation with the approval result of the electronic signature application processing (S41). It may be.
  • FIG. 7 is a diagram showing an outline of an example of a flow of an electronic signature application process for obtaining a predetermined approval necessary for applying an electronic signature to a document such as an estimate or a contract.
  • This process is, for example, a process performed in step S15 in the above-described example of FIG. 4 and steps S35 and S41 in the example of FIG.
  • a case where a person in charge of contract work at a service introduction company or a business partner uses the information processing terminal to access the electronic contract system 100 and manually instruct the electronic signature application processing is shown as an example. .
  • the person in charge makes an inquiry request for a list of documents to be digitally signed to the electronic contract system 100 using the person-in-charge terminal 311 (S51).
  • a document that can be digitally signed by the service introducing company or business partner to which the subject person in charge belongs (for example, a document that has access authority and has not yet been digitally signed) by the document management unit 170.
  • the document management unit 170 Is extracted from the document TB 171 and acquired to present it to the person-in-charge terminal 311 (S52).
  • the person in charge selects a document (estimate or contract) to be electronically signed from the list of documents presented on the person-in-charge terminal 311 (S53), and further requires approval when making the electronic signature.
  • One or more authorized persons such as superiors are selected (S54).
  • the approval right holder for example, the user is selected from those who are registered in advance in the user TB 161 by the user management unit 160 in the electronic contract system 100 (that is, those who can access the electronic contract system 100). May be.
  • an electronic signature application request is made to the electronic contract system 100 (S55).
  • the request includes the target document and approval right holder information.
  • the signature application processing unit 120 assigns an application ID, registers an entry for tracking the approval status in the approval status TB 123, and then registers the OTP processing unit 121.
  • a unique one-time password is generated and assigned to each authorized person (S56).
  • an approval request e-mail document including an application ID, information such as a file name identifying the target document, and one-time password information generated in step S56 is created for each approval authority, and this is processed by mail.
  • the part 122 transmits the information to the e-mail address of each authorized person (S57).
  • each approval authority receives an approval request e-mail from the approval authority terminal 312 (S58)
  • the electronic contract system 100 browses the target document based on the application ID and document specific information included therein. Each request is made (S59).
  • the electronic contract system 100 obtains and outputs the requested document from the document TB 171 (S60), and each approval authority uses the approval authority terminal 312 to display the contents of the document. (S61).
  • each approval authority returns the approval request received in step S58 to the sender as it is (S62).
  • the electronic contract system 100 that is the transmission source receives the e-mail of the returned approval request
  • the one-time password included therein is combined with the one-time password assigned to the target approval authority in step S56. It is checked whether or not it is done, and the result is recorded in the approval status TB123 (S63).
  • step S56 If replies to the approval request e-mail are received from all approval rights holders and the one-time password included therein matches the one assigned in step S56, it is assumed that the approval has been properly made.
  • the process proceeds to the subsequent electronic signature processing by the electronic contract system 100 or the supplier system 400.
  • the one-time password did not match, for example, when the electronic contract system 100 did not receive a response to the e-mail of the approval request within a predetermined response time, or for reasons such as rejection of approval or impersonation by a third party. In such a case, the electronic signature is not performed because the electronic signature application is rejected.
  • Such a process ensures that the approval process is performed by the predetermined approval authority (or based on the intention of the predetermined approval authority) without placing a burden on the approval authority. It is possible to prevent a person from signing an electronic signature without obtaining approval from the approver.
  • the certificate registration work for the non-certified certificate authority 200 can be performed collectively on behalf of the service introduction company and the business partner.
  • the system it is possible to reduce the system operation load of the service introducing company.
  • the system by configuring the system as a system that can be used in common by all service introduction companies, it is not necessary for the customer to use the electronic contract system separately regardless of the service introduction company of the other party of the transaction.
  • a service introduction company or a business partner uses a digital certificate to electronically sign a document such as a contract stored in the electronic contract system 100, approval is performed based on the intention of the approval right holder.
  • an electronic signature application processing process that guarantees this, it becomes possible for a business partner to securely conclude an electronic contract with a service introduction company.
  • the above-described electronic contract system 100 has a mechanism for guaranteeing that approval is performed based on the intention of the approval authority by having the electronic signature application process as shown in the example of FIG. is doing.
  • the approval request e-mail from the signature application processing unit 120 is received by the approval authority, for example, the e-mail address of the approval authority is erroneously registered. If it is erroneously transmitted to a person other than the above, it cannot be excluded that a person other than the person with the authorization right simply approves the electronic mail.
  • the electronic contract system 100 avoids a problem in the case of erroneous transmission of an e-mail by adopting a method in which the authorization right person himself inputs and approves the one-time password to the system. It is possible to do.
  • the system configuration and processing contents are basically the same as the contents shown in the above-described first embodiment. Therefore, the re-description is omitted, but the flow of electronic signature application processing that is a difference is described below. explain.
  • FIG. 8 is a diagram showing an outline of an example of the flow of the electronic signature application process in the present embodiment.
  • the person in charge first selects a document to be signed using the person-in-charge terminal 311, and further selects one or more authorized persons (assuming that the approval order is also set).
  • FIG. 7 of the first embodiment up to where the signature application request is made to the electronic contract system 100 (S75) and until the electronic contract system 100 that has received the signature application request generates a one-time password (S76). This is the same as steps S51 to S55 and S56 of the electronic signature application process shown in FIG.
  • the mail processing unit 122 of the electronic contract system 100 displays the application ID, the one-time password generated in step 76, the previous authorization holder (if any), and the approval-only screen provided by the interface unit 110.
  • An approval request e-mail document including URL (Uniform Resource Locator) information for access is transmitted to the e-mail address of the next approval authority in the approval order (S77).
  • URL Uniform Resource Locator
  • the target approval authority receives the approval request e-mail from the approval authority terminal 312 (S78), accesses the URL of the approval screen included therein, and logs in to the approval screen (S79).
  • the approval authority inputs a normal login ID and password for the electronic contract system 100 and a one-time password included in the approval request e-mail. It is also possible to enter the one-time password by accessing the URL itself by making the URL for the approval-only screen a unique URL that is generated each time, for example, including the one-time password. is there.
  • the electronic contract system 100 based on the user TB 161 and the approval status TB 123, verification of the login ID and password, confirmation of the authorization right person, and verification for verifying the one-time password by the signature application processing unit 120 or the like Processing is performed (S80). If there is no problem with the authentication result, the approval status TB 123 is referred to, and an unapproved document or a list of cases for the target approval authority is displayed and presented on the approval authority terminal 312 (S81).
  • the approval right person specifies the approval target case from the list of unapproved cases displayed on the approval right person terminal 312 and inputs approval / disapproval (S82). At this time, as in steps S59 to S61 in the example of FIG. 7, processing for browsing a document related to the target case may be performed. Information on the approval result is registered in the approval status TB 123 by the signature application processing unit 120 of the electronic contract system 100 (S83).
  • a new one-time password is generated in the same manner as step S76 in order to perform the approval process for the next approval authority (S84), and an e-mail requesting approval is sent to the next approval authority. Is transmitted (S85).
  • the subsequent processing (S86-) is the same as the above-described steps S78-S83).
  • the workflow of the approval process can be configured by repeating the series of processes in steps S76 to S83 in order for each authorized person.
  • the person in charge can access the electronic contract system 100 using the person-in-charge terminal 311 to check the approval status obtained based on the contents of the approval status TB 123 as needed.
  • the last approval right holder of the workflow that is, the approval right holder who owns the electronic certificate issued from the electronic contract system 100, performs the approval process, for example, on the approval-only screen, It is desirable to display a confirmation message such as "Are you sure?"
  • an approval request e-mail is sent to a plurality of approval right holders at the same time, and each approval right person performs an approval process individually, and the approval is obtained when everyone approves.
  • an asynchronous procedure is taken, it is also possible to apply a synchronous procedure by a workflow according to the approval order as in this embodiment to the electronic signature application processing in the first embodiment. Conversely, the asynchronous procedure as in the first embodiment can be applied to the electronic signature application process in the present embodiment.
  • an approval-dedicated screen is provided for each item or document, and information on the URL for this is embedded in the approval request.
  • the login ID and password for the system, and the one-time password are input. That is, the approval process cannot be performed unless these pieces of information are available.
  • the approval process cannot be performed unless these pieces of information are available.
  • the electronic contract system 100 prevents the unlimited registration of business partners through an approval process when a service introducing company newly registers business partners, and the safety of the system. It is to secure the sex. Since the system configuration and processing contents are basically the same as the contents shown in the first embodiment, the re-description is omitted. The flow of processing related to will be described below.
  • FIG. 9 is a diagram showing an outline of an example of the flow of processing when a service introduction company concludes a basic transaction contract with a new business partner in the present embodiment.
  • the target business partner has already concluded a basic contract with another service introduction company and has been issued an electronic certificate via the electronic contract system 100.
  • the service introducing company and the business partner conclude a basic transaction contract (S91).
  • the service introduction company makes an agreement about the target supplier with respect to the electronic contract system 100 based on an instruction via the information introduction terminal such as the service introduction company individual system 300 or the person in charge.
  • a registration information confirmation request is made (S92).
  • the target business partner is specified by inputting the ID of the electronic certificate already owned by the target business partner or the e-mail address of the owner.
  • information of the target supplier is acquired from the supplier management unit 150 and presented (S93).
  • the service introduction company confirms the contents of the registered information of the supplier based on the instruction via the information introduction terminal such as the individual service introduction company system 300 or the person in charge (S94).
  • one or more approval right holders for the registration of the business partner are selected.
  • the approval right holder includes the owner of the electronic certificate issued from the electronic contract system 100.
  • a series of steps subsequent to step S75 in the signature application process shown in FIG. 8 of the second embodiment (in this embodiment, the approval request is not a signature application request but a supplier registration).
  • approval processing for approving the registration of business partners in order by the workflow is performed by a plurality of approval right holders (S96).
  • a confirmation message such as “Do you confirm that you are a legitimate business partner who passed credit review etc. in the company?” Is displayed on the approval screen. Is desirable.
  • the electronic contract system 100 When approval is given by the final approval right holder (that is, the owner of the electronic certificate), the electronic contract system 100 is registered as a business partner with respect to the business partner system 400 or the information processing terminal of the person in charge of the business partner.
  • a request for consent to be made is made (S97).
  • the request can be made by sending an e-mail by the mail processing unit 122.
  • it is desirable to display a confirmation message such as "Are you sure you want to be registered as a business partner by (service introduction company)?"
  • the supplier accepts input of consent / disapproval for registering as a business partner based on an instruction via the information processing terminal of the business partner system 400 or the approval right holder (that is, the owner of the electronic certificate).
  • a response is made to the electronic contract system 100 (S98).
  • the supplier management unit 150 when a response of acceptance is received, the supplier management unit 150 newly registers the target customer as a customer of the target service introduction company and registers it in the customer TB 151 (S99).
  • FIG. 10 is a diagram showing an outline of another example of the flow of processing when a service introduction company concludes a basic transaction contract with a new business partner in the present embodiment.
  • the target business partner has not yet concluded a basic contract with any service introduction company and has not received an electronic certificate issued via the electronic contract system 100. Yes.
  • the service introducing company and the business partner conclude a basic transaction contract (S101).
  • the service introduction company uses the electronic contract system based on an instruction through the information introduction terminal such as the service introduction company individual system 300 or a person in charge.
  • 100 is requested to register information about the target business partner (S102).
  • the information on the target business partner includes, for example, an electronic mail address of an electronic certificate issuance partner and company information.
  • the supplier management unit 150 temporarily registers the information of the target supplier in association with the target service introduction company in the supplier TB 151 (S103).
  • the electronic contract system 100 sends the electronic contract system 100 to the customer system 400 or the information processing terminal of the person in charge of the customer. Notification is made by e-mail or the like to access (S106).
  • This notification includes, for example, information such as a temporary login ID and password issued by the user management unit 160 and an access destination URL.
  • the business partner accesses the electronic contract system 100 via the information processing terminal of the person in charge and performs the first login process (S107).
  • the electronic contract system 100 when the login is successful, the electronic contract system 100 requests the supplier system 400 or the information processing terminal of the person in charge of the supplier to consent to being registered as the supplier (S108).
  • the request can be made by electronic mail as in step S97 in the example of FIG.
  • the request may be displayed on the screen after login. At this time, for example, it is desirable to display a confirmation message such as "Are you sure you want to be registered as a business partner by (service introduction company)?"
  • the business partner Based on an instruction through the information processing terminal such as the business partner system 400 or a person in charge, the business partner accepts an input of consent / non-consent for registration as a business partner and responds to the electronic contract system 100. (S109).
  • the supplier management unit 150 when receiving a response of acceptance, changes the temporary registration registered in the supplier TB 151 in step S103 to the main registration for the target supplier (S110). Thereafter, in the same manner as the processing from step S24 onward in FIG. 5, based on the instruction via the information processing terminal such as the service introducing company individual system 300 or a person in charge, Is issued (S111), and issuance of an electronic certificate is received.
  • control is performed through an approval process by a workflow, and By obtaining approval from business partners, it is possible to prevent unlimited registration of business partners and to ensure the safety of systems and services.
  • the present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the scope of the invention. Needless to say.
  • the above-described embodiment has been described in detail for easy understanding of the present invention, and is not necessarily limited to the one having all the configurations described.
  • a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. .
  • control lines and information lines indicate what is considered necessary for explanation, and not all control lines and information lines on mounting are necessarily shown. Actually, it may be considered that almost all the components are connected to each other.
  • the present invention can be used in an electronic contract system that supports an electronic commerce contract between companies.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Accounting & Taxation (AREA)
  • General Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Software Systems (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

　電子契約サービスの導入企業や取引先の運用負荷を低減するとともに、取引先がサービス導入企業との間で安全に電子契約を締結することを可能とする電子契約システムである。代表的な実施の形態によれば、第１の取引主体と第２の取引主体との間の電子契約の締結を支援する電子契約システムであって、第１の取引主体毎に電子契約に係る文書に対して電子署名を行う電子署名部と、電子署名を行う際の承認処理を行う署名申請処理部と、前記文書を保持する文書ＴＢとを有し、署名申請処理部は、第１の取引主体からの前記文書に対する電子署名の申請を受け付けて、承認権者毎にワンタイムパスワードを生成し、これを含む電子メールを作成して各承認権者に送付し、全ての承認権者から返信を受領し、かつ各返信の中に対応するワンタイムパスワードが含まれる場合に、対応する前記電子署名部により前記文書に対して電子署名を行う。

Description

電子契約システム
　本発明は、電子商取引の技術に関し、特に、企業間の電子商取引契約を支援する電子契約システムに適用して有効な技術に関するものである。
　商品等の受発注に伴う売買契約等の各種の契約を伴う取引、特に、企業間での継続的な取引では、電子証明書を利用した電子商取引が普及してきている。ここでは、電子証明書（もしくは電子証明書を用いた電子署名）により、電子商取引契約の主体である企業やユーザ、利用端末、文書等を認証したり証明したりすることが行われる。
　これに関連した技術として、例えば、特開２０１１－４５０１６号公報（特許文献１）には、複数の端末装置に共通して発行された端末証明書と所定サービスの提供を可能にするサービス証明書および所定サービスの提供契約を個別に識別可能な契約識別コードを対応付けた契約情報を予め記憶し、端末証明書で認証された端末装置から受け取った契約識別コードに対応するサービス証明書を端末装置に送信するサーバ装置と、端末証明書を予め記憶し、所定サービスの提供契約が成立した後に成立した契約識別コードを取得し、端末証明書を用いてサーバ装置から認証されると、サーバ装置から契約識別コードに対応するサービス証明書を受信する端末装置と、を具備する通信システムが記載されている。これにより、インターネット経由でサービス提供する際に、電子証明書を利用してサービス提供先及びサービス提供に使用する機器を認証して、機器・サーバ間で安全かつ簡易に通信を行うことを可能とするものである。
　また、特開平１０－３２７１４７号公報（特許文献２）には、サービス提供装置から契約内容を含む契約情報を契約者である各サービス享受者のサービス享受装置に送信し、契約情報を受信した各サービス享受装置で契約情報にサービス享受者の署名を付けた一者署名付き契約情報を作成してサービス提供装置に送信し、サービス提供装置では各サービス享受装置から送信された一者署名付き契約情報を受信し、まとめて一つの文書にし、サービス提供者の署名を付けたサービス提供者署名付き契約情報を作成し、保管するとともに各サービス享受装置に送信することで、オープンなネットワーク環境において電子商取引に必要な認証・公証サービスを実現する技術が記載されている。
特開２０１１－４５０１６号公報 特開平１０－３２７１４７号公報
　電子商取引における契約処理を支援するための電子契約システムを構築する際に、電子証明書を用いてユーザや利用端末、文書等の認証や証明を行うためには、電子証明書を発行する認証局が必要となるが、その際、いわゆる認定認証局を用いる場合と非認定認証局を用いる場合とが考えられる。
　認定認証局とは、いわゆる電子署名法における認証業務認定制度により認定された認証局を指す。一般的に認定認証局を用いる場合、電子証明書自体の安全性・信頼性は比較的高いものの、証明書取得手続きが煩雑かつ高額で取得者の負荷が高いことから、広く普及しにくい状況がある。一方で、認定認証局以外の非認定認証局を用いる場合は、安全性・信頼性が劣る場合があり得ることから、同様に広く普及しにくい状況があるものの、証明書取得手続きは認証局を運営する事業者に依存するとはいえ比較的容易であるため、利用の容易さという点では優る。
　電子証明書を用いた電子署名により契約処理を行う電子契約支援システムを構築する際に、証明書の発行主体としてコストの観点や柔軟な対応などの利用の容易さを考慮して非認定認証局を用いる場合でも、以下の課題が生じ得る。例えば、企業等において、多忙な決裁権者が直接決裁処理を行う代わりに部下等の担当者が代理で決裁する（例えば、契約書に電子署名する）ような処理がよく行われる。このとき、相手方にとっては、当該決裁（電子署名）が本当に決裁権者本人により、もしくは決裁権者の意思に基づいて行われたものであるのか、担当者が独断で行ったものかが分からないため、相手方は契約を否認されるのではないかというリスクを負いつつ契約を締結せざるを得ない状況となる。
　また、電子契約による電子商取引の仕組み・サービスを導入する企業にとっては、例えば、取引先と基本契約を締結してサービスを利用可能とする毎に、当該取引先についての電子証明書を非認定認証局から取得して渡す（もしくは当該取引先が個別に非認定認証局から取得する）必要があり、運用が煩雑となる。また、取引先にとっては、基本契約を締結した企業が複数あった場合に、これらの企業毎に電子契約により電子商取引を行う仕組みやシステムが異なる場合には、それぞれの企業毎にシステムを使い分ける必要が生じ、運用が煩雑となる。
　そこで本発明の目的は、電子契約サービスの導入企業や取引先の運用負荷を低減するとともに、取引先がサービス導入企業との間で安全に電子契約を締結することを可能とする電子契約システムを提供することにある。
　本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
　本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
　本発明の代表的な実施の形態による電子契約システムは、電子商取引における第１の取引主体と第２の取引主体との間の電子契約の締結を支援するシステムであって、１つ以上の前記第１の取引主体毎に、前記第１の取引主体についての電子契約に係る文書に対して電子署名を行う電子署名部と、前記第１の取引主体についての前記文書に対して電子署名を行う際の承認処理を行う署名申請処理部と、前記各第１の取引主体についての前記文書を保持する文書記録装置と、を有するものである。
　前記署名申請処理部は、前記第１の取引主体からの前記文書に対する電子署名の申請を受け付けて、当該申請に含まれる前記第１の取引主体における１人以上の第１の承認権者毎に第１のワンタイムパスワードを生成し、当該第１のワンタイムパスワードおよび前記文書を特定する情報を含む第１の電子メールを作成して前記各第１の承認権者に送付し、全ての前記第１の承認権者から前記第１の電子メールに対する返信を受領し、かつ当該各返信の中に、対応する前記第１の承認権者に割り当てた前記第１のワンタイムパスワードと合致する内容が含まれる場合に、前記第１の取引主体に対応する前記電子署名部により、前記文書に対して電子署名を行う。
　本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
　すなわち、本発明の代表的な実施の形態によれば、電子契約サービスの導入企業や取引先の運用負荷を低減するとともに、取引先がサービス導入企業との間で安全に電子契約を締結することが可能となる。
本発明の実施の形態１である電子契約システムの構成例について概要を示した図である。 本発明の実施の形態１における非認定認証局を用いた電子契約サービスの構成例について概要を示した図である。 本発明の実施の形態１におけるサービス導入企業が電子契約サービスを利用可能となるまでの処理の流れの例について概要を示したフロー図である。 本発明の実施の形態１におけるサービス導入企業が潜在的な取引先から見積依頼を受けた場合の処理の流れの例について概要を示した図である。 本発明の実施の形態１におけるサービス導入企業が新たな取引先と取引の基本契約を締結した場合の処理の流れの例について概要を示した図である。 本発明の実施の形態１におけるサービス導入企業と取引先との間で個別取引の契約が締結される場合の処理の流れの例について概要を示した図である。 本発明の実施の形態１における文書に電子署名を行うために必要な所定の承認を得るための電子署名申請処理の流れの例について概要を示した図である。 本発明の実施の形態２における電子署名申請処理の流れの例について概要を示した図である。 本発明の実施の形態３におけるサービス導入企業が新たな取引先と取引の基本契約を締結した場合の処理の流れの例について概要を示した図である。 本発明の実施の形態３におけるサービス導入企業が新たな取引先と取引の基本契約を締結した場合の処理の流れの別の例について概要を示した図である。 従来技術における認定認証局を用いた電子契約サービスの構成例について概要を示した図である。 従来技術における非認定認証局を用いた電子契約サービスの構成例について概要を示した図である。 従来技術における非認定認証局を用いた電子契約サービスの他の構成例について概要を示した図である。
　以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。
　図１１は、従来技術における認定認証局を用いた電子契約サービスの構成例について概要を示した図である。この場合は、電子契約により電子商取引を行うための取引基本契約を締結したサービス導入企業（図中では「Ａ社（３００ａ’）」）と、取引先（図中では「取引先２（４０２’）」）が、それぞれ、電子契約システム１０１を運営するサービスベンダと電子契約サービスの利用契約を締結することで、電子契約システム１０１を介して契約を締結することが可能となる。
　このとき、サービス導入企業と取引先がそれぞれ個別に認定認証局２０１に対して電子証明書の取得申請を行い、電子契約サービスで用いるための電子証明書を取得する。なお、他の企業等（図中では「Ｂ社（３００ｂ’）」や「取引先１（４０１’）」、「取引先３（４０３’）」など）が新たに電子契約サービスを利用する場合は、個別に電子契約システム１０１を運営するサービスベンダと電子契約サービスの利用契約を締結し、認定認証局２０１から電子証明書を取得する。このように、電子契約サービスを利用するサービス導入企業や取引先がそれぞれ個別に電子証明書取得処理を行う必要があり、費用面、手続面で大きな負荷となる。
　図１２は、従来技術における非認定認証局を用いた電子契約サービスの構成例について概要を示した図である。この例では、電子契約サービスを導入して電子契約により電子商取引を行うサービス導入企業（図中では「Ａ社」～「Ｃ社」）が、それぞれ、システムベンダ１０１’により個別に開発された電子契約システム（図中では「Ａ社電子契約システム（１００ａ）」、「Ｂ社電子契約システム（１００ｂ）」）により、取引基本契約を締結した各取引先（図中では「取引先１（４０１’）」～「取引先３（４０３’）」）と電子契約を締結して電子商取引を行う。電子契約の際に用いる電子証明書は、各サービス導入企業（電子契約システム）がそれぞれ非認定認証局２００から取得する。取引基本契約を締結した各取引先が用いる電子証明書について取得して発行するという登録業務を行う構成とすることも可能である。
　図１２の例では、「取引先２（４０２’）」については、「Ａ社」と「Ｂ社」の双方と取引基本契約を締結しており、双方と電子契約により電子商取引を行うことが可能である。しかしながら「Ａ社電子契約システム（１００ａ）」と「Ｂ社電子契約システム（１００ｂ）」は個別に開発された別システムであるため、それぞれのインタフェースや仕様等は必ずしも同一とは限らない。従って、「取引先２（４０２’）」にとっては、取引の相手方が「Ａ社」であるか「Ｂ社」であるかによって電子契約システムを使い分ける必要があり、煩雑である。
　図１３は、従来技術における非認定認証局を用いた電子契約サービスの他の構成例について概要を示した図である。この例では、上述の図１２の構成において各サービス導入企業が個別に保有していた電子契約システム（「Ａ社電子契約システム（１００ａ）」、「Ｂ社電子契約システム（１００ｂ）」）の機能を、システムベンダ１０１’がＡＳＰ（Application Service Provider）としてネットワーク経由でサービスとして提供する構成としたものである。サービス導入企業（図中では「Ａ社（３００ａ’）」、「Ｂ社（３００ｂ’）」）のシステム運用の負荷は低減されるものの、「取引先２（４０２’）」が電子契約システムを使い分ける必要があることなどは図１２の例の場合と同様である。
　＜実施の形態１＞
　本発明の実施の形態１である電子契約システムは、上記のような課題に対応するため、非認定認証局に対する証明書登録業務（本人確認および証明書の発行要求および配布）を、サービス導入企業や取引先に代わって一括して行うことで、サービス導入企業のシステム運用の負荷を低減させる。また、全てのサービス導入企業が共通に利用可能なシステムとして構成することで、取引の相手方のサービス導入企業に関わらず、取引先が電子契約システムを使い分けることを不要とする。また、電子契約システムが保管する契約書等の文書に対してサービス導入企業や取引先が電子証明書を利用して電子署名を行う際に、承認権者の意思に基づいて承認が行われることを保証するような電子署名申請プロセスを有することで、取引先がサービス導入企業との間で安全に電子契約を締結することを可能とする。
　［システム構成］
　図１は、本発明の実施の形態１である電子契約システムの構成例について概要を示した図である。電子契約システム１００は、例えば、電子契約サービスを提供するシステムベンダ等の企業により運営され、サーバ機器やクラウドコンピューティング環境における仮想サーバ等により構成される情報処理システムである。
　この電子契約システム１００は、図示しないインターネット等のネットワークを介して、非認定認証局２００や、サービス導入企業（図中では「Ａ社」～「Ｃ社」）の個別システムであるサービス導入企業個別システム３００（図中の「Ａ社個別システム（３００ａ）」～「Ｃ社個別システム（３００ｃ）」を総称する）、各サービス導入企業の取引先（図中では「取引先１」～「取引先５」）の個別システムである取引先システム４００（図中の「取引先１システム（４０１）」～「取引先５システム（４０５）」を総称する）と通信により接続可能な構成を有する。
　電子契約システム１００は、例えば、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System：データベース管理システム）、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアプログラムとして実装される、インタフェース部１１０、署名申請処理部１２０、電子署名部１３０（図中の「Ａ社電子署名部（１３０ａ）」～「Ｃ社電子署名部（１３０ｃ）」を総称する）、証明書登録処理部１４０、取引先管理部１５０、ユーザ管理部１６０、および文書管理部１７０などの各部を有する。なお、これら各部は、電子契約システム１００のサブシステムや、独立したシステムとして実装されていてもよい。
　インタフェース部１１０は、電子契約システム１００による電子契約サービスのユーザに対する操作画面等のユーザインタフェースを提供する機能を有する。例えば、図示しないＷｅｂサーバプログラムを利用して、ユーザが利用する情報処理端末上のＷｅｂブラウザに対して画面を表示させる。
　署名申請処理部１２０は、サービス導入企業や取引先のシステムや担当者から電子契約システム１００が保管する文書に対する電子署名の申請を受け付けて、指定された承認権者に対して承認依頼を行い、全ての承認権者から承認された場合に、後述する電子署名部１３０により対象の文書に対する電子署名を行うという一連の署名申請処理を行う機能を有する。各承認権者に対する承認依頼や承認結果などの承認状況については、データベースやファイルテーブルにより実装される承認状況テーブル（ＴＢ）１２３に記録する。なお、署名申請処理の詳細については後述する。
　署名申請処理部１２０は、さらに、署名申請処理の中で用いられるワンタイムパスワードを生成する機能を有するワンタイムパスワード（ＯＴＰ）処理部１２１、および、指定されたメールアドレスに対して指定された文書を電子メールにより送付する一般的なメールサーバの機能からなるメール処理部１２２などをさらに有している。これらの各機能については一般的な公知のサーバやプログラム、ライブラリなどを適宜利用することができる。
　電子署名部１３０は、電子契約サービスの各導入企業についての電子契約に係る文書データについて、上述した署名申請処理部１２０によって各承認権者からの承認が得られた場合に、対象のサービス導入企業による電子署名を自動で行う機能を有する。このために、各電子署名部１３０は、それぞれ、対象のサービス導入企業について、サービス提供の開始に先立って、後述する証明書登録処理部１４０により非認定認証局２００から電子証明書の発行を受けてこれを保持しておくものとする。なお、本実施の形態では、電子署名部１３０をサービスの導入企業毎に個別に実装するものとしているが、サービス導入企業毎に個別に電子署名を行うことが可能であればまとめて実装することも可能である。
　証明書登録処理部１４０は、サービス導入企業からの電子証明書の発行依頼を受けて、サービス導入企業もしくはその取引先についての電子証明書の発行依頼を非認定認証局２００に対して行う登録業務の機能を有する。証明書登録処理部１４０は、さらに、非認定認証局２００に対して証明書発行依頼を行う際に必要となる所定のフォーマットの帳票を作成して出力する帳票作成部１４１を有していてもよい。
　取引先管理部１５０は、電子契約システム１００による電子契約サービスを利用する各サービス導入企業がそれぞれ取引基本契約を締結している取引先の情報を取引先テーブル（ＴＢ）１５１に保持するとともに、登録や更新等の管理を行う機能を有する。この取引先ＴＢ１５１を参照することにより、当該電子契約システム１００を介しては、各サービス導入企業と、これらと取引基本契約を締結している取引先との間でのみ電子契約を締結して電子商取引を行うことが可能となるよう制御することができる。
　ユーザ管理部１６０は、電子契約システム１００にアクセスすることができるユーザについて、氏名や所属企業等の属性情報、ユーザＩＤやパスワードなどの認証情報、アクセス権限などの情報をユーザテーブル（ＴＢ）１６１に保持するとともに、登録や更新等の管理を行う機能を有する。ここでのユーザは、電子契約システム１００の管理者等に加えて、各サービス導入企業や取引先の担当者や電子署名の際の承認権者などが含まれる。
　文書管理部１７０は、電子契約システム１００を介して締結された電子契約に係る文書の原本を文書テーブル（ＴＢ）１７１に保管するとともに、アクセス権限のあるユーザからのアクセス要求に対して参照を許可する文書管理の機能を有する。当該機能についても、一般的な公知の文書管理システムやプログラム等を適宜利用することができる。
　非認定認証局２００は、例えば、ＪＩＰＤＥＣ（登録商標：一般財団法人日本情報経済社会推協会）が運営するＪＣＡＮ（登録商標）仕様のパブリック証明書を発行するＪＣＡＮ（登録商標）ルート認証局などを利用することで、安価に電子証明書の発行を行うことが可能である。このとき、電子契約システム１００の運営企業がＪＩＰＤＥＣ（登録商標）から認定（ＬＲＡ認定）を受けてＪＣＡＮ（登録商標）仕様の電子証明書の登録業務を行うことも可能である。なお、このようなパブリック証明書を利用せず、電子契約システム１００の運営企業が自ら非認定認証局２００を構築し、プライベートな電子証明書を発行するようにしてもよい。
　各サービス導入企業個別システム３００（図中では「Ａ社個別システム（３００ａ）」～「Ｃ社個別システム（３００ｃ）」）は、例えば、取引先との間で見積依頼の受付から見積提示、契約の締結、取引に至る一連の電子商取引を実施する基幹連携システム等の情報処理システムである。また、各取引先システム４００（図中では「取引先１システム（４０１）」～「取引先５システム（４０５）」）についても同様に、例えば、サービス導入企業との間で見積依頼から見積の受領、契約の締結、取引に至る一連の電子商取引を実施する情報処理システムである。なお、取引先としては、例えば、サービス導入企業にとっての商品等の仕入先だけでなく、顧客などの販売先や保守会社などの委託先等、電子契約を締結する相手方となる企業等が広く含まれる。
　図２は、本実施の形態における非認定認証局を用いた電子契約サービスの構成例について概要を示した図である。ここでは、電子契約システム１００がサービス導入企業（図中では「Ａ社（３００ａ’）」、「Ｂ社（３００ｂ’）」）からの依頼を受けて、非認定認証局２００に対する証明書登録業務を一括して行う構成をとることで、サービス導入企業および取引先（図中では「取引先１（４０１’）」～「取引先３（４０３’）」）が個別に非認定認証局２００から証明書の発行を受ける処理を行うことを不要とする。
　また、各サービス導入企業は、電子契約システム１００の運営企業と電子契約サービスの利用契約を締結することで、電子契約システム１００により電子契約に係る処理を行うことができるため、各サービス導入企業におけるシステム運用負荷を低減させることが可能となる。また、取引先ＴＢ１５１においてサービス導入企業毎に取引基本契約を締結している取引先の情報を一元的に管理する構成をとることで、取引先（図中では「取引先２（４０２’）」）にとっては相手方のサービス導入企業に関わらず同じ電子契約システム１００を利用することが可能となる。
　［処理の流れ］
　図３は、サービス導入企業が電子契約サービスを利用可能となるまでの処理の流れの例について概要を示したフロー図である。まず、サービス導入企業が電子契約システム１００の運営企業に対して電子契約サービスの利用契約の申込を行い（Ｓ０１）、所定の要件を満たしていれば契約を締結する（Ｓ０２）。なお、上記の処理は、サービス導入企業および電子契約システム１００の運営企業の人手により行うものとして説明したが、サービス導入企業の個別システム３００と電子契約システム１００との間でシステム的に行うようにしてもよい。
　サービス契約が締結されると、電子契約システム１００では、管理者等による手動もしくは自動で、対象のサービス導入企業の属性等の企業情報を、図示しないサービス導入企業マスタ等のテーブルや取引先ＴＢ１５１などに登録する（Ｓ０３）。予め対象のサービス導入企業の取引先が分かっている場合は、この時点で当該情報について取引先ＴＢ１５１に登録するようにしてもよい。さらに、対象のサービス導入企業について、対応する電子署名部１３０を実装する（Ｓ０４）。例えば、対象のサービス導入企業用のプログラムやモジュール、サーバ等を適宜実装する。
　その後、サービス導入企業では、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示（例えば、Ｗｅｂブラウザ等により電子契約システム１００にアクセスして行う指示）に基づいて、電子契約システム１００に対して当該サービス導入企業についての電子証明書の発行申請を行う（Ｓ０５）。発行申請を受け付けた電子契約システム１００では、証明書登録処理部１４０により、必要に応じて帳票作成部１４１によって申請用帳票を作成した上で、非認定認証局２００に対して電子証明書の発行依頼を行う（Ｓ０６）。
　発行依頼を受け付けた非認定認証局２００では、申請内容について所定の判定処理等を行った上で電子証明書を発行し（Ｓ０７）、電子契約システム１００に対して送付する（Ｓ０８）。電子契約システム１００では、受領した電子証明書を対象のサービス導入企業に対応する電子署名部１３０が利用可能なように保存する（Ｓ０９）。サービス導入企業が独自に電子署名を行えるように、電子証明書をサービス導入企業に対しても送付するようにしてもよい。
　図４は、サービス導入企業が潜在的な取引先から見積依頼を受けた場合の処理の流れの例について概要を示した図である。まず、潜在的な取引先において、取引先システム４００もしくは担当者等の情報処理端末を介した指示（例えば、Ｗｅｂブラウザ等によりサービス導入企業個別システム３００にアクセスして行う指示）に基づいて、サービス導入企業個別システム３００に対して商品等の見積依頼を行う（Ｓ１１）。サービス導入企業個別システム３００では、依頼内容に基づいて自動もしくは担当者の手動により見積書を作成し（Ｓ１２）、これを電子契約システム１００に自動もしくは担当者の情報処理端末を介した指示に基づいてアップロードして登録依頼を行う（Ｓ１３）。電子契約システム１００では、文書管理部１７０により、アップロードされた見積書を文書ＴＢ１７１に登録する（Ｓ１４）。
　さらに、サービス導入企業個別システム３００では、自動もしくは担当者の情報処理端末を介した指示に基づいて、電子契約システム１００に対して、アップロードした見積書に電子署名を行うために必要な所定の承認を得るプロセスである電子署名申請処理を行う（Ｓ１５）。電子署名申請処理の内容については後述する。
　電子署名申請処理により、見積書を作成したサービス導入企業において所定の承認権者による承認が得られた場合、電子契約システム１００では、対象のサービス導入企業に対応する電子署名部１３０により、対象の見積書に対して電子署名を行い（Ｓ１６）、これを対象の取引先システム４００もしくは担当者等から閲覧可能となるようアクセス権限等を設定する（Ｓ１７）。このとき、電子署名がされた見積書が登録されて閲覧可能となった旨を取引先システム４００もしくは担当者等に電子メール等により通知するようにしてもよい。
　図４の例では、電子署名申請処理が完了したことにより（Ｓ１５）、見積書に電子署名を行って（Ｓ１６）これを閲覧可能としている（Ｓ１７）が、見積書を登録したとき（Ｓ１４）に予め電子署名を行っておき、電子署名申請処理が完了した時点で閲覧可能とする（アクセス制限を解除する）ようにしてもよい。
　見積書が閲覧可能となった後、例えば、取引先の担当者等は、情報処理端末を使用して、電子契約システム１００に保管された見積書に対する閲覧要求を行う（Ｓ１８）。ここでは、例えば、情報処理端末上のＷｅｂブラウザ等を利用して、サービス導入企業個別システム３００のＷｅｂサイト等を経由して電子契約システム１００に対して閲覧要求を行うことができる。電子契約システム１００では、要求された見積書を文書ＴＢ１７１から取得して出力することで提示し（Ｓ１９）、取引先の担当者等は、情報処理端末を使用してこれを閲覧する（Ｓ２０）。
　図５は、サービス導入企業が新たな取引先と取引の基本契約を締結した場合の処理の流れの例について概要を示した図である。まず、サービス導入企業と取引先が取引の基本契約を締結する（Ｓ２１）。ここでの契約は書面等により行われるが、可能な場合にはサービス導入企業個別システム３００や取引先システム４００に対して、サービス導入企業や取引先の担当者が情報処理端末を利用してアクセスする等によりシステム的に行ってもよい。
　取引基本契約が締結されると、サービス導入企業では、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示に基づいて、電子契約システム１００に対して、対象の取引先についての情報の登録依頼を行う（Ｓ２２）。依頼を受けた電子契約システム１００では、取引先管理部１５０により対象の取引先の情報を対象のサービス導入企業と関連付けて取引先ＴＢ１５１に登録する（Ｓ２３）。
　その後、サービス導入企業では、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示に基づいて、電子契約システム１００に対して、対象の取引先についての電子証明書の発行申請を行う（Ｓ２４）。発行申請を受け付けた電子契約システム１００では、申請内容に基づいて、図３の例におけるステップＳ０６～Ｓ０９での処理と同様の処理によって非認定認証局２００から電子証明書の発行を受け（Ｓ２５）、これを取引先（もしくは取引先システム４００）に対して送付する（Ｓ２６）。
　取引先システム４００では、受領した電子証明書を電子署名の際に利用可能なように保存する（Ｓ２７）。なお、上記の証明書の配布処理は、サービス導入企業が新たな取引先と基本契約を締結したときの初回のみの処理であり、当該取引先に電子証明書が配布された後は不要である。
　図６は、サービス導入企業と取引先との間で個別取引の契約が締結される場合の処理の流れの例について概要を示した図である。まず、取引先では、見積依頼のときと同様に、取引先システム４００もしくは担当者等の情報処理端末を介した指示に基づいて、サービス導入企業個別システム３００に対して契約の申込みを行う（Ｓ３１）。サービス導入企業個別システム３００では、申込内容や見積書の内容に基づいて自動もしくは担当者の手動により契約書を作成し（Ｓ３２）、これを電子契約システム１００に自動もしくは担当者の情報処理端末を介した指示に基づいてアップロードして登録依頼を行う（Ｓ３３）。
　電子契約システム１００では、取引先ＴＢ１５１を参照して対象の取引先が登録されているかを確認した上で、すなわち、対象の取引先が電子契約サービスを利用可能かを確認した上で、文書管理部１７０により、アップロードされた契約書を文書ＴＢ１７１に登録する（Ｓ３４）。さらに、サービス導入企業個別システム３００では、自動もしくは担当者からの指示に基づいて、電子契約システム１００に対して、アップロードした契約書に電子署名を行うために、図４の例におけるステップＳ１５と同様の電子署名申請処理を行う（Ｓ３５）。
　電子署名申請処理により、契約書を作成したサービス導入企業において所定の承認権者による承認が得られた場合、電子契約システム１００では、対象のサービス導入企業に対応する電子署名部１３０により、対象の契約書に対して電子署名を行い（Ｓ３６）、当該契約書が対象の取引先システム４００もしくは担当者等から閲覧可能となるようアクセス権限等を設定する（Ｓ３７）。このとき、電子署名がされた契約書が登録されて閲覧可能となった旨を取引先システム４００もしくは担当者等に電子メール等により通知するようにしてもよい。
　契約書が閲覧可能となった後、例えば、取引先の担当者等は、情報処理端末を使用して、サービス導入企業個別システム３００のＷｅｂサイト等を経由して電子契約システム１００に保管された契約書に対する閲覧要求を行う（Ｓ３８）。このとき、閲覧可能な文書の一覧リストを電子契約システム１００に対して要求し、得られたリストの中から閲覧対象の契約書を選択する形とすることも可能である。この場合、電子契約システム１００は、文書管理部１７０により、対象の取引先がアクセス権限を有する文書のリストを文書ＴＢ１７１から抽出して提示する。閲覧要求を受けた電子契約システム１００では、要求された契約書を文書ＴＢ１７１から取得して出力することで提示し（Ｓ３９）、取引先の担当者等は、情報処理端末を使用してこれを閲覧し、必要に応じて内容の追記などを行う（Ｓ４０）。
　その後、取引先では、自動もしくは担当者の情報処理端末を介した指示に基づいて、電子契約システム１００に対して、契約書に電子署名を行うために、図４の例におけるステップＳ１５と同様の電子署名申請処理を行う（Ｓ４１）。電子署名申請処理により、取引先において所定の承認権者による承認が得られた場合、取引先システム４００では、対象の契約書に対して電子署名を行い（Ｓ４２）、署名された契約書を電子契約システム１００に対してアップロードして原本として保管するよう要求する（Ｓ４３）。電子契約システム１００では、受領した契約書を原本として文書ＴＢ１７１に保管する（Ｓ４４）。
　なお、取引先による電子署名の処理（Ｓ４２）を、上記のステップＳ３６と同様に電子契約システム１００上で実施するようにして、電子署名申請処理（Ｓ４１）の承認結果と連携して実行させるようにしてもよい。
　図７は、見積書や契約書等の文書に電子署名を行うために必要な所定の承認を得るための電子署名申請処理の流れの例について概要を示した図である。この処理は、例えば、上述の図４の例におけるステップＳ１５や、図６の例におけるステップＳ３５、Ｓ４１において行われる処理である。ここでは、サービス導入企業や取引先において契約業務を行う担当者等が情報処理端末を利用して電子契約システム１００にアクセスして手動で電子署名申請処理の指示を行う場合を例として示している。
　まず、担当者は、担当者端末３１１を利用して電子契約システム１００に対して電子署名の対象となる文書のリストの照会要求を行う（Ｓ５１）。電子契約システム１００では、文書管理部１７０により、対象の担当者が属するサービス導入企業もしくは取引先が電子署名することが可能な文書（例えば、アクセス権限があり、電子署名が未だされていない文書）のリストを文書ＴＢ１７１から抽出して取得することで担当者端末３１１に提示する（Ｓ５２）。
　担当者は、担当者端末３１１に提示された文書のリストから、電子署名を行う対象の文書（見積書や契約書）を選択し（Ｓ５３）、さらに、電子署名を行う際に承認を必要とする上長等の承認権者を１人以上選択する（Ｓ５４）。承認権者の選択の際には、例えば、電子契約システム１００においてユーザ管理部１６０により予めユーザＴＢ１６１にユーザ登録されている者（すなわち、電子契約システム１００にアクセス可能な者）から選択するようにしてもよい。その後、電子契約システム１００に対して電子署名申請の要求を行う（Ｓ５５）。当該要求には、対象の文書と承認権者の情報が含まれる。
　電子署名申請の要求を受けた電子契約システム１００では、署名申請処理部１２０により申請ＩＤを採番して、承認状況ＴＢ１２３に承認状況をトラッキングするためのエントリを登録した上で、ＯＴＰ処理部１２１により、承認権者毎にユニークなワンタイムパスワードを生成して割り当てる（Ｓ５６）。その後、申請ＩＤと、対象の文書を特定するファイル名等の情報、およびステップＳ５６で生成したワンタイムパスワードの情報を含む承認要求の電子メール文書を承認権者毎に作成し、これをメール処理部１２２により各承認権者の電子メールアドレスに送信する（Ｓ５７）。
　各承認権者は、承認権者端末３１２により承認要求の電子メールを受領すると（Ｓ５８）、これに含まれる申請ＩＤや文書の特定情報に基づいて電子契約システム１００に対して対象の文書に対する閲覧要求をそれぞれ行う（Ｓ５９）。閲覧要求を受けた電子契約システム１００では、要求された文書を文書ＴＢ１７１から取得して出力することで提示し（Ｓ６０）、各承認権者は、承認権者端末３１２を使用して文書の内容をそれぞれ確認する（Ｓ６１）。
　文書の内容に問題がなければ、各承認権者は、それぞれステップＳ５８で受領した承認要求の電子メールに対してそのまま送信元に返信する（Ｓ６２）。送信元である電子契約システム１００では、返信された承認要求の電子メールを受領すると、これに含まれるワンタイムパスワードと、ステップＳ５６において対象の承認権者に対して割り当てたワンタイムパスワードとが合致しているか否かを照合し、結果を承認状況ＴＢ１２３に記録する（Ｓ６３）。
　全ての承認権者から承認要求の電子メールに対する返信を受領し、かつこれに含まれるワンタイムパスワードがステップＳ５６にて割り当てたものと合致していた場合は、適切に承認がされたものとして、電子契約システム１００もしくは取引先システム４００による後続の電子署名の処理に移る。なお、例えば、所定の応答時間内に承認要求の電子メールに対する応答を電子契約システム１００が受領できなかった場合や、承認拒絶もしくは第三者によるなりすまし等の理由によりワンタイムパスワードが合致しなかった場合には、電子署名申請が拒絶されたものとして電子署名を行わないようにする。
　このような処理により、承認権者に負担をかけずに所定の承認権者により（もしくは所定の承認権者の意思に基づいて）承認処理が行われることを保証し、担当者等の第三者が承認者の承認を得ずに独断で電子署名を行うことを防ぐことができる。
　以上に説明したように、本発明の実施の形態１である電子契約システム１００によれば、非認定認証局２００に対する証明書登録業務を、サービス導入企業や取引先に代わって一括して行うことで、サービス導入企業のシステム運用の負荷を低減することが可能となる。また、全てのサービス導入企業が共通に利用可能なシステムとして構成することで、取引の相手方のサービス導入企業に関わらず、取引先が電子契約システムを使い分けることが不要となる。また、電子契約システム１００が保管する契約書等の文書に対してサービス導入企業や取引先が電子証明書を利用して電子署名を行う際に、承認権者の意思に基づいて承認が行われることを保証するような電子署名申請処理プロセスを有することで、取引先がサービス導入企業との間で安全に電子契約を締結することが可能となる。
　＜実施の形態２＞
　上述した実施の形態１の電子契約システム１００では、図７の例に示したような電子署名申請処理を有することで、承認権者の意思に基づいて承認が行われることを保証する仕組みを有している。しかしながら、図７の例に示したような電子署名申請処理では、例えば、承認権者の電子メールアドレスが誤って登録されるなど、署名申請処理部１２０からの承認要求の電子メールが承認権者以外の者に誤送信された場合、当該承認権者以外の者が当該電子メールに対して単純返信することで容易に承認されてしまうことを排除できない。
　そこで、本発明の実施の形態２である電子契約システム１００は、ワンタイムパスワードを承認権者自身がシステムに入力して承認する方式とすることで、電子メールの誤送信の際の問題を回避することを可能とするものである。なお、システム構成や処理内容については、基本的に上記の実施の形態１に示した内容と同様であるため、再度の記載は省略するが、相違点である電子署名申請処理の流れについて以下に説明する。
　図８は、本実施の形態における電子署名申請処理の流れの例について概要を示した図である。電子署名申請処理において、最初に、担当者が担当者端末３１１を利用して署名対象の文書を選択し、さらに１人以上の承認権者（承認順序も設定するものとする）を選択して、電子契約システム１００に対して署名申請要求を行うところ（Ｓ７５）、および署名申請要求を受けた電子契約システム１００がワンタイムパスワードを生成するところ（Ｓ７６）までは、実施の形態１の図７の例に示した電子署名申請処理のステップＳ５１～Ｓ５５およびＳ５６と同様であるため、説明は省略する。
　その後、電子契約システム１００のメール処理部１２２は、申請ＩＤと、ステップ７６で生成したワンタイムパスワード、これまでの承認権者（存在する場合）、およびインタフェース部１１０により提供される承認専用画面にアクセスするためのＵＲＬ（Uniform Resource Locator）の情報を含む承認要求の電子メール文書を、承認順序における次の承認権者の電子メールアドレスに送信する（Ｓ７７）。
　対象の承認権者は、承認権者端末３１２により承認要求の電子メールを受領すると（Ｓ７８）、これに含まれる承認専用画面のＵＲＬにアクセスし、承認専用画面にログインする（Ｓ７９）。このとき、承認権者は、電子契約システム１００に対する通常のログインＩＤとパスワード、および承認要求の電子メールに含まれるワンタイムパスワードを入力するものとする。なお、承認専用画面のＵＲＬを、ワンタイムパスワードを含めて生成する等、毎回異なるユニークなＵＲＬとすることにより、当該ＵＲＬにアクセスすること自体でワンタイムパスワードを入力したものとすることも可能である。
　電子契約システム１００では、ユーザＴＢ１６１および承認状況ＴＢ１２３に基づいて、ログインＩＤとパスワードの照合、および承認権者であることの確認を行うとともに、署名申請処理部１２０等によりワンタイムパスワードを照合する認証処理を行う（Ｓ８０）。認証結果が問題なければ承認状況ＴＢ１２３を参照して対象の承認権者についての未承認の文書もしくは案件のリストを承認権者端末３１２上に表示して提示する（Ｓ８１）。
　承認権者は、承認権者端末３１２に表示された未承認案件のリストから承認対象の案件を特定して承認／不承認の旨の入力を行う（Ｓ８２）。このとき、図７の例におけるステップＳ５９～Ｓ６１のように、対象の案件に係る文書を閲覧する処理を行なってもよい。承認結果の情報は、電子契約システム１００の署名申請処理部１２０により、承認状況ＴＢ１２３に登録する（Ｓ８３）。
　案件が承認された場合は、次の承認権者の承認処理を行うため、ステップＳ７６と同様に新たにワンタイムパスワードを生成し（Ｓ８４）、次の承認権者に対して承認要求の電子メールを送信する（Ｓ８５）。以降の処理（Ｓ８６～）は、上述したステップＳ７８～Ｓ８３）と同様である。
　このように、承認権者毎に順にステップＳ７６～Ｓ８３の一連の処理を繰り返すことで、承認処理のワークフローを構成することができる。ワークフローにおける承認状況は、例えば、担当者が担当者端末３１１を利用して電子契約システム１００にアクセスすることで、承認状況ＴＢ１２３の内容に基づいて得られる承認状況を随時確認することができる。なお、ワークフローの最後の承認権者、すなわち電子契約システム１００から発行された電子証明書を所有する承認権者が承認処理を行う際は、例えば、承認専用画面に「電子署名を実行してもよろしいですか？」のような確認メッセージを表示するのが望ましい。
　実施の形態１の図７の例では、複数の承認権者に一斉に承認要求の電子メールを送信し、各承認権者が個別に承認処理を行って、全員が承認した場合に承認されたものとする非同期的な手順をとっているが、実施の形態１における電子署名申請処理に本実施の形態のような承認順序に従ったワークフローによる同期的な手順を適用することも可能である。また、逆に、本実施の形態における電子署名申請処理に実施の形態１のような非同期的な手順を適用することも可能である。
　以上に説明したように、本発明の実施の形態２である電子契約システム１００によれば、案件や文書毎の承認専用画面を設けて、これに対するＵＲＬの情報を承認要求に埋め込み、承認権者のシステムへのログインＩＤとパスワード、およびワンタイムパスワードをそれぞれ入力させるようにする。すなわち、これらの情報が揃っていないと承認処理を行うことができないようにする。これにより、例えば、ユーザＩＤとパスワードが漏洩した場合や、最新のワンタイムパスワードが漏洩した場合でも、承認専用画面にアクセスして承認処理が行われること防止し、適切な承認権者が承認を行うことを保証して、承認要求の電子メールの誤送信等の際の問題を回避することが可能となる。
　＜実施の形態３＞
　上述した実施の形態１の電子契約システム１００では、図５の例に示したような処理により、サービス導入企業が新たな取引先と取引の基本契約を締結した場合に、サービス導入企業の担当者等が取引先の情報を電子契約システム１００に登録し、電子証明書を発行させる仕組みを有している。これにより、システムの利便性を向上させている。
　しかしながら、サービス導入企業が自社の責任で自由に取引先を電子契約システム１００に登録し、電子証明書を発行させることができる仕組みでは、例えば、架空の取引先の登録や、社内の与信審査を通過していない企業の取引先としての登録が可能となり、電子契約システム１００の安全性が損なわれることになる。
　そこで、本発明の実施の形態３である電子契約システム１００は、サービス導入企業が取引先を新たに登録する際に承認処理を介することで、取引先の無制限の登録を防止し、システムの安全性を確保するものである。なお、システム構成や処理内容については、基本的に上記の実施の形態１に示した内容と同様であるため、再度の記載は省略するが、相違点である、サービス導入企業による取引先の登録に係る処理の流れについて以下に説明する。
　図９は、本実施の形態における、サービス導入企業が新たな取引先と取引の基本契約を締結した場合の処理の流れの例について概要を示した図である。ここでは、対象の取引先が、既に他のサービス導入企業との間で基本契約を締結し、電子契約システム１００を介して電子証明書の発行を受けている場合の例を示している。
　まず、実施の形態１の図５の例におけるステップＳ２１と同様に、サービス導入企業と取引先が取引の基本契約を締結する（Ｓ９１）。取引基本契約が締結されると、サービス導入企業では、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示に基づいて、電子契約システム１００に対して、対象の取引先についての登録情報の確認要求を行う（Ｓ９２）。ここでは、例えば、対象の取引先が既に所有している電子証明書のＩＤや、所有者の電子メールアドレスなどを入力することで、対象の取引先を特定する。要求を受けた電子契約システム１００では、取引先管理部１５０から対象の取引先の情報を取得して提示する（Ｓ９３）。サービス導入企業では、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示に基づいて、取引先の登録情報の内容を確認する（Ｓ９４）。
　その後、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示に基づいて、取引先の登録についての１人以上の承認権者（承認順序も設定するものとする）を選択する（Ｓ９５）。なお、承認権者には電子契約システム１００から発行された電子証明書の所有者を含めるものとする。選択された各承認権者について、実施の形態２の図８に示した署名申請処理におけるステップＳ７５（本実施の形態では署名申請要求ではなく取引先の登録に係る承認要求となる）以降の一連の処理と同様の処理により、複数の承認権者によってワークフローにより順に取引先の登録について承認する承認処理を行う（Ｓ９６）。各承認権者が承認を行う際、例えば、承認専用画面に「社内で与信審査等の審査を通過した正当な取引先であることを確認していますか？」のような確認メッセージを表示するのが望ましい。
　最終の承認権者（すなわち、電子証明書の所有者）により承認が行われると、電子契約システム１００は、取引先システム４００もしくは取引先の担当者の情報処理端末に対して、取引先として登録されることに対する承諾の要求を行う（Ｓ９７）。例えば、メール処理部１２２によって電子メールを送信することにより要求を行うことができる。このとき、例えば、「（サービス導入企業）によって取引先として登録されてもよろしいですか？」などの確認メッセージを表示等するのが望ましい。
　取引先では、取引先システム４００もしくは承認権者（すなわち電子証明書の所有者）の情報処理端末を介した指示に基づいて、取引先として登録されることに対する承諾／不承諾の入力を受け付けて電子契約システム１００に対して応答する（Ｓ９８）。電子契約システム１００では、承諾の応答を受けた場合は、取引先管理部１５０により、対象の取引先を新たに対象のサービス導入企業の取引先として関連付けて取引先ＴＢ１５１に登録する（Ｓ９９）。
　図１０は、本実施の形態における、サービス導入企業が新たな取引先と取引の基本契約を締結した場合の処理の流れの別の例について概要を示した図である。ここでは、対象の取引先が、未だいずれのサービス導入企業との間でも基本契約を締結しておらず、電子契約システム１００を介した電子証明書の発行を受けていない場合の例を示している。
　まず、実施の形態１の図５の例におけるステップＳ２１と同様に、サービス導入企業と取引先が取引の基本契約を締結する（Ｓ１０１）。取引基本契約が締結されると、サービス導入企業では、図５の例におけるステップＳ２２と同様に、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示に基づいて、電子契約システム１００に対して、対象の取引先についての情報の登録依頼を行う（Ｓ１０２）。対象の取引先についての情報には、例えば、電子証明書の発行相手の電子メールアドレスや、企業情報などが含まれる。依頼を受けた電子契約システム１００では、取引先管理部１５０により対象の取引先の情報を対象のサービス導入企業と関連付けて取引先ＴＢ１５１に仮登録する（Ｓ１０３）。
　その後、図９の例に示したステップＳ９５、９６の一連の処理と同様の処理により、サービス導入企業において選択された１人以上の承認権者によるワークフローにより、順に取引先の登録について承認する承認処理を行う（Ｓ１０４、１０５）。
　最終の承認権者（すなわち、電子証明書の所有者）により承認が行われると、電子契約システム１００は、取引先システム４００もしくは取引先の担当者の情報処理端末に対して、電子契約システム１００にアクセスするよう電子メール等により通知を行う（Ｓ１０６）。この通知には、例えば、ユーザ管理部１６０により発行された仮のログインＩＤとパスワード、アクセス先のＵＲＬなどの情報が含まれる。
　取引先では、担当者の情報処理端末等を介して電子契約システム１００にアクセスして初回のログイン処理を行う（Ｓ１０７）。電子契約システム１００では、正常にログインできた場合に、取引先システム４００もしくは取引先の担当者の情報処理端末に対して、取引先として登録されることに対する承諾の要求を行う（Ｓ１０８）。例えば、図９の例におけるステップＳ９７と同様に電子メールにより要求を行うことができる。また、ログイン後の画面に要求を表示するようにしてもよい。このとき、例えば、「（サービス導入企業）によって取引先として登録されてもよろしいですか？」などの確認メッセージを表示等するのが望ましい。
　取引先では、取引先システム４００もしくは担当者等の情報処理端末を介した指示に基づいて、取引先として登録されることに対する承諾／不承諾の入力を受け付けて電子契約システム１００に対して応答する（Ｓ１０９）。電子契約システム１００では、承諾の応答を受けた場合は、取引先管理部１５０により、対象の取引先についてステップＳ１０３において取引先ＴＢ１５１に登録された仮登録を本登録に変更する（Ｓ１１０）。その後は、図５のステップＳ２４以降の処理と同様に、サービス導入企業個別システム３００もしくは担当者等の情報処理端末を介した指示に基づいて、電子契約システム１００に対して、対象の取引先についての電子証明書の発行申請を行い（Ｓ１１１）、電子証明書の発行を受ける。
　以上に説明したように、本発明の実施の形態３である電子契約システム１００によれば、サービス導入企業において取引先を新たに登録する際に、ワークフローによる承認処理を介するように制御し、また、取引先からも承認を得るようにすることで、取引先の無制限の登録を防止し、システムやサービスの安全性を確保することが可能となる。
　以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
　また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
　本発明は、企業間の電子商取引契約を支援する電子契約システムに利用可能である。
１００、１０１…電子契約システム、１０１’…システムベンダ、１１０…インタフェース部、１２０…署名申請処理部、１２１…ＯＴＰ処理部、１２２…メール処理部、１２３…承認状況テーブル（ＴＢ）、１３０…電子署名部、１３０ａ～ｃ…Ａ社～Ｃ社電子署名部、１４０…証明書登録処理部、１４１…帳票作成部、１５０…取引先管理部、１５１、１５１ａ、ｂ…取引先テーブル（ＴＢ）、１６０…ユーザ管理部、１６１…ユーザテーブル（ＴＢ）、１７０…文書管理部、１７１…文書テーブル（ＴＢ）、
２００…非認定認証局、２０１…認定認証局、
３００…サービス導入企業個別システム、３００ａ～ｃ…Ａ社～Ｃ社個別システム、３００ａ’、ｂ’…Ａ社、Ｂ社、
４００…取引先システム、４０１～４０５…取引先１～５システム、４０１’～４０３’…取引先１～３。
 
 
 
 
 

Claims (12)

  1. 　電子商取引における第１の取引主体と第２の取引主体との間の電子契約の締結を支援する電子契約システムであって、
    　１つ以上の前記第１の取引主体毎に、前記第１の取引主体についての電子契約に係る文書に対して電子署名を行う電子署名部と、
    　前記第１の取引主体についての前記文書に対して電子署名を行う際の承認処理を行う署名申請処理部と、
    　前記各第１の取引主体についての前記文書を保持する文書記録装置と、
    　を有し、
    　前記署名申請処理部は、
    　前記第１の取引主体からの前記文書に対する電子署名の申請を受け付けて、当該申請に含まれる前記第１の取引主体における１人以上の第１の承認権者毎に第１のワンタイムパスワードを生成し、当該第１のワンタイムパスワードおよび前記文書を特定する情報を含む第１の電子メールを作成して前記各第１の承認権者に送付し、全ての前記第１の承認権者から前記第１の電子メールに対する返信を受領し、かつ当該各返信の中に、対応する前記第１の承認権者に割り当てた前記第１のワンタイムパスワードと合致する内容が含まれる場合に、前記第１の取引主体に対応する前記電子署名部により、前記文書に対して電子署名を行う、電子契約システム。
  2. 　電子商取引における第１の取引主体と第２の取引主体との間の電子契約の締結を支援する電子契約システムであって、
    　１つ以上の前記第１の取引主体毎に、前記第１の取引主体についての電子契約に係る文書に対して電子署名を行う電子署名部と、
    　前記第１の取引主体についての前記文書に対して電子署名を行う際の承認処理を行う署名申請処理部と、
    　前記各第１の取引主体についての前記文書を保持する文書記録装置と、
    　を有し、
    　前記署名申請処理部は、
    　前記第１の取引主体からの前記文書に対する電子署名の申請を受け付けて、当該申請に含まれる前記第１の取引主体における１人以上の第１の承認権者毎に、当該申請に含まれる承認順序に基づいて順に、第１のワンタイムパスワードを生成し、当該第１のワンタイムパスワードおよび第１の承認用画面のＵＲＬの情報を含む第１の電子メールを作成して前記第１の承認権者に送付し、前記第１の承認用画面を介して前記第１の承認権者から入力された承認結果を取得し、最終順序の前記第１の承認権者により承認する旨の結果を取得した場合に、前記第１の取引主体に対応する前記電子署名部により、前記文書に対して電子署名を行い、
    　前記第１の承認権者からの承認結果を受け付ける際に、前記第１の承認用画面を介して、前記第１の承認権者が当該電子契約システムにログインするために必要な認証情報に加えて、前記第１のワンタイムパスワードの入力を受け付け、これらが合致した場合に前記第１の承認権者による当該電子契約システムへの承認結果の入力のためのログインを許可する、電子契約システム。
  3. 　請求項１に記載の電子契約システムにおいて、
    　前記署名申請処理部は、
    　前記第１の取引主体についての前記文書について、対応する電子契約の相手方である前記第２の取引主体からの前記文書に対する電子署名の申請を受け付けて、当該申請に含まれる前記第２の取引主体における１人以上の第２の承認権者毎に第２のワンタイムパスワードを生成し、当該第２のワンタイムパスワードおよび前記文書を特定する情報を含む第２の電子メールを作成して前記各第２の承認権者に送付し、全ての前記第２の承認権者から前記第２の電子メールに対する返信を受領し、かつ当該各返信の中に、対応する前記第２の承認権者に割り当てた前記第２のワンタイムパスワードと合致する内容が含まれる場合に、前記第２の取引主体において前記文書に対する電子署名を実施させる、電子契約システム。
  4. 　請求項２に記載の電子契約システムにおいて、
    　前記署名申請処理部は、
    　前記第１の取引主体についての前記文書について、対応する電子契約の相手方である前記第２の取引主体からの前記文書に対する電子署名の申請を受け付けて、当該申請に含まれる前記第２の取引主体における１人以上の第２の承認権者毎に、当該申請に含まれる承認順序に基づいて順に、第２のワンタイムパスワードを生成し、当該第２のワンタイムパスワードおよび第２の承認用画面のＵＲＬの情報を含む第２の電子メールを作成して前記各第２の承認権者に送付し、前記第２の承認用画面を介して前記第２の承認権者から入力された承認結果を取得し、最終順序の前記第２の承認権者により承認する旨の結果を取得した場合に、前記第２の取引主体において前記文書に対する電子署名を実施させ、
    　前記第２の承認権者からの承認結果を受け付ける際に、前記第２の承認用画面を介して、前記第２の承認権者が当該電子契約システムにログインするために必要な認証情報に加えて、前記第２のワンタイムパスワードの入力を受け付け、これらが合致した場合に前記第２の承認権者による当該電子契約システムへの承認結果の入力のためのログインを許可する、電子契約システム。
  5. 　請求項１に記載の電子契約システムにおいて、
    　さらに、前記各第１の取引主体が当該電子契約システムを介して電子契約を締結することが可能な前記第２の取引主体についての情報を保持する取引先記録装置を有し、
    　前記第１の取引主体についての前記文書について、対応する電子契約の相手方である前記第２の取引主体の情報が前記取引先記録装置に登録されている場合にのみ、前記文書に対する電子署名および前記文書記録装置への保持を許可する、電子契約システム。
  6. 　請求項２に記載の電子契約システムにおいて、
    　さらに、前記各第１の取引主体が当該電子契約システムを介して電子契約を締結することが可能な前記第２の取引主体についての情報を保持する取引先記録装置を有し、
    　前記第１の取引主体についての前記文書について、対応する電子契約の相手方である前記第２の取引主体の情報が前記取引先記録装置に登録されている場合にのみ、前記文書に対する電子署名および前記文書記録装置への保持を許可する、電子契約システム。
  7. 　請求項５に記載の電子契約システムにおいて、
    　前記第１の取引主体が当該電子契約システムを介して電子契約を締結することが可能な前記第２の取引主体についての情報を前記取引先記録装置に記録する際に、前記第１の取引主体における第３の承認権者、および前記第２の取引主体における第４の承認権者による承認の入力を受け付けた場合にのみ記録を許可する、電子契約システム。
  8. 　請求項６に記載の電子契約システムにおいて、
    　前記第１の取引主体が当該電子契約システムを介して電子契約を締結することが可能な前記第２の取引主体についての情報を前記取引先記録装置に記録する際に、前記第１の取引主体における第３の承認権者、および前記第２の取引主体における第４の承認権者による承認の入力を受け付けた場合にのみ記録を許可する、電子契約システム。
  9. 　請求項１に記載の電子契約システムにおいて、
    　さらに、前記第１の取引主体からの、前記第１の取引主体もしくは前記第１の取引主体が当該電子契約システムを介して電子契約を締結することが可能な前記第２の取引主体に対する電子証明書の発行の要求を受け付けて、認証局に対して前記電子証明書の発行を依頼し、発行された前記電子証明書を、前記第１の取引主体もしくは前記第２の取引主体に対して配布する証明書登録処理部を有する、電子契約システム。
  10. 　請求項２に記載の電子契約システムにおいて、
    　さらに、前記第１の取引主体からの、前記第１の取引主体もしくは前記第１の取引主体が当該電子契約システムを介して電子契約を締結することが可能な前記第２の取引主体に対する電子証明書の発行の要求を受け付けて、認証局に対して前記電子証明書の発行を依頼し、発行された前記電子証明書を、前記第１の取引主体もしくは前記第２の取引主体に対して配布する証明書登録処理部を有する、電子契約システム。
  11. 　請求項９に記載の電子契約システムにおいて、
    　前記認証局は非認定認証局である、電子契約システム。
  12. 　請求項１０に記載の電子契約システムにおいて、
    　前記認証局は非認定認証局である、電子契約システム。
     
     
     
PCT/JP2013/082798 2012-12-26 2013-12-06 電子契約システム WO2014103663A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2012-283353 2012-12-26
JP2012283353A JP2014127034A (ja) 2012-12-26 2012-12-26 電子契約システム

Publications (1)

Publication Number Publication Date
WO2014103663A1 true WO2014103663A1 (ja) 2014-07-03

Family

ID=51020755

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/082798 WO2014103663A1 (ja) 2012-12-26 2013-12-06 電子契約システム

Country Status (2)

Country Link
JP (1) JP2014127034A (ja)
WO (1) WO2014103663A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105303330A (zh) * 2015-11-20 2016-02-03 周庆余 一种网络平台签章管控系统
CN105844481A (zh) * 2016-03-24 2016-08-10 胡金钱 一种对合同进行数字签名以及防伪验证的系统和方法
CN110263581A (zh) * 2019-05-08 2019-09-20 深圳法大大网络科技有限公司 合同签署方法、系统、终端设备及存储介质
CN111523861A (zh) * 2020-04-24 2020-08-11 北京思特奇信息技术股份有限公司 电子化合同的线上签章流程
EP4163848A4 (en) * 2020-06-04 2023-05-31 Fujitsu Limited CONTROL METHOD, INFORMATION PROCESSING DEVICE AND CONTROL PROGRAM

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7281351B2 (ja) * 2019-06-10 2023-05-25 株式会社しんきん情報サービス 払込票処理システム
JP7291992B2 (ja) * 2019-06-10 2023-06-16 株式会社しんきん情報サービス 払込票処理システム
JP6991179B2 (ja) * 2019-06-28 2022-01-12 フリー株式会社 取引管理装置、取引管理方法及び取引管理プログラム
JP7233459B2 (ja) 2020-04-10 2023-03-06 フリーサイン株式会社 クラウド型契約管理システム及びそのプログラム
JP6864409B1 (ja) * 2020-12-16 2021-04-28 アガサ株式会社 臨床試験関連ファイル管理システム
JP7174870B1 (ja) 2022-01-27 2022-11-17 弁護士ドットコム株式会社 プログラム、情報処理装置、情報処理システム、情報処理方法
JP7237217B1 (ja) 2022-03-29 2023-03-10 株式会社マネーフォワード 情報処理システム、プログラム及び情報処理方法
JP7249453B1 (ja) 2022-04-18 2023-03-30 弁護士ドットコム株式会社 契約管理プログラム、情報処理装置、情報処理システム、情報処理方法
JP7249452B1 (ja) 2022-04-18 2023-03-30 弁護士ドットコム株式会社 契約締結プログラム、情報処理装置、情報処理システム、情報処理方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003091649A (ja) * 2001-09-19 2003-03-28 Fujitsu Ltd 電子文書送信プログラム、電子文書受信プログラム、電子文書送信方法、電子文書受信方法、電子文書送信装置および電子文書受信装置
JP2004252950A (ja) * 2003-01-29 2004-09-09 Japan Research Institute Ltd 事務管理システム、事務管理方法および事務管理プログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003091649A (ja) * 2001-09-19 2003-03-28 Fujitsu Ltd 電子文書送信プログラム、電子文書受信プログラム、電子文書送信方法、電子文書受信方法、電子文書送信装置および電子文書受信装置
JP2004252950A (ja) * 2003-01-29 2004-09-09 Japan Research Institute Ltd 事務管理システム、事務管理方法および事務管理プログラム

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105303330A (zh) * 2015-11-20 2016-02-03 周庆余 一种网络平台签章管控系统
CN105844481A (zh) * 2016-03-24 2016-08-10 胡金钱 一种对合同进行数字签名以及防伪验证的系统和方法
CN110263581A (zh) * 2019-05-08 2019-09-20 深圳法大大网络科技有限公司 合同签署方法、系统、终端设备及存储介质
CN111523861A (zh) * 2020-04-24 2020-08-11 北京思特奇信息技术股份有限公司 电子化合同的线上签章流程
EP4163848A4 (en) * 2020-06-04 2023-05-31 Fujitsu Limited CONTROL METHOD, INFORMATION PROCESSING DEVICE AND CONTROL PROGRAM

Also Published As

Publication number Publication date
JP2014127034A (ja) 2014-07-07

Similar Documents

Publication Publication Date Title
WO2014103663A1 (ja) 電子契約システム
JP6042766B2 (ja) 電子取引システム、電子取引方法、及びプログラム
CN100566248C (zh) 数字签名保证系统、方法和装置
US9736146B2 (en) Embedded extrinsic source for digital certificate validation
RU2292589C2 (ru) Аутентифицированный платеж
US6438690B1 (en) Vault controller based registration application serving web based registration authorities and end users for conducting electronic commerce in secure end-to-end distributed information system
US20090271321A1 (en) Method and system for verification of personal information
US20060179008A1 (en) Provision of authorization and other services
US20030018585A1 (en) Method and system for the communication of assured reputation information
JP2001229336A (ja) 企業間での職務ベースの認可のための方法
KR101520511B1 (ko) 개인식별번호를 이용한 사용자 인증 시스템, 사용자 단말 장치, 조회 장치, 인증 서버 및 그 사용자 인증 방법
US20220321357A1 (en) User credential control system and user credential control method
CN112199721A (zh) 认证信息处理方法、装置、设备及存储介质
EP1647932A1 (en) Method and system to automatically evaluate a participant in a trust management infrastructure
JP2001216400A (ja) 電子商取引システム
JP6027485B2 (ja) 電子取引システム、電子取引方法、及びプログラム
CN114666168A (zh) 去中心化身份凭证验证方法、装置，以及，电子设备
TWI646480B (zh) 結合區塊鏈的憑證發行與驗證之系統及其方法
JP2010079682A (ja) 電子化契約書認証システムおよび電子化契約書認証方法
KR101047951B1 (ko) 기업 자원 관리를 이용한 전자세금계산서 발행 시스템 및 방법
JP2003108708A (ja) セキュアアプリケーションフレームワーク及び該セキュアアプリケーションフレームワークを用いた電子申請システム，装置，方法並びにプログラム
KR102494521B1 (ko) 가맹점 신청 정보 처리 방법 및 디바이스
JP2001306811A (ja) 保険契約システム
Niya et al. A Blockchain-based Anonymous P2P Trading System
JP3106039U (ja) 電子商取引システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13868347

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13868347

Country of ref document: EP

Kind code of ref document: A1