JP6166805B1 - Electronic signature system, method and program for electronic contract - Google Patents

Abstract

An electronic contract system, an electronic contract method, and a program capable of controlling a necessary process after identifying a debtor and a guarantor. An electronic contract system includes a user master that stores information on a person who uses an electronic contract system as either a debtor signer or a guarantor signer, and a login user is a debtor signer. And a function for enabling the debtor to perform an electronic signature or a function for the guarantor to perform an electronic signature based on the determination result. Controls whether to enable. When the signer performs an electronic signature, the electronic contract system uses the signer's electronic certificate and key pair to perform an electronic signature, and dynamically creates a stamp indicating that the customer has performed the electronic signature as the signer. Generate and add a stamp of the electronic contract document. [Selection] Figure 16

Description

  The present invention relates generally to an electronic contract management system, method and program. More specifically, the present invention relates to an electronic contract management system, method and program for a financial institution to perform a contract procedure with a corporate customer. The present invention relates to an electronic contract discarding system, method, and program for discarding a created contract. The present invention relates to an electronic signature system, method, and program in an electronic contract that can control necessary processes after identifying a debtor and a guarantor and a confirmer of contract contents in a contract procedure.

  As a basic business of a financial institution, a loan business is known in addition to a deposit business and a currency exchange business. Loans can be divided into several types according to their content. A certificate loan is a loan made by receiving a certificate (money consumption agreement) from a customer, and is used for lending long-term funds such as corporate capital. A bill loan is a loan made by receiving a promissory note from a customer, and is used for lending short-term funds such as corporate working capital. Special overdrafts are loans that a financial institution makes overdrafts up to a certain maximum without using the current account, which is a settlement account for bills and checks. Special overdrafts are sometimes called special overdrafts.

  In the lending business, there is always a risk of credit loss because it lends funds to customers. For this reason, taking into account various factors such as the customer's credit status, use of funds, loan period, amount, etc., the financial institution's internal review procedure (also referred to as “approval”) determines whether the loan is available or not. Is done. More specifically, when a business customer representative in a financial institution receives a loan application from a customer, the customer's credit status (current performance, financial status, repayment status at the time of past loan, etc.) is checked. Judge whether or not to lend. If it is determined that the loan can be granted, an application is made to a senior executive with predetermined approval authority for execution of the loan, and approval is received. After approval, the person in charge of the corporate customer in the financial institution prepares a certificate (money consumption agreement) and hands it over to the corporate customer. The necessary documents (for example, seal registration certificate, commercial register copy, So that there are no errors in the content. If there is collateral, mortgage is set. After that, various business processes (for example, drafting, checking, bookkeeping, printing verification, etc.) are performed within the financial institution, and the loan is executed.

  As described above, in the conventional lending business, the person in charge of the financial institution often visited the customer, exchanged the certificate, received the necessary documents, etc., so that the financial institution conducted a loan transaction with the customer. An electronic loan contract system used for a part of a process for concluding a loan contract when performing has been proposed (Patent Document 1).

  Meanwhile, Internet-based services provided by financial institutions to customers are being widely used by customers. As such Internet-based services, corporate internet banking, corporate foreign exchange services, internet dealing systems, etc. are known, and portal services for these services (for example, provided by one of the applicants of this patent application) (Value Door (R)) is also known. As described above, operations related to loan contracts have a relatively large portion that relies on human resources, and therefore needs for electronic services for loan contracts are increasing.

JP 2005-222268 A

  In conventional loan operations, there were many portions that were not digitized, so the burden on corporate customers, branch offices of financial institutions, and paperwork departments was excessive. Although an electronic loan contract system such as that disclosed in Patent Document 1 has been proposed, if it is dropped into the practice of a financial institution, there are many inconvenient parts, and the practice cannot be carried out as it is.

  In addition, once a contract is created and signed by a corporate customer, the contract must be discarded and the contract must be created again as necessary to obtain the signature and seal of the corporate customer. Situations may arise, and in such cases, additional burdens have occurred between corporate customers and financial institutions.

  In addition, when a contract is verified and signed within a corporate customer, a confirmation that the debtor and guarantor (for example, joint guarantor) is involved as the contractor, and the contents of the contract are checked as necessary. (For example, accounting department, legal department) involved, it was necessary to smoothly proceed with the contract conclusion process according to each role.

  The present invention has been made in view of such a problem, and an object thereof is to provide an electronic contract system, an electronic contract method, and a program for a financial institution to perform a contract procedure with a corporate customer. It is another object of the present invention to provide an electronic contract system, an electronic contract method, and a program for discarding an already contracted electronic contract document. Furthermore, the present invention provides an electronic contract system, an electronic contract method, and a program that can control necessary processes after identifying signers such as debtors and guarantors and confirmers of contract contents in contract procedures. With the goal.

  In order to solve the above-described problem, an electronic contract system for handling an electronic contract document concluded between a financial institution and a customer according to one aspect of the present invention provides the electronic contract system as a signer of a debtor at the customer. And a user master that stores information of a person who uses the guarantor as a signer, and a login user of the electronic contract system corresponds to either the obligor signer or the guarantor signer. Screen control for controlling whether the obligor enables a function for performing an electronic signature or whether the guarantor enables a function for performing an electronic signature based on the determination result A processing means; an electronic signature means for electronically signing the electronic contract document using the signer's electronic certificate and key pair when the signer performs an electronic signature; There comprises stamping means said dynamically generates a stamp indicating that the digital signature was performed as a signer adds the stamp to the electronic contract document.

  According to another aspect of the present invention, there is provided a method executed by an electronic contract system that handles an electronic contract document concluded between a financial institution and a customer. A user master for storing information of a person who uses the signer of the contractor and the signer of the guarantor, wherein the method is such that the logged-in user of the electronic contract system is the signer of the debtor and the guarantor. A function for enabling the obligor to perform an electronic signature based on the determination result, or a function for the guarantor to perform an electronic signature. Control whether to enable and when the signer performs a digital signature function, the signer's electronic certificate and key pair are used to execute the function. Comprising a to perform a digital signature to the child contract document, that the customer is the electronic signature dynamically generates a stamp indicating that performed as the signer adds the stamp to the electronic contract document.

  The user interface provided by an electronic contract system for handling an electronic contract document concluded between a financial institution and a customer according to an aspect of the present invention is the electronic contract system, wherein the electronic contract system is used by the customer. A user master that stores information of a person who uses the signer of the debtor and the signer of the guarantor, and the user interface is configured such that the logged-in user of the electronic contract system is the signer of the debtor and the user It is determined that the guarantor corresponds to one of the signers of the guarantor, and based on the determination result, the function for enabling the debtor to perform the electronic signature is enabled or the guarantor performs the electronic signature. Means for enabling the function, and when the signer performs an electronic signature, the signer's electronic certificate and key pair Means for electronically signing the electronic contract document using, and means for dynamically generating a stamp indicating that the customer has performed the electronic signature as the signer and adding the stamp to the electronic contract document Is provided.

  According to the present invention, various contract procedures including a loan contract can be smoothly performed in accordance with the flow of business between a financial institution and a corporate customer. According to the present invention, it is possible to smoothly perform a contract between a financial institution and a business partner by discarding a prepared contract and creating a contract again as necessary. According to the present invention, it is possible to perform a contract procedure according to a role in a corporate customer such as a debtor, a guarantor, and a confirmer.

  According to the present invention, since the stamp fee required for the monetary consumption loan agreement created in the conventional loan business is not required, an effect of increasing customer satisfaction can be obtained. In the present invention, since an electronic signature (a digital signature, sometimes simply a signature) is used, an effect of preventing non-repudiation can also be obtained.

A detailed understanding of the embodiments disclosed herein can be obtained from the following description, illustrated with reference to the accompanying drawings.
It is an outline figure of the whole system containing the electronic contract system concerning the present invention. 1 is a system configuration diagram of an electronic contract system according to the present invention. It is a figure explaining the processing flow about electronic certificate and key pair (public key-private key) creation by a certificate authority server. Process flow for contract creation by financial institution corporate customer representative, customer signer (and confirmer, if necessary) contract details and electronic signature, and loan administration cooperation processing within the financial institution FIG. It is a figure which shows an example of the contract information list which displays the list of contract documents. It is a figure which shows the example of a screen of the contract information for inputting and selecting contract data. It is a figure explaining an example of the data structure of a customer master. It is a figure explaining an example of the data structure of a user master. It is a figure explaining an example of the data structure of contract DB. It is a figure which shows the example of a screen of the contract details referred by the customer. It is a figure which shows the example of a screen of the contract procedure start referred by the customer. It is a figure which shows the example of a screen of the contract procedure referred by the customer. FIG. 3 is a diagram illustrating an exemplary stamp indicating that an electronic signature has been performed. It is a figure explaining a processing flow in case a checker exists in a customer. It is a figure explaining the processing flow at the time of destroying the contract document made with an electronic signature. It is a figure explaining the functional block of the electronic contract system which concerns on this invention.

  Hereinafter, embodiments of the present invention will be described in detail. In this specification, electronic contract conclusion processing between a financial institution 1 that provides an electronic contract conclusion service and a customer 2 that uses the service, that is, creation and presentation of contract data by a person in charge of the financial institution 1, customer 2 First, the various processes leading to the approval of the contract content and the electronic signature and the loan office cooperation process in the financial institution 1 will be described. In other words, the loan contract conclusion business and the office process after the approval of the loan for the customer 2 will be described first. Therefore, the work before the preparation of the contract, that is, the work until the application for the loan from the customer 2 is made and the decision is made in the financial institution 1 to determine whether the loan is possible or not, and the approval is given. (A case number 912, which will be described later, is numbered when a proposal is drafted and is used to identify each proposal). After that, processing when a situation occurs in which a contract that has been once created and an electronic signature has been discarded will be described. In this specification, a loan contract between the financial institution 1 and the customer 2 will be described as an example. However, the present invention is not limited to the loan contract, and the financial institution 1 and the customer 2 Needless to say, it can be applied to various contract procedures.

  FIG. 1 is a schematic diagram of the entire system including an electronic contract system 100 according to the present invention. The financial institution 1 is a financial institution such as a bank, and the customer 2 is a corporation or an individual business owner. The financial institution 1 has a known system such as a billing system and an internet banking system (not shown), and further includes an electronic contract system 100 according to the present invention as shown in FIG. The electronic contract system 100 can communicate with one or a plurality of financial institution terminals 110 and can provide the financial institution terminals 110 with various applications related to the electronic contract conclusion service. The financial institution terminal 110 is used by a predetermined person in the financial institution 1 such as a person in charge of a corporate customer in a sales office and a person in charge of an examination department in a head office. The electronic contract system 100 and the financial institution terminal 110 can communicate with each other via a well-known wired / wireless network such as a dedicated line or a LAN in the financial institution 1.

  The customer 2 has one or a plurality of customer terminals 120 that are terminals that can be used by a representative of a corporation, a person who is given a predetermined authority within the corporation, and a predetermined person such as an individual business owner. . The customer terminal 120 can communicate with the electronic contract system 100 via a known network such as the Internet 130, and can use various applications related to the electronic contract conclusion service provided by the electronic contract system 100. The customer terminal 120 can be connected to a reader 121 that can read various information from an IC card, and can receive and use various information read from the IC card by the reader 121. In this specification, an IC card is described as an example, but an alternative storage medium capable of storing various types of information may be used. In this specification, the Internet 130 is described as an example of a network between the customer terminal 120 and the electronic contract system 100. However, other alternative networks may be used.

  The electronic contract system 100 can communicate with the certificate authority server 140 via the known network 150. Requests for creation of electronic certificates and key pairs (public key-private key) for corporate representatives, persons who have been given authority within the corporation, and private business owners are authenticated from the electronic contract system 100 When transmitted to the station server 140, the certificate authority server 140 can generate an electronic certificate and a key pair of the person who has received the request and transmit them to the electronic contract system 100. In this specification, an electronic certificate and a key pair (public key-private key) are used in the electronic signature process. For electronic certificates, cryptographic algorithms that are said to be relatively secure from time to time (for example, SHA-256 and RSA 2048 in some eras) are used to issue electronic certificates for signing. The Note that the key pair (public key-private key) and electronic certificate are stored in a storage medium such as an IC card that can be read by the reader 121, and a representative of the corporation of the customer 2 and a predetermined authority within the corporation. The personal identification number (PIN), which will be described later, is assigned to the representative of the legal entity of the customer 2 from the person in charge of the financial institution 1 and the authority predetermined within the legal entity. Delivery in consideration of security may be made, for example, handed over directly to the person who is granted or the individual business owner. It is assumed that an electronic certificate and a key pair (public key-private key) of a person who uses the electronic contract system 100 in the financial institution 1 are generated by the certificate authority server 140 in advance.

  FIG. 2 is a system configuration diagram of the electronic contract system 100 according to the present invention. As shown in FIG. 2, the electronic contract system 100 includes a control unit 201, a main storage unit 202, an auxiliary storage unit 203, and an interface (IF) unit 204 that are connected to each other via a bus 210 or the like, like a general computer. And an output unit 205. The electronic contract system 100 can also include a customer master 206, a user master 207, and a contract DB 208 as files / databases.

  The control unit 201 is also called a central processing unit (CPU), performs control of each component in the electronic contract system 100 and calculation of data, and stores various programs stored in the auxiliary storage unit 203 into the main storage unit 202 can be read and executed. The main storage unit 202 is also called a main memory, and can store various received data, computer-executable instructions, data after arithmetic processing by the instructions, and the like. The auxiliary storage unit 203 is a storage device typified by a hard disk (HDD) and is used when data and programs are stored for a long period of time.

  In the embodiment of FIG. 2, the embodiment in which the control unit 201, the main storage unit 202, and the auxiliary storage unit 203 are provided in the same server computer has been described. However, as another embodiment, the electronic contract system 100 includes the control unit 201. Further, by using a plurality of main storage units 202 and auxiliary storage units 203, parallel distributed processing by a plurality of server computers can be realized. As another embodiment, a plurality of servers for the electronic contract system 100 may be installed, and a plurality of servers may share one auxiliary storage unit 203.

  The IF unit 204 serves as an interface for transmitting and receiving data to and from other systems and devices, and provides an interface for receiving various commands and input data (such as various masters and tables) from the system operator. Can do. The output unit 205 can provide a display screen for displaying the processed data, a printing unit for printing the data, and the like.

  The customer master 206 is a customer master file that stores basic information of the customer 2 and is a master file that is also referred to as CIF (Customer Information File). When the customer 2 newly performs a transaction with the financial institution 1, customer information is registered in the customer master 206.

  FIG. 7 is a diagram for explaining an example of the data structure of the customer master 206. As shown in FIG. 7, the customer master 206 can include a store number 701, a business partner number 702, bank account information 703, and attribute information 704, but is not limited to these data items. Any data item can also be included. For example, the customer master 206 may be configured to include information such as a seal of a registered seal, a type of corporate credit card owned, a personal identification number, a past loan record, and the like. In the case where accounts are held in a sales store, a common number (for example, an identification number that can be used in “name identification” processing) that connects the accounts may be included. Since such a common number can be used as a number for identifying the customer 2, it can also be stored in a customer master of another financial institution. In such a case, it is possible to associate customer information held by a plurality of financial institutions based on the common number. The customer master 206 can be used by a plurality of applications as a common data item of customer account information.

  The store number 701 is a number that identifies each sales office that manages the customer 2, and the business partner number 702 is a customer identification number in the sales office. The store number 701 and the customer number 702 may be collectively referred to as a CIF number (also called a customer number). That is, in FIG. 7, the store number 701 and the customer number 702 are shown as different data items. However, the CIF number can be configured with a single data item. As another embodiment, it is also possible to use only the customer number 702 as a customer identification number that can be used in the bank. In such a case, a certain customer number 702 exists in a plurality of sales offices. It is never used and is used as a unique number within the bank.

  The bank account information 703 is information on the bank account of the customer 2 and can include information such as a store number, a subject, an account number, and an account name. The attribute information 704 can include information such as the company name, the name of the Kana, the representative director, the address, and the contact information of the customer 2.

  Returning to FIG. 2, the user master 207 is a master file that stores information on a person who uses the electronic contract system 100 as a signer or confirmer in the customer 2. Signers include debtors and guarantors (eg, joint guarantors). The confirmer is a person (for example, a general manager or a manager in charge of accounting) designated in the customer 2 to check the contents of the contract. When a new signer and confirmer of the customer 2 uses the electronic contract system 100, information is added to the user master 207, while information on an existing user of the electronic contract system 100 is changed. (For example, when the person is not a signer or a confirmer due to personnel changes, etc.), a non-use flag is set in the information of the user, or information such as a department or job title is updated. In one embodiment of the present invention, it is not necessary for all of the confirmers appointed within the customer 2 to confirm the contents of the contract, and it is only necessary for the number of confirmers specified for each contract to confirm. . For example, when four confirmers are specified in a certain corporation (that is, four confirmers are registered in the user master 207), it is acceptable to confirm two persons for a contract. Any two of the four people may confirm.

  FIG. 8 is a diagram for explaining an example of the data structure of the user master 207. The user master 207 includes a user ID 801, a password (PW) 802, a title and name 803, a signer flag 804, a confirmer flag 805, a non-use flag 806, a contract type 807, a store number 701, and a customer number 702. It can include, but is not limited to these data items, and can include any other data item. The store number 701 and the customer number 702 are the same as the data items in the customer master 206, and it is possible to identify which customer 2 the user is the user by using these data items.

  The user ID 801 is an identifier for identifying the user of the electronic contract system 100 in the customer 2, and the PW 802 is an authentication password associated with the user ID 801. The user ID 801 and PW 802 are used in the authentication process of the electronic contract system 100, but may be the same as the ID and PW of other systems (for example, corporate internet banking) possessed by the financial institution 1, or It may be different. Information such as a password of a person who uses the electronic contract system 100 in the financial institution 1 may be stored in or used in a master table used when using various applications in the financial institution 1. Person information necessary for the person master 207 may be stored, and is not particularly limited.

  The title and name 803 indicate the title of the customer 2, for example, the representative director, the general manager, the manager in charge of accounting, and the name, for example, the company name or personal name. The title and name 803 may indicate the department to which the employee belongs. The signer flag 804 indicates whether the person is designated as a signer, and if designated as a signer, further indicates whether the signer is a debtor signer or a guarantor signer. . The confirmer flag 805 indicates whether the person is designated as the confirmer. In the electronic contract system 100 according to the present invention, the contract prior confirmation function can be used. For example, if the department or person in charge who checks the contract details and the department or person in charge who concludes the contract want to complete confirmation by the confirmer first, the confirmer with a predetermined value set in the confirmation flag Confirms the contents of the contract, and then a function is available that allows the signer to approve and sign the contents of the contract. The non-use flag 806 indicates whether or not the user ID 801 is used. As described above, the non-use flag 806 is a flag used when there is a change in existing user information.

  The contract type 807 indicates the contract type of the user ID 801. For example, the “legal dual-use type” in which both the position as a corporation and the position as an individual are combined into one user ID, and only the position as a corporation is represented. “Corporate-only type”, “Individual-only type” that shows only the position as an individual, “Pre-contract confirmation type” used when the obligor / guarantor cannot digitally sign unless confirmation by the person confirming contract details is completed Etc. exist.

  The legal-use user ID 801 can perform an electronic signature as “obligor (corporation)” in the debtor column of the contract and an electronic signature as “guarantor (individual)” in the guarantor column. Thus, after logging in to the electronic contract system 100 with one user ID 801, it is possible to first make an electronic signature as a debtor and then to make an electronic signature as a guarantor without logging out. . More specifically, when a user who has a legal and dual-use contract logs in to the electronic contract system 100, both the debtor signature button 1104 and the guarantor signature button 1105 in FIG. 11 are enabled (valid). Therefore, digital signatures can be made in order from each position. In the present invention, a stamp prepared later is not added to an electronic document, but both a stamp as a debtor and a stamp as a guarantor are generated and added to the electronic document. Is possible.

  The corporate-limited type user ID 801 performs an electronic signature as “obligor (corporation)” in the debtor column of the contract, and cannot perform an electronic signature as a guarantor. The personal ID type user ID can be used, for example, in the case where the relative of the representative director becomes an individual guarantor, and an electronic signature is given as “guarantor (individual)” in the guarantor column of the contract. It can be carried out. When logging in with these types of user IDs 801, the corresponding buttons of the debtor signature button 1104 and the guarantor signature button 1105 in FIG. 11 are enabled (valid), so that an electronic signature can be performed from that position. .

  The user ID 801 of the prior contract confirmation type cannot confirm an electronic signature because it is a confirmer, but the obligor / guarantor cannot sign an electronic signature unless the confirmation by the contract content confirmation authority having the ID 801 is completed. Used when desired. The user ID 801 of the prior contract confirmation type is desirably possessed by a person having a predetermined authority such as an accounting department manager in the customer 2.

  Returning to FIG. 2, the contract DB 208 is a database that stores data included in the contract and a contract as an electronic document. In another embodiment of the present invention, the electronic document may be stored in another location in the electronic contract system 100, and the contract document DB 208 may store information indicating the storage location of the electronic document.

  FIG. 9 is a view for explaining an example of the data structure of the contract document DB 208. The contract DB 208 includes an electronic contract management number 901, a store number / customer number 902, a customer name 903, a debtor / guarantor 904, a contract condition 905, a signer 906, a confirmer 907, an electronic document 908, a discard flag 909, The revocation signer 910, the status 911, and the case number 912 can be included, but the present invention is not limited to these data items, and any other data items can be included.

  The electronic contract management number 901 is an identifier for identifying a contract (for example, a money consumption agreement), and is a number assigned by the electronic contract system 100 when the electronic contract is created. The store number / customer number 902 is also called a CIF number, and is an identifier for identifying a customer. The customer name 903 indicates the customer name of the customer. The debtor / guarantor 904 indicates one or more debtors and one or more guarantors in the contract. Depending on the type of contract, the guarantor may be a joint guarantor, or there may be no guarantor. The contract condition 905 indicates the loan conditions such as the amount of borrowing, use of funds, final repayment date, borrowing interest rate, repayment method and interest payment method. In addition to the items indicated in this specification, the contract type and content Other items that may be included accordingly may also be indicated. The signer 906 can include one or more obligors and guarantors who conclude the contract and who sign the contract. The obligor and the guarantor set in the signer 906 can be designated from those registered in the user master 207. When an electronic signature is performed on the electronic document 908, a signed identifier is added to the corresponding debtor / guarantor of the signer 906. In the embodiment of the present invention, the signer 906 may be configured to indicate that the financial institution 1 has performed an electronic signature. In such a case, the signer 906 can be configured to include one or more debtors and guarantors of the customer 2 and those who have signed the electronic signature of the financial institution 1.

  The confirmer 907 can include the number of persons who confirm the contents of the contract before the signer approves / signs the contents of the contract. If the number of persons is set, one or more who confirmed the contract Can also be shown. When the number of persons is stored in the confirmer 907, it is indicated that the contract is a contract that needs to be confirmed by the confirmer. When the confirmer 907 indicates one or more confirmers, a person registered as a confirmer in the user master 207 in the customer 2 (for example, a predetermined value is set in the confirmer flag 805). It is shown that the person has confirmed the contract. For example, in a case where the department / person in charge of checking the contents of the contract is different from the department / person in charge of entering into the contract, the confirmer 907 receives the signature of the signer unless the confirmation work of the contract contents by the confirmer is completed. It is a data item used when it is not possible to perform (contract advance confirmation function). The confirmer 907 has a null value when the number of confirmers of the contract is not designated by the financial institution 1. When the electronic document 908 is confirmed, a confirmed identifier indicating that the confirmation work is completed is added to the corresponding confirmer of the confirmer 907.

  An electronic document 908 indicates an electronic document (for example, PDF file) of a contract generated by the electronic contract system 100. In another embodiment of the present invention, information on the storage location of the electronic document is stored in the electronic document 908, and the actual electronic document exists in any location in the storage medium in the electronic contract system 100. It may be.

  The discard flag 909 is a flag for setting a predetermined value when the contents of the contract are changed and the contract itself is to be discarded. The discard signer 910 indicates a person who performs an electronic signature for discarding the contract. Since both the financial institution 1 and the customer 2 can perform the electronic signature of the discard, the discard signer 910 may be configured to have the data of the discarded person regarding both the financial institution 1 and the customer 2. The status 911 indicates the current state of the contract data, for example, “drafting” indicating that the person in charge is creating, indicating that the person in charge has been created and is waiting for approval by the superior “Waiting for presentation”, “Waiting for signature” indicating that the customer's signature has not been completed, “Waiting for administrative management cooperation” indicating that the customer has been signed and passed to the execution process, and loan to customer 2 There is a status such as “Loan executed” indicating that the transaction has been executed. The case number 912 is a number that is assigned at the time of drafting a proposal and is used to identify each proposal. By using electronic contract management number 901 and project number 912, it becomes possible to grasp which approval is based on the contract for the loan, and conversely, it is also possible to find out the approval from which a certain contract is based. Become.

  Next, a process in which the financial institution 1 receives a request from the customer 2 and adds a new user to the user master 207 will be described with reference to FIG.

  FIG. 3 is a diagram for explaining a processing flow for creating an electronic certificate and a key pair (public key-private key) by a certification authority (CA) server 140.

  In S301, the electronic contract system 100 receives the user ID creation application from the customer 2, generates a user ID 801, stores the user ID 801, PW 802, job title and name 803 in the user master 207, and signer. The flag 804 or the confirmer flag 805, the contract type 807, the store number 701, and the customer number 702 are also stored. The user ID creation application may be made by hand to the corporate customer in charge of the financial institution 1 together with the identity verification material of the customer 2 signer or the confirmer, or from the customer terminal 120 to the electronic contract system 100. May be applied according to a predetermined flow, and the person in charge of the financial institution 1 may confirm the application for creation.

  In S302, electronic contract system 100 transmits to certificate authority server 140 a request to create the electronic certificate and key pair (public key-private key) of the user who has received the application for creating the user ID. The electronic certificate (certificate) describes personal information such as name and affiliation, and the public key of the person, and is digitally signed by the certificate authority server 140. That is, the electronic certificate indicates that the public key belongs to the signer. The key pair (public key-private key) is a pair of a public key and a secret key used for an electronic contract executed by the electronic contract system 100 according to the present invention.

  The mechanism of electronic signature will be described. The electronic signature is a technique for realizing functions corresponding to the seal and signature of a seal in the computer world. The electronic contract system 100 according to the present invention can first create a hash value based on the electronic document 908 using any kind of hash function. The electronic contract system 100 can generate the encrypted data by further encrypting the hash value using the signer's private key. Thereafter, the electronic contract system 100 performs an electronic signature by setting the electronic certificate and public key of the signer in the electronic document 908. A public key is a key that can be used to verify that a user with a corresponding private key has signed, and if the digitally signed data can be decrypted with the public key, the public key pair A user with a certain secret key has signed. The signer's electronic certificate and key pair (public key-private key) are stored in an IC card or the like, read by the reader 121, and used in the electronic contract system 100.

  In S303, the electronic contract system 100 can receive the electronic certificate and key pair (public key-private key) of the user generated by the certificate authority server 140 and store them in the electronic contract system 100. . The received electronic certificate and key pair (public key-private key) can be stored in a storage medium such as an IC card and sent from the financial institution 1 to the signer of the customer 2. Further, the personal identification number (PIN) when using the secret key may be handed over directly from the corporate customer representative of the financial institution 1 to the signer of the customer 2. Note that the personal identification number (PIN) is necessary for electronic signatures and can be changed by the signer of the customer 2.

  FIG. 4 shows the creation of a contract by the person in charge of the corporate customer of the financial institution 1, the confirmation of the contract contents and the electronic signature by the signer of the customer 2 (and the confirmer if necessary), and the inside of the financial institution 1. It is a figure explaining the processing flow about loan office work cooperation processing. In the electronic contract system 100 according to the present invention, the contract is created only by the person in charge of the corporate customer of the financial institution 1 and is not created by any other person (for example, the customer 2).

  In step S <b> 401, the person in charge of the corporate customer of the financial institution 1 accesses the electronic contract system 100 via the financial institution terminal 110. In response to the access, the electronic contract system 100 can provide the financial institution terminal 110 with a contract information list 500 as illustrated in FIG.

  The contract information list 500 illustrated in FIG. 5 can display a list of contract documents. Contracts can include those before the contract is concluded and those after the contract is concluded, and the list of contracts displayed according to the search conditions can vary. In the contract information list 500, contract information displayed by the department / store to which the person in charge of the corporate customer of the financial institution 1 belongs can be controlled.

  In S 401, the person in charge of the corporate customer of the financial institution 1 presses the creation button shown in FIG. 5 via the financial institution terminal 110. When the creation button is pressed, the electronic contract system 100 can provide the financial institution terminal 110 with a screen of contract information 600 as illustrated in FIG. The contract information 600 includes a case number assigned at the time of the deliberation, an electronic contract management number which is an identification number of the contract, a sales office in charge, account information of the customer 2, basic information 601 such as a customer name, a debtor, The guarantor information 602, the contract condition 603, the signer selection field 604, and the confirmer number designation field 605 can be provided. The data items included in the contract information 600 can be set based on information stored in the customer master 206, the user master 207, and the contract DB 208, and may vary depending on the type and content of the contract. Therefore, the number of signers and confirmers can be arbitrarily set within the range of the user of the customer stored in the user master 207. For example, in the signer selection field 604, a person who digitally signs as a debtor or guarantor can be selected from those registered in the user master 207. For this reason, the financial institution 1 can designate a person who wants to be a debtor or guarantor among the customers 2 in the signer selection field 604. In the number-of-checkers designation field 605, the number of confirmers can be designated on the financial institution 1 side. Even if there are more persons registered as confirmers of the customer 2 in the user master 207 than the number specified, only the number of confirmers need to confirm the contents of the contract. For example, if there are four confirmers in the customer 2 and two are designated in the confirmer number designation field 605, any two of the four may be confirmed. Furthermore, in one embodiment of the present invention, it is also possible to attach explanatory material for the signer (for example, a file named “Description of specific guarantee (for individuals)” shown in FIGS. 10 and 11). . The confirmer can be used when it is desired to set a person who confirms the contents of the contract before the signer signs. When each data item of the contract information 600 is input or selected and the registration / creation button is pressed, the electronic contract system 100 creates an electronic document 908 based on the input or selected contract data, and the contract DB 208. Each data is registered in.

  In S402, the supervisor in charge of the corporate customer of financial institution 1 selects arbitrary contract data on the screen of contract information list 500 and presses the display button, and contract data and electronic data are displayed on the screen of contract information 600. When the content of a document (for example, a PDF file of a contract) is confirmed and an approval button (not shown) is pressed, the status 911 is changed to “waiting for signature”, and the contract data and the electronic document are disclosed to the customer 2 It will be. More specifically, a supervisor accesses the electronic contract system 100 using the financial institution terminal 110, and the electronic contract system 100 provides the contract information list 500 to the financial institution terminal 110. The status column of the contract information list 500 can indicate the current state of the contract data. For example, as described above, “Drafting”, “Waiting for presentation”, “Waiting for signature”, “Waiting for administrative management” And status such as “Loan executed”. The superior uses the financial institution terminal 110 to select the contract data that is displayed in the contract information list 500 and has the status “waiting for presentation”, presses the display button, and refers to the contract information 600. After confirming the contents of the contract, an approval button (not shown) can be pressed. When the approval button is pressed, the status of the data of the contract is changed to “waiting for signature”, and the signer or confirmer of the customer 2 uses the customer terminal 120 to access the electronic contract system 100. The contract data and electronic documents can be referred to. That is, this “waiting for signature” status indicates that the customer 2 is waiting for a signature by a signer (eg, debtor, guarantor, etc.).

  An example of the referenced electronic document will be described with reference to FIG. FIG. 13 shows four types of stamps indicating that an electronic document has been digitally signed, that is, a stamp 1301 in the case of an electronic signature by a financial institution 1 at the time of a new contract, and a customer 2 at the time of a new contract. A stamp 1302 in the case of an electronic signature by the customer, a stamp 1303 in the case of an electronic signature by the financial institution 1 when the existing contract is discarded, and a stamp 1304 in the case of an electronic signature by the customer 2 when the existing contract is discarded ing.

  In this specification, the stamp is defined as information for identifying the signer and the type of the electronic contract document. The signer indicates a person who performs an electronic signature, such as a debtor or a guarantor. The type of the electronic contract document indicates the status of the electronic contract procedure (for example, new or discarded). In this specification, four types of stamps are illustrated, but this is only an example. The stamp indicating that the electronic signature has been performed has a different mark depending on the obligor and the guarantor, and may vary depending on the number of persons designated as the obligor and guarantor of the contract. The stamp 1301 is a stamp that clearly indicates that the electronic signature has been applied to the electronic document when the approval button is pressed in S402 and the status of the data of the contract is changed to “waiting for signature”. The stamp 1301 can include an electronic contract management number 901 (“# 000000004975” in the example of FIG. 13). Details of the electronic signature are as described above with reference to FIG. By having the stamp 1301, a person other than the financial institution 1 (for example, the customer 2) can explicitly identify that the contract is created by the financial institution 1.

  Here, the stamp generation processing will be described. The stamp in the present invention is not a stamp (imprint) prepared in advance in the electronic contract system 100, but the attribute of the login user of the electronic contract system 100 and the status of the contract procedure of the electronic contract (for example, new, discarded, etc.). Dynamically generated based on For this reason, as described above, the stamp in the present invention is dynamically generated by the electronic contract system 100 so as to be different depending on a person designated as a debtor within the customer 2 and a person designated as a guarantor. Even if the position of the debtor is the same, it can be dynamically generated by the electronic contract system 100 so that the stamp marks differ between the position as a corporation and the position as an individual.

  More specifically, when the login user belongs to the financial institution 1, the electronic contract system 100 includes the electronic contract management number of the contract stored in the electronic contract management number 901. A stamp 1301 can be generated. For example, an electronic contract management number “# 000000004975” is displayed on the stamp 1301, which indicates that the stamp 1301 is dynamically generated by the electronic contract system 100. The stamp shape (for example, a round shape, a rounded square shape, an oval shape, etc.) itself may be selected from those prepared in advance as a format for the financial institution 1. Arbitrary ones may be selected depending on the type of contract such as a contract, special overdraft, and bill loan.

  In addition, when the login user belongs to the customer 2, the electronic contract system 100 reads the title and name 803 and the signer flag 804 stored in the user master 207, and reads the title and name 803 read out. Based on the signer flag 804, the stamp of the customer 2 for the contract can be generated. The title and name 803 are data items indicating the title of the customer 2, for example, the representative director, the department manager, the accounting manager, and the name, for example, the company name or the individual name. The signer flag 804 indicates whether the person is designated as a signer, and if designated as a signer, further indicates whether the signer is a debtor signer or a guarantor signer. Flag. The electronic contract system 100 can dynamically generate a stamp for the customer 2 such as the stamp 1302 based on the title and name 803 and the signer flag 804. As the stamp shape (for example, round shape, rounded square shape, oval shape, etc.) itself, an arbitrary shape may be selected from those prepared in advance as a format for the customer 2.

  The stamp 1302 is a stamp that clearly indicates that the electronic signature has been applied to the electronic document after the obligor / guarantor confirms the contract contents in the customer 2. The stamp 1302 can include information (named “Wakakusa Taro” in the example of FIG. 13) for identifying the person who performed the electronic signature. By having the stamp 1302, a person other than the customer 2 (for example, the financial institution 1) can explicitly identify that the contract is signed by the customer 2. The stamp 1303 is a stamp indicating that an electronic signature for destruction is first applied to the electronic document on the financial institution 1 side when an existing contract has to be destroyed. The stamp 1303 may be generated so as to include a case number such as a request to be discarded, or may be generated so as to include other information. By having the stamp 1303, a person other than the financial institution 1 (for example, the customer 2) can explicitly identify that the contract has been destroyed by the financial institution 1. A stamp 1304 is a stamp indicating that the electronic signature for discarding has been performed by the customer 2 on the electronic document discarded by the financial institution 1. The stamp 1304 can include information (named “Wakakusa Taro” in the example of FIG. 13) for identifying a person who has made a digital signature for destruction. The presence of the stamp 1304 allows a person other than the customer 2 (for example, the financial institution 1) to explicitly identify that the contract has been destroyed by the customer 2.

  Returning to FIG. 4, the description continues. In S <b> 403, the signer of the customer 2 accesses the electronic contract system 100 using the customer terminal 120. In response to the access, the electronic contract system 100 can display a list of contract data that the customer 2 must sign. The displayed contract data is data whose status is “waiting for signature”. When any one of the displayed contract data is selected, the electronic contract system 100 can provide the contract details 1000 as illustrated in FIG. 10 to the customer terminal 120.

  FIG. 10 is a diagram showing the contract details 1000 including the outline of the contract, the electronic document of the contract, and the communication items from the financial institution 1 to the customer 2. The contract details 1000 can include a debtor column 1001, a guarantor column 1002, and a confirmer column 1003. The outline of the contract includes the main contractor (the main obligor of the obligor of the obligor / guarantor 904 is set), the contract amount (the contract amount of the contract condition 905 is set), the contract Date (contract date in the contract condition 905 is set), electronic contract management number 901, contract PDF (electronic document of the electronic document 908), communication item / notification item (communication item / notification in the contract condition 905) Item is set). As described with reference to FIG. 13, the electronic document 908 displays a stamp 1301 for explicitly indicating that the contract is created by the financial institution 1.

  The obligor column 1001 can display one or more obligors selected in the signer selection 604 of FIG. In the example of FIG. 10, three persons (Wakasa Trading Co., Ltd., Taro Wakakusa, Jiro Wakasa) are designated as debtors. The obligor column 1001 is displayed so that the person who has already signed and the person who has not yet signed can be identified based on whether or not a signed identifier is added to the corresponding obligor of the signer 906. (For example, changing the color or font, dividing the display area, etc.). The debtor column 1001 can also display whether the electronic signature has been completed as a whole or has not yet been completed.

  The guarantor column 1002 can display one or more guarantors selected in the signer selection 604 of FIG. The guarantor may be a joint guarantor depending on the type of contract. In the example of FIG. 10, two persons (Taro Wakakusa and Jiro Wakasa) are designated as joint guarantors. The guarantor column 1002 is displayed so that a person who has already signed and a person who has not yet signed can be identified based on whether or not a signed identifier is added to the corresponding guarantor of the signer 906. (For example, changing the color or font, dividing the display area, etc.). The guarantor column 1002 can also display whether the electronic signature has been completed as a whole or has not yet been completed.

  The confirmer field 1003 can be displayed when the number of one or more confirmers is designated in the confirmer number designation field 605 of FIG. For example, when “2” is designated in the confirmer number designation field 605, the confirmer field 1003 displays a person who is registered in the user master 207 as a confirmer among the corporations as a “confirmable person”. And the person who has actually confirmed can be displayed in the column of the confirmer. Alternatively, only those who have actually confirmed may be displayed in the checker column 1003. The electronic contract system 100 according to the present invention is configured such that a debtor or a guarantor can perform an electronic signature as a signer only when a confirmer confirms the contents of a contract and presses a confirmation button. Can. As described above, since the information of the person who actually confirmed is stored in the confirmer 907, the electronic contract system 100 identifies the person who confirmed and the person who did not confirm based on the information. It can be displayed as possible (for example, changing the color or font, dividing the display area, etc.). Those who have not confirmed can be obtained from the information stored in the user master 207.

  After confirming the contract details, the signer of the customer 2 can press the contract procedure button 1004 shown in FIG. 10 using the customer terminal 120. A return button 1005 is a button used when returning to the screen displaying the list of contract data described in S403. When the contract procedure button 1004 is pressed, the electronic contract system 100 can provide the customer terminal 120 with a screen of the contract procedure start 1100 as shown in FIG.

  The contract procedure start 1100 includes an obligor column 1101, a guarantor column 1102, a confirmer column 1103, an obligor signature button 1104, a guarantor signature button 1105, a confirmation button 1106, and a return button 1107. As described with reference to FIG. 10, the contract procedure start 1100 can include a summary item of the contract, an electronic document of the contract, and a communication item from the financial institution 1 to the customer 2.

  The debtor column 1101 can indicate whether the debtor has been signed. The guarantor column 1102 can indicate whether the guarantor (including joint guarantor) has been signed. The confirmer column 1103 can indicate whether the contractor has confirmed the contract. The obligor signature button 1104 is enabled when the login user is designated as the obligor's signer in the user master 207. When the obligor signature button 1104 is pressed, the contract shown in FIG. The screen of the procedure 1200 is displayed. The guarantor signature button 1105 is enabled when the logged-in user is designated as the guarantor signer in the user master 207. When the guarantor signature button 1105 is pressed, the contract shown in FIG. The screen of the procedure 1200 is displayed. The confirmation button 1106 is a button that is enabled (or displayed) when the logged-in user is a person designated as a confirmer in the user master 207, and is pressed when the confirmer approves the contract contents. The That is, the confirmer refers to the contract (PDF) as an electronic document in the contract procedure start 1100 and presses the confirm button 1106 when determining that there is no problem with the contents. The return button 1107 is a button used when returning to the screen displaying the list of contract data described in S403.

  FIG. 12 is an example of a screen for the contract procedure 1200. The contract procedure 1200 can include a check box 1201, a signature button 1202, and a return button 1203. The check box 1201 is used by the obligor and the guarantor to indicate whether or not the obligor and the guarantor understand and confirm the contents of the contract when signing. The signature button 1202 is used by the debtor and the guarantor to perform an electronic signature on the electronic document. The signature button 1202 can change the display content depending on whether the logged-in user is designated as a debtor in the user master 207 or as a guarantor. A return button 1203 is used to return to the contract procedure start 1100 screen.

  As described with reference to FIG. 10, the contract procedure 1200 can include contract outline items, contract electronic documents, and communication items from the financial institution 1 to the customer 2. Since FIG. 12 shows a case where the obligor signature button 1104 is pressed, the signature button 1202 indicates “sign as obligor (corporate)”, but the guarantor signature button 1105 is pressed. In this case, as described above, the signature button 1202 is written as “sign as guarantor”. That is, in the electronic contract system 100 according to the present invention, screen control is performed according to the information of the logged-in user stored in the user master 207.

  After the signer confirms the contents of the contract, when the check box 1201 is checked and the signature button 1202 is pressed, the electronic signature processing is performed by the “electronic signature mechanism” described with reference to FIG. Done. When performing an electronic signature, it is necessary to input a personal identification number (PIN). When the electronic signature is applied to the electronic document, as described above with reference to FIG. 13, the electronic contract system 100 generates a stamp 1302 indicating that the electronic signature has been applied to the electronic document by the debtor. It will be displayed above. When there are a plurality of debtors, the displayed stamp 1302 corresponds to each debtor. For example, the debtor Taro Wakakusa has a stamp 1302 generated for Taro Wakakusa. Jiro Wakasa has a stamp 1302 generated for Jiro Wakasa (for example, a stamp including the name of the debtor). When the electronic signature is made by all of the designated debtor and guarantor for the electronic document (in this case, all debtor and guarantor stamps 1302 are displayed on the electronic document) by customer 2 The confirmation and signing of the contract is completed, and the status 911 is changed to “Waiting for administrative management cooperation”.

  Returning to FIG. 4 again, in S404, the person in charge of the corporate customer of the financial institution 1 confirms the content of the contract data in the “waiting for administrative management cooperation” status, and executes the loan execution practice (for example, drafting, checking, and bookkeeping). If it is determined that the data can be transferred to the business processing department responsible for printing verification, etc., the corresponding contract data is selected from the contract information list 500 shown in FIG. 5, and the execution request button is pressed. When the execution request button is pressed, the electronic contract system 100 updates the status 911 from “Waiting for office management cooperation” to “Office management cooperation completed” so that the person in charge of the paper processing department can handle the contract data. can do. Further, after the loan is executed, the status 911 is updated to “loan executed”. As described above, the status 911 can indicate the respective stages from the time when the contract is created to the time after the loan is executed. By referring to the status 911, for example, when a loan is executed based on a signed electronic contract, and the loan is paid off, transferred, or canceled, the account (interim management) is performed using the electronic contract management number as a key. It is possible to link information on payment and transfer from the system that manages the customer, and the customer can check the status from the screen of the electronic contract.

  Next, a processing flow in the case where a confirmer exists in the customer 2 will be described with reference to FIG. In S1401, the electronic contract system 100 provides the customer terminal 120 with a screen for starting a contract procedure 1100. The electronic contract system 100 makes an inquiry to the contract DB 208 using the electronic contract management number 901 as a key, and determines whether or not the information on the number of confirmers is stored in the confirmer 907. If the information on the number of confirmers is stored, the process proceeds to S1402. On the other hand, if the information on the number of confirmers is not stored, the process proceeds to S1404.

  In S1402, the electronic contract system 100 determines whether or not the information of the person who confirmed with the confirmer 907 is stored for the number of persons described above. If the information of the person who confirmed the information is stored for the number of persons described above, the process proceeds to S1404. If not, the process proceeds to S1403.

  In S1403, the electronic contract system 100 displays the confirmation button 1106 and enables it (valid), while disabling the obligor signature button 1104 and the guarantor signature button 1105. The debtor signature button 1104 and the guarantor signature button 1105 may be displayed on the screen of the contract procedure start 1100 even if they are disabled. When the confirmation by the confirmer is completed, the confirm button 1106 is pressed, and the information of the person who confirms is added to the confirmer 907 (for example, the name of the confirmer “Wakakusa Accounting” is added).

  In step S <b> 1404, the electronic contract system 100 enables the obligor signature button 1104 and the guarantor signature button 1105 in response to the determination that the confirmer 907 stores the information of the confirmers for the designated number of persons. To. In such a case, the confirmer button 1106 may be hidden or disabled in order to prevent unnecessary confirmation work by an additional confirmer. In S1405, as described above, the electronic signature is performed on the electronic document by the debtor and the guarantor.

  Next, with reference to FIG. 15, a processing flow for discarding a contract with an electronic signature will be described. For example, when a contract is destroyed, it suddenly occurs after the conclusion of the contract, when the representative director changes, when there is a sudden change in the economic situation after the conclusion of the contract, etc. It was what was done.

  In step S <b> 1501, after a request for discarding the electronic contract is made, the person in charge of the corporate customer in the financial institution 1 accesses the electronic contract system 100 via the financial institution terminal 110. The electronic contract system 100 can provide the financial institution terminal 110 with a list of one or more contracts concluded with the customer 2 (that is, the contract information list 500 shown in FIG. 5). The person in charge of the corporate customer in the financial institution 1 selects the contract data to be discarded from the contract information list 500 and presses the contract cancel button. When the contract cancel button is pressed, the electronic contract system 100 sets a value indicating discard in the discard flag 909 and sets the financial institution 1 in the discard signer 910. Thereafter, the electronic contract system 100 can perform a digital signature for discarding the electronic document 908. The fact that the electronic signature for discard by the financial institution 1 has been performed is indicated by a stamp 1303 in FIG. In one embodiment of the present invention, it has been described that a value is set in the discard flag 909 and a digital signature for discarding is added to the electronic document 908 to add a stamp 1303. However, as another embodiment, a financial institution In 1, it is possible to set a value to the discard flag 909 and not perform an electronic signature (that is, do not add a stamp).

  In S1502, the electronic contract system 100 can change the status 911 to “wait for discard”. Since contract data with the status “Waiting for Discard” is presented to the customer 2, the debtor of the customer 2 accesses the electronic contract system 100 via the customer terminal 120 and confirms a list of contract data to be discarded. To do.

  In S1503, the debtor of customer 2 can select the contract data to be discarded from the list of contract data to be discarded via the customer terminal 120, and press the discard signature button. In response to pressing of the discard signature button, the electronic contract system 100 sets the obligor of the customer 2 as the discard signer 910 and attaches a stamp 1304 as illustrated in FIG. 13 on the electronic document 908. Can do. In addition, when there are a plurality of debtors and each debtor performs a revocation signature, a stamp 1304 corresponding to each debtor is displayed. For example, a stamp 1304 indicates the debtor “Wakakusa Taro” who has made a digital signature for destruction.

  FIG. 16 is a diagram illustrating functional blocks of the electronic contract system 100 according to the present invention. The electronic contract system 100 includes a certificate authority communication unit 1601, a contract data processing unit 1602, an electronic signature unit 1603, a confirmation processing unit 1604, a screen control processing unit 1605, a stamp processing unit 1606, an execution processing request unit 1607, a discard processing unit 1608, A customer master 206, a user master 207, and a contract DB 208 are provided.

  The certificate authority communication unit 1601 receives a user ID creation application from the customer 2 and generates a user ID 801, stores the user ID 801, PW 802, title and name 803 in the user master 207, and signer flag 804 or A confirmer flag 805, a contract type 807, a store number 701, and a supplier number 702 can also be stored. The certificate authority communication unit 1601 can transmit to the certificate authority server 140 a request to create the electronic certificate and key pair (public key-private key) of the user who has received the user ID creation application. In the electronic certificate, personal information such as name and affiliation and the public key of the person are described, and an electronic signature is performed by the certificate authority server 140. The key pair (public key-private key) is a pair of a public key and a secret key used for an electronic contract executed by the electronic contract system 100 according to the present invention. The certificate authority communication unit 1601 can receive the electronic certificate and key pair (public key-private key) of the user generated by the certificate authority server 140 and store them in the electronic contract system 100.

  The contract data processing unit 1602 can store the contract data input from the financial institution terminal 110 (for example, data input on the screen of the contract information 600) in the contract DB 208, and an electronic document based on the contract data. 908 can be generated and stored in the contract DB 208, and by updating the status 911, the contract data disclosure range (for example, only the department of the person in charge of the corporate customer of the financial institution 1 (also referred to as the front department), Both the customer 2 and the financial institution 1, both the front department and the paperwork department of the financial institution 1, etc.) can be controlled. By performing such control, the financial institution 1 side can present the contract data and the electronic document 908 to the customer 2 when the contract data and the electronic document 908 are generated.

  The electronic signature unit 1603 generates a hash value based on an electronic document 908 to be digitally signed using an arbitrary type of hash function, and further encrypts and encrypts the hash value using the signer's private key. Data can be generated. The electronic signature unit 1603 can perform an electronic signature by setting the electronic certificate and public key of the signer in the electronic document 908. A public key is a key that can be used to verify that a user with a corresponding private key has signed, and if the digitally signed data can be decrypted with the public key, the public key pair A user with a certain secret key has signed.

  The electronic signature unit 1603 can read the discard flag 909 in the contract DB 208 and can perform a discard electronic signature on the electronic document 908 associated with the contract data for which the discard flag 909 indicates a predetermined value. The electronic signature for discarding can also be executed in the same manner as described above.

  The confirmation processing unit 1604 can control screen display when a confirmer exists for the contract in the screen used by the customer 2, for example, the contract details 1000 and the contract procedure start 1100. The confirmation processing unit 1604 makes an inquiry to the contract DB 208 using the electronic contract management number 901 of the contract as a key, determines whether or not the number of confirmers is stored in the confirmer 907, and further confirms It can be determined whether or not the information of the person who confirmed in 907 is stored. Accordingly, the confirmation processing unit 1604 displays the obligor signature button 1104 and the guarantor signature button 1105 illustrated in FIG. 11 when the information on the number of confirmers is stored in the confirmer 907 of the contract data. Can be disabled. This disabling function is to allow a debtor or a guarantor to perform an electronic signature as a signer only when a designated number of confirmers confirm the contents of the contract. The confirmation processing unit 1604 may enable the obligor signature button 1104 and the guarantor signature button 1105 in response to the determination that the confirmers 907 store information of the confirmers for the designated number of persons. it can. The confirmation processing unit 1604 can identify whether or not one or a plurality of confirmers confirmed based on whether or not the information of the person who confirmed with the confirmer 907 is stored in the confirmer column 1003. It can be displayed (for example, changing the color or font, dividing the display area, etc.). Further, the confirmer column 1003 illustrated in FIG. 10 and the confirmer column 1103 and the confirmation button 1106 illustrated in FIG. 11 are based on whether or not a confirmer is set in the confirmer 907 of the contract data. Whether it is displayed can be controlled. Further, the confirmation processing unit 1604 can store information on the person who confirmed the confirmation person 907 in response to receiving the signal indicating that the confirmation by the confirmation person has been completed from the customer terminal 120.

  The screen control processing unit 1605 reads the selected contract data from the contract DB 208 and controls the screen display of the contract details 1000 shown in FIG. 10, the contract procedure start 1100 and the contract procedure 1200 shown in FIG. Can do. The screen control processing unit 1605 can determine an attribute (for example, a debtor, a guarantor, and a confirmer) of the login user, and control display items on the screen based on the determined attribute information. For example, when the logged-in user is the debtor of the customer 2, the signature button 1204 is enabled, and the signature button 1202 is labeled “signed as debtor (corporate)”. As described above, the screen control processing unit 1605 can control the screen. For example, if the logged-in user is the guarantor of customer 2, the guarantor signature button 1105 is enabled, and the signature button 1202 is labeled "sign as guarantor" It can be controlled by the screen control processing unit 1605.

  The screen control processing unit 1605 can control the display of the obligor column 1001 and the guarantor column 1002 based on the obligor / guarantor information designated by the signer 906. For example, if a plurality of obligors are designated as the signer 906, the screen control processing unit 1605 displays the designated obligors in the obligor column 1001, and furthermore, the obligor corresponding to the signer 906. Based on whether or not a signed identifier is added to the, it is possible to display the debtor who has already signed and the debtor who has not signed yet so that they can be identified (for example, changing the color and font) , Separate display areas, etc.). The screen control processing unit 1605 completes the electronic signature in the obligor column 1001 and the guarantor column 1002 as a whole based on whether or not a signed identifier has been added to all the corresponding obligors of the signer 906. It is also possible to display whether or not it is not yet completed.

  The stamp processing unit 1606 generates electronic signature stamps 1301 and 1303 by the financial institution 1 and electronic signature stamps 1302 and 1304 by the customer 2, and updates the contract DB 208 by attaching the generated stamps to the electronic document 908. be able to. More specifically, if the login user belongs to the financial institution 1, the stamp processing unit 1606 includes the electronic contract management number of the contract stored in the electronic contract management number 901. A stamp 1301 can be generated. For example, an electronic contract management number “# 000000004975” is displayed on the stamp 1301 in FIG. 13, which indicates that the stamp 1301 is dynamically generated by the electronic contract system 100. . The stamp shape (for example, a round shape, a rounded square shape, an oval shape, etc.) itself may be selected from those prepared in advance as a format for the financial institution 1. Arbitrary ones may be selected depending on the type of contract such as a contract, special overdraft, and bill loan.

  In addition, when the login user belongs to the customer 2, the stamp processing unit 1606 reads the title and name 803 and the signer flag 804 stored in the user master 207, and reads the title and name 803 read out. Based on the signer flag 804, the stamp of the customer 2 for the contract can be generated. The title and name 803 are data items indicating the title of the customer 2, for example, the representative director, the department manager, the accounting manager, and the name, for example, the company name or the individual name. The signer flag 804 indicates whether the person is designated as a signer, and if designated as a signer, further indicates whether the signer is a debtor signer or a guarantor signer. Flag. The stamp processing unit 1606 can dynamically generate a stamp for the customer 2 such as the stamp 1302 based on the job title and name 803 and the signer flag 804. As the stamp shape (for example, round shape, rounded square shape, oval shape, etc.) itself, an arbitrary shape may be selected from those prepared in advance as a format for the customer 2. Thus, the stamp processing unit 1606 makes an inquiry to the user master 207 to determine whether the logged-in user is a signer, a signer, a debtor, or a guarantor. Then, stamps 1302 and 1304 for customer 2 can be generated. The generated stamps 1301 to 1304 can be attached to the electronic document 908 by the stamp processing unit 1606 and stored in the contract document DB 208.

  The stamp processing unit 1606 reads the discard flag 909 and the discard signer 910 from the contract DB 208, and the electronic document 908 associated with the contract data in which the discard flag 909 indicates a predetermined value (for example, a value “1” indicating discard). Can be extracted. The stamp processing unit 1606 can generate stamps 1303 and 1304 indicating that a digital signature for discarding has been performed on the extracted electronic document 908 and add it to the electronic document 908. The stamp 1303 is added when the discard signer 910 indicates that it is the financial institution 1, and the stamp 1304 is added when the discard signer 910 indicates that it is the debtor of the customer 2.

  In response to receiving a loan execution request for the selected contract data from the financial institution terminal 110, the execution processing request unit 1607 displays a status 911 so that the person in charge of the paper processing department can handle the contract data. It can be updated from “Waiting for office management cooperation” to “Office management cooperation completed”. The loan execution request can be made under the condition that the execution request button in FIG. 5 is pressed. The business processing department can be responsible for loan execution practices (eg, drafting, checking, bookkeeping, print verification, etc.).

  The discard processing unit 1608 can perform a process of discarding a contract with an electronic signature. More specifically, the discard processing unit 1608 can provide the financial institution terminal 110 with one or more contracts concluded with the customer 2 in response to the communication with the financial institution terminal 110. . In response to receiving a signal indicating that the contract data to be discarded is selected by the financial institution 1 and the contract discard button is pressed, the discard processing unit 1608 sets a predetermined value ( For example, the value “1” indicating the discard can be set, and the financial institution 1 can be set as the discard signer 910. The discard processing unit 1608 can present the contract data to the customer 2 by changing the status 911 of the contract data to “wait for discard”.

  In response to the communication with the customer terminal 120, the discard processing unit 1608 can provide the customer terminal 120 with one or a plurality of contract data for which the electronic signature for discard has already been performed by the financial institution 1. In response to receiving a signal indicating that any contract data is selected by the customer 2 and the contract cancel button is pressed, the discard processing unit 1608 sends the obligor of the customer 2 to the discard signer 910. Can be set. When there are a plurality of debtors, the discard processing unit 1608 can set information indicating each debtor of the customer 2 in the discard signer 910.

  Although the principle of the present invention has been described above with reference to exemplary embodiments, those skilled in the art will recognize that various embodiments that can be corrected in configuration and details can be realized without departing from the spirit of the present invention. Will understand. That is, the present invention can adopt an embodiment as, for example, a system, apparatus, method, program, or storage medium.

DESCRIPTION OF SYMBOLS 1 Financial institution 2 Customer 100 Electronic contract system 110 Financial institution terminal 120 Customer terminal 121 Reader 130, 150 Network 140 Certificate authority server 201 Control unit 202 Main storage unit 203 Auxiliary storage unit 204 Interface (IF) unit 205 Output unit 206 Customer master 207 User master 208 Contract DB
500 Contract Information List 600 Contract Information 1000 Contract Details 1100 Contract Procedure Start 1200 Contract Procedure 1601 Certificate Authority Communication Unit 1602 Contract Data Processing Unit 1603 Electronic Signature Unit 1604 Confirmation Processing Unit 1605 Screen Control Processing Unit 1606 Stamp Processing Unit 1607 Execution Processing Request Unit

Claims (11)

An electronic contract system that handles electronic contract documents concluded between financial institutions and customers,
And the user of the information to be used as either of the electronic contract system of the obligor signer and guarantor signer in the customer, the user master for storing the contract type information indicating a contract type of the user ,
A function for determining that the logged-in user of the electronic contract system corresponds to either the signer of the debtor or the signer of the guarantor, and for the debtor to perform an electronic signature based on the determination result Screen control processing means for controlling whether to enable a function for enabling the guarantor to perform an electronic signature;
When the signer performs an electronic signature,
An electronic signature means for electronically signing the electronic contract document using the electronic certificate and key pair of the signer;
A stamp processing means for dynamically generating a stamp indicating that the customer has performed the electronic signature as the signer, and adding the stamp to the electronic contract document ;
The contract type information includes at least information representing only the position as a corporation,
The user who has information representing only the position as a corporation can make an electronic signature as a debtor of the corporation, but cannot make an electronic signature as an individual guarantor.
Electronic contract system. The user master further stores information of a person who uses the electronic contract system as a confirmer in the customer,
The electronic contract system determines whether the confirmation work by the confirmer is necessary for the electronic contract document and determines whether a predetermined number of confirmers confirm the electronic contract document. A confirmation processing means,
The confirmation processing means includes:
In response to the determination that the confirmation work by the confirmer is necessary for the electronic contract document, the function for the signer to perform the electronic signature is disabled,
2. The apparatus of claim 1, further configured to enable a function for the signer to perform an electronic signature in response to a determination that a predetermined number of verifiers have confirmed the electronic contract document. The electronic contract system described.   In response to selection of a function for the debtor to perform an electronic signature or a function for the guarantor to perform an electronic signature, the debtor or the guarantor performs an electronic signature on the electronic document. The electronic contract system of claim 1, wherein the display on the graphical user interface used to change is changed. The generated stamp includes a first stamp and a second stamp;
The first stamp is generated when the signer is a debtor;
The second stamp is generated when the signer is a guarantor.
The electronic contract system according to claim 1. The contract type information includes a “legal and personal use type” that combines both a corporate position and an individual position into a single user ID, a “corporate limited type” that represents only a corporate position, and an individual position. show only "private limited type", and debtor-guarantor as long as the confirmation by the contract confirmation authority is not completed includes "pre-contract confirmation type" as used in the case that can not be electronic signature, as set forth in claim 1 Electronic contract system. A method executed by an electronic contract system that handles an electronic contract document concluded between a financial institution and a customer,
The electronic contract system includes information on a user who uses the electronic contract system as one of a debtor signer and a guarantor signer in the customer, and contract type information indicating a contract type of the user. It has a user master to store,
The method
A function for determining that the logged-in user of the electronic contract system corresponds to either the signer of the debtor or the signer of the guarantor, and for the debtor to perform an electronic signature based on the determination result Controlling whether to enable the guarantor to enable the electronic signature function;
When the function for the signer to perform an electronic signature is executed,
Electronically signing the electronic contract document using the signer's electronic certificate and key pair;
Dynamically generating a stamp indicating that the customer has performed the electronic signature as the signer, and adding the stamp to the electronic contract document ,
The contract type information includes at least information representing only the position as a corporation,
The user who has information representing only the position as a corporation can make an electronic signature as a debtor of the corporation, but cannot make an electronic signature as an individual guarantor.
Method. The user master further stores information of a person who uses the electronic contract system as a confirmer in the customer,
The method
Determining whether confirmation by the confirmer is necessary for the electronic contract document and determining whether a predetermined number of confirmers have confirmed the electronic contract document;
In response to the determination that the confirmation work by the confirmer is necessary for the electronic contract document, disabling the function for the signer to perform the electronic signature;
7. The method of claim 6, further comprising: enabling a function for the signer to perform an electronic signature in response to a determination that a predetermined number of confirmers have confirmed the electronic contract document. the method of.   In response to selection of a function for the debtor to perform an electronic signature or a function for the guarantor to perform an electronic signature, the debtor or the guarantor performs an electronic signature on the electronic document. The method of claim 6, wherein the display on the graphical user interface used to change is changed. The generated stamp includes a first stamp and a second stamp;
The first stamp is generated when the signer is a debtor;
The second stamp is generated when the signer is a guarantor.
The method of claim 6. The contract type information includes a “legal and personal use type” that combines both a corporate position and an individual position into a single user ID, a “corporate limited type” that represents only a corporate position, and an individual position. show only "private limited type", and debtor-guarantor as long as the confirmation by the contract confirmation authority is not completed includes "pre-contract confirmation type" as used in the case that can not be electronic signature, according to claim 6 Method.   The program which makes a computer perform the method as described in any one of Claims 6 thru | or 10.