JP2023111804A - Program, method and information processing device - Google Patents

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

The present disclosure relates to programs, methods, and information processing apparatuses.

In business activities, various agreements and applications are approved inside and outside the company to advance the business. For example, within the company, an approver makes a final decision on the content to be approved. In Japanese Patent Application Laid-Open No. 2013-178842 (Patent Document 1) below, a plurality of authorizers are set for electronic document data indicating the content of an application for the purpose of smoother approval processing within the company. In this case, skip authority is given to skip the approval process by the approver on the approval path.
In addition, with regard to contracts inside and outside the company, in recent years, due to the development of IT technology, contracts that have been concluded on paper until now are gradually being executed by electronic contracts.

In an electronic contract, a user of an electronic contract service electronically signs a document or the like to be signed. Electronic contract services are provided by business operators in various ways, such as so-called party signature type and so-called business signature type (witness type).
When a contract is concluded using an electronic contract service, information specifying the parties to the contract may be used to allow the parties to the contract to view the document data to be contracted while proceeding with the conclusion work. For example, when proceeding with the conclusion of a contract using e-mail addresses as information identifying the parties to the contract, one of the parties desiring to conclude the contract sends the contract data to the electronic contract service while specifying the e-mail address of the other party. Then, the person (or the receiving company) who receives the contract data uses the electronic contract service to approve the contract data and proceed with the work of concluding an electronic contract.

JP 2013-178842 A

However, when proceeding with the conclusion of an electronic contract while designating an approver involved in the conclusion work between the parties to the contract, a person who does not have the authority to conclude the contract is designated as the approver. There may be a situation where the conclusion work is performed by an unauthorized agent by. If such unauthorized agency is possible, even if the electronic contract service is used, the reliability of the concluded contract may decline, and the use of the electronic contract service itself may not be encouraged.

Therefore, in the electronic contract service, there is a need for a technique that can prevent unauthorized representation by an unauthorized person.

According to one embodiment shown in the present disclosure, a program is provided for operating a computer. The computer is for executing an electronic contract between a plurality of corporate or individual users, and the program instructs the processor of the computer to conclude an electronic contract in a first group composed of a plurality of users. a step of receiving settings of a first user who will be an actual approver; information identifying the first group of users from a second user different from the first group of users; a step of receiving contract data to conclude an electronic contract; a step of requesting an operation to approve the conclusion of a data contract; irrespective of whether or not the user of the contract 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 data, managing the contract data in a computer.

According to the present disclosure, an appropriate approver can be set on the receiver side of the electronic contract service, so that unauthorized proxy can be suppressed when a receiver without decision-making authority is set.

It is a figure showing the whole electronic contract system 1 composition of an embodiment. 2 is a block diagram showing a functional configuration of a receiver-side terminal device 10; FIG. 2 is a block diagram showing a functional configuration of server 20. FIG. It is a conceptual diagram for explaining an electronic contract. Reference numeral 2021 in FIG. 5 shows the data structure of the electronic contract management database 2021. FIG. Reference numeral 2022 in FIG. 5 shows the data structure of the approver information 2022 at the time of transmission. Reference numeral 2023 in FIG. 5 shows the data structure of the forwarding destination approver setting 2023 . Reference numeral 2024 in FIG. 5 shows the data structure of the approval history 2024. As shown in FIG. It is a figure which shows the flow of related processing of contract conclusion. FIG. 10 is a diagram showing a flow of processing for determining a domain of an email address in conclusion of a contract and processing using the determination result; FIG. 10 is a diagram showing a phase in which contract data is confirmed on the terminal of the approver of the first business operator; FIG. 10 is a diagram showing how to set an approver of contract data in the terminal of the user of the first business operator; FIG. 10 is a diagram showing an approver flow of contract data on the approver's terminal of the first business operator; It is a figure which shows the signature data of the contract data in which agreement conclusion was completed. FIG. 10 is a diagram showing partially anonymized signature data of an approver in the contract data for which the conclusion of an agreement has been completed; FIG. 10 is a diagram showing a recommendation of a person to be included as an approver in the contract data approval flow based on past approval histories of electronic contracts.

Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In the following description, the same parts are given the same reference numerals. Their names and functions are also the same. Therefore, detailed description thereof will not be repeated.

<Overview of First Embodiment>
In this embodiment, a user operates a PC (personal computer) and concludes a contract using an electronic contract service. In the electronic contract, contract data subject to the conclusion of the electronic contract, which is the content agreed upon by the parties to the contract, is approved by both parties to proceed with the conclusion of the contract.

The contract data includes, for example, data created at least as follows, based on contract terms agreed upon by both parties.
・ Contract data created by software for creating documents ・ Data that associates each item of contract conditions with the content agreed upon by both parties for each item

An electronic contract has one or more approvers for approving contract data. Based on the contract data, the approver determines whether or not the contract can be concluded under the conditions indicated in the contract data.

In the electronic contract system 1 described below, the server 20 is for concluding an electronic contract between a plurality of users who are corporations or individuals. Individuals include sole proprietors.
・Conclusion of an electronic contract between corporations agree to enter into a contract.
・ Conclusion of electronic contracts between legal entities and individuals For example, between users of the first group (corporations such as real estate management companies) and users who are individuals, such as real estate lease contracts, employment contracts, insurance contracts, etc. , agree to conclude a contract with the first group and the user who is an individual as the contract subject.
- Conclusion of an electronic contract between individuals There may be two or more parties to the contract (for example, a three-party contract).

<1.1 Configuration diagram of the entire system>
FIG. 1 is a block diagram showing an example of the overall configuration of the electronic contract system 1 of the embodiment. As shown in FIG. 1, the electronic contract system 1 includes a receiver-side terminal device 10, a sender-side terminal device 30, and a server 20, and these devices are communicably connected to each other via a network 80. .

In the example of FIG. 1, the receiver side terminal device 10 used by the user is shown. The recipient's terminal device 10 is, for example, a PC.

By executing the program, the receiver's terminal device 10 provides the user with an environment for operating the system according to the program. The receiver's terminal device 10 reads and executes the program to connect the receiver's terminal device 10, the sender's terminal device 30, and the server 20 for communication. Then, the receiver-side terminal device 10 transmits data related to the electronic contract (for example, contract data, information indicating that each user has approved the contract data, information for allowing the user to browse the contract data for which a contract has been concluded, etc.). , is transmitted and received between the terminal device 10 on the receiver side, the terminal device 30 on the sender side, and the server 20 .

The server 20 appropriately transmits the data required for the electronic contract to the recipient terminal device 10, thereby visualizing the status of the electronic contract on the recipient terminal device 10. FIG. 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.

For example, the server 20 manages other various data such as information on users related to electronic contracts, information on contract data used in electronic contracts, and information on the date and time of approval by a certain user in electronic contracts.

The recipient-side terminal device 10 includes a communication IF (Interface) 12 , an input device 13 , an output device 14 , a memory 15 , a storage section 16 and a processor 19 .

The communication IF 12 is an interface for inputting and outputting signals so that the receiver's terminal device 10 communicates with an external device.

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

The output device 14 is a device (display, speaker, etc.) for presenting information to the user.

The memory 15 temporarily stores programs and data processed by the programs, and is a volatile memory such as a DRAM (Dynamic Random Access Memory).

The storage unit 16 is for storing data, and is, for example, a flash memory or a HDD (Hard Disc Drive).

The processor 19 is hardware for executing an instruction set described in a program, and is composed of arithmetic units, registers, peripheral circuits, and the like.

The server 20 is a device that manages information of users who conclude contracts by electronic contracts, contract data used for electronic contracts, and other information.

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

The communication IF 22 is an interface for inputting and outputting signals for the server 20 to communicate with an external device.

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

The memory 25 temporarily stores programs and data processed by the programs, and is a volatile memory such as a DRAM (Dynamic Random Access Memory).

The storage 26 is for storing data, and is, for example, a flash memory or a HDD (Hard Disc Drive).

The processor 29 is hardware for executing an instruction set described in a program, and is composed of arithmetic units, registers, peripheral circuits, and the like.

The terminal device 30 on the sender side includes a communication IF (Interface) 32 , an input device 33 , an output device 34 , a memory 35 , a storage section 36 and a processor 39 .

The communication IF 32 is an interface for inputting and outputting signals so that the terminal device 30 on the sender side communicates with an external device.

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

The output device 34 is a device (display, speaker, etc.) for presenting information to the user.

The memory 35 temporarily stores programs and data processed by the programs, and is a volatile memory such as a DRAM (Dynamic Random Access Memory).

The storage unit 36 is for storing data, and is, for example, a flash memory or a HDD (Hard Disc Drive).

The processor 39 is hardware for executing an instruction set described in a program, and is composed of arithmetic units, registers, peripheral circuits, and the like.

<1.2 Functional Configuration of Recipient Side Terminal Device 10>
FIG. 2 is a diagram showing the functional configuration of the receiver-side terminal device 10. As shown in FIG. The receiver-side 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 .

The antenna 111 radiates the signal emitted by the receiver-side terminal device 10 into space as radio waves. Antenna 111 also receives radio waves from space and provides a received signal to first wireless communication section 121 .

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

The processor 19 controls the operation of the receiver's terminal device 10 by reading and executing programs stored in the storage unit 16 . The processor 19 is implemented by, for example, an application processor.

The operation accepting unit 130 has a mechanism for accepting user input operations. For example, the operation reception unit 130 is realized as a pointing device such as a mouse, a touch pad, a touch panel, a keyboard, a controller, an imaging unit that senses the movement of the user's body as an input operation, or the like. For example, the operation reception unit 130 senses the movement of a body part such as a hand, the expression of the user's face, etc. as the body movement of the user, and receives the movement of the body part as an input operation. The operation reception unit 130 determines whether the user's operation is a flick operation, a tap operation, or a drag ( swipe) operation is determined.

The storage unit 16 is composed of flash memory, RAM (Random Access Memory), etc., and stores programs used by the recipient terminal device 10 and various data received by the recipient terminal device 10 from the server 20. .

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

The audio processor 140 modulates and demodulates the audio signal. Audio processing unit 140 modulates the signal supplied from microphone 141 and supplies the modulated signal to processor 19 . Also, the audio processing unit 140 provides an audio signal to the speaker 142 .

Microphone 141 receives a voice input and provides voice signal corresponding to the voice input to voice processing section 140 .

The speaker 142 converts the audio signal given from the audio processing unit 140 into audio and outputs the audio to the outside of the receiver's terminal device 10 .

The storage unit 16 stores electronic contract management information 161, transmission approver information 162, transfer destination approver setting 163, and approval history 164. FIG.
The electronic contract management information 161 is information for managing each electronic contract.
The approver information 162 at the time of transmission indicates the information of the approver on the receiver side designated by the sender terminal device 30 in the electronic contract to proceed with the conclusion on the receiver side terminal device 10 .
The transfer destination approver setting 163 indicates information of a user who is set as an approver in the user group of the recipient terminal device 10 .
The approval history 164 indicates approval history information including information on the timing of approval by the user who is the approver in each electronic contract.

By operating the processor 19 according to the program, functions as an input operation reception unit 191 , a transmission/reception unit 192 , a data processing unit 193 and a notification control unit 194 are exhibited.

The input operation reception unit 191 performs processing for receiving a user's input operation to the input device such as the operation reception unit 130 . If the operation reception unit 130 is, for example, a touch-sensitive device, the input operation reception unit 191 detects whether the user's operation is a flick operation based on the coordinate information at which the user touches the touch-sensitive device with a finger or the like. , a tap operation, a drag (swipe) operation, and the like.

The transmitting/receiving unit 192 performs processing for the recipient-side terminal device 10 to transmit/receive data to/from an external device such as the server 20 or the like according to a communication protocol.

The data processing unit 193 performs processing according to a program to perform computation on the data input by the receiver-side terminal device 10, and outputs the computation result to a memory or the like.

The notification control unit 194 performs, as processing for presenting information to the user, processing for displaying a display image on the display 132, processing for outputting sound from the speaker 142, processing for generating vibration with a vibrator or the like, and the like.

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

The communication unit 201 performs processing for the server 20 to communicate with an external device.

The storage unit 202 stores various databases such as an electronic contract management database 2021, transmission approver information 2022, forwarding approver setting 2023, approval history 2024, and the like.

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.

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

The transfer destination approver setting 2023 is a database for managing information of users who are previously set as approvers in association with a group to which a plurality of users such as businesses belong. Details will be described later.

The approval history 2024 is an approval history database that includes information on the timing at which the approver user approves each electronic contract. Details will be described later.

The control unit 203 is implemented by the processor 29 reading a program stored in the storage unit 202 and executing instructions included in the program. The control unit 203 operates according to a program to exhibit functions 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/time information acquisition module 2035.

The reception control module 2031 controls processing for the server 20 to receive a signal from an external device according to a communication protocol.

The transmission control module 2032 controls the processing by which the server 20 transmits signals to external devices according to a communication protocol.

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

The approver user information acquisition module 2034 is configured to perform approval as an approver on the receiver side in the conclusion of an electronic contract, regardless of whether or not the user is specified as a user on the receiver side in the terminal device 30 on the sender side. It performs a series of processes for managing set user information.

The approval date/time information acquisition module 2035 performs a series of processes for managing date/time information indicating when the approver approved.

<1.4 Conceptual diagram for explaining electronic contracts>
FIG. 4 is a conceptual diagram for explaining an electronic contract. In this embodiment, the "electronic contract" means that the electronic contract service provided by the business operator or the like that operates the server 20 is used for the contract data agreed by the parties to the contract using the signature key as follows. including electronic signatures.
・ Using the signature key prepared by the contracting party, the contracting party electronically signs the contract data. ・ Using the signature key prepared by the electronic contract service provider, the contracting party Electronically sign electronic signatures at will (e.g., in response to a contracting party approving contract data)

For example, the parties to the contract operate their respective terminal devices to exchange contract document data on the Internet between the terminal devices via the server 20, and the parties to the contract perform an input operation to express their intention to agree. , means that the parties to the contract attach an electronic signature to the electronic data of the contract documents.

First, the contract sender operates the sender-side terminal device 30 to upload the contract data to the server 20 on the cloud, for example. The server 20 attaches the contract sender's electronic signature to the contract data agreed upon by the contract sender.

The contract sender performs an operation to request the contract receiver to conclude an agreement. Specifically, the terminal device 30 on the sender's side accepts an operation from the user to designate the recipient of the contract and transmits it to the server 20 . In this embodiment, the sender-side terminal device 30 receives information specifying one or more contract recipients from the user, and requests the contract recipient users to conclude an agreement via the server 20. . Information for specifying a user received from a contract sender may be as follows.
・E-mail address of each contract recipient ・Account of the service used by the contract recipient (for example, if a user account is issued in the electronic contract service provided by the server 20, the user ID, Information that identifies the user account, information that identifies the user account in a service other than the electronic contract service provided by the server 20, etc.)

The server 20 of the electronic contract system 1 is addressed to the recipient's mail address specified by the user of the contract sender, and information for accessing the contract data (for example, described as a URL (Uniform Resource Locator) link) to the agreement recipient.

Here, the server 20 may receive from the contract sender a specification of the reading order of the plurality of contract recipients. For example, when the server 20 accepts the specification of a plurality of email addresses of the contract recipients from the contract sender, the server 20, in accordance with the order of the specified email addresses, sequentially sends information for accessing the contract data, It may be sent to each contract recipient.

For example, it is assumed that the contract sender has specified a first e-mail address, a second e-mail address, and a third e-mail address as contract receivers. First, the server 20 transmits a link for viewing the contract data to the first contract recipient at the first email address, and accepts an approval operation. The server 20, in response to receiving an operation to approve the contract data from the first contract recipient, records that the first contract recipient has approved and the timing of the approval. (For example, to attach the electronic signature of the first contract recipient in response to the operation to approve it), and to allow the second contract recipient at the second email address to view the contract data. send a link to Thereafter, the server 20 similarly records the fact that the second contract recipient has given approval and the timing of the approval (for example, in response to the approval operation, the second contract recipient provide an electronic signature), send a link to view the contract data to the third contract recipient in response to the second contract recipient's approval, and receive the third contract Accepts an operation for approval from a person.

The recipient of the contract can click the link described in the received e-mail on the recipient's terminal device 10, check the content of the contract data on the server 20 online, and conclude an agreement. The receiver's terminal device 10 presents the user of the receiver's terminal device 10 with a screen for accepting an operation indicating agreement on this contract, and accepts an operation for agreement from the user.
If there is a defect in the contract content at this point, the server 20 may receive an operation from the contract recipient to the effect that he/she does not agree to the contract.

The server 20 attaches the contract receiver's electronic signature to the contract data by accepting an operation to agree on the contract data from the contract receiver. Contract data is stored in the server 20 . By attaching the electronic signatures of both parties to the contract, falsification of the contract is prevented.

The present embodiment realizes such a cloud-type electronic contract service. In the following embodiments, regarding the authority to conclude a contract, a technique for preventing a person belonging to an organization from executing an electronic contract without authority will be described.

For this reason, the approver user information acquisition module 2034 (see FIG. 3) of the server 20 manages the information of persons who can conclude a contract within the organization, and processes to prevent the operation of concluding an agreement by a person who does not have the same authority. I do.

The electronic contract information acquisition module 2033 is responsible for overall electronic contract processing other than the authority management described above. That is, the electronic contract information acquisition module 2033 performs processing for recording the contract data in the server 20 based on the operation of the contract sender, processing for generating a link for accessing the contract data, and It performs processing of sending an e-mail for concluding a contract, processing of receiving access based on the link from the recipient of the contract and receiving an operation for concluding a contract, and other processing.

<2 Data structure>
FIG. 5 is a diagram showing the data structure of the database stored by the server 20. As shown in FIG. Note that FIG. 5 is an example and does not exclude data that is not described.

Each record of the electronic contract management database 2021 of FIG. Item "recipient's email address 1", item "recipient's email address 2", item "recipient's email address 3", item "document ID used for electronic contract" including. The illustrated example shows an example in which it is possible to receive designation of three users as a plurality of recipient-side users from the sender-side user in the electronic contract, but the number is not limited to three.

The item “contract ID” indicates identification information issued by the server 20, for example, for each contract concluded by electronic contract.

Specifically, the item "contract ID" is an ID unique to an electronic contract, which is necessary when managing each contract concluded between users by electronic contract.

The item "sender's document transmission date and time" indicates the timing at which the user on the sender's side transmitted the contract data to the server 20 in order to conclude a contract by means of an electronic contract. For example, the server 20 performs a process of accepting an upload of contract data from a user on the sender side, and stores the timing at which the process was performed in the item "sent date and time of document sent by sender".

The item "contract status" indicates the status of conclusion of an electronic contract that is being concluded between the sender and the receiver. Specifically, the status of the conclusion of an electronic contract between parties may include the following.
- “Uncontracted”: A state in which work for concluding an electronic contract between users has not started. For example, a state in which a user's designation related to the work of concluding an electronic contract is accepted.
- "Contract concluded": A state in which each user is specified in the conclusion of an electronic contract, but an operation to approve the contents of the contract has not been received from at least one of the specified users.
"Completed contract": A state in which the server 20 accepts an operation approved by each user specified in the conclusion of the electronic contract, and the conclusion of the electronic contract is completed.

The item "sender's email address" indicates information for specifying the sender's user, and specifically indicates the email address of the sender's user.

The item "recipient's email address 1" indicates information for specifying the recipient's user, specifically, the email address (first) of the recipient's user.

The item "recipient's email address 2" indicates information for specifying the recipient's user in the same manner as described above, and specifically indicates the recipient's email address (second one).

The item "recipient's email address 3" indicates information for specifying the recipient's user in the same manner as described above, and specifically indicates the recipient's email address (third).

The item "document ID used for electronic contract" indicates the identification information (ID) of the data of the document that is the target of the electronic contract. For example, as the document identification information, the server 20 accepts the upload of the document data as the target of the electronic contract, and issues unique information in association with the document data (identification information issued to the document, each link information for terminal equipment to access).

Each record of the approver information 2022 at the time of transmission in FIG. ,including. The illustrated example shows an example in which it is possible to receive designation of three users as a plurality of recipient-side users from the sender-side user in the electronic contract, but the number is not limited to three.

The item “contract ID” indicates identification information issued by the server 20, for example, for each contract concluded by electronic contract.

Specifically, the item "contract ID" is an ID unique to an electronic contract, which is necessary when managing each contract concluded between users by electronic contract.

The item "user ID of approver 1" indicates the user ID of the approver (first) on the receiver side, which is specified by the user on the sender side of the electronic contract.

The item "user ID of approver 2" similarly indicates the user ID of the approver (second person) on the recipient side.

The item "user ID of approver 3" similarly indicates the ID of the approver (third person) on the recipient side.

The transfer destination approver setting 2023 in FIG. department name” and the item “estimated position of user”.

In the following example, in the forwarding destination approver setting 2023, an example of managing users who are set as approvers in each group (business company, etc.) will be described.

Here, for each group, the server 20 manages a list of users belonging to the group (for example, a list of employees of a business company) (for example, a list of employees managed by a personnel department of a business company). The database may be imported into the server 20), and in the list of users in the group, it may be possible to manage being set as an approver in association with a specific user. That is, in the list of users of the group, there may be a mixture of users who are set as approvers and users who are not set as approvers.

The item "approver user ID" is identification information given to a user who is set as an approver when the electronic contract is concluded and becomes the recipient.

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

For example, the server 20 accepts in advance the designation of the user who should be the approver of the electronic contract from the group (for example, business company) to which the user who will be the approver belongs, and registers it in the forwarding destination approver setting 2023. Keep When the server 20 accepts the specification of any user in the recipient group from the user on the sender side of the electronic contract, even if the user who will be the approver is not specified, Notify the user who is set as the approver in the group on the administrator side to approve as the approver. For example, to the email address of the user set as the approver, a notification to the effect that there is a request for conclusion of the electronic contract and a link to the contract data for the electronic contract are sent.

Specifically, the item "approver user ID" is a unique ID for the approver, which is required when managing the program.

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

The item "user name" indicates the name of the user set as the approver.

The item "user's company name" indicates the name of the organization to which the user who is set as the approver belongs (business company name, etc.).

The item “user's department name” indicates the name of the department to which the user set as the approver belongs.

The item "presumed position of user" indicates the position name presumed for the user who is set as the approver. A method for estimating the user's job title will be described later. Here, it may be possible to register the job title of the user in advance in the server 20 .

The approval history 2024 in FIG. 5 includes the item “contract ID”, the item “approver 1 user ID”, the item “approval date and time of approver 1”, the item “approver 2 user ID”, and the item “approver 2 approval date and time”, the item “approver 3 user ID”, and the item “approval date and time of approver 3”. The illustrated example shows an example in which it is possible to receive designation of three users as a plurality of recipient-side users from the sender-side user in the electronic contract, but the number is not limited to three.

The item “contract ID” indicates identification information issued by the server 20, for example, for each contract concluded by electronic contract.

Specifically, the item "contract ID" is an ID unique to an electronic contract, which is necessary when managing each contract concluded between users by electronic contract.

The item “approver 1 user ID” indicates the ID of the approver (first) user.

The item "approval date and time of approver 1" indicates the date and time when the approver (first person) approved.

The item "user ID of approver 2" indicates the ID of the user who is the approver (second person).

The item "approval date and time of approver 2" indicates the date and time when the approver (second approver) approves.

The item "user ID of approver 3" indicates the ID of the approver (third person).

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

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

FIG. 6 is a diagram showing the flow of contract conclusion processing between parties via the server 20 . In the following example, it is assumed that both the transmitting side and the receiving side are business operators. Specifically, when concluding a contract by means of an electronic contract, the user of the second business operator (sending side) identifies the user of the first business operator (receiving side) and concludes the contract via the server 20. Let me explain an example to follow.

In step S601, the sender-side terminal device 30 of the second business operator accepts an operation from the user to designate the data of the document to be used in the electronic contract between the second business operator and the first business operator. The sender-side terminal device 30 transmits the data of the received document to the server 20 as contract data.

In transmitting the contract data, the sender-side terminal device 30 accepts the input of the mail address of one or more users of the first business operator as the destination of the document from the user of the second business operator. The terminal device 30 on the sender's side transmits the information of the received mail address to the server 20 .

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

In step S632, the server 20 refers to the forwarding destination approver setting 2023 to determine whether or not a user who will be the approver is set in the first business operator.

(i) If the user who will be the approver is not set in the first operator, the server 20, for the user specified by the user of the second operator (user of the first operator), Requests an operation to approve the conclusion of a contract for contract data. Specifically, the server 20 sends an e-mail to the email address of the user on the recipient side, which is specified by the user of the second business operator when concluding the electronic contract, to confirm the contents of the document to be the electronic contract. and to accept the operation to approve the content of the contract.

(ii) If a user who will be the approver is set in the first business operator, the server 20 sends the electronic contract destination to the first user who will be the approver when the electronic contract is concluded in the first business operator. irrespective of whether or not the email address of the user (transfer destination approver setting 2023) is included, the first user, who is the approver, is requested to approve the conclusion of the contract for the document. For example, the server 20 sends a message to the email address of the first user that includes information to prompt the confirmation of the contents of the document subject to the electronic contract and to accept an operation to approve the contents of the contract; , a message including at least one of the information that the first user has been set as an approver.

The server 20 requests the first user, who is the destination of the electronic contract and who is the approver, to perform an operation of approving the contract conclusion of the contract data. For example, the server 20 sends a message to the e-mail address of the first user, including information to the effect that confirmation of the contents of the contract data subject to the electronic contract will be urged, and that an operation to approve the contract contents will be accepted; Also, a message including at least one of information indicating that the first user has been set as an approver is transmitted.

For example, the server 20 may identify a user involved in contract conclusion in the first business operator and update the electronic contract management database 2021 based on the information of the identified user as follows. The server 20 may refer to the updated electronic contract management database 2021 to send information for making the request to the user requesting approval of the contract data.
・ At least some of the users designated as the second business operator and the first user set as the approver in the forwarding destination approver setting 2023 are regarded as the approvers involved in the conclusion of the electronic contract. The electronic contract management database 2021 is updated based on the information (e-mail address) specifying the approver user. For example, in the electronic contract management database 2021, information specifying the first user is stored in the recipient's mail address in association with the contract ID.

As described above, the server 20 allows each approver to peruse the document based on each information of the approver information 2022 at the time of transmission and the transfer destination approver setting 2023, and requests the approval operation.

Here, if the first user who will be the approver is set in the forwarding destination approver setting 2023, the server 20 will send all users (first It is assumed that the business operator's user) and the first user are requested to perform an operation to approve the contract data. It should be noted that there may be a case where the first user who is the approver is included in the users designated as destinations by the users of the second business operator.

In step S651, the receiver-side terminal device 10 of the user of the first business operator (the user specified by the user of the second business operator and the first user set as the approver) receives the server 20 to receive contract data for use in electronic contracts from users of the second business operator.

In step S652, the receiver-side terminal device 10 presents the contract data to the user by displaying the information on the display 132, notifying it by voice, or the like. The receiver-side terminal device 10 receives an input operation (input operation for approval) for confirming the contents of the contract data and concluding a contract from the user who is the approver. In response to the input operation for concluding a contract, the recipient-side terminal device 10 transmits to the server 20 information indicating that the contract will be concluded.

At this time, the server 20 sequentially requests approval in the order specified as the destinations. For example, if there is an approver of the forwarding destination (who sends the message to the forwarding destination first), the document may be transferred to the approver of the forwarding destination after receiving all the approvals of the users specified as the destinations. Alternatively, the document may be finally transmitted to the forwarding destination, or approval may be received from the approver of the forwarding destination rather than the user designated as the destination. Also, the server may determine the order of transfer to the approver of the transfer destination in the order of approval of the users specified as the destination.

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

The server 20 receives information indicating that a contract is to be concluded from each user who is an approver in the first business operator, thereby allowing the user of the second business operator and the user of the first business operator ( For example, when concluding an electronic contract, information indicating that contract conclusion has been completed is sent to the e-mail address of the user involved as the sender or receiver. For example, the server 20 sends a notification to the e-mail address of the user of the first business operator that the contract conclusion work has been completed on the side of the user of the second business operator, and the documents for which the contract was concluded. Send a message containing link information for browsing.

In step S602, the terminal device 30 on the sender's side presents the result of completion of electronic contract conclusion to the user of the second business operator by displaying information on the display or the like.
As described above, the server 20 manages the contract data based on various databases assuming that an agreement has been reached between the first business operator and the second business operator regarding the contract data.

FIG. 7 is a diagram showing the flow of processing for determining the domain of an e-mail address in conclusion of a contract and processing using the determined result.

The server 20 determines the domain of the e-mail address by comparing the e-mail addresses of each user who is a party to the conclusion of the contract.
Determining the domain of the e-mail address means comparing the domains of the e-mail address of the user of the second business and the domain of the e-mail address of the user of the first business to determine whether they have different domains. means that The details of where the domain portions of the email addresses are compared and determined will be described later in the description of step S732.

Also, the purpose of determining the domain of the mail address will be described. When the contract is concluded, the server 20 automatically determines the sender side and the receiver side from the mail address, so that the number of the sender side and the number of the receiver side can be determined. At that time, it is also possible for the recipient side to match the number of approvers on the recipient side with the number of senders.

As a premise, if there are many people on the sender side, there is a high possibility that the contract data is checked by a large number of people on the sender side, and there is a high possibility that it is an important document. In this case, by matching the number of approvers on the receiver side to the number of senders on the receiver side, important documents can be carefully judged by a plurality of people. This case is also described later in modification (1).

By performing the mail address domain determination in this way, it becomes possible to perform the processing of the above cases.

In addition, by comparing the domain part of the sender's email address and 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 from different companies or the same company. It is possible to determine whether it is a business operator of the same company or a business operator of the same series such as a parent-child relationship. For example, by pre-associating the domain of the mail address of the same affiliated business operator and storing it in the storage unit, it is possible to determine whether the sender and the recipient are the same affiliated business operator (for example, a parent company and a minor company). It is possible to determine whether it is a contract conclusion between

For example, if the sender and the receiver are the same business operator, it is possible that the contract data is approved by an electronic contract after undergoing a request for approval in advance within the business operator. In this case, assuming that there is little concern about unauthorized representation, the following may be done.

When the server 20 determines that the users on the sender side and the receiver side are users of the same company (the domain part of the email address is the same for the sender and the receiver), the forwarding destination approver setting 2023 Even if a user who will be the approver is set in , it will not be forwarded to the user who will be the approver, and the user specified by the sender will approve the contract data. good.
Also, in the above case, in the transfer destination approver setting 2023, at least some of the approver users set in the transfer destination approver setting 2023 at the business operator, such as forwarding to a user with a specific position. may be transferred to

In step S732, the server 20 compares the email address of the user on the receiver side and the email address of the user on the sender side, and determines whether the domain portions are different. If the domain parts are different, the server 20 distinguishes the receiver side and the sender side as users belonging to different affiliations, and presents the distinguished result to each user on the sender side and the receiver side.

For example, assume that the email address of the user of the second business is xxx@abcde.co.jp and the email address of the user of the first business is xxx@efghi.co.jp. At this time, when the server 20 looks at and compares the domain parts of both, the domain part of the email address of the user of the second operator is @abcde.jp, and the email address of the user of the first operator is @ You can see that it is different at efghi.jp. If the domain part of the e-mail address is different, it is highly likely that they are not from the same company. This is because many corporations (companies) have their own domains, and there is a high possibility that employees use e-mail addresses that use the corporation's own domains.

Therefore, if it is determined that the domain parts are different, and one side is the sender side and the other side is the receiver side, it is assumed that the sender side and the receiver side are different business operators. It is possible to distinguish In this case, the server 20 can distinguish the mail address of the user of the second business from the sender's side and the mail address of the user of the first business from the recipient's side.

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

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

<Screen example>
FIG. 8 is a diagram showing a phase in which the user confirms the contract data on the terminal of the approver of the first business operator.

In the screen example of FIG. 8, the receiver-side terminal device 10 presents the user of the receiver-side terminal device 10 with a screen for receiving an operation indicating that the user of the receiver-side terminal device 10 agrees on the contract data, and the user of the receiver-side terminal device 10 receives an operation for agreeing. is received from the user. This corresponds to the processing of steps S651, S652, etc. in FIG. Details will be explained in the next section.

The contract approver clicks the link described in the received e-mail on the recipient's terminal device 10, confirms the content of the contract data on the server 20 online via a browser, etc., and concludes an agreement. be able to. The receiver's terminal device 10 presents the user of the receiver's terminal device 10 with a screen for accepting an operation indicating agreement on this contract, and accepts an operation for agreement from the user.

In addition, the server 20 attaches the contract receiver's electronic signature to the contract data by accepting an operation to agree on the contract data from the contract receiver. Contract data is stored in the server 20 . By attaching the electronic signatures of both parties to the contract, falsification of the contract is prevented.

For example, in the receiver-side terminal device 10 of the receiver "Corporation B", an input operation for requesting the conclusion of an agreement between the sender "Corporation A" and the receiver "Corporation B" is accepted. will be explained. The sender "Corporation A" is on the sender side, and the receiver "Corporation B" is on the receiver side.

In addition, the sender of the sender "Co., Ltd. A" performs the operation of specifying the mail address of the user "M Shimo M Akira" of the recipient "Co. Suppose you enter an operation to specify as a recipient.

Assume that the approver for the recipient “Corporation B” is set in the forwarding destination approver setting 2023 in the server 20 . The server 20 performs an operation for concluding an agreement from the sender-side terminal device 30 of the sender "Corporation A" while the user of the receiver "Corporation B" is specified by the sender of the sender "Corporation A". accept. The server 20 forwards the request for conclusion of an agreement to the user "Toyuki Nzawa" who is set in the forwarding destination approver setting 2023 as the approver of the recipient "Corporation B".

At this time, the receiver-side terminal device 10 of the user "Toko Nzawa" who is set as the approver presents the following information to the user to determine whether or not to perform an operation to agree to the conclusion of the contract. Make it easy for the user to decide.
・Information of the sender's business operator who will be the other party to conclude the contract ・Information of the user of the other business operator who sent the contract data to be concluded document data, etc.)
・Information of the user on the recipient side (first user) specified by the business operator on the sender side (information on the transfer source of the contract documents)

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 prompting the user to confirm and approve the contract document.
Message 810B: This is an area for displaying the information of the transfer source user when the contract data is transferred because the user is set in the transfer destination approver setting 2023 . As a result, the user who is set as the approver in the transfer destination approver setting 2023 can easily check the information of the user specified by the sender as the recipient of the contract data. For example, the sender can easily confirm to which department of the operating company the contract data has been sent.
• Area 810C: This area displays the contents of the contract documents to be concluded. Recipient-side terminal device 10 displays, in area 810C, the type of contract documents (for example, the types of various contracts such as non-disclosure agreements and outsourcing agreements), names of contracting parties, clauses of contract documents, and the like. .
• Button 810D: This is an area for receiving an operation from the second user to approve the contract documents after confirming the contract documents.

The user confirms each piece of information presented on the dialog screen 810 and determines whether to agree on the contract data.

Recipient-side terminal device 10, in response to accepting the input operation to button 810D from the user, transmits information indicating that the user has approved the contract data to server 20 (S652).

FIG. 9 is a diagram showing how to set the approver of the contract data in the terminal of the user of the first business operator. By being able to set an approver on the recipient side in an electronic contract, it is possible to prevent unauthorized representation when a recipient without decision-making authority is set.

How the first business operator sets the approver of the contract data is based on the relationship between the user who is the approver of the first business operator and the user who is the contract recipient at the first business operator. may be determined by For example, if the recipient of the contract of the first business operator is a member of the sales department, the approvers of the first business operator are the general manager of the sales department and the deputy general manager of the sales department. can be set in-house. Also, the approval flow refers to a series of procedures to be approved by the approver of the electronic contract. A specific example will be described later.

As described above, the server 20 manages the contract approver user in the forwarding destination approver setting 2023 according to the attributes (department, position, etc.) of the contract receiver user. good too.

How the first business operator sets approvers may also be determined based on the relationship between the approvers of the first business operator and the content of the contract data. How to determine the content of the contract data is determined by reading the contract data (eg, PDF data) with OCR (or by preserving the result of character recognition processing in advance in the storage unit), Read as a sentence what the content of is.

Then, machine learning is performed based on the contract data and the result of reading the content of the contract data to generate a learned model.

This enables the server 20 to determine what kind of contract data is based on the contract data and the learned model. Further, the server 20 stores a table for determining the content of the contract data according to the result of reading the contract data. The type of contract content (type of contract such as non-disclosure agreement, outsourcing contract, etc.) may be determined.

Further, the server 20 holds a table for determining department information according to the result of reading the contract data, so that when the contract data is determined based on the result of reading the contents of the contract data and the table, It is also possible to determine whether the document is directed to a department.

For example, assume that the title of the contract data is "invoice to sales department of company A". In this case, the contract data is first read by OCR, and then it is possible to determine which department the content of the contract data belongs to based on the read text and the learned model. For example, in a document showing the contents of contract data, the title is "Invoice for the sales department of company A", so it can be determined that the contents of the contract data relate to the sales department. By carrying out the procedure as described above, the server 20 can determine which department the content of the contract data relates to.

Then, for example, if the content of the contract data is a document related to the sales department, the approvers of the first business operator are the sales manager and the deputy sales manager. Approver may be set. An approval flow for contract documents may be set within the company by the approvers set as described above. A specific example will be described later.

For example, a case will be described in which a certain company "Co., Ltd. C" has established internal regulations on how to set approvers of contract data. Assume that the document screen 910 of "Corporation C" displays a part of the approver's settings.

At this time, the document screen 910 displayed on the terminal device of the user of "Corporation C" presents each of the following information to the user. can be easily determined by the user.
・Determining the approver based on the user who received the contract document or the organization to which the user belongs ・Determining the approver based on the contents of the contract document

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 for displaying the agreement on how to set the approver based on the information of the user of the contract recipient of Company C.
• Message 910B: This is an area for displaying the agreement on how to set the approver based on the information on the contents of the contract data.

FIG. 10 is a diagram of a phase of displaying an approver flow of contract data at the approver's terminal of the first business operator.

The server 20 appropriately transmits the data necessary for the electronic contract to the recipient-side terminal device 10 and accepts the operation of the recipient-side user to visualize the status of the electronic contract on the recipient-side terminal device 10. Let

By visualizing the status of the electronic contract (for example, the status of the electronic signature being given by the approver user's approval), the approver of the first business operator can , approver users of the first business operator have not yet approved the contract data. As a result, the approver of the first business operator can encourage the approver who has not approved the contract data to take some action, which leads to shortening the speed of conclusion of the contract data.

For example, when the sender "Corporation A" requests the recipient "Corporation B" to conclude a contract, the approver of the recipient "Corporation B" approves the contract data documents. explain. The sender "Corporation A" is the sender side, and the receiver "Corporation B" is the receiver side. At this time, it is assumed that there are four approvers, Approver A, Approver B, Approver C, and Approver D, for the contract data at the receiver "B Co., Ltd." on the receiver side.

The approver's terminal device presents a visualized state of the electronic contract of the contract data on the screen. The approver's terminal device presents information as to which approver has approved the contract data (whether it has been signed) and which approver has not yet approved the contract data.

Specifically, the receiver-side terminal device 10 of the approver B of the receiver “company B” on the receiver side presents the following information on the dialog screen 1010 .
- Message 1010A: This is an area for displaying the contents of the contract data.
• Area 1010B: This is an area for displaying the approval status of the contract data.
Message 1010C: This is an area for displaying when the approval status of the contract data was obtained.

FIG. 11 is a diagram showing signature data of contract data for which contract conclusion has been completed.

The server 20 holds data relating to a signature (hereinafter referred to as signature data) in contract data when concluding an electronic contract. With the signature data, those involved in the conclusion of the contract can confirm information such as "when and which approver agreed to the contract document" and "whether the approval record is still valid". .

For example, a situation after the completion of the contract conclusion of the contract data between the receiver "Corporation A" and the sender "Corporation B" will be described. Assume that the sender "company B" is the sender side, and the receiver "company A" is the receiver side. It is assumed that the approver A of the receiver "Co., Ltd. A" on the receiver side accepts an operation to present the signature data of the contract data in the receiver-side terminal device 10 .

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

FIG. 12 is a diagram showing partially anonymized signature data in contract data for which contract conclusion has been completed.

As described above, the server 20 associates the contract data managed assuming that an agreement has been reached between the parties to the contract, the information of the user who approved the contract data, and the information of the timing at which the user approved the contract data. management in the approval history 2024 or the like.

The server 20 responds to a contract data viewing request from a user and stores at least one of information on the user who has given approval and information on the timing at which the user has given approval, which is information to be stored in association with the contract data. The contract data may be presented to the user who made the viewing request without allowing any of the contract data to be viewed.

Regarding how to specify the user to be anonymized, the sender side specifies the user information that the receiver wants to anonymize, or the receiver side specifies the user information that the sender wants to anonymize. , may be accepted from each user.

The server 20 may accept designation of a user to be anonymized from a user, and may disclose to a contracting party without accepting designation of anonymization for a specific user such as a user with the highest position. This allows contract parties to easily verify whether the contract has been approved by an authorized user.

The server 20 holds signature data of contract data when concluding an electronic contract. The signature data may be partially anonymized by setting. Partially anonymizing the signature data makes it difficult to guess the order of approval, and has the effect of reducing the scope of disclosure of the company's approval flow to other organizations.

For example, a situation after the conclusion of the contract between the receiver "Corporation A" and the sender "Corporation B" will be described. Assume that the sender "company B" is the sender side, and the receiver "company A" is the receiver side. It is assumed that the approver A of the receiver "Co., Ltd. A" on the receiver side accepts an operation to present the signature data of the contract data in the receiver-side terminal device 10 .

At this time, the recipient-side terminal device 10 of the approver A presents the following information to the user on the dialog screen 1210 .
• Area 1210A: This area is for displaying the contents of the contract data.
• Message 1210B: An area to inform the user when all signatures on the contract data are valid.
• Area 1210C: This is an area where the information of the signature data can be confirmed. The user can confirm information such as "when and which approver agreed to the contract" and "whether the approval record is still valid". However, it is assumed that part of the signature data is anonymized on the screen.

FIG. 13 is a diagram showing a recommendation of a person to be included as an approver in the contract data approval flow based on past electronic contract conclusion histories.

In concluding an electronic contract, the first business operator 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 always grasp which person in the first business operator has what kind of authority, and to sort them out.

For the first business operator, recommending an approver based on the history of past conclusions of electronic contracts may help the first business operator when deciding on an approver.

For example, a situation will be described in which the terminal of the receiver "Corporation B" accepts an operation for concluding contract data between the user of the sender "Corporation A" and the receiver "Corporation B". It is assumed that the sender "Corporation A" is on the sender side, and the receiver "Corporation B" is on the receiver side.

The business operator of the recipient "Corporation B" needs to consider who should agree on the contract data as an approver, and then conclude the contract data. Therefore, the server 20 may recommend an appropriate approver to be included in the approval flow from the past electronic contract conclusion history, and present the information of the appropriate approver to the user of the business operator. and

For example, assume that the contents of the contract data are related to sales, and that there are a plurality of past electronic contract histories that are very similar to the contents of the contract data.

As for determining the content of the contract data, an embodiment is described in the description of FIG. Also, the similarity determination of the contents of the contract data may be determined by looking at the title of the contract data. For example, assume that there are contract data titled "Bill to sales department of company A May 2021" and contract data titled "Quotation to sales department of company A June 2021". In this case, the former title and the latter title differ only in the year and month part, and are identical in all other wordings, and can be determined to be similar. As described above, it is possible to judge the similarity of the content of the contract data by looking at the title of the contract data.

It is assumed that among the multiple electronic contract histories, there is a history in which Mr. Tanaka of the sales department was involved as an approver. In that case, the server 20 determines that Mr. Tanaka of the sales department is the appropriate approver for this contract data as well, and sends information about the appropriate approver to the user of the recipient "Corporation B". present on the screen.

At this time, the recipient-side terminal device 10 of the approver B presents the following information to the user on the dialog screen 1310 .
• Area 1310A: This area is for displaying the contents of the contract data.
• Message 1310B: This is an area for displaying the approver's recommended information.
• Area 1310C: This area is for displaying past electronic contract history that is very similar to contract data.

<Modification>
(1) Identifying the number of people required to conclude a contract based on the number of parties involved in the conclusion of the contract Each party may evaluate the number of users involved in contract conclusion and present the evaluation results to each user.

For example, the server 20 determines the number of users on the sender's side involved in the conclusion of the electronic contract by acquiring information on the users on the sender's side. Based on the determination result, the server 20 specifies the number of recipient-side users who should be involved in the conclusion of the electronic contract, and determines whether the specified result is at least one of the recipient-side users or the sender-side users. It is also possible to present

For example, the server 20 keeps the number of senders and receivers within a certain range (for example, the difference between the number of senders and receivers is zero or within a certain value). In order to keep the difference in the number of people involved in the conclusion of the contract between the party and the recipient within a certain amount, the side with the larger number of people should be offered to reduce the number of people, or the side with the smaller number of people should be offered to increase the number of people. good too.

For example, the server 20 may present to each user a proposal to increase or decrease the number of persons involved in contract conclusion on the sender side or the receiver side at the following times.
・ At the stage of performing an operation to approve the contract documents (step S652, etc.)
- Step of transferring the data of the document to be contracted to the user set as having contract conclusion authority (step S632)
・ At the stage when the sender side uploads the contract documents to be the target of contract conclusion (step S601, etc.)

Determining the number of senders from the mail address information is described in detail in the description of FIG.

If there are many people on the sender side, many people on the sender side are involved in checking the contract data, and there is a high possibility that it is an important document. In this situation, by matching the number of approvers on the receiver side to the number of senders on the receiver side, important documents can be carefully judged by a plurality of people.

It is assumed that the more people involved in concluding contracts, the more cautiously they proceed with concluding contracts. Therefore, by structuring as described above, both parties can be prudent and discrepancies in recognition of the importance of the contract can be reduced.

<Modification>
(2) Estimation of Approver's Position The server 20 may determine the position of the user who has approved the contract data based on the approval order of the users who have approved the contract data on the recipient's side.

The server 20 may extract user candidates to be set as approvers in the transfer destination approver setting 2023 in the recipient's group based on the result of job title determination.

In step S633, the server 20 estimates the position of each approver (such as "general manager" or "president"), evaluates the effectiveness of the approver based on the estimated result, and presents it to the user on the sender side. may be The estimated position is hereinafter referred to as an estimated position.

In concluding a contract, it is often possible to decide the approval flow following the position in the company. Approval flow refers to a series of procedures to be approved by an approver of an electronic contract. Evaluating the effectiveness of the approver increases the probability of establishing a smooth approval flow in contract conclusion. Therefore, by configuring as described above, when there are multiple approver candidates ("President", "Director", "Division Manager", etc.), it is possible to create a logic that can determine the appropriate decision-maker.

How the position is estimated may be based on the information of the transfer destination approver setting 2023, the approval history 2024, and the contents of the contract data. For example, if Mr. Tamura is in the sales department and there is a history of approval at the end of the approval flow every time for contract data related to the sales department, there is a high possibility that Mr. Tamura's presumed title is sales manager. can be determined.

As described above, the server 20 estimates the user's position as follows.
・ With reference to the electronic contract management database 2021 and the approval history 2024, when concluding contract data, it is estimated that a user with a high percentage of being designated as a concluding party on the sender side or the receiver side has a position. ・ Electronic contract management By referring to the database 2021 and the approval history 2024, when concluding contract data, the sender side or the receiver side, based on the order of approval (for example, the order of approval is the latter, or the user who approves last), the user , and estimate the height of the position. For example, the last in the order of approval is presumed to have a higher position (e.g., president, manager, etc.)

<Modification>
(3) Determining Appropriate Approval Person In step S631, the server 20 acquires position information and validity information of a plurality of approvers, and determines an appropriate approver on the side of the recipient of contract conclusion. Alternatively, based on the determined result, information on an appropriate decision-making authority may be presented to the user on the recipient side.
Regarding this modification, details such as an embodiment are described in the description of FIG. 13 .

In the approval flow, it is necessary to carefully decide who is set as the approver. Therefore, by configuring as described above, the server 20 can present an appropriate decision-maker based on the approver's position information and validity information.

<Modification>
(4) Recommending an Appropriate Approval Person The server 20 extracts candidates for users to be set as approvers based on the history of contracts concluded by groups on the sender or recipient side, and the extracted candidates are The user may be presented with information suggesting that the candidate user be included in the contract conclusion user.
For example, the server 20 extracts user candidates to be set as approvers in the recipient-side group based on the history of contracts concluded by the recipient-side group, and assigns the extracted user candidates to the sender. Information that is proposed to be included in concluding a contract with a user on the recipient side may be presented to a group of users on the recipient side.
Regarding this modification, details such as an embodiment are described in the description of FIG. 13 .

Therefore, by configuring as described above, it is possible to recommend who should be included in the workflow as an authorized decision-maker based on the history of past contract conclusions, which can be helpful in determining the approval flow. Approval flow refers to a series of procedures to be approved by an approver of an electronic contract.

(5) Notification regarding contract conclusion request As described above, when concluding a contract, the user on the sender side specifies the user on the receiver side to approve the contract data subject to the contract, and the contract data On the other hand, the server 20 manages the contract data assuming that the user who approves has given an electronic signature.

The server 20 may notify each user of the conclusion of the contract in the following manner.
If the server 20 determines that the user on the receiver side specified by the user on the sender side does not have the authority to conclude a contract (not set as an approver in the forwarding destination approver setting 2023), the approval to the user who has the authority to For example, if an email containing a link for confirming the contract conclusion request and contract data is sent to the email address of the authorized user, or if the user logs into the electronic contract system provided by the server 20 to display the content of the notification.
If the server 20 determines that the user on the receiver side specified by the user on the sender side does not have the authority to conclude a contract, the server 20 asks the user specified by the user on the sender side to conclude a contract. A notice indicating that you do not have the authority to do so, a notice indicating that the transfer has been made to a user who has the authority to conclude a contract (user on the recipient side), and other notices.
- The server 20 may distinguish between the information of a user who does not have approval authority on the receiver side and the information of a user who has approval authority, and present the information to the user on the sender side. For example, if a recipient user specified by a sender user does not have approval authority, a display indicating to the sender user that the specified recipient user does not have approval authority while doing so, display that it has been transferred to a user with approval authority. For example, for a sender-side user, a user who does not have approval authority and a user who has been transferred and has approval authority may be sent an email to a sender-side user in a different manner, or a sender-side user may Notify by displaying on the screen when accessing.

(6) Method of specifying a user for contract conclusion The server 20 provides the electronic contract system to each user (or a business operator to which multiple users belong), so that each user logs in User information managing. For example, the server 20 manages information displayed in the electronic contract system, such as the user name, the user's e-mail address, and the user's company name. The server 20 thus manages the information of the users belonging to each business with respect to each business.

Here, when the user on the sender side designates the user on the receiver side when concluding a contract, the server 20 provides information that identifies the user in the electronic contract system (for example, user account information (ID in the electronic contract system) etc.)) may be accepted. By specifying the email address associated with the account information of the user designated as the user on the recipient side, the server 20 includes a contract conclusion request and a link for confirming the contract data addressed to the email address. An email may be sent.

In addition, when the user on the sender side specifies the account of the user on the receiver side, the server 20 registers the mail address associated with the account and the transfer destination approver setting 2023 as having approval authority. It may be determined whether or not the user associated with the account has approval authority by checking the email address of the user who has been registered.

As described above, even if the user on the sender side specifies information other than the email address as the information for identifying the recipient, the comparison with the email address information of each user stored in the server 20 reveals that Whether or not each user has approval authority can be determined.

Although several embodiments of the present disclosure have been described above, these embodiments can be implemented in various other forms, and various omissions, replacements, and modifications are possible without departing from the spirit of the invention. It can be performed. These embodiments and their modifications are intended to be included in the scope of the invention described in the claims and their equivalents as well as included in the scope and gist of the invention.

<Appendix>
The items described in the above embodiments will be added below.
(Appendix 1)
A program for operating a computer (20), the computer is for making an electronic contract between a plurality of corporate or individual users, the program causes a processor (29) of the computer to execute a plurality of A step of accepting a setting (2023) of a first user who will be an approver when concluding an electronic contract in a first group composed of users of the first group, and a second user different from the users of the first group from, a step of receiving information identifying a user of the first group and contract data to conclude an electronic contract with the first group (S601); a step of requesting a user identified by a second user to perform an operation of approving contract conclusion of contract data when no user is set; and a first user who is an approver in the first group. is set, regardless of whether or not the first user is included in the information of the user specified by the second user, approve the contract conclusion of the contract data for the first user a step of requesting an operation to approve (S632); A program for executing a step (S633) of managing the contract data in a computer assuming that the agreement has been established.

(Appendix 2)
In the step of receiving the contract data, by obtaining information on the first group of users and the second user, and comparing the email addresses of the first group of users with the email addresses of the second users, the first 2. The program according to claim 1, wherein the program of claim 1 determines (S732) that the group of and the second user are contract parties of different affiliations.

(Appendix 3)
In the step of receiving the contract data, by comparing the e-mail addresses of the users of the first group and the e-mail addresses of the second users and determining whether the domain parts are different, the contract parties who conclude the electronic contract 3. The program according to claim 2, which distinguishes between different affiliations and presents the distinguished result to at least one of the first group of users and the second user (S732).

(Appendix 4)
In the contract data receiving step, the number of second users involved in the conclusion of the electronic contract is determined by acquiring the information of the second users, and based on the result of the determination, the number of persons who should be involved in the conclusion of the electronic contract. 3. The program according to claim 2, wherein the number of users in the first group is determined and the results of the determination are presented to at least one of the first group of users or the second user.

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

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

(Appendix 7)
In the managing step, user candidates to be set as the first user are extracted based on the history of contracts concluded by the first group, and the extracted user candidates are used to conclude contracts with the second user. 13. The program of claim 1, presenting (1310B) to a first group of users information that is suggested for inclusion by users of.

(Appendix 8)
In the managing step, the contract data to be managed as an agreement established, the information of the user who approved the contract data, and the information of the timing when the user approved the contract data are associated and stored in the storage unit. (2024), the program of claim 1.

(Appendix 9)
In the managing step, at least one of information of the user who performed the approval, which is information stored in association with the contract data in response to a request to view the contract data, and information of the timing at which the user performed the approval. 9. The program according to claim 8, wherein the contract data is presented to the user who made the viewing request without viewing the contract data (1210C).

(Appendix 10)
A method of operating a computer, the computer for effecting electronic contracts between a plurality of corporate or individual users, the method comprising: a processor of the computer configured by a plurality of users; a step of accepting settings of a first user who will be an approver when concluding an electronic contract in the group; and specifying a user of the first group from a second user different from the users of the first group a step of receiving information and contract data to conclude an electronic contract with the first group; a step of requesting the specified user to perform an operation of approving the conclusion of the contract of the contract data; irrespective of whether or not the first user is included in the information of the user who has received the contract data, the step of requesting the first user to perform an operation of approving the conclusion of the contract in the contract data; a step of managing the contract data in a computer, assuming that an agreement has been reached between the first group and the second user or a second group including the second user with respect to the contract data by accepting the operation of and how to perform.

(Appendix 11)
An information processing apparatus comprising a control unit, the information processing apparatus being for making an electronic contract concluded between a plurality of corporate or individual users, the control unit comprising a plurality of users. a step of accepting settings of a first user who will be an approver when concluding an electronic contract in the group; and specifying a user of the first group from a second user different from the users of the first group a step of receiving information and contract data to conclude an electronic contract with the first group; a step of requesting the specified user to perform an operation of approving the conclusion of the contract of the contract data; irrespective of whether or not the first user is included in the information of the user who has received the contract data, the step of requesting the first user to perform an operation of approving the conclusion of the contract in the contract data; a step of managing the contract data in a computer, assuming that an agreement has been reached between the first group and the second user or a second group including the second user with respect to the contract data by accepting the operation of and an information processing device that executes

1: electronic contract system, 10: receiver 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 transmission 163: transfer destination approver setting 164: approval history 191: input operation reception unit 192: transmission/reception unit 193: data processing unit 194: notification control unit 201: communication Unit 202: Storage unit 203: Control unit 2021: Electronic contract management database 2022: Sending approver information 2023: Forwarding approver setting 2024: Approval history 2031: Receiving control module 2032: Sending control Module 2033: Electronic contract information acquisition module 2034: Approver user information acquisition module 2035: Approval date and time information acquisition module

Claims (11)

A program for operating a computer,
The computer is for making an electronic contract between a plurality of users who are corporations or individuals,
The program causes the processor of the computer to:
a step of receiving a setting of a first user who will be an approver when concluding the electronic contract in a first group composed of a plurality of users;
a step of receiving, from a second user different from the first group of users, information identifying the first group of users and contract data with which the electronic contract is to be concluded with the first group; and,
When the first user who is the approver is not set in the first group, requesting the user specified by the second user to perform an operation of approving the contract conclusion of the contract data. and
whether or not the first user is included in the user information specified by the second user when the first user who is the approver is set in the first group; requesting the first user to perform an operation of approving the conclusion of a contract of the contract data;
By accepting the operation to approve from the requested user, it is assumed 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. , and managing the contract data in the computer. In the step of accepting contract data, acquiring information on the first group of users and the second user, and comparing the email addresses of the first group of users with the email addresses of the second user. determines that the first group and the second user are contract parties from different affiliations. In the step of accepting the contract data, the electronic contract is concluded by comparing the e-mail addresses of the users of the first group and the e-mail addresses of the second users and determining whether the domain portions are different. 3. The program according to claim 2, wherein different affiliations of contracting parties are distinguished, and the distinguished result is presented to at least one of the first group of users or the second user. In the step of receiving the contract data, the number of the second users involved in the conclusion of the electronic contract is determined by acquiring the information of the second user, and based on the determination result, the electronic contract The program according to claim 2, wherein the number of users in the first group that should be involved in the conclusion of is specified, and the specified result is presented to at least one of the users in the first group or the second user . 2. The program according to claim 1, wherein, in said managing step, the title of the users who have approved said contract data is determined based on the order of approval of said plurality of users who have approved said contract data in said first group. 6. The program according to claim 5, wherein, in said managing step, candidates for users to be set as said first users in said first group are extracted based on a result of determining said positions. In the managing step, user candidates to be set as the first user are extracted based on the contract conclusion history of the first group, and the extracted user candidates are sent to the second user. 2. The program according to claim 1, wherein the first group of users is presented with information that is suggested to be included in a user entering into a contract with the user. In the managing step, the contract data managed assuming that the agreement has been established, information on a user who has given approval to the contract data, and information on the timing at which the user has given approval are associated with each other in a storage unit. 2. The program according to claim 1, stored in a . In the managing step, in response to a request to view the contract data, the information of the user who gave the approval and the information of the timing at which the user gave the approval, which are information to be stored in association with the contract data. 9. The program according to claim 8, wherein the contract data is presented to the user who made the viewing request without viewing at least one of. A method of operating a computer comprising:
The computer is for making an electronic contract between a plurality of users who are corporations or individuals,
The method comprises: a processor of the computer comprising:
a step of receiving a setting of a first user who will be an approver when concluding the electronic contract in a first group composed of a plurality of users;
a step of receiving, from a second user different from the first group of users, information identifying the first group of users and contract data with which the electronic contract is to be concluded with the first group; and,
When the first user who is the approver is not set in the first group, requesting the user specified by the second user to perform an operation of approving the contract conclusion of the contract data. and
whether or not the first user is included in the user information specified by the second user when the first user who is the approver is set in the first group; requesting the first user to perform an operation of approving the conclusion of a contract of the contract data;
By accepting the operation to approve from the requested user, it is assumed 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. and managing said contract data in said computer. An information processing device comprising a control unit,
The information processing device is for concluding an electronic contract between a plurality of users who are corporations or individuals,
The control unit
a step of receiving a setting of a first user who will be an approver when concluding the electronic contract in a first group composed of a plurality of users;
a step of receiving, from a second user different from the first group of users, information identifying the first group of users and contract data with which the electronic contract is to be concluded with the first group; and,
When the first user who is the approver is not set in the first group, requesting the user specified by the second user to perform an operation of approving the contract conclusion of the contract data. and
whether or not the first user is included in the user information specified by the second user when the first user who is the approver is set in the first group; requesting the first user to perform an operation of approving the conclusion of a contract of the contract data;
By accepting the operation to approve from the requested user, it is assumed 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. and a step of managing the contract data in the information processing device.