Program, method, and information processing device

Abstract

To prevent unauthorized agency when a recipient without decision-making authority is set in an electronic contract.SOLUTION: A program causes a processor of a computer to execute the steps of: receiving a setting of a first user as an approver when concluding an electronic contract, in a first group; receiving, from a second user different from a user of the first group, information for identifying users of the first group and contract data, the object of concluding an electronic contract with the first group; and when the first user is set as the approver in the first group, requesting the first user to perform an operation of approving contract conclusion of the contract data regardless of whether or not the first user is included in the user information identified by the second user.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] The present disclosure relates to a program, a method, and an information processing device. [Background technology]

[0002] In business activities, various agreements and applications are approved both inside and outside the company as the business progresses. For example, within a business, an approver makes a decision on the content to be approved. Japanese Patent Application Laid-Open Publication No. 2013-178842 (Patent Document 1) below describes that, with the aim of smoother approval processing within the company, when multiple approvers are set for electronic document data showing application content, skip authority is granted to skip the approval process by an approver on the approval route. In addition, with regard to contracts both inside and outside a business, in recent years, advances in IT technology have led to a gradual shift from paper-based contracts to electronic contracts.

[0003] In an electronic contract, the user of the electronic contract service electronically signs the document to be signed. Electronic contract services are provided by businesses in various formats, including the so-called party signature type and the so-called business signature type (witness type). When a contract is concluded using an electronic contract service, the parties may be able to view the document data that is the subject of the contract between them using information that identifies the parties to the contract. For example, if email addresses are used to identify the parties to the contract, one of the parties who wants to enter into the contract sends the contract data to the electronic contract service with the other party's email address specified. The person (or company) who receives the contract data then uses the electronic contract service to approve the contract data, thereby proceeding with the conclusion of the electronic contract. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2013-178842 A Summary of the Invention [Problem to be solved by the invention]

[0005] However, when the parties to a contract designate an approver for the conclusion of the contract and proceed with the conclusion of the contract through electronic means, it is possible that a person without the authority to conclude the contract may be designated as the approver, resulting in the conclusion being carried out by an unauthorized person without the authority to approve. If such unauthorized representation is possible, even if an electronic contract service is used, the reliability of the contract that is concluded may be reduced, and there is a risk that the use of electronic contract services themselves will not be promoted.

[0006] Therefore, there is a need for technology that can prevent unauthorized representation by unauthorized persons in electronic contract services. [Means for solving the problem]

[0007] According to one embodiment of the present disclosure, a program for operating a computer is provided. The computer is for concluding an electronic contract between multiple corporate or individual users, and the program causes the computer's processor to execute the following steps: accepting setting of a first user who will be an approver when concluding an electronic contract in a first group consisting of multiple users; accepting information identifying a user of the first group and contract data that is the subject of an electronic contract to be concluded with the first group from a second user different from the users of the first group; if a first user who will be an approver in the first group is not set, requesting a user specified by the second user to operate to approve the conclusion of the contract data; if a first user who will be an approver in the first group is set, requesting the first user to operate to approve the conclusion of the contract data, regardless of whether the first user is included in the information of users specified by the second user; and, by accepting the approval operation from the requested user, managing the contract data in the computer, assuming that an agreement has been reached on the contract data between the first group and the second user or a second group including the second user. [Effects of the Invention]

[0008] According to the present disclosure, by allowing the recipient of an electronic contract service to set an appropriate approver, it is possible to prevent unauthorized representation when a recipient without decision-making authority is set. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a diagram showing the overall configuration of an electronic contract system 1 according to an embodiment. [Figure 2] FIG. 2 is a block diagram showing the functional configuration of a receiver-side terminal device 10. [Figure 3] FIG. 2 is a block diagram showing the functional configuration of a server 20. [Figure 4]FIG. 1 is a conceptual diagram for explaining an electronic contract. [Figure 5] 5 is a diagram showing the data structure of the electronic contract management database 2021. 2022 in Fig. 5 is a diagram showing the data structure of the approver information at the time of sending 2022. 2023 in Fig. 5 is a diagram showing the data structure of the forwarding destination approver setting 2023. 2024 in Fig. 5 is a diagram showing the data structure of the approval history 2024. [Figure 6] FIG. 10 is a diagram showing the flow of processes related to contract conclusion. [Figure 7] FIG. 10 is a diagram showing a process for determining the domain of an email address when concluding a contract, and a flow of a process using the determined result. [Figure 8] FIG. 10 is a diagram showing a situation in which contract data is confirmed at the terminal of an approver of a first business operator. [Figure 9] FIG. 10 is a diagram showing how to set an approver of contract data on a terminal of a user of a first business operator. [Figure 10] FIG. 10 is a diagram showing an approver flow of contract data at the approver terminal of the first business operator. [Figure 11] FIG. 10 is a diagram showing signature data of contract data for which an agreement has been concluded. [Figure 12] FIG. 10 is a diagram showing partially anonymized signature data of an approver in contract data for which an agreement has been concluded. [Figure 13] FIG. 10 is a diagram showing recommended people to be included as approvers in the approval flow of contract data, based on the approval history of past electronic contracts. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In the following description, the same components are denoted by the same reference numerals. The names and functions of the components are also the same. Therefore, detailed descriptions thereof will not be repeated.

[0011] <Outline of the first embodiment> In this embodiment, a user operates a personal computer (PC) to conclude a contract using an electronic contract service. In an electronic contract, the parties agree on the contract data, which is the subject of the electronic contract, and the conclusion of the contract is advanced by both parties approving the contract data.

[0012] The contract data is based on the contract terms agreed upon by both parties and includes, for example, data created in at least the following manner. Contract data created by document creation software Data that maps each item of the contract terms and the content agreed upon by both parties for each item

[0013] In an electronic contract, there is one or more approvers who approve the contract data. Based on the contract data, the approvers decide whether or not to conclude the contract under the conditions specified in the content of the contract data.

[0014] In the electronic contract system 1 described below, the server 20 is used to conclude electronic contracts between multiple users who are corporations or individuals. Note that individuals include sole proprietors. Conclusion of electronic contracts between legal entities For example, a user in a first group (such as a corporation) and a user in a second group (such as a corporation) agree to conclude a contract with the first group and the second group as contracting parties. Conclusion of electronic contracts between legal entities and individuals For example, a contract such as a real estate lease contract, an employment contract, or an insurance contract is agreed upon between a user of a first group (a corporation such as a real estate management company) and an individual user, with the first group and the individual user as the contracting parties. Entering into electronic contracts between individuals There may also be more than two parties to a contract (for example, a tripartite contract).

[0015] <1.1 Overall system configuration> Figure 1 is a block diagram showing an example of the overall configuration of an embodiment of an electronic contract system 1. As shown in Figure 1, the electronic contract system 1 includes a receiver terminal device 10, a sender terminal device 30, and a server 20, which are connected to each other via a network 80 so that they can communicate with each other.

[0016] 1 shows a receiver's terminal device 10 used by a user. The receiver's terminal device 10 is, for example, a PC.

[0017] The receiver's terminal device 10 executes a program to provide the user with an environment for operating a system corresponding to the program. The receiver's terminal device 10 reads and executes the program to establish a communication connection between the receiver's terminal device 10, the sender's terminal device 30, and the server 20. The receiver's terminal device 10 then transmits and receives data related to the electronic contract (e.g., contract data, information indicating that each user has approved the contract data, information allowing users to view the concluded contract data, etc.) between the receiver's terminal device 10, the sender's terminal device 30, and the server 20.

[0018] The server 20 visualizes the status of the electronic contract on the recipient's terminal device 10 by appropriately transmitting data necessary for the electronic contract to the recipient's terminal device 10. The server 20 manages various data related to the electronic contract of the user who operates the electronic contract. The server 20 communicates with the recipient's terminal device 10 and transmits images, files, text data, etc. to the recipient's terminal device 10 according to the progress of each user's electronic contract.

[0019] For example, the server 20 manages various data such as information on users related to electronic contracts, information on contract data used in electronic contracts, and information on the approval date and time when a user approved an electronic contract.

[0020] The receiver terminal device 10 includes a communication IF (Interface) 12 , an input device 13 , an output device 14 , a memory 15 , a storage unit 16 , and a processor 19 .

[0021] The communication IF 12 is an interface for inputting and outputting signals so that the receiver-side terminal device 10 can communicate with an external device.

[0022] The input device 13 is a device for receiving input operations from a user (for example, a touch panel, a touch pad, a pointing device such as a mouse, a keyboard, etc.).

[0023] The output device 14 is a device (such as a display or speaker) for presenting information to the user.

[0024] The memory 15 is for temporarily storing programs and data to be processed by the programs, and is a volatile memory such as a DRAM (Dynamic Random Access Memory).

[0025] The storage unit 16 is for storing data, and is, for example, a flash memory or a hard disk drive (HDD).

[0026] The processor 19 is hardware for executing an instruction set written in a program, and is composed of an arithmetic unit, a register, a peripheral circuit, and the like.

[0027] The server 20 is a device that manages information about users who enter into contracts electronically, contract data used when making electronic contracts, and other information.

[0028] The server 20 includes a communication IF 22 , an input / output IF 23 , a memory 25 , a storage 26 , and a processor 29 .

[0029] The communication IF 22 is an interface for inputting and outputting signals so that the server 20 can communicate with external devices.

[0030] The input / output IF 23 functions as an input device for receiving input operations from the user and as an interface with an output device for presenting information to the user.

[0031] The memory 25 is for temporarily storing programs and data to be processed by the programs, and is a volatile memory such as a DRAM (Dynamic Random Access Memory).

[0032] The storage 26 is for storing data, and is, for example, a flash memory or a hard disk drive (HDD).

[0033] The processor 29 is hardware for executing an instruction set written in a program, and is composed of an arithmetic unit, registers, peripheral circuits, and the like.

[0034] The sender terminal device 30 includes a communication IF (Interface) 32 , an input device 33 , an output device 34 , a memory 35 , a storage unit 36 ​​, and a processor 39 .

[0035] The communication IF 32 is an interface for inputting and outputting signals so that the sender side terminal device 30 can communicate with an external device.

[0036] The input device 33 is a device for receiving input operations from a user (for example, a touch panel, a touch pad, a pointing device such as a mouse, a keyboard, etc.).

[0037] The output device 34 is a device (such as a display or speaker) for presenting information to the user.

[0038] The memory 35 is for temporarily storing programs and data to be processed by the programs, and is a volatile memory such as a DRAM (Dynamic Random Access Memory).

[0039] The storage unit 36 ​​is for storing data and is, for example, a flash memory or a hard disk drive (HDD).

[0040] The processor 39 is hardware for executing an instruction set written in a program, and is composed of an arithmetic unit, registers, peripheral circuits, and the like.

[0041] <1.2 Functional configuration of the receiver terminal device 10> 2 is a diagram showing the functional configuration of the recipient's terminal device 10. The recipient's terminal device 10 includes an antenna 111, a first wireless communication unit 121, a processor 19, an operation reception unit 130, a storage unit 16, a memory 15, a display 132, an audio processing unit 140, a microphone 141, and a speaker 142.

[0042] The antenna 111 radiates the signal emitted by the receiver-side terminal device 10 into space as a radio wave. The antenna 111 also receives the radio wave from space and provides the received signal to the first wireless communication unit 121.

[0043] The first wireless communication unit 121 performs modulation / demodulation processing and the like for transmitting and receiving signals via the antenna 111 etc. so that the recipient-side terminal device 10 can communicate with other communication devices. The first wireless communication unit 121 is a communication module for wireless communication that includes a tuner, a high-frequency circuit etc., and performs modulation / demodulation and frequency conversion of the wireless signals transmitted and received by the recipient-side terminal device 10, and provides the received signals to the processor 19.

[0044] The processor 19 reads and executes the programs stored in the storage unit 16 to control the operation of the receiver's terminal device 10. The processor 19 is realized by, for example, an application processor.

[0045] The operation reception unit 130 has a mechanism for receiving input operations from a user. For example, the operation reception unit 130 is realized as a pointing device such as a mouse, touchpad, or touchpanel, a keyboard, a controller, or an imaging unit that senses the user's body movements as input operations. For example, the operation reception unit 130 senses the user's body movements, such as the movements of body parts such as hands, or the user's facial expressions, and receives these body part movements as input operations. The operation reception unit 130 determines the type of operation, such as whether the user's operation is a flick operation, a tap operation, or a drag (swipe) operation, based on the coordinates at which the input operation is received, such as when the user touches a finger on a touchpad or touchpanel.

[0046] The storage unit 16 is configured with a flash memory, a RAM (Random Access Memory), etc., and stores programs used by the receiver's terminal device 10, various data received by the receiver's terminal device 10 from the server 20, etc.

[0047] The display 132 displays data such as images, videos, and text under the control of the processor 19. The display 132 is realized by, for example, an LCD (Liquid Crystal Display), an organic EL (Electroluminescence) or other display device.

[0048] The audio processing unit 140 modulates and demodulates audio signals. The audio processing unit 140 modulates a signal provided from a microphone 141 and provides the modulated signal to the processor 19. The audio processing unit 140 also provides the audio signal to a speaker 142.

[0049] The microphone 141 receives an audio input and provides an audio signal corresponding to the audio input to the audio processing unit 140 .

[0050] The speaker 142 converts the audio signal provided from the audio processing unit 140 into audio and outputs the audio to the outside of the receiver-side terminal device 10 .

[0051] The storage unit 16 stores electronic contract management information 161, send-time approver information 162, forwarding destination approver setting 163, and approval history 164. The electronic contract management information 161 is information for managing each electronic contract. The approver information at the time of transmission 162 indicates information on the approver on the recipient side designated by the terminal device 30 on the sender side in the electronic contract that is being concluded by the terminal device 10 on the recipient side. The transfer destination approver setting 163 indicates information about a user who is set as an approver in the group of users of the receiver-side terminal device 10. The approval history 164 indicates information on the approval history, including information on the timing of approval by the user who will be the approver, for each electronic contract.

[0052] The processor 19 operates according to a program to function as an input operation receiving unit 191, a transmitting / receiving unit 192, a data processing unit 193, and a notification control unit 194.

[0053] The input operation reception unit 191 performs processing to receive a user's input operation on an input device such as the operation reception unit 130. When the operation reception unit 130 is, for example, a touch-sensitive device, the input operation reception unit 191 determines the type of operation, such as whether the user's operation is a flick operation, a tap operation, or a drag (swipe) operation, based on information about the coordinates where the user has touched the touch-sensitive device with a finger or the like.

[0054] The transmitting / receiving section 192 performs processing for the receiver's terminal device 10 to transmit and receive data to and from an external device such as the server 20 in accordance with a communication protocol.

[0055] The data processing unit 193 performs calculations on the data that the receiver's terminal device 10 receives as input in accordance with a program, and outputs the calculation results to a memory or the like.

[0056] The notification control unit 194 performs processing to present information to the user, such as processing to display a display image on the display 132, processing to output sound to the speaker 142, and processing to generate vibrations from a vibrator or the like.

[0057] <1.3 Functional configuration of server 20> 3 is a diagram showing the functional configuration of the server 20. As shown in FIG. 3, the server 20 functions as a communication unit 201, a storage unit 202, and a control unit 203.

[0058] The communication unit 201 performs processing for the server 20 to communicate with external devices.

[0059] The storage unit 202 stores various databases such as an electronic contract management database 2021, send-time approver information 2022, transfer destination approver settings 2023, and approval history 2024.

[0060] The electronic contract management database 2021 is a database for managing information on each contract concluded in the electronic contract system 1. Details will be described later.

[0061] The approver information at the time of transmission 2022 is a database for managing information on users who are set as approvers for each contract concluded in the electronic contract system 1. Details will be described later.

[0062] The forwarding destination approver setting 2023 is a database for managing information on users who are set as approvers in advance in association with a group to which multiple users, such as business operators, belong. Details will be described later.

[0063] The approval history 2024 is a database of approval history, including information on the timing of approval by the user who will be the approver for each electronic contract. Details will be described later.

[0064] The control unit 203 is realized by the processor 29 reading a program stored in the storage unit 202 and executing instructions included in the program. By operating in accordance with the program, the control unit 203 performs functions shown as a reception control module 2031, a transmission control module 2032, an electronic contract information acquisition module 2033, an approver user information acquisition module 2034, and an approval date and time information acquisition module 2035.

[0065] The reception control module 2031 controls the process by which the server 20 receives signals from external devices in accordance with a communication protocol.

[0066] The transmission control module 2032 controls the process in which the server 20 transmits signals to external devices in accordance with a communication protocol.

[0067] The electronic contract information acquisition module 2033 performs a series of processes for managing electronic contract information.

[0068] The approver user information acquisition module 2034 performs a series of processes to manage the information of users who are set to approve as approvers on the recipient side, regardless of whether they are designated as users on the recipient side in the sender side terminal device 30 when concluding an electronic contract.

[0069] The approval date and time information acquisition module 2035 performs a series of processes for managing information on the date and time when the approver gave approval.

[0070] <1.4 Conceptual diagram for explaining electronic contracts> 4 is a conceptual diagram for explaining an electronic contract. In this embodiment, an "electronic contract" includes using an electronic contract service provided by a business operator or the like that operates server 20 to digitally sign contract data agreed upon by the contracting parties using a signature key as follows: The contracting parties digitally sign the contract data using a signing key prepared by the contracting parties themselves. Using a signing key provided by the electronic contract service provider, the contract data is electronically signed based on the will of the contracting parties (for example, in response to the contracting parties' operation to approve the contract data).

[0071] For example, the contracting parties operate their respective terminal devices to exchange contract document data between their terminal devices over the Internet via server 20, and the contracting parties input an indication of their intention to agree, whereby they affix their electronic signatures to the electronic data of the contract documents.

[0072] First, the contract sender operates the sender terminal device 30 to upload the contract data to, for example, the cloud server 20. The server 20 affixes the contract sender's digital signature to the contract data agreed upon by the contract sender.

[0073] The contract sender performs an operation to request the contract receiver to enter into an agreement. Specifically, the sender terminal device 30 accepts an operation from the user to designate a contract receiver and transmits it to the server 20. In this embodiment, the sender terminal device 30 accepts information identifying one or more contract receivers from the user, and requests the users of the contract receivers to enter into an agreement via the server 20. The information identifying the user accepted from the contract sender may be as follows: The email address of each agreement recipient Account for the service used by the contract recipient (for example, if a user account has been issued for the electronic contract service provided by the server 20, information identifying the user account, such as a user ID, or information identifying a user account for a service other than the electronic contract service provided by the server 20)

[0074] The server 20 of the electronic contract system 1 sends information for accessing the contract data (for example, a link written as a URL (Uniform Resource Locator)) to the recipient of the contract via email to the recipient's email address specified by the user who sent the contract.

[0075] Here, the server 20 may accept from the contract sender a designation of the viewing order of multiple contract recipients. For example, when the server 20 accepts from the contract sender the designation of multiple email addresses of contract recipients, the server 20 may send information for accessing the contract data to each contract recipient in the order of the designated email addresses.

[0076] For example, suppose the contract sender specifies a first email address, a second email address, and a third email address as contract recipients. The server 20 first sends a link to the first contract recipient at the first email address to allow the first recipient to view the contract data and accepts an approval operation. In response to accepting the approval operation for the contract data from the first contract recipient, the server 20 records the fact that the first contract recipient has given their approval and the timing of the approval (e.g., by attaching the first contract recipient's digital signature in response to the approval operation), and sends a link to the second contract recipient at the second email address to allow the second contract recipient to view the contract data. Thereafter, the server 20 similarly records the fact that the second contract recipient has given their approval and the timing of the approval (e.g., by attaching the second contract recipient's digital signature in response to the approval operation), and in response to the second contract recipient's approval, sends a link to the third contract recipient to allow the third contract recipient to view the contract data and accepts an approval operation from the third contract recipient.

[0077] The contract recipient can click on the link contained in the email received on the recipient's terminal device 10, check the contents of the contract data on the server 20 online, and conclude an agreement. The recipient's terminal device 10 presents a screen for accepting an operation indicating agreement to the contract to the user of the recipient's terminal device 10, and accepts an operation for agreement from the user. If there is a defect in the contract contents at this point, the server 20 may accept an operation from the contract recipient indicating that the contract is not agreed to.

[0078] The server 20 accepts an operation from the contract recipient to agree to the contract data, and then affixes the contract recipient's digital signature to the contract data. The contract data is stored in the server 20. The affixing of digital signatures from both contracting parties prevents the contract from being tampered with.

[0079] This embodiment realizes such a cloud-based electronic contract service. In the following embodiment, a technology for preventing a person belonging to an organization from concluding an electronic contract without authorization will be described.

[0080] For this reason, the approver user information acquisition module 2034 (see FIG. 3) of the server 20 manages information on persons who are authorized to conclude contracts within the organization, and performs processing to prevent persons who do not have the authority from operating to conclude agreements.

[0081] The electronic contract information acquisition module 2033 is responsible for all electronic contract processing other than the above-mentioned authority management. That is, the electronic contract information acquisition module 2033 performs the process of recording the contract data in the server 20 based on the operation of the contract sender as described above, the process of generating a link for accessing the contract data, the process of sending an email to the contract recipient for contract conclusion, the process of accepting access from the contract recipient based on the link and accepting operations for contract conclusion, and other processes.

[0082] <2 Data Structure> Fig. 5 is a diagram showing the data structure of a database stored in the server 20. Note that Fig. 5 is an example and does not exclude data not shown.

[0083] Each record in the electronic contract management database 2021 in Figure 5 includes the items "contract ID," "sender's document transmission date and time," "contract status," "contract completion date and time," "sender's email address," "recipient's email address 1," "recipient's email address 2," "recipient's email address 3," and "document ID used in electronic contract." The illustrated example shows an example in which the sender's user in an electronic contract can specify three users as multiple recipients, but the number is not limited to three.

[0084] The item "contract ID" indicates identification information issued by, for example, the server 20 for each contract concluded by electronic contract.

[0085] Specifically, the item "contract ID" is a unique ID for an electronic contract that is required when managing each contract concluded between users by electronic contract.

[0086] The item "sender's side document transmission date and time" indicates the timing when the sender's user transmitted the contract data to the server 20 in order to conclude the contract by electronic contract. For example, the server 20 performs a process to accept an upload of the contract data from the sender's user, and stores the timing of the process in the item "sender's side document transmission date and time."

[0087] The item "Agreement Status" indicates the status of the electronic contract that is being concluded between the sender and the recipient. Specifically, the status of the electronic contract between the parties may include the following: "Uncontracted": The state in which the process of concluding an electronic contract between users has not yet begun. For example, the state in which the designation of users involved in the process of concluding an electronic contract is being accepted. - "Contract in progress": A state in which each user has been designated in the execution of an electronic contract, but the operation to approve the contents of the contract has not yet been received from at least one of the designated users. "Contract completed": The state in which the server 20 has accepted the operation of approving each user designated in the conclusion of the electronic contract, and the conclusion of the contract by electronic contract has been completed.

[0088] The item "sender's email address" indicates information for identifying the sender's user, specifically, the email address of the sender's user.

[0089] The item "Recipient's Email Address 1" indicates information for identifying the recipient's user, specifically the recipient's email address (first one).

[0090] The item "Recipient's email address 2" indicates information for identifying the recipient's user, similar to the above, and specifically indicates the recipient's email address (second email address).

[0091] The item "Recipient's email address 3" indicates information for identifying the recipient's user, similar to the above, and specifically indicates the recipient's email address (third).

[0092] The item "Document ID used in electronic contract" indicates the identification information (ID) of the data of the document that is the subject of the electronic contract. For example, the document identification information includes unique information (such as identification information issued to the document, link information for each terminal device to access the document) that is issued in association with the document data when the server 20 accepts an upload of the document data that is the subject of the electronic contract.

[0093] Each record of the approver information at the time of sending 2022 in Fig. 5 includes an item "contract ID," an item "approver 1 user ID," an item "approver 2 user ID," and an item "approver 3 user ID." In the example shown, a sender user in an electronic contract can specify three users as multiple recipient users, but the number of users is not limited to three.

[0094] The item "contract ID" indicates identification information issued by, for example, the server 20 for each contract concluded by electronic contract.

[0095] Specifically, the item "contract ID" is a unique ID for an electronic contract that is required when managing each contract concluded between users by electronic contract.

[0096] The item "Approver 1 User ID" indicates the ID of the user who is the approver (first person) on the recipient side, which is specified by the user on the sender side of the electronic contract.

[0097] The item "Approver 2 User ID" similarly indicates the ID of the approver (second user) on the recipient side.

[0098] The item "Approver 3 User ID" similarly indicates the ID of the approver (third person) on the recipient side.

[0099] The forwarding destination approver settings 2023 in Figure 5 includes the items "Approver User ID", "User's Email Address", "User's Name", "User's Company Name", "User's Department Name", and "User's Estimated Job Title".

[0100] In the following example, the forwarding destination approver setting 2023 is used to manage users who are set as approvers in each group (such as a business company).

[0101] Here, the server 20 may manage a list of users belonging to each group (for example, a list of employees of a business company) (for example, an employee database managed by the human resources department of a business company may be imported into the server 20), and may manage whether a user is set as an approver in association with a specific user in the list of users of the group. That is, the list of users of the group may contain a mixture of users who are set as approvers and users who are not set as approvers.

[0102] The item "Approver User ID" is identification information assigned to a user who is set as an approver when the user is on the receiving side when concluding an electronic contract.

[0103] Specifically, it is the information of the user who will be the approver on the recipient side, regardless of the information (email address) that identifies the recipient user specified by the sender of the electronic contract (i.e., even if the user is not specified as the recipient's email address by the sender).

[0104] For example, the server 20 receives in advance the designation of a user who will be the approver of an electronic contract from a group (e.g., a business company) to which the user who will be the approver belongs, and registers the designation in the forwarding approver setting 2023. When the server 20 receives the designation of one of the users in the recipient's group from the user who is the sender of the electronic contract, the server 20 notifies the user who is set as the approver in the recipient's group to approve the electronic contract as the approver, even if the user who will be the approver is not designated. For example, the server 20 sends a notification to the email address of the user who is set as the approver that there is a request to conclude an electronic contract, along with a link to the contract data that is the subject of the electronic contract.

[0105] Specifically, the item "Approver User ID" is a unique ID for the approver that is required when managing a program.

[0106] The item "user's email address" indicates information for identifying a user who is set as an approver when the user is the recipient of an electronic contract, specifically the email address of the user.

[0107] The item "user name" indicates the name of the user who is set as the approver.

[0108] The item "User's company name" indicates the name of the organization (such as a business company name) to which the user set as the approver belongs.

[0109] The item "User's department name" indicates the name of the department to which the user set as the approver belongs.

[0110] The item "User's Estimated Job Title" indicates the estimated job title of the user who is set as the approver. A method for estimating the user's job title will be described later. Here, the job title of the user may be registered in advance in the server 20.

[0111] 5 includes the item "contract ID," the item "approval date and time by approver 1," the item "approval date and time by approver 2," the item "approval date and time by approver 2," the item "approval date and time by approver 3," and the item "approval date and time by approver 3." The example shown in the figure shows an example in which a sender user in an electronic contract can specify three users as multiple recipient users, but the number of users is not limited to three.

[0112] The item "contract ID" indicates identification information issued by, for example, the server 20 for each contract concluded by electronic contract.

[0113] Specifically, the item "contract ID" is a unique ID for an electronic contract that is required when managing each contract concluded between users by electronic contract.

[0114] The item "Approver 1 User ID" indicates the ID of the approver (first person).

[0115] The item "Approval date and time by approver 1" indicates the date and time when the approver (first person) approved.

[0116] The item "Approver 2 User ID" indicates the ID of the approver (second user).

[0117] The item "Date and time of approval by approver 2" indicates the date and time when the approver (second person) approved.

[0118] The item "Approver 3 User ID" indicates the ID of the approver (third person).

[0119] The item "approval date and time of approver 3" indicates the date and time when the approver (third person) approved.

[0120] <Operation of the First Embodiment> Next, the operation of each device constituting the electronic contract system 1 will be described.

[0121] 6 is a diagram showing the flow of processing for concluding a contract between the parties via the server 20. In the following example, the explanation will be given assuming that both the sending and receiving parties are businesses. Specifically, the explanation will be given of an example in which, when concluding a contract by electronic contract, a user of a second business (sending party) identifies a user of a first business (receiving party) and then proceeds with concluding the contract via the server 20.

[0122] In step S601, the sender terminal device 30 of the second business accepts an operation from the user to specify the data of a document to be used in the electronic contract between the second business and the first business. The sender terminal device 30 transmits the accepted data of the document to the server 20 as contract data.

[0123] When transmitting the contract data, the sender terminal device 30 receives input of the email addresses of one or more users of the first business as the destinations of the document from the user of the second business. The sender terminal device 30 transmits the received email address information to the server 20.

[0124] In step S631, the server 20 receives contract data used in the electronic contract from the sender terminal device 30 of the second business. The server 20 updates the electronic contract management database 2021 based on the information received from the sender terminal device 30 (contract data, information specifying the user of the first business, etc.).

[0125] In step S632, the server 20 refers to the transfer destination approver setting 2023 to determine whether or not a user who will be the approver has been set at the first business entity.

[0126] (i) If the first business operator has not set a user to be the approver, the server 20 requests the user (the user of the first business operator) specified by the user of the second business operator to perform an operation to approve the conclusion of the contract data. Specifically, the server 20 sends a message to the email address of the recipient user specified by the user of the second business operator when concluding the electronic contract, urging the user to confirm the contents of the document that is the subject of the electronic contract, and including information that the server 20 will accept an operation to approve the contents of the contract.

[0127] (ii) If a user who will be the approver is set at the first business operator, the server 20 requests the first user who will be the approver when the electronic contract is concluded at the first business operator (forwarding approver setting 2023) to operate to approve the conclusion of the contract for the document, regardless of whether the destination of the electronic contract includes the email address of the first user who will be the approver when the electronic contract is concluded at the first business operator. For example, the server 20 sends to the email address of the first user a message urging the first user to confirm the contents of the document that is the subject of the electronic contract, a message including information that the operation to approve the contract contents is accepted, or a message including at least one of information that the document has been forwarded because the first user has been set as the approver.

[0128] The server 20 requests the first user, who is the addressee of the electronic contract and the approver, to perform an operation to approve the conclusion of the contract data. For example, the server 20 sends to the email address of the first user a message urging the first user to confirm the content of the contract data that is the subject of the electronic contract, a message including information that the operation to approve the contract content is accepted, and a message including at least one of information that the message has been forwarded because the first user has been set as the approver.

[0129] For example, the server 20 may identify a user involved in the conclusion of a contract at the first business operator and update the electronic contract management database 2021 based on the information of the identified user as follows: By referring to the updated electronic contract management database 2021, the server 20 may transmit information for making a request to a user requesting approval of the contract data. At least some of the users designated by the second business operator and the first user set as the approver in the forwarding approver setting 2023 are set as approvers for the conclusion of the electronic contract, and the electronic contract management database 2021 is updated based on information (email addresses) identifying these users who will be approvers. For example, in the electronic contract management database 2021, information identifying the first user is stored in the recipient's email address in association with the contract ID.

[0130] As described above, the server 20 allows each approver to view the document and request approval based on the approver information at the time of sending 2022 and the approver setting at the transfer destination 2023.

[0131] Here, the server 20 will be described as requesting all users (users of the first business operator) designated as destinations by the user of the second business operator and the first user to approve the contract data when a first user who will be the approver is set in the transfer destination approver setting 2023. Note that there may be cases where the first user who is the approver is included in the users designated as destinations by the user of the second business operator.

[0132] In step S651, the recipient terminal device 10 of the user of the first business (the user designated by the user of the second business and the first user set as the approver) receives contract data to be used in the electronic contract from the user of the second business via the server 20.

[0133] In step S652, the recipient's terminal device 10 presents the contract data to the user by displaying information on the display 132, notifying by voice, etc. The recipient's terminal device 10 confirms the contents of the contract data from the approver user, and accepts an input operation for concluding the contract (an input operation for approving). In response to the input operation for concluding the contract, the recipient's terminal device 10 transmits information indicating that the contract will be concluded to the server 20.

[0134] At this time, the server 20 requests approval in the order in which the destinations are specified. For example, if there is an approver at the destination (sent to the destination first), the request may be transferred to the approver at the destination after receiving approval from all users specified as the destinations. Alternatively, the request may be sent to the destination last, or approval may be received from the approver at the destination rather than from the user specified as the destination. The order in which the server transfers the request to the approver at the destination may be determined based on the order of approval from the users specified as the destinations.

[0135] In step S633, the server 20 receives information indicating that a contract will be concluded for the contract data from the user of the first business, and updates various information such as the approval history 2024 and the electronic contract management database 2021.

[0136] Upon receiving information indicating that a contract will be concluded from each user who is an approver at the first business, the server 20 transmits information indicating that the contract has been concluded to the user of the second business and the user of the first business (for example, the email addresses of users involved as senders or receivers in concluding an electronic contract). For example, the server 20 transmits a message to the email address of the user of the first business notifying that the work of concluding the contract has been completed on the side of the user of the second business, including link information for viewing the documents that are the subject of the contract.

[0137] In step S602, the sender terminal device 30 presents the result of the completion of the electronic contract conclusion to the user of the second business by, for example, displaying information on a display. As a result of the above, the server 20 assumes that an agreement has been reached between the first business operator and the second business operator regarding the contract data, and manages the contract data based on various databases.

[0138] FIG. 7 is a diagram showing the flow of processing for determining the domain of an email address when concluding a contract, and processing using the determined result.

[0139] The server 20 determines the domain of the email address by comparing the email addresses of each user who is a party to the contract. Determining the domain of an email address means comparing the domain parts of the email address of a user of the second business with the domain parts of the email address of a user of the first business to determine whether they are different domains. Details of how the domain parts of email addresses are compared and determined will be described later in the explanation of step S732.

[0140] Next, we will explain the purpose of determining the domain of an email address. When concluding a contract, the server 20 automatically determines the sender and recipient from their email addresses, making it possible to determine the number of senders and recipients. At that time, the recipient can also adjust the number of approvers on their side to match the number of senders.

[0141] As a premise, if the number of senders is large, it is highly likely that the contract data is being checked by many people on the sender's side, and is therefore highly likely to be an important document. In this case, the receiver can match the number of approvers on the receiver's side to the number of senders, allowing important documents to be carefully reviewed by multiple people. This case will be described later in Variation (1).

[0142] In this way, by determining the email address domain, it is possible to process the above cases.

[0143] Furthermore, by comparing the domain part of the sender's email address with the domain part of the recipient's email address, it is possible to determine whether the sender's user and the recipient's user are different businesses, the same business, or businesses in the same affiliation, such as a parent-child relationship. For example, by previously associating the domains of the email addresses of businesses in the same affiliation and storing them in a storage unit, it is possible to determine whether the sender and recipient are businesses in the same affiliation (for example, whether a contract is concluded between a parent company and a subsidiary company).

[0144] For example, if the sender and recipient are the same business, it may be possible to approve the contract data via electronic contract after first going through approval process within the business. In this case, it is assumed that there is little concern about unauthorized representation, and the following may be done.

[0145] If the server 20 determines that the sender and receiver users are users of the same business (the domain part of the email address is the same for the sender and receiver), even if a user who will be the approver is set in the forwarding destination approver setting 2023, the server 20 may not forward the data to the user who will be the approver, and may manage the data as if the contract data has been agreed upon by the user designated by the sender who has approved it. In the above case, the business operator may forward the request to at least some of the approver users set in the forwarding destination approver setting 2023, such as forwarding to users with a specific job title.

[0146] In step S732, the server 20 compares the email address of the recipient user with the email address of the sender user to determine whether the domain parts are different. If the domain parts are different, the server 20 distinguishes the recipient and sender as users belonging to different organizations, and presents the distinguished result to each user on the sender and recipient side.

[0147] For example, suppose the email address of a user of a second business is xxx@abcde.co.jp, and the email address of a user of a first business is xxx@efghi.co.jp. In this case, when server 20 compares the domain parts of both email addresses, it is found that the domain part of the email address of the user of the second business is @abcde.jp, while the email address of the user of the first business is @efghi.jp, which are different. If the domain parts of the email addresses are different, it is highly likely that the people are not from the same company. This is because corporations (companies) often have their own domains, and it is highly likely that their employees use email addresses that use the corporation's own domain.

[0148] Therefore, if it is determined that the domain parts are different, and one is the sender side and the other is the recipient side, it is possible to distinguish between the sender side and the recipient side as being from different businesses. In this case, the server 20 can distinguish the email address of the user of the second business as the sender side and the email address of the user of the first business as the recipient side.

[0149] As described above, the server 20 presents the results of distinguishing between contracting parties who will conclude an electronic contract and who belong to different affiliations to at least one of the users of the first business operator and the second business operator.

[0150] As described above, the server 20 allows each approver to view the contract data and requests approval based on the approver information at the time of transmission 2022 and the approver setting at the transfer destination 2023.

[0151] <Screen example> FIG. 8 is a diagram showing a situation in which a user checks contract data on the terminal of an approver of a first business.

[0152] The screen example in Fig. 8 is a screen that the recipient's terminal device 10 presents to the user of the recipient's terminal device 10 to accept an operation indicating consent to the contract data, and accepts an operation for consent from the user. This corresponds to the processing of steps S651, S652, etc. in Fig. 6, etc. Details will be explained in the next section.

[0153] The contract approver can click on the link in the email received on the recipient's terminal device 10, check the contents of the contract data on the server 20 online via a browser or the like, and conclude an agreement. The recipient's terminal device 10 presents a screen for accepting an operation indicating agreement to the contract to the user of the recipient's terminal device 10, and accepts an operation for agreement from the user.

[0154] Furthermore, when the server 20 receives an operation from the contract recipient agreeing to the contract data, the server 20 affixes the contract recipient's digital signature to the contract data. The contract data is stored in the server 20. The affixing of digital signatures from both contracting parties prevents the contract from being tampered with.

[0155] For example, we will explain a situation in which the receiver's terminal device 10 of the receiver "Co., Ltd. B" accepts input operations to request the conclusion of a contract between the sender "Co., Ltd. A" and the receiver "Co., Ltd. B." The sender "Co., Ltd. A" is the sender side, and the receiver "Co., Ltd. B" is the receiver side.

[0156] Furthermore, the sender, "A Co., Ltd.", inputs an operation to specify the email address of the user "Mshita Maki" of the receiver, "B Co., Ltd.", thereby specifying "Mshita Maki" as the contract recipient.

[0157] Assume that the approver for the receiver "B Co., Ltd." is set in the forwarding approver settings 2023 in the server 20. The server 20 accepts an operation to conclude an agreement from the sender terminal device 30 of the sender "A Co., Ltd.", with the user of the receiver "B Co., Ltd." specified by the sender of the sender "A Co., Ltd." The server 20 transfers a request for concluding an agreement to the user "Nzawa Tyuki" who is set in the forwarding approver settings 2023 as the approver for the receiver "B Co., Ltd."

[0158] At this time, the receiver terminal device 10 of the user "Nzawa Tyuki" who is set as the approver will present the following information to the user, allowing the user to easily decide whether or not to perform an operation to agree to the contract conclusion. - Information about the sender's business, with which the contract is concluded Information about users of the other business to whom the contract data that is the subject of the contract is transmitted - Contents of contract data that are the subject of the contract (document data of contract documents, etc.) - Information on the recipient user (first user) specified by the sender's business (information on the source of the contract document)

[0159] Specifically, the receiver's terminal device 10 of the user displays the following information on the dialog screen 810: Message 810A: This is an area for displaying a message to prompt the user to confirm and approve the contract documents. Message 810B: This is an area for displaying the information of the user from whom the contract data is transferred when the contract data is transferred because the user is set in the transfer destination approver setting 2023. This allows the user who is set as the approver in the transfer destination approver setting 2023 to easily check the information of the user who is designated by the sender as the recipient of the contract data. For example, it is possible to easily check which department in the business company the contract data was sent to by the sender. Area 810C: This area displays the contents of the contract document that is the subject of the contract. In area 810C, the recipient's terminal device 10 displays the type of contract document (for example, various types of contracts such as a confidentiality agreement or a business outsourcing agreement), the names of the contracting parties, the clauses of the contract document, etc. Button 810D: This is an area for accepting an operation to approve the contract documents from the second user after checking the contract documents.

[0160] The user checks the information presented on the dialog screen 810 and determines whether or not to agree to the contract data.

[0161] In response to receiving an input operation on the button 810D from the user, the receiver's terminal device 10 transmits information indicating that the user has approved the contract data to the server 20 (S652).

[0162] Figure 9 shows how to set the approver for contract data on the terminal of a user of the first business operator. By being able to set the approver on the recipient side in an electronic contract, it becomes possible to prevent unauthorized representation when a recipient without decision-making authority is set.

[0163] How the first business sets the approver of the contract data may be determined based on the relationship between the user who will be the approver at the first business and the user who will be the recipient of the contract at the first business. For example, if the recipient of the contract at the first business is a sales staff member, the approvers at the first business may be the sales manager and deputy sales manager, and the approval flow may be set internally in accordance with the relationships within the same department. Also, an approval flow refers to a series of procedures by which the approver of an electronic contract gives consent. Specific examples will be described later.

[0164] As described above, the server 20 may manage the user who will be the approver of the contract in the transfer destination approver setting 2023 according to the attributes (department, position, etc.) of the user who will be the recipient of the contract.

[0165] How the first business operator sets the approver may be determined based on the relationship between the approver of the first business operator and the content of the contract data. The content of the contract data is determined by reading the contract data (e.g., PDF data) using OCR (or by storing the results of character recognition processing in advance in a memory unit) and reading the content of the contract data as text.

[0166] Then, machine learning is performed based on the contract data and the results of reading the contents of the contract data to generate a trained model.

[0167] This enables the server 20 to determine the type of contract data based on the contract data and the trained model. The server 20 may also store a table for determining the content of the contract data according to the results of reading the contract data, and determine the type of contract content of the contract data (such as a confidentiality agreement or a service agreement) based on the results of reading the content of the contract data and the table.

[0168] In addition, the server 20 may store a table for determining department information according to the results of reading the contract data, and determine which department the contract data is intended for based on the results of reading the contents of the contract data and the table.

[0169] For example, suppose the title of the contract data is "Invoice to the Sales Department of Co., Ltd. A." In this case, the contract data is first read using OCR, and then, based on the read text and the trained model, it can be determined which department the contents of the contract data belong to. For example, since the title of a document showing the contents of the contract data is "Invoice to the Sales Department of Co., Ltd. A," it can be determined that the contents of the contract data relate to the sales department. By implementing the above, the server 20 can determine which business department the contents of the contract data belong to.

[0170] For example, if the content of the contract data is a document related to the sales department, the approvers of the first business entity may be set based on the degree of relevance to the content of the contract data, such as the sales manager and deputy sales manager. The approval flow for the contract document may be set within the company using the approvers set in this way. A specific example will be described later.

[0171] For example, a case will be described in which a certain company, "Corporation C," has established internal rules for how to set approvers for contract data. Assume that a part of the approver settings is displayed on the document screen 910 of "Corporation C."

[0172] At this time, the document screen 910 displayed on the terminal device of the user of "C Corporation" presents the following information to the user, allowing the user to easily determine how to set the approver for the contract data at "C Corporation." - The approver is determined based on the user who received the contract document or the organization to which the user belongs. - The approver is determined based on the contents of the contract documents.

[0173] Specifically, the server 20 displays the following information on the document screen 910 of the terminal device of "Corporation C". Message 910A: This is an area that displays the arrangement for setting the approver based on the information of the user who will receive the contract from Company C. Message 910B: This is an area that displays the arrangement for setting the approver based on the information in the contract data.

[0174] FIG. 10 is a diagram showing a situation in which the approver flow of contract data is displayed on the terminal of the approver of the first business.

[0175] The server 20 transmits data necessary for the electronic contract to the recipient's terminal device 10 as appropriate, and visualizes the status of the electronic contract on the recipient's terminal device 10 by accepting operations by the recipient's user.

[0176] By visualizing the status of an electronic contract (for example, the status of an electronic signature being made by the approver's user approving), the approver of the first business can know which of the approver's users of the first business has not yet approved the contract data when there are multiple approvers. As a result, the approver of the first business can urge the approver who has not yet approved the contract data to take some kind of action, which also leads to faster conclusion of the contract data.

[0177] For example, let us consider a situation where a sender, "Company A," requests a receiver, "Company B," to conclude a contract, and an approver at the receiver, "Company B," approves the documents for the contract data. The sender, "Company A," is the sender side, and the receiver, "Company B," is the receiver side. In this case, for the receiver, "Company B," there are four approvers for the contract data at Company B: Approver A, Approver B, Approver C, and Approver D.

[0178] The approver's terminal device displays a visualized version of the electronic contract status of the contract data on its screen. The approver's terminal device also displays information on which approvers have approved the contract data (whether they have signed) and which approvers have not yet approved the contract data.

[0179] Specifically, the receiver-side terminal device 10 of approver B of the receiver "Co. B" on the receiver side presents the following information on a dialogue screen 1010. Message 1010A: This is an area that displays the contents of the contract data. Area 1010B: An area for displaying the approval status of the contract data. Message 1010C: This is an area for displaying the approval status of the contract data as of a certain point in time.

[0180] FIG. 11 is a diagram showing the signature data of the contract data after the contract has been concluded.

[0181] When concluding an electronic contract, the server 20 stores data related to the signature (hereinafter referred to as signature data) in the contract data. The signature data allows those involved in concluding the contract to confirm information such as "when and who approved the contract documents" and "whether the approval record is still valid."

[0182] For example, let us consider a situation after the conclusion of a contract between the receiver "Company A" and the sender "Company B" for the contract data is completed. The sender "Company B" is the sender side, and the receiver "Company A" is the receiver side. Let us assume that an approver A of the receiver "Company A", who is on the receiver side, accepts an operation to present the signature data of the contract data on the receiver's terminal device 10.

[0183] At this time, the receiver-side terminal device 10 of approver A presents the following information to the user on a dialogue screen 1110: Area 1110A: This is an area for displaying the contents of the contract data. Message 1110B: This is an area for notifying the user when all signatures in the contract data are valid. Area 1110C: This is an area where the information of the signature data can be confirmed. The user can check information such as "when and which approver agreed to the contract" and "whether the approval record is still valid."

[0184] FIG. 12 is a diagram showing partially anonymized signature data in contract data after the conclusion of the contract.

[0185] As described above, the server 20 manages the contract data as if an agreement had been reached between the contracting parties, information about the user who approved the contract data, and information about the timing of the user's approval, in association with each other in the approval history 2024, etc.

[0186] In response to a request from a user to view contract data, the server 20 may present the contract data to the user who made the request without allowing the user to view at least one of the information about the user who gave approval and the information about the timing at which the user gave approval, which is information stored in association with the contract data.

[0187] Regarding how to identify users to be anonymized, the sender may accept from each user information about users that the receiver wishes to anonymize, or the receiver may accept from the sender information about users that the sender wishes to anonymize.

[0188] The server 20 may accept from the user the designation of users to be anonymized, but may not accept the designation of anonymization for certain users, such as the user with the highest position, and may instead disclose the users' names to the contracting parties. This allows the contracting parties to easily confirm whether the contract has been approved by an authorized user.

[0189] The server 20 stores signature data for the contract data when concluding an electronic contract. The signature data may be partially anonymized by setting it. By partially anonymizing the signature data, it becomes difficult to guess the approval order, which has the effect of reducing the scope of disclosure of the company's approval flow to other organizations.

[0190] For example, let us consider a situation after a contract has been concluded between the receiver "Company A" and the sender "Company B." The sender "Company B" is the sender side, and the receiver "Company A" is the receiver side. Let us assume that an approver A of the receiver "Company A," who is on the receiver side, accepts an operation to present the signature data of the contract data on the receiver's terminal device 10.

[0191] At this time, the receiver-side terminal device 10 of approver A presents the following information to the user on a dialogue screen 1210: Area 1210A: An area for displaying the contents of the contract data. Message 1210B: This is an area for notifying the user when all signatures in the contract data are valid. Area 1210C: This is an area where information about the signature data can be confirmed. The user can check information such as "when and which approver agreed to the contract" and "whether the approval record is still valid." However, some of the signature data is anonymized on the screen.

[0192] FIG. 13 is a diagram showing recommended people to be included as approvers in the approval flow for contract data, based on the history of past electronic contract conclusions.

[0193] When concluding an electronic contract, the first business must set an approver for the contract data. However, determining which person is the appropriate approver for which contract data is a burdensome task. This is because, if the approver is determined by a human, it is necessary to constantly keep track of which person within the first business has what authority and assign them accordingly.

[0194] For the first business operator, the system may be able to assist in deciding on an approver by recommending approvers based on the history of past electronic contract conclusions.

[0195] For example, we will explain a situation in which a terminal of the receiver "Co., Ltd. B" accepts an operation to conclude contract data between a user of the sender "Co., Ltd. A" and the receiver "Co., Ltd. B." The sender "Co., Ltd. A" is the sender side, and the receiver "Co., Ltd. B" is the receiver side.

[0196] The recipient company "Co., Ltd." needs to consider who should approve the contract data and then conclude the contract data. Therefore, the server 20 may recommend an appropriate approver to be incorporated into the approval flow based on the past history of electronic contract conclusions, and present the information of the appropriate approver to the company's user.

[0197] For example, suppose the content of the contract data is related to sales, and there are multiple past electronic contract histories that are very similar to the content of the contract data.

[0198] An example of determining the content of contract data is described in the explanation of Figure 9. The similarity of the content of contract data can also be determined by looking at the title of the contract data. For example, suppose there is contract data titled "Invoice to the Sales Department of Co., Ltd. A, May 2021" and contract data titled "Quotation to the Sales Department of Co., Ltd. A, June 2021." In this case, the former and latter titles differ only in the year and month, and all other wording is the same, so they can be determined to be similar. As described above, it is possible to determine the similarity of the content of contract data by looking at the title of the contract data.

[0199] Suppose that among the multiple electronic contract histories, all of them show that Mr. Tanaka from the sales department was involved as an approver. In this case, the server 20 determines that Mr. Tanaka from the sales department is also an appropriate approver for the current contract data, and displays information about the appropriate approver on the screen of the user of the recipient's business operator, "Company B."

[0200] At this time, the receiver-side terminal device 10 of approver B presents the following information to the user on a dialogue screen 1310: Area 1310A: An area for displaying the contents of the contract data. Message 1310B: This is an area for displaying the approver's recommendation information. Area 1310C: This area is for displaying past electronic contract history, which is very similar to contract data.

[0201] <Modification> (1) Identify the number of people required to conclude a contract based on the number of parties involved in the contract. The server 20 may evaluate the number of users involved in the contract conclusion for each of the two parties by determining the number of users on the sender side or the number of users on the receiver side, and present the evaluation results to each user.

[0202] For example, the server 20 determines the number of users on the sender's side who will be involved in the conclusion of the electronic contract by acquiring information on users on the sender's side. Based on the result of the determination, the server 20 may identify the number of users on the receiver's side who will be involved in the conclusion of the electronic contract, and present the identified result to at least one of the users on the receiver's side or the users on the sender's side.

[0203] For example, the server 20 may suggest to the sender with a larger number of people that they reduce the number of people, or to the receiver with a smaller number of people that they increase the number of people, so that the difference in the number of people between the sender and receiver is within a certain range (for example, the difference in the number of people between the sender and receiver is zero or within a certain value), and so that the difference in the number of people involved in concluding a contract on each side is within a certain range.

[0204] For example, the server 20 may present a proposal to each user on the sender or receiver side to increase or decrease the number of people involved in the contract conclusion at the following times: A step of approving the contract documents (e.g., step S652) A step of transferring data of the document to be contracted to a user who is set as having the authority to conclude the contract (step S632). The stage where the sender uploads the contract documents to be used for the contract (step S601, etc.)

[0205] Details of determining the number of senders from email address information are provided in the explanation of FIG.

[0206] If the sender has a large number of people, it means that many people are involved in checking the contract data on the sender's side, and it is highly likely that the document is important. In this situation, the receiver can match the number of approvers on the receiver's side to the number of senders, allowing multiple people to carefully review important documents.

[0207] The more people involved in the conclusion of a contract, the more careful the contract is likely to be. Therefore, by structuring it as described above, the level of caution of both parties can be aligned, reducing discrepancies in understanding the importance of the contract.

[0208] <Modification> (2) Estimate the approver's position The server 20 may determine the job title of the user who has approved the contract data on the recipient's side based on the order of approval of the multiple users who have approved the contract data.

[0209] The server 20 may extract candidates for users to be set as approvers in the transfer destination approver setting 2023 in the recipient's group based on the result of determining the job title.

[0210] In step S633, the server 20 may estimate the job title (such as "department manager" or "president") of each approver, evaluate the effectiveness of the approver based on the estimation result, and present it to the user on the sending side. The estimated job title will be referred to as the "estimated job title" below.

[0211] When concluding a contract, it is common to determine the approval flow based on internal job titles. An approval flow refers to the series of procedures that an approver of an electronic contract must follow to give their consent. Evaluating the effectiveness of the approver increases the likelihood of creating a smooth approval flow when concluding a contract. Therefore, by configuring it as described above, it is possible to create logic that can determine the appropriate person with decision-making authority when there are multiple candidates for approver (such as "president," "director," or "division manager").

[0212] The job title may be estimated based on the information in the forwarding approver setting 2023, the approval history 2024, and the contents of the contract data. For example, if Tamura is in the sales department and there is a history of him always approving contract data related to the sales department at the end of the approval flow, it can be determined that Tamura's estimated job title may be highly likely to be the sales manager.

[0213] As described above, the server 20 estimates the user's job title in the following manner. By referring to the Electronic Contract Management Database 2021 and Approval History 2024, users who are designated as contracting parties on the sender or receiver side at a high rate when concluding contract data are assumed to have a position. By referring to the Electronic Contract Management Database 2021 and Approval History 2024, when concluding contract data, the sender or receiver side estimates whether the user has a position and the level of the position based on the order of approval (for example, whether the approval order is later or the user who approves last). For example, the last person in the approval order estimates a higher position (for example, president, department manager, etc.).

[0214] <Modification> (3) Determine the appropriate person with decision-making authority In step S631, the server 20 may acquire the job title information and effectiveness information of multiple approvers, determine the appropriate decision-maker on the recipient side of the contract conclusion, and present information on the appropriate decision-maker to the user on the recipient side based on the determination result. Details of this modification, such as an example, are given in the description of FIG.

[0215] In the approval flow, it is necessary to carefully decide who to set as the approver. Therefore, by configuring as described above, the server 20 can present the appropriate person with the decision-making authority based on the approver's job title information and effectiveness information.

[0216] <Modification> (4) Recommend appropriate decision-makers The server 20 may extract candidate users to be set as approvers based on the history of contract conclusions made by the sender or receiver group, and may present the user with information suggesting that the extracted candidate users be included as users who will conclude the contract. For example, the server 20 may extract candidate users to be set as approvers in the receiver's group based on the history of contract conclusions made by the receiver's group, and present information to the users in the receiver's group suggesting that the extracted candidate users be included in the conclusion of a contract with the sender's user. Details of this modification, such as an example, are given in the description of FIG.

[0217] Therefore, by configuring it as described above, it is possible to recommend who should be included in the workflow as the decision maker based on the history of past contract conclusions, which can be helpful when deciding on an approval flow. An approval flow refers to a series of procedures in which an approver of an electronic contract gives their consent.

[0218] (5) Notification regarding request for contract conclusion As described above, when concluding a contract, the user on the sending side approves the contract data that is the subject of the contract by specifying the user on the receiving side, and the contract data is managed on server 20, assuming that the approving user has affixed an electronic signature to the contract data.

[0219] The server 20 may notify each user of the conclusion of the contract as follows. If the server 20 determines that the recipient user designated by the sender user does not have the authority to conclude a contract (the recipient user is not set as an approver in the forwarding destination approver settings 2023), the server 20 notifies a user with the authority to approve the contract, requesting the conclusion of the contract. For example, the server 20 sends an email containing a request for conclusion of the contract and a link to confirm the contract data to the email address of the authorized user, or displays the contents of the notification when the user logs in to the electronic contract system provided by the server 20. If the server 20 determines that the recipient user designated by the sender user does not have the authority to enter into a contract, the server 20 notifies the user designated by the sender user that the user does not have the authority to enter into a contract, notifies the user that the data has been forwarded to a user (recipient user) who has the authority to enter into a contract, or gives other notifications to the user. The server 20 may distinguish between information about users on the recipient side who do not have approval authority and information about users who do have approval authority and present this information to the sender side user. For example, if a recipient side user designated by the sender side user does not have approval authority, the server 20 may display to the sender side user a message indicating that the designated recipient side user does not have approval authority, while also displaying a message indicating that the document has been forwarded to a user who has approval authority. For example, the sender side user may be notified of users who do not have approval authority and users who have been forwarded and have approval authority in different ways by sending an email to the sender side user or by displaying this information on a screen when the sender side user accesses the electronic contract system.

[0220] (6) Method of designating users for contract execution The server 20 manages user information for each user to log in, in order to provide the electronic contract system to each user (or to a business to which multiple users belong). For example, the server 20 manages information such as the user name, user email address, and user company name displayed in the electronic contract system. In this way, the server 20 manages, for each business, the information of users belonging to that business.

[0221] Here, when a sender user designates a recipient user for contract conclusion, the server 20 may accept designation of information that identifies the user in the electronic contract system (for example, user account information (such as an ID in the electronic contract system)). The server 20 may identify an email address associated with the account information of the user designated as the recipient user, and send an email to that email address containing a request to conclude the contract and a link for confirming the contract data.

[0222] In addition, when a sender user specifies an account of a recipient user, the server 20 may determine whether the user associated with the account has approval authority by comparing the email address associated with the account with the email address of a user registered as having approval authority, such as in the forwarding destination approver setting 2023.

[0223] As described above, even if the sender user specifies information other than an email address to identify the recipient, it is possible to determine whether each user has approval authority by comparing it with the email address information of each user stored in server 20.

[0224] Although several embodiments of the present disclosure have been described above, these embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and modifications are intended to be included in the scope of the inventions and their equivalents as defined in the claims, as well as in the scope and spirit of the inventions.

[0225] <Additional Notes> The matters described in the above embodiments will be supplemented below. (Appendix 1) A program for operating a computer (20), the computer being used to conclude an electronic contract between a plurality of corporate or individual users, the program includes a step of receiving, in a processor (29) of the computer, a setting (2023) of a first user who will be an approver when concluding an electronic contract in a first group made up of a plurality of users, a step (S601) of receiving, from a second user different from the users of the first group, information identifying a user of the first group and contract data to be the subject of concluding an electronic contract with the first group, and a step of receiving, in a case where a first user who will be an approver in the first group is not set, the second user a step (S632) of requesting a user who is more specified by the first user to operate to approve the conclusion of a contract for the contract data, when a first user who is to be the approver in the first group is set, regardless of whether the first user is included in the information of users specified by the second user; and a step (S633) of managing the contract data in a computer by accepting the approval operation from the requested user, assuming that an agreement has been reached between the first group and the second user or a second group including the second user regarding the contract data.

[0226] (Appendix 2) The program of claim 1, wherein in the step of accepting contract data, information on the user of the first group and the second user is obtained, and the email addresses of the user of the first group and the second user are compared to determine that the first group and the second user are contracting parties belonging to different parties (S732).

[0227] (Appendix 3) The program of claim 2, wherein in the step of accepting contract data, the email address of the user of the first group is compared with the email address of the second user to determine whether the domain parts are different, thereby distinguishing whether the contracting parties entering into the electronic contract belong to different parties, and presenting the distinguished result to at least one of the user of the first group or the second user (S732).

[0228] (Appendix 4) The program according to claim 2, wherein in the step of accepting contract data, the number of second users involved in the conclusion of the electronic contract is determined by obtaining information about the second users, and based on the result of the determination, the number of users in the first group who should be involved in the conclusion of the electronic contract is identified, and the identified result is presented to at least one of the users in the first group or the second users.

[0229] (Appendix 5) 2. The program according to claim 1, wherein in the managing step, the job title of the user who has approved the contract data is determined based on the approval order of the multiple users in the first group who have approved the contract data (2023).

[0230] (Appendix 6) 6. The program according to claim 5, wherein in the managing step, candidates for a user to be set as the first user in the first group are extracted based on a result of determining the position (2023).

[0231] (Appendix 7) The program of claim 1, wherein in the managing step, candidate users to be set as the first user are extracted based on the history of contracts concluded by the first group, and information suggesting that the extracted candidate users be included as users who will conclude a contract with the second user is presented to the users of the first group (1310B).

[0232] (Appendix 8) The program according to claim 1, wherein in the managing step, the contract data to be managed as if an agreement had been reached, information on the user who approved the contract data, and information on the timing of the user's approval are associated and stored in the memory unit (2024).

[0233] (Appendix 9) The program of claim 8, wherein in the managing step, in response to a request to view the contract data, the contract data is presented to the user who made the request without allowing them to view at least one of information about the user who gave approval and information about the timing at which the user gave approval, which information is stored in association with the contract data (1210C).

[0234] (Appendix 10) A method for operating a computer, the computer being configured to conclude an electronic contract among a plurality of corporate or individual users, the method comprising the steps of: receiving, by a processor of the computer, a setting of a first user who will be an approver when an electronic contract is concluded in a first group consisting of a plurality of users; receiving, from a second user different from the users of the first group, information identifying a user of the first group and contract data to be the subject of an electronic contract to be concluded with the first group; if a first user who will be an approver in the first group has not been set, requesting a user specified by the second user to perform an operation to approve the conclusion of the contract data; if a first user who will be an approver in the first group has been set, requesting the first user to perform an operation to approve the conclusion of the contract data, regardless of whether the first user is included in the information of users specified by the second user; and, by accepting the approval operation from the requested user, managing the contract data in the computer, assuming that an agreement has been reached regarding the contract data between the first group and the second user or a second group including the second user.

[0235] (Appendix 11) an information processing device having a control unit, the information processing device for concluding an electronic contract among a plurality of corporate or individual users, the control unit executing the following steps: accepting, in a first group consisting of a plurality of users, a setting of a first user who will be an approver when concluding an electronic contract; accepting, from a second user different from the users of the first group, information identifying a user of the first group and contract data that is the subject of concluding an electronic contract with the first group; when a first user who will be an approver in the first group has not been set, requesting a user identified by the second user to perform an operation to approve the conclusion of a contract for the contract data; when a first user who will be an approver in the first group has been set, requesting the first user to perform an operation to approve the conclusion of a contract for the contract data, regardless of whether the first user is included in the information of users identified by the second user; and, by accepting the approval operation from the requested user, managing the contract data in a computer, assuming that an agreement has been reached on the contract data between the first group and the second user or a second group including the second user. [Explanation of symbols]

[0236] 1: Electronic contract system, 10: Recipient side terminal device, 12: Communication IF, 13: Input device, 14: Output device, 15: Memory, 16: Storage unit, 19: Processor, 20: Server, 22: Communication IF, 23: Input / output IF, 25: Memory, 26: Storage, 29: Processor, 30: Sender side terminal device, 32: Communication IF, 33: Input device, 34: Output device, 35: Memory, 36: Storage unit, 39: Processor, 80: Network, 111: Antenna, 121: First wireless communication unit, 130: Operation reception unit, 132: Display, 140: Audio processing unit, 141: Microphone, 142: Speaker, 161: Electronic contract management information, 162: Approver information at time of sending, 163: Approver setting at forwarding destination, 164: Approver history, 191: Input operation reception unit, 192: Transmitting / receiving unit, 193: Data processing unit, 194: Notification control unit, 201: Communication unit, 202: Storage unit, 203: Control unit, 2021: Electronic contract management database, 2022: Approver information at time of sending, 2023: Approver setting at forwarding destination, 2024: Approver history, 2031: Reception control module, 2032: Transmission control module, 2033: Electronic contract information acquisition module, 2034: Approver user information acquisition module, 2035: Approver date and time information acquisition module

Claims

1. A program for operating a computer, the computer is for concluding an electronic contract among a plurality of users who are corporations or individuals, The program causes the processor of the computer to: a step of accepting a setting of a first user who will be an approver when concluding the electronic contract in a first group made up of a plurality of users; receiving, from a second user different from the users of the first group, information identifying the users of the first group and contract data that is the subject of the electronic contract to be concluded with the first group; a step of requesting a user specified by the second user to perform an operation to approve the conclusion of the contract data when the first user who will be the approver is not set in the first group; When the first user who will be the approver is set in the first group, requesting the first user to perform an operation to approve the conclusion of the contract data, regardless of whether the first user is included in user information specified by the second user; receiving the approval operation from the requested user, the computer regards the contract data as having been agreed upon between the first group and the second user or a second group including the second user; and managing the contract data in the computer; A program that, in a step of requesting the first user to operate to approve the conclusion of a contract for contract data, presents information of a user identified by the second user to the first user who is set as the approver.

2. In the step of requesting the first user to operate to approve the conclusion of the contract data, The program according to claim 1, wherein an operation screen is presented to the first user set as the approver, the operation screen including both information about the user identified by the second user and an operation member for accepting an operation to confirm and approve the contract data.

3. A program as described in claim 2, wherein, in a step of requesting the first user to perform an operation to approve the conclusion of a contract for contract data, information about the second user or a second group including the second user is displayed on the operation screen.

4. 1. A method of operating a computer, comprising: the computer is for concluding an electronic contract among a plurality of users who are corporations or individuals, The method further comprises: a step of accepting a setting of a first user who will be an approver when concluding the electronic contract in a first group made up of a plurality of users; receiving, from a second user different from the users of the first group, information identifying the users of the first group and contract data that is the subject of the electronic contract to be concluded with the first group; a step of requesting a user specified by the second user to perform an operation to approve the conclusion of the contract data when the first user who will be the approver is not set in the first group; When the first user who will be the approver is set in the first group, requesting the first user to perform an operation to approve the conclusion of the contract data, regardless of whether the first user is included in user information specified by the second user; receiving the approval operation from the requested user, and managing the contract data in the computer, assuming that an agreement has been reached between the first group and the second user or a second group including the second user regarding the contract data; A method in which, in a step of requesting the first user to approve the conclusion of a contract for contract data, information of a user identified by the second user is presented to the first user who is set as the approver.

5. An information processing device including a control unit, the information processing device is for concluding an electronic contract among a plurality of users who are corporations or individuals, The control unit a step of accepting a setting of a first user who will be an approver when concluding the electronic contract in a first group made up of a plurality of users; receiving, from a second user different from the users of the first group, information identifying the users of the first group and contract data that is the subject of the electronic contract to be concluded with the first group; a step of requesting a user specified by the second user to perform an operation to approve the conclusion of the contract data when the first user who will be the approver is not set in the first group; When the first user who will be the approver is set in the first group, requesting the first user to perform an operation to approve the conclusion of the contract data, regardless of whether the first user is included in user information specified by the second user; receiving the approval operation from the requested user, and managing the contract data in the information processing device, assuming that an agreement has been reached between the first group and the second user or a second group including the second user regarding the contract data; An information processing device that, in a step of requesting the first user to operate to approve the conclusion of a contract for contract data, presents information of a user identified by the second user to the first user who is set as the approver.

Images