JP7827604B2 - Program, information processing device, information processing system, and information processing method - Google Patents

Description

This disclosure relates to a program, an information processing device, an information processing system, and an information processing method.

With the development and spread of computer technology, documents that were previously stored on paper are being digitized. For example, documents such as contracts that require the signatures and seals of the parties involved are being considered for management as electronic data.
Japanese Patent Laid-Open No. 2003-144222 discloses a data storage destination restriction device that can restrict data storage destinations for each user group within a company.
Patent Document 2 discloses an information processing system relating to digital contracts that includes a creator terminal, a verification company terminal, and a contract management server.

JP 2021-51345 A JP 2017-10096 A

In electronic contract systems, when information about an electronic contract (contract information) is received from the sender, there may be cases where there is no designated person in the recipient's organization who will be responsible for concluding the contract, or the recipient himself/herself is not authorized to conclude (sign) the contract within the recipient's organization, and separate approval from a specific department or person with authority is required.In such cases, it is necessary to ask the sender to designate a recipient for the contract information, which is a cumbersome process.
Therefore, the present disclosure has been made to solve the above-mentioned problems, and its purpose is to provide a technology in an electronic contract system that executes electronic contract procedures, which forwards contract information sent from a sender to a designated contact point without requiring the sender to perform the complicated task of setting up a receiver.

A program comprising a processor and a storage unit for causing a computer to execute electronic contract procedures between users belonging to different organizations, the program causing the processor to execute a contract acceptance step for accepting contract information to be the subject of a contract from a first user, a recipient acceptance step for accepting second identification information from the first user as the recipient of the contract information accepted in the contract acceptance step, and a transfer step for transferring the contract information accepted in the contract acceptance step to one or more third users based on the second identification information accepted in the recipient acceptance step.

According to the present disclosure, contract information sent in response to the second identification information can be forwarded to a third user who is a designated contact point. The third user who is the contact point can approve the contract information themselves or forward the contract information to an appropriate approver.

1 is a diagram showing the overall configuration of an information processing system 1. FIG. 2 is a block diagram showing the functional configuration of the server 10. FIG. 2 is a block diagram showing the functional configuration of a first user terminal 20. FIG. 2 is a block diagram showing the functional configuration of a second user terminal 30. FIG. 2 is a block diagram showing the functional configuration of a third user terminal 40. FIG. 2 is a block diagram showing the functional configuration of a fourth user terminal 41. FIG. 10 is a diagram showing the data structure of a user table 1012. FIG. 10 is a diagram showing the data structure of a group table 1013. FIG. 10 is a diagram showing the data structure of a document table 1014. FIG. 10 is a diagram showing the data structure of a confirmation table 1015. FIG. 10 is a diagram showing the data structure of an input item table 1016. FIG. 10 is a diagram showing the data structure of a transfer management table 1017. 10 is a flowchart showing the operation of a contract creation process. 10 is a flowchart showing the operation of a contract confirmation process. 10 is a screen example showing the operation of a contract creation process. 10 is a screen example showing a message sent to the second user terminal 30. 10 is a screen example of a first screen showing the operation of the contract confirmation process. 10 is a screen example of a second screen (first embodiment) showing the operation of the contract confirmation process. 10 is a screen example of a second screen (second embodiment) showing the operation of the contract confirmation process. 10 is a screen example of a third screen showing the operation of the contract confirmation process. FIG. 2 is a block diagram showing the basic hardware configuration of a computer 90.

Embodiments of the present disclosure will be described below with reference to the drawings. In all figures describing the embodiments, common components will be designated by the same reference numerals, and repeated explanations will be omitted. Note that the following embodiments do not unduly limit the content of the present disclosure as described in the claims. Furthermore, not all components shown in the embodiments are necessarily essential components of the present disclosure. Furthermore, each figure is a schematic diagram and is not necessarily a precise illustration.

<Configuration of System 1>
The system 1 in the present disclosure is an information processing system for realizing an electronic contract conclusion service between multiple users.
The system 1 includes information processing devices, namely, a server 10, a first user terminal 20, a second user terminal 30, a third user terminal 40, and a fourth user terminal 41, which are connected via a network N.
FIG. 1 is a diagram showing the overall configuration of an information processing system 1.
FIG. 2 is a block diagram showing the functional configuration of the server 10. As shown in FIG.
FIG. 3 is a block diagram showing the functional configuration of the first user terminal 20. As shown in FIG.
FIG. 4 is a block diagram showing the functional configuration of the second user terminal 30. As shown in FIG.
FIG. 5 is a block diagram showing the functional configuration of the third user terminal 40. As shown in FIG.
FIG. 6 is a block diagram showing the functional configuration of the fourth user terminal 41.

Each information processing device is composed of a computer equipped with an arithmetic unit and a storage device. The basic hardware configuration of the computer and the basic functional configuration of the computer realized by this hardware configuration are described below. For each of the server 10, first user terminal 20, second user terminal 30, third user terminal 40, and fourth user terminal 41, descriptions that overlap with the basic hardware configuration and basic functional configuration of the computer described below will be omitted.

<Configuration of Server 10>
The server 10 is an information processing device that provides an electronic contract conclusion service between multiple users.
The server 10 includes a storage unit 101 and a control unit 104 .

<Configuration of the storage unit 101 of the server 10>
The storage unit 101 of the server 10 includes an application program 1011 , a user table 1012 , a group table 1013 , a document table 1014 , a confirmation table 1015 , an input item table 1016 , and a transfer management table 1017 .

The application program 1011 is a program that causes the control unit 104 of the server 10 to function as each functional unit.

The user table 1012 is a table that stores and manages information about member users (hereinafter referred to as users) who use the service. When a user registers to use the service, the user's information is stored in a new record in the user table 1012.
This allows the user to use the service according to the present disclosure. Note that the user who uses the service according to the present disclosure does not necessarily need to be registered in the user table 1012.
The user table 1012 is a table having a user ID as a primary key and columns of user ID, user name, email address, group ID, and approval authority.
FIG. 7 is a diagram showing the data structure of the user table 1012.

The user ID is an item for storing user identification information for identifying a user, and a unique value is set for each user in the user identification information.
The user name is an item for storing the name of the user. The user name may be set to any character string such as a nickname instead of a name.
The email address is an item for storing the email address of the user.
The group ID is an item for storing group identification information of a group to which a user belongs. A user may belong to multiple groups.
The approval authority is an item that stores authority information regarding the approval of a user. For a user who has the authority to approve the conclusion of a contract (approval authority), information indicating that the user has the authority to approve the conclusion of a contract, such as True, is stored. On the other hand, for a user who does not have the authority to approve the conclusion of a contract, information indicating that the user does not have the authority to approve the conclusion of a contract, such as False, blank, or null value, is stored.
Alternatively, information indicating that the user has the role of a contact person within the group (contact role information) may be stored. In this way, a user whose contact role information is stored in the approval authority can be determined to be a contact person.
The system may be configured so that approval authority can be set depending on the contract information. For example, a system may be configured so that user A has approval authority for specific contract information A but does not have approval authority for specific contract information B.
The system may be configured so that approval authority can be set according to the type of contract information (contract information type), such as a confidentiality agreement, a joint research agreement, a contract for work, etc. For example, the system may be configured so that user A has approval authority for a confidentiality agreement but does not have approval authority for a contract for work.
Alternatively, the system may be configured to store multiple levels (levels, ranks) of authority information depending on the user's department, government office, etc. For example, information such as C for temporary staff, B for regular employees, A for managers, and S for executives may be stored in the approval authority field, and only users with approval authority of a predetermined rank or higher (e.g., A or higher for a confidentiality agreement) may be able to approve the conclusion of a contract depending on the contract type information, contract amount, etc. of the contract information.

The group table 1013 is a table that stores and manages information (group information) about groups to which a user belongs. The group can define any group to which a user belongs, such as a corporation, a company, a club, an organization, or a department within a company.
The group table 1013 is a table having the group ID as a primary key and columns of group ID, group name, and administrator ID.
FIG. 8 is a diagram showing the data structure of the group table 1013.

The group ID is an item for storing group identification information for identifying a group, and a unique value is set for each group.
The group name is an item for storing the name of the group. Any character string can be set as the group name.
The administrator ID is an item for storing user identification information of a user who has administrator authority in a group. A user with administrator authority can arbitrarily define and set a user who has a certain or higher position or authority in a group such as an organization.

The document table 1014 is a table for storing and managing information (contract information) relating to an electronic contract exchanged between a creator and a recipient.
The document table 1014 is a table having a document ID as a primary key and columns of document ID, document data, and creator ID.
FIG. 9 is a diagram showing the data structure of the document table 1014. As shown in FIG.

The document ID is an item for storing document identification information for identifying contract information. The document identification information is an item for which a unique value is set for each contract information.
The document data is an item that stores contract information (binary or text data).
Creator ID is an item for storing user identification information for identifying the user who created the contract information.

The confirmation table 1015 is a table that stores and manages information (checker information) including the email addresses of users who will be checkers of contract information.
The confirmation table 1015 is a table having columns for document ID, confirmation order, designated person data, confirmer email address, confirmation flag, language data, access code, and date and time.
FIG. 10 is a diagram showing the data structure of the confirmation table 1015.

The document ID is an item for storing document identification information of the contract information to be checked by the checker.
The confirmation order is an item for storing information regarding the confirmation order when the contract information is confirmed by the confirmer. The contract information stored by the creator is circulated to the confirmers in the confirmation order and confirmed.
The designated person data is an item for storing information for identifying a user who designated a person to check the contract information. Specifically, the designated person data includes information for identifying a user, such as an email address or user identification information.
The checker email address is an item that stores the email address of the checker of the contract information. The checker's email address does not need to be registered in advance as a user to use the service disclosed herein. In other words, the checker's email address does not need to be included in the user table 1012.
The confirmation flag is an item for storing confirmation identification information for identifying whether or not the confirming procedure for the contract information has been completed by the confirming person. When the confirming person has completed the confirmation of the contract information, information indicating that the confirmation has been completed, such as a value of True, is stored in the confirmation flag item.
The language data is an item for storing information (language information) related to the language of the verifyer.
The access code is an item for storing an access code set for the verifying person.
The date and time is an item for storing the date and time when the checker performed the procedure for checking the contract information. Specifically, the date and time when the check identification information was stored in the check flag item is stored.

The input item table 1016 is a table that stores and manages information (input item information) related to input items associated with electronic contract information.
The input item table 1016 is a table having columns of input item ID, document ID, inputter ID, input data, input rule, and date and time.
FIG. 11 is a diagram showing the data structure of the input item table 1016.

The input item ID is an item that stores input item identification information for identifying an input item.
The document ID is an item that stores document identification information of the electronic contract information with which the input item is associated.
The inputter ID is an item that stores the user identification information or email address of the inputter who entered the input data into the input item. Specifically, the inputter ID stores the creator ID, the email address of the user identified by the creator ID, the email address of the verifying person, etc.
The input data is an item that stores input data entered into an input item by a user.
The input rule is a field that stores input rule information related to the input rules of input items. The input rule can store input rule information related to the input rules of any input item, such as data types such as date, datetime, text, and integer, as well as the number of characters in the case of text, regular expressions for text, etc.
The date and time is an item for storing the date and time when the inputter inputs the input data into the input item.

The transfer management table 1017 is a table that stores and manages information relating to transfer conditions (transfer condition information).
The transfer management table 1017 is a table having columns for transfer conditions and transfer destination user IDs.
FIG. 12 is a diagram showing the data structure of the transfer management table 1017.

The forwarding conditions are items for storing conditions for forwarding to a user specified by a forwarding destination user ID.
For example, the forwarding conditions can store predetermined user identification information and email addresses. That is, contract information with specific user identification information and email addresses as the destination can be specified and forwarded to a user with a specific forwarding destination user ID.
For example, the forwarding condition can store predetermined group identification information, which means that contract information having a user associated with a specific group identification information as the destination can be specified and forwarded to a user having a specific destination user ID.
For example, the transfer conditions can store predetermined contract type information. That is, contract information having specific contract type information can be identified and transferred to a user having a specific transfer destination user ID.
For example, the transfer conditions can store information about the contract amount (contract amount information). That is, contract information whose contract amount is equal to or less than a predetermined amount can be specified and transferred to a user with a specific transfer destination user ID.
For example, the forwarding conditions can store information about the creator (creator information). That is, the creator information, such as whether the user related to the creator (sender) is a specific user or a user belonging to a specific group, can be specified, and the message can be forwarded to a user with a specific destination user ID. A specific user ID can be set as the destination depending on the company or organization to which the creator belongs.
The transfer conditions may include a combination of conditions for user identification information, group identification information, contract type information, contract amount information, creator information, and the like.
A user with administrator authority can store the transfer conditions in association with the transfer destination user ID by operating the administrator terminal. A user with administrator authority may be configured to store only users who belong to the group ID associated with his/her own user ID in the group table 1013 as the transfer destination user ID. In other words, a user with administrator authority may be configured to store other users who belong to the group to be managed as the transfer destination user ID. This prevents a user with administrator authority from transferring contract information to a user outside the management scope.
The forwarding destination user ID is an item for storing the user identification information of the forwarding destination user. Instead of the user identification information, the email address of the forwarding destination user may be stored.

<Configuration of the control unit 104 of the server 10>
The control unit 104 of the server 10 includes a user registration control unit 1041, a contract creation unit 1042, and a contract confirmation unit 1043. The control unit 104 executes an application program 1011 stored in the storage unit 101, thereby realizing each functional unit.

The user registration control unit 1041 performs processing to store information about users who wish to use the service according to the present disclosure in the user table 1012 .
The information stored in the user table 1012 is entered when a user opens a web page operated by a service provider from any information processing terminal, enters information into a predetermined input form, and sends the information to the server 10. The user registration control unit 1041 stores the received information in a new record in the user table 1012, completing the user registration. This allows the user stored in the user table 1012 to use the service.
Before the user registration control unit 1041 registers the user information in the user table 1012, the service provider may conduct a predetermined examination to restrict whether or not the user is permitted to use the service.
The user ID may be any character string or number that can identify the user, any character string or number desired by the user, or may be automatically set by the user registration control unit 1041.

The contract creation unit 1042 executes the contract creation process. Details will be described later.

The contract confirmation unit 1043 executes the contract confirmation process. Details will be described later.

<Configuration of First User Terminal 20>
The first user terminal 20 is an information processing device operated by a user who uses the service. The first user terminal 20 may be, for example, a desktop personal computer (PC) or a laptop PC, or may be a mobile terminal such as a smartphone or a tablet. It may also be a wearable terminal such as an HMD (Head Mount Display) or a wristwatch terminal.
The first user terminal 20 includes a storage unit 201 , a control unit 204 , an input device 206 , and an output device 208 .

<Configuration of the storage unit 201 of the first user terminal 20>
The storage unit 201 of the first user terminal 20 includes a first user ID 2011 and an application program 2012 .

The first user ID 2011 is the user's account ID. The user transmits the first user ID 2011 from the first user terminal 20 to the server 10. The server 10 identifies the user based on the first user ID 2011 and provides the user with the services disclosed herein. The first user ID 2011 includes information such as a session ID temporarily assigned by the server 10 to identify the user using the first user terminal 20.

The application program 2012 may be stored in advance in the storage unit 201, or may be configured to be downloaded from a web server operated by a service provider via a communication IF.
The application programs 2012 include applications such as a web browser application.
The application program 2012 includes an interpreted programming language such as JavaScript (registered trademark) that runs on a web browser application stored on the first user terminal 20 .

<Configuration of the control unit 204 of the first user terminal 20>
The control unit 204 of the first user terminal 20 includes an input control unit 2041 and an output control unit 2042. The control unit 204 executes the first user ID 2011 stored in the storage unit 201, thereby realizing each functional unit.

<Configuration of the input device 206 of the first user terminal 20>
The input device 206 of the first user terminal 20 includes a camera 2061 , a microphone 2062 , a position information sensor 2063 , a motion sensor 2064 , and a touch device 2065 .

<Configuration of the output device 208 of the first user terminal 20>
The output device 208 of the first user terminal 20 includes a display 2081 and a speaker 2082 .

<Configuration of second user terminal 30>
The second user terminal 30 is an information processing device operated by a user who uses the service. The second user terminal 30 may be, for example, a desktop personal computer (PC) or a laptop PC, or may be a mobile terminal such as a smartphone or a tablet. It may also be a wearable terminal such as an HMD (Head Mount Display) or a wristwatch terminal.
The second user terminal 30 includes a storage unit 301 , a control unit 304 , an input device 306 , and an output device 308 .

<Configuration of the storage unit 301 of the second user terminal 30>
The storage unit 301 of the second user terminal 30 includes a second user ID 3011 and an application program 3012 .

The second user ID 3011 is the user's account ID. The user transmits the second user ID 3011 from the second user terminal 30 to the server 10. The server 10 identifies the user based on the second user ID 3011 and provides the user with the services disclosed herein. The second user ID 3011 includes information such as a session ID temporarily assigned by the server 10 to identify the user using the second user terminal 30.

The application program 3012 may be stored in advance in the storage unit 301, or may be configured to be downloaded from a web server operated by a service provider via a communication IF.
Application programs 3012 include applications such as a web browser application.
The application program 3012 includes an interpreted programming language such as JavaScript (registered trademark) that runs on a web browser application stored on the second user terminal 30 .

<Configuration of the control unit 304 of the second user terminal 30>
The control unit 304 of the second user terminal 30 includes an input control unit 3041 and an output control unit 3042. The control unit 304 executes the second user ID 3011 stored in the storage unit 301, thereby realizing each functional unit.

<Configuration of the input device 306 of the second user terminal 30>
The input device 306 of the second user terminal 30 includes a camera 3061 , a microphone 3062 , a position information sensor 3063 , a motion sensor 3064 , and a keyboard 3065 .

<Configuration of the output device 308 of the second user terminal 30>
The output device 308 of the second user terminal 30 includes a display 3081 and a speaker 3082 .

<Configuration of third user terminal 40>
The third user terminal 40 is an information processing device operated by a user who uses the service. The third user terminal 40 may be, for example, a desktop personal computer (PC) or a laptop PC, or may be a mobile terminal such as a smartphone or a tablet. It may also be a wearable terminal such as an HMD (Head Mount Display) or a wristwatch terminal.
The third user terminal 40 includes a storage unit 401 , a control unit 404 , an input device 406 , and an output device 408 .

<Configuration of the storage unit 401 of the third user terminal 40>
The storage unit 401 of the third user terminal 40 includes a third user ID 4011 and an application program 4012 .

The third user ID 4011 is the user's account ID. The user transmits the third user ID 4011 from the third user terminal 40 to the server 10. The server 10 identifies the user based on the third user ID 4011 and provides the user with the services disclosed herein. The third user ID 4011 includes information such as a session ID temporarily assigned by the server 10 to identify the user using the third user terminal 40.

The application program 4012 may be stored in advance in the storage unit 401, or may be configured to be downloaded from a web server operated by a service provider via a communication IF.
The application programs 4012 include applications such as a web browser application.
The application program 4012 includes an interpreted programming language such as JavaScript (registered trademark) that runs on a web browser application stored on the third user terminal 40 .

<Configuration of the control unit 404 of the third user terminal 40>
The control unit 404 of the third user terminal 40 includes an input control unit 4041 and an output control unit 4042. The control unit 404 executes the third user ID 4011 stored in the storage unit 401, thereby realizing each functional unit.

<Configuration of the input device 406 of the third user terminal 40>
The input device 406 of the third user terminal 40 includes a camera 4061 , a microphone 4062 , a position information sensor 4063 , a motion sensor 4064 , and a keyboard 4065 .

<Configuration of the output device 408 of the third user terminal 40>
The output device 408 of the third user terminal 40 includes a display 4081 and a speaker 4082 .

<Configuration of Fourth User Terminal 41>
The fourth user terminal 41 is an information processing device operated by a user who uses the service. The fourth user terminal 41 may be, for example, a desktop personal computer (PC) or a laptop PC, or may be a mobile terminal such as a smartphone or a tablet. It may also be a wearable terminal such as an HMD (Head Mount Display) or a wristwatch terminal.
The fourth user terminal 41 includes a storage unit 411 , a control unit 414 , an input device 416 , and an output device 418 .

<Configuration of the storage unit 411 of the fourth user terminal 41>
The storage unit 411 of the fourth user terminal 41 includes a fourth user ID 4111 and an application program 4112 .

The fourth user ID 4111 is the user's account ID. The user transmits the fourth user ID 4111 from the fourth user terminal 41 to the server 10. The server 10 identifies the user based on the fourth user ID 4111 and provides the user with the services disclosed herein. The fourth user ID 4111 includes information such as a session ID temporarily assigned by the server 10 to identify the user using the fourth user terminal 41.

The application program 4112 may be stored in advance in the storage unit 411, or may be configured to be downloaded from a web server operated by a service provider via a communication IF.
Application programs 4112 include applications such as a web browser application.
The application program 4112 includes an interpreter programming language such as JavaScript (registered trademark) that runs on a web browser application stored in the fourth user terminal 41 .

<Configuration of the control unit 414 of the fourth user terminal 41>
The control unit 414 of the fourth user terminal 41 includes an input control unit 4141 and an output control unit 4142. The control unit 414 executes the fourth user ID 4111 stored in the storage unit 411, thereby realizing each functional unit.

<Configuration of the input device 416 of the fourth user terminal 41>
The input device 416 of the fourth user terminal 41 includes a camera 4161 , a microphone 4162 , a position information sensor 4163 , a motion sensor 4164 , and a keyboard 4165 .

<Configuration of the output device 418 of the fourth user terminal 41>
The output device 418 of the fourth user terminal 41 includes a display 4181 and a speaker 4182 .

<Operation of Information Processing System 1>
Each process of the information processing system 1 will be described below.
FIG. 13 is a flowchart showing the operation of the contract creation process.
FIG. 14 is a flowchart showing the operation of the contract confirmation process.
FIG. 15 is an example of a screen showing the operation of the contract creation process.
FIG. 16 is an example of a screen showing a message sent to the second user terminal 30. In FIG.
FIG. 17 is an example of the first screen showing the operation of the contract confirmation process.
FIG. 18 is an example of a second screen (first embodiment) showing the operation of the contract confirmation process.
FIG. 19 is an example of a second screen (second embodiment) showing the operation of the contract confirmation process.
FIG. 20 is an example of the third screen showing the operation of the contract confirmation process.

<Contract creation process>
The contract creation process is a process in which a creator creates contract information and sends it to a verifyer. In the present disclosure, a first user is a user who creates the contract information, and a second user, a third user, and a fourth user are users who verify the contract information. Note that when creating contract information, multiple users can be set as verifyers.
In the present disclosure, the first user is a user who belongs to a group such as an organization or company that is different from the second user, and the second user, the third user, and the fourth user are users who belong to the same group such as an organization or company.

Figure 13 is an example screen showing the operation of the contract creation process. The screen 50 for creating contract information, displayed on the display 2081 of the first user terminal 20, displays a status 510 indicating the current creation status of the contract information, buttons 521, 522, and 523 for specifying input fields, a contract information display area 530, document data 531, input fields 532, 533, and 534, and a send button 540.

<Outline of contract creation process>
The contract creation process is a series of steps in which the creator creates contract information, sets the verifying party to whom the contract information will be sent, sets input fields for the contract information, sets input rules for the input fields, accepts input data for the input fields from the creator, determines transfer conditions, and sends the contract information to the verifying party or transfer destination that has been set.

<Details of contract creation process>
In step S101, the contract creation unit 1042 of the server 10 receives, from the creator, contract information to be the subject of a contract to be concluded between the creator and the verifying party.
Specifically, the first user operates the input device 206 of the first user terminal 20 to create contract information including document data related to the contract. The document data can be in any data format, such as Portable Document Format (PDF), Word, or Extensible Markup Language (XML), and the contract information can include such document data.
The first user operates the input device 206 of the first user terminal 20 to send the created document data and the first user ID 2011 to the server 10. The contract creation unit 1042 of the server 10 accepts the received first user ID 2011 and document data, and stores them in the creator ID and document data fields of a new record in the document table 1014, respectively. As a result, the contract creation unit 1042 of the server 10 stores the new contract information in the document table 1014.

The screen 50 for creating contract information displays document data 531 stored in the document table 1014.

In step S102, second identification information is received from the first user as the recipient of the contract information received in step S101. For example, the second identification information is information for identifying the second user. The second identification information may include the email address or second user ID of the second user. In the present disclosure, an email address will be described as an example of second identification information. Note that the second identification information does not need to be information for identifying a specific user, but may include identification information for identifying a specific group such as a company, organization, group, or department. Specifically, the first user can specify, as the second identification information, a specific department of a specific company, rather than a user, as the recipient of the contract information.
Specifically, the first user operates the input device 206 of the first user terminal 20 to select and identify a user who will be the confirmer (recipient) of the contract information. In the present disclosure, it is assumed that the first user selects and identifies a second user as the recipient.
The first user operates the input device 206 of the first user terminal 20 to input the email address of the second user who will be the checker, and transmits it to the server 10. The contract creation unit 1042 of the server 10 stores the received email address and the document ID of the contract information created and stored in step S101 in the checker email address and document ID fields of the confirmation table 1015, respectively, and associates the contract information with the email address of the second user and stores them. The first user may also set the language and access code of the second user and store them in association with the email address of the second user.
At this time, a value of 1 is stored in the confirmation order field of the confirmation table 1015. In step S102, the first user may be able to select and set multiple users to be the checkers. In this case, the value of the confirmation order field for the users to be the checkers is incremented by one and stored according to the selection order. This sets the circulation order of the checkers in the contract confirmation process, which will be described later. Note that setting the circulation order is not essential.

In step S103, the first user operates the input device 206 of the first user terminal 20 to set input items for the contract information.
Specifically, the first user operates the input device 206 of the first user terminal 20 to set multiple input items for the contract information created and stored in step S101. The input items can be any input items such as a seal field for stamping seal data, an input field for inputting text data such as signature data, a check box field for selecting check items, a date field for inputting a date, etc.
The first user operates the input device 206 of the first user terminal 20 to send a request to add an input item to the server 10. When the contract creation unit 1042 of the server 10 receives the request, it stores the document ID of the contract information as the document ID of a new record in the input item table 1016. As a result, the newly added input item information is stored in association with the contract information. The first user can store multiple pieces of input item information in association with the contract information.

In step S104, the first user sets input rules for each input item to be added. The first user operates the input device 206 of the first user terminal 20, etc., to specify input rules for each input item information set in step S103 and transmits them to the server 10. The contract creation unit 1042 of the server 10 stores the received input rules in the input rule field of the record for each input item information in the input item table 1016. This makes it possible to set input rules for each input item.

In step S105, the contract creation unit 1042 of the server 10 accepts input data for a plurality of input items input by the first user.
Specifically, the first user operates the input device 206 of the first user terminal 20 to input input data for each input item set in step S104. For example, the first user may input input data for a number used to manage contract information, such as a serial number for the group to which the first user belongs, into an input item for which a management number is set. The first user may input input data for the contract conclusion date of the contract information into an input item for which a contract conclusion date is set. After completing input of input data into the input items, the first user transmits the input item ID and input data for each input item to the server 10.
The contract creation unit 1042 of the server 10 receives and accepts the input item ID and input data for each input item. The contract creation unit 1042 of the server 10 stores the received input data in the input data item of the input item information in the input item table 1016 identified by the received input item ID. As a result, the input data entered by the first user is stored in the input item table 1016.

The contract creation unit 1042 of the server 10 receives an instruction from the first user to request the second user to conclude a contract based on the contract information.
Specifically, the first user operates the input device 206 of the first user terminal 20 and presses the send button 540 displayed on the screen 50 for creating contract information, thereby sending a request to send the contract information to the server 10.

In step S106, upon receiving the request, the contract creation unit 1042 of the server 10 transfers the contract information received in step S101 to one or more third users based on the second identification information received in step S102.

Specifically, in step S102, the contract creation unit 1042 of the server 10 acquires the checker's email address stored in the confirmation table 1015. Based on the acquired checker's email address, the contract creation unit 1042 of the server 10 searches the email address field in the user table 1012 and acquires the checker's user ID.
The contract creation unit 1042 of the server 10 searches the transfer condition items in the transfer management table 1017 based on the acquired user ID of the checker, and acquires the transfer destination user ID. Specifically, if there is a transfer condition in which the acquired checker user ID is set as the checker user ID in the transfer condition, the transfer destination user ID associated with the transfer condition is acquired.
The contract creation unit 1042 of the server 10 may search the transfer condition items in the transfer management table 1017 based on the user ID of the checker, contract type information, the contract amount specified in the contract information, creator information, etc., to obtain the transfer destination user ID. The contract creation unit 1042 of the server 10 may be configured to identify and obtain multiple transfer destination user IDs. In the present disclosure, the transfer destination user ID includes, for example, a third user ID.

The contract creation unit 1042 of the server 10 searches the user ID field in the user table 1012 based on the acquired transfer destination user ID, and acquires the email address of the transfer destination user. The contract creation unit 1042 of the server 10 acquires the document ID, confirmation order, designated person data, language data, and access code fields associated with the second user from the confirmation table 1015, associates them with the email address of the transfer destination user, and stores them in the document ID, confirmation order, designated person data, language data, access code, and checker email address fields of a new record in the confirmation table 1015, respectively.
When multiple destination users are specified, the contract creation unit 1042 of the server 10 may be configured to store a value incremented by one from the value of the confirmation order item of the second user in the confirmation order item of the record of each destination user. In this case, the contract creation unit 1042 of the server 10 may be configured to move down and store (update) the confirmation order value of the record of a checker who is later in the confirmation order (higher in the confirmation order) when a specific destination user is added to the record of the confirmation table 1015. This makes it possible to replace the transfer source user with the destination user while maintaining the confirmation order when multiple checkers are specified.
Furthermore, the contract creation unit 1042 of the server 10 stores information indicating that the confirmation process has been skipped due to the transfer in the confirmation flag field of the record of the second user stored in the confirmation table 1015. The contract creation unit 1042 of the server 10 may be configured to delete the record of the second user from the confirmation table 1015. This causes the contract confirmation process by the second user to be skipped.

In step S107, the contract creation unit 1042 of the server 10 sends a message to the second user or the user who will be the checker, such as the forwarding destination user, notifying that a request to check the contract information has been sent from the first user. Specifically, the contract creation unit 1042 of the server 10 searches the check order field in the check table 1015 and identifies the user who will be the first checker (first checker) with the smallest value stored in the check order field. In the present disclosure, the first checker is, for example, the third user. The contract creation unit 1042 of the server 10 sends a message to the email address of the first checker via a communication means such as email notifying that a request to check the contract information has been sent from the first user.
The message sent to the first confirmation user includes a URL (Uniform Resource Locator) containing a document ID for identifying the contract information. The URL may directly include the document ID, or may include information such as a string obtained by optionally encrypting the document ID, or a string that can identify the document ID by referencing a table (not shown). The URL may also include information for identifying the first confirmation user. For example, if the first confirmation user is not registered as a user with the service disclosed herein, the URL must include information for identifying the first confirmation user.

If the first user sets an access code for the second user, the first user will separately communicate the access code to the first confirmation user by email or other means. This means that even if a third party obtains the message notified to the first confirmation user, the third party will not be able to perform the contract confirmation process unless they obtain the access code.

The contract creation unit 1042 of the server 10 may notify the second user accepted in step S102 that the contract information accepted in step S101 has been forwarded to one or more third users. Specifically, the contract creation unit 1042 of the server 10 searches the confirmation table 1015 for a record in which information indicating that the confirmation process has been skipped is stored in the confirmation flag field, and sends a message to the confirmer email address of that record notifying that the contract information has been forwarded to the first confirmation user.

Figure 16 is an example screen showing a message sent to the third user terminal 40, which is the user terminal of the first confirmation user. The message screen 60 displayed on the display 4081 of the third user terminal 40 includes a message 61 and a URL 62 containing a document ID for identifying the contract information.

<Modification>
When the first user selects and sets multiple checkers in step S102, the first user may be able to independently set different input item information for each of the multiple checkers in step S103. For example, when the first user sets two users, a second user and a ninth user, as checkers, the first user may set the input items for the contract start date and contract end date for the second user and the input item for the contract conclusion date for the ninth user. In this case, in the contract confirmation process described below, the second user can enter input data for the input items for the contract start date and contract end date, but cannot enter input data for the input item for the contract conclusion date. On the other hand, the ninth user cannot enter input data for the input items for the contract start date and contract end date, but can enter input data for the input item for the contract conclusion date. The system may be configured so that multiple checkers can be selected and set for one input item.

Input items 532, 533, and 534 are drawn as drawing objects on screen 50 for creating contract information. Input items 532 and 533 are drawn with the user identification information "USER-B" of the user who has selected and set up to enter the input item as the allocation, and the item "Text" as the input item type. Input item 534 related to stamping is drawn with the user identification information "USER-C" of the user who has selected and set up to stamp as the allocation, and the item "Stamp" as the input item type.

<Contract confirmation process>
The contract confirmation process is a process in which the confirmer confirms the contents of the contract information received from the creator.

<Outline of contract confirmation process>
The contract confirmation process is a series of processes that accepts access from the confirmer, presents the confirmer with a first screen that displays the contract information, accepts input data for input fields from the confirmer, and accepts data related to confirmation of the contract information from the confirmer.
The contract confirmation process is a series of processes in which, if the person confirming the contract does not have the authority to approve the contract information or is a contact point employee, a second screen is presented to the person confirming the contract to select and specify an approver, the person confirming the contract information is selected by the person confirming the contract, the input data for the input fields is accepted by the person confirming the contract, and the contract information is sent to the set approver.
Details of the contract confirmation process for the third user and fourth user, who will be the confirmers in this disclosure, will be described below as details of the contract confirmation process (third user) and details of the contract confirmation process (fourth user), respectively.

<Details of contract confirmation process (third user)>
In step S301, the third user, who is the first confirmation user, operates the input device 406 of the third user terminal 40 or the like to select the URL described in the received message, thereby opening the web page specified by the URL using the browser application of the third user terminal 40. As a result, the third user terminal 40 transmits a request to the server 10 to execute the contract confirmation process.

If an access code item is stored in the record of the third user in confirmation table 1015, the third user is requested to input an access code, and the input access code is compared with the access code stored in the record of the third user in confirmation table 1015, thereby performing authentication processing for the third user.
Specifically, the server 10 transmits an input screen for authenticating the access code to the third user terminal 40. The third user operates the input device 406 of the third user terminal 40 to input the access code and transmit it to the server 10. The contract confirmation unit 1043 of the server 10 determines whether the received access code matches the access code stored in the third user's record in the confirmation table 1015, and if they match, continues the contract confirmation process. On the other hand, if they do not match, stops the contract confirmation process. Note that the authentication process using the access code may be omitted.

The contract confirmation unit 1043 of the server 10 searches the document ID item in the document table 1014 based on the document ID included in the received request and obtains the contract information.The contract confirmation unit 1043 of the server 10 searches the document ID item in the confirmation table 1015 based on the document ID included in the received request and obtains the verifying party information.The contract confirmation unit 1043 of the server 10 searches the document ID item in the input item table 1016 based on the document ID included in the received request and obtains the input item information associated with the contract information.

In step S302, the contract confirmation unit 1043 of the server 10 identifies the third user and obtains the approval authority information of the third user. The third user may be identified based on the third user ID 4011 included in the request received from the third user terminal 40, or based on identification information for identifying the third user included in the URL. If the third user is not registered as a user with the service disclosed herein, the third user must be identified from the URL. For example, the URL may include the third user's email address, user ID, etc. as information for identifying the third user.

The contract confirmation unit 1043 of the server 10 searches the user ID field in the user table 1012 based on the user identification information of the identified third user, and acquires the approval authority field of the third user. Note that in the present disclosure, the approval authority of the third user is configured to be stored in the user table 1012, but the approval authority of the third user may be stored for each group to which the third user belongs, or for each contract information or for each contract information type. The contract confirmation unit 1043 of the server 10 acquires the approval authority information of the third user for the target contract information.
Furthermore, if the third user is not registered as a user for the service according to the present disclosure, the third user may be regarded as a user without approval authority and processing may be executed.

In step S303, the contract confirmation unit 1043 of the server 10 generates the second screen or the first screen based on the acquired contract information, confirmer information (information identifying the third user), input item information, and confirmer approval authority information, and transmits it to the third user terminal 40.

Specifically, if the approval authority information of the third user acquired in step S302 contains information indicating that the third user has the authority to approve the conclusion of the contract, the contract confirmation unit 1043 of the server 10 presents the first screen to the third user and proceeds to step S304.

On the other hand, if the third user is a user who cannot approve the contract conclusion of the received contract information, the second screen is presented to the third user and the process proceeds to step S307. Specifically, if the approval authority information of the third user acquired in step S302 stores information indicating that the user does not have the authority to approve the contract conclusion, the contract confirmation unit 1043 of the server 10 presents the second screen to the third user and the process proceeds to step S307.

If the third user is a user with contact role information, the second screen may be presented to the third user and the process may proceed to step S307. In this case, if the third user is a user who cannot approve the contract conclusion of the received contract information, the execution of the contract confirmation process may be terminated.
This allows the third user to set an approver only if he or she is the person in charge of the contract, and other users who are unable to approve the conclusion of the contract cannot set an approver.

In step S304, the display 4081 of the third user terminal 40 presents the third user with a first screen for accepting an operation to approve the contract information. The third user checks and approves the contract information displayed on the display 4081 of the third user terminal 40.
In addition, the first screen presented to the third user may be configured to be presented to the third user in the language specified for the confirmer, based on the language information stored in the language data item of the third user's record in confirmation table 1015.

Figure 17 is an example of the first screen showing the operation of the contract confirmation process. The first screen 70A for approving contract information, which is displayed on the display 4081 of the third user terminal 40, displays a status 710 indicating the current creation status of the contract information, a contract information display area 730, document data 731, input items 732, 733, 734, 735, 736, and an agree button 740.

In step S305, the contract confirmation unit 1043 of the server 10 accepts input for one or more input items of the contract information.
Specifically, the third user operates the input device 406 of the third user terminal 40 or the like to input data into the input items 732, 733, 734, and 735 set in the contract information. In the present disclosure, input by the third user into the input item 736 is not assigned, and therefore, it is visually displayed that the third user cannot input input data.

In step S306, the contract confirmation unit 1043 of the server 10 receives an instruction from the third user to agree to and approve the conclusion of the contract in the contract information received from the first user.
The third user checks the contract information and input data displayed on the display 4081 of the third user terminal 40, and if he or she agrees or accepts the contents, he or she operates the input device 406 of the third user terminal 40 to press the Agree button 740 displayed on the screen 70 for confirming the contract information, thereby executing a process of transmitting a request including the document ID, information identifying the third user, and the input data for each input item entered in step S305 to the server 10. The information identifying the third user may be the third user ID 4011.
The contract confirmation unit 1043 of the server 10 stores information indicating that the third user has confirmed the contract information based on the received request. Specifically, the contract confirmation unit 1043 of the server 10 searches the confirmation table 1015 based on the received document ID and information identifying the third user, and stores a value of True in the confirmation flag field of the corresponding record. For example, if the information identifying the third user is an email address, the contract confirmation unit 1043 searches the document ID and confirmer email address fields of the confirmation table 1015 and stores a value of True in the confirmation flag field of the corresponding record. If the information identifying the third user is user identification information, the contract confirmation unit 1043 searches the document ID and confirmer email address fields of the confirmation table 1015 based on the email address of the third user identified by searching the user ID field of the user table 1012, and stores a value of True in the confirmation flag field of the corresponding record.
The contract confirmation unit 1043 of the server 10 stores the received input data in the input data item specified by the input item ID associated with the input data in the input item table 1016. As a result, in step S305, the input data entered by the third user is stored as input item information in the input item table 1016.

The contract confirmation unit 1043 of the server 10 determines that the contract confirmation process has been performed by all checkers with approval authority. Specifically, the contract confirmation unit 1043 of the server 10 determines that the contract confirmation process has been performed by all checkers with approval authority when the value of True is stored in the confirmation flag of the record of the checker with approval authority in the confirmation table 1015. In other words, the determination is made by ignoring the value of the confirmation flag of the record of the checker who does not have approval authority.
When the contract confirmation process is performed by all the confirmers with approval authority, the contract confirmation unit 1043 of the server 10 sends a message to the first user notifying that the contract confirmation process has been completed.
Specifically, the contract creation unit 1042 of the server 10 sends a message to the first user's email address via a communication means such as email, notifying the first user that the second user has completed confirmation of the contract information. In other words, the message notifies the first user that the second user has approved the contract conclusion. This allows the first user to know that the contract conclusion with the second user has been completed. The second user can complete the appropriate contract conclusion procedures without the first user knowing that the contract conclusion has been approved by a third user in the organization to which the second user belongs. Note that the message may also include content notifying the third user that the third user has completed confirmation of the contract information.
The message sent to the first user may include information about a URL including a document ID for identifying the contract information.
When multiple users are set as checkers, the contract confirmation unit 1043 of the server 10 may send a message notifying the checkers other than the user who last executed the contract confirmation process that the contract confirmation process has been completed. This allows the checkers to receive notification that the contract confirmation process has been completed by all checkers.
The contract confirmation unit 1043 of the server 10 may also send a message notifying a user with authority equivalent to that of an administrator in a group to which multiple confirmers belong that the contract confirmation process has been completed. This allows the administrator in the group to which the confirmer belongs to be notified that the contract confirmation process has been completed. The contract confirmation unit 1043 of the server 10 acquires the group ID field by searching the user ID or email address field in the user table 1012 based on the user ID or email address. The contract confirmation unit 1043 of the server 10 then searches the group ID field in the group table 1013 based on the acquired group ID field, acquires the administrator ID field, and identifies a user with authority equivalent to that of an administrator by searching the user ID in the user table 1012 based on the administrator ID, and sends a message notifying that the contract confirmation process has been completed.

<Second Screen Presentation Process (First Example)>
In step S307, the display 4081 of the third user terminal 40 presents the third user with a second screen (first embodiment) that accepts an operation to specify users related to one or more approvers.
For example, if the third user is not registered as a user for the service according to the present disclosure, the second screen presentation process (first embodiment) may be executed.
In addition, the second screen presented to the third user may be configured to be presented to the third user in the language specified for the confirmer, based on the language information stored in the language data item of the third user's record in confirmation table 1015.

Figure 18 is an example of the second screen (first embodiment) showing the operation of the contract confirmation process. The second screen 80, which is displayed on the display 4081 of the third user terminal 40 and accepts operations to identify users related to one or more approvers, displays input fields for entering the approver's email address 801, name 802, company name 803, language 804, and access code 805, as well as a cancel button 821 and an add button 822.

In step S308, information specifying one or more fourth users as approvers is received from the third user.
Specifically, the third user operates the input device 406 of the third user terminal 40 to input the approver's email address, name, company name, language used by the approver, and access code into email address 801, name 802, company name 803, language 804, and access code 805, respectively, displayed on the second screen 80. Note that the third user may omit inputting the company name, language, and access code.

<Second Screen Presentation Process (Second Example)>
In step S307, the display 4081 of the third user terminal 40 presents the third user with a second screen (second embodiment) that accepts an operation to specify users related to one or more approvers.
For example, if the third user is registered as a user in the service according to the present disclosure, the second screen presentation process (second embodiment) may be executed.

19 is an example of a second screen (second embodiment) showing the operation of the contract confirmation process. The second screen 80, which is displayed on the display 4081 of the third user terminal 40 and accepts an operation to identify users related to one or more approvers, displays input fields for inputting the approver's email address 801, name 802, company name 803, language 804, and access code 805, a cancel button 821, an add button 822, a user candidate presentation area 841 that presents multiple users as user candidates, and a switch button 861 that switches the type of user candidate.
The third user can selectively switch between four types of user candidates, namely, "Group,""History,""GroupHistory," and "Other," by operating the input device 406 of the third user terminal 40 or the like and pressing the switch button 861 displayed on the second screen 80, and present multiple user candidates in the user candidate presentation area 841.
The switching button 861 may be configured so that the items "Group,""GroupHistory," and "Other" cannot be pressed if the third user does not belong to a predetermined group and is not associated with group identification information, or if the third user is in a state where he or she cannot use group-related functions. In other words, the configuration may be such that only user candidates based on "History" are presented to the third user. In addition, a configuration may be included in which predetermined officials such as section chiefs and department managers are presented as user candidates.

In step S308, information specifying one or more fourth users as approvers is received from the third user.
Specifically, similar to the second screen presentation process (first embodiment), the third user can operate the input device 406 of the third user terminal 40 to input the approver's email address, name, company name, language used by the approver, and access code into email address 801, name 802, company name 803, language 804, and access code 805, respectively, displayed on the second screen 80. The third user may omit inputting the company name, language, and access code.

In the second screen presentation process (second embodiment), the contract confirmation unit 1043 of the server 10 can accept an operation to identify one or more users who are approvers from the user candidates presented in the user candidate presentation area 841.
Specifically, the third user operates the input device 406 of the third user terminal 40 or the like to select and specify one or more user candidates presented in the user candidate presentation area 841. The control unit 404 of the third user terminal inputs information about the selected user candidates into input fields such as email address 801, name 802, company name 803, language 804, etc.
This allows the third user to select a third user who will be the approver from among the multiple user candidates presented, thereby reducing the input burden on the third user.

<Suggesting user candidates based on groups>
The contract confirmation unit 1043 of the server 10 presents, to the third user associated with the second group, one or more users who can approve the contract information from among the multiple users associated with the second group as user candidates. At this time, it may be configured not to present, as user candidates, one or more users who cannot approve the contract information from among the multiple users associated with the second group.
Specifically, the third user operates the input device 406 of the third user terminal 40, presses the "Group" button from the switch button 861 displayed on the second screen 80, and sends a request to the server 10 to present user candidates based on the group.
When the contract confirmation unit 1043 of the server 10 receives the request, it searches the email address or user ID field in the user table 1012 based on the email address or user ID of the third user, which is information identifying the third user, and acquires the group ID field (second group ID). Based on the acquired second group ID, the contract confirmation unit 1043 of the server 10 searches the group ID field in the user table 1012 and acquires the user ID, user name, email address, and approval authority fields.
The contract confirmation unit 1043 of the server 10 transmits the user ID, user name, and email address of the user who has approval authority to the third user terminal 40. The display 4081 of the third user terminal 40 displays a list of the received user candidate information including the user name, email address, etc. in the user candidate presentation area 841.

<Presentation of User Candidates Based on History (First Embodiment)>
The contract confirmation unit 1043 of the server 10 presents one or more fourth users previously identified by the third user as user candidates based on the history information of the third user. At this time, one or more users who cannot approve the contract information may not be presented as user candidates.
Specifically, the third user operates the input device 406 of the third user terminal 40, presses the "History" button from the switch button 861 displayed on the second screen 80, and sends a request for presenting user candidates based on the history to the server 10. Upon receiving the request, the contract confirmation unit 1043 of the server 10 searches the designated person data item in the confirmation table 1015 based on the information identifying the third user, and acquires the confirmer email addresses of users previously identified by the third user as approvers. Based on the acquired email addresses, the contract confirmation unit 1043 of the server 10 searches the email address item in the user table 1012, and acquires the user ID, user name, email address, and approval authority items.
The contract confirmation unit 1043 of the server 10 transmits the user ID, user name, and email address of the user who has approval authority to the third user terminal 40. The display 4081 of the third user terminal 40 displays a list of the received user candidate information including the user name, email address, etc. in the user candidate presentation area 841.

<Presenting User Candidates Based on History (Second Embodiment)>
The contract confirmation unit 1043 of the server 10 presents, as user candidates, one or more fourth users previously identified by multiple users, including the third user, associated with the second group, based on the history information of the second group with which the third user is associated. At this time, the server 10 may be configured not to present, as user candidates, one or more users who cannot approve the contract information.
Specifically, the third user operates the input device 406 of the third user terminal 40, presses the "Group History" button from the switch button 861 displayed on the second screen 80, and sends a request to the server 10 to present user candidates based on the group history.
When the contract confirmation unit 1043 of the server 10 receives the request, it searches the email address or user ID field in the user table 1012 based on the email address or user ID of the third user, which is information identifying the third user, and acquires the group ID field (second group ID). Based on the acquired second group ID, the contract confirmation unit 1043 of the server 10 searches the group ID field in the user table 1012 and acquires the user ID and email address fields. This makes it possible to acquire multiple users associated with the second group.
The contract confirmation unit 1043 of the server 10 searches the designated person data item in the confirmation table 1015 based on the acquired user IDs and email addresses of the multiple users associated with the second group, and acquires the confirmer email addresses of users who have been previously identified as approvers by the multiple users associated with the second group.The contract confirmation unit 1043 of the server 10 searches the email address item in the user table 1012 based on the acquired email addresses, and acquires the user ID, user name, email address, and approval authority items.
The contract confirmation unit 1043 of the server 10 transmits the user ID, user name, and email address of the user who has approval authority to the third user terminal 40. The display 4081 of the third user terminal 40 displays a list of the received user candidate information including the user name, email address, etc. in the user candidate presentation area 841.

<Suggesting user candidates based on other information>
The contract confirmation unit 1043 of the server 10 presents multiple users as user candidates based on at least one of the contract information, the first user associated with the first group, and the first group. At this time, one or more users who cannot approve the contract information may not be presented as user candidates.
Specifically, the third user operates the input device 406 of the third user terminal 40, presses the “Other” button among the switching buttons 861 displayed on the second screen 80, and transmits a request for presenting user candidates based on other information to the server 10. Upon receiving the request, the contract confirmation unit 1043 of the server 10 identifies contract information previously concluded with the first user and contract information previously concluded with other users associated with the first group to which the first user belongs, searches the document ID field in the confirmation table 1015 based on the document ID included in the contract information, and acquires the confirmer email address field of users previously identified as approvers in the contract information. At this time, the server 10 may be configured to refer to the user table 1012 and the group table 1013 and acquire only the confirmer email addresses of users associated with the second group to which the third user belongs. Based on the acquired email addresses, the contract confirmation unit 1043 of the server 10 searches the email address field in the user table 1012 and acquires the user ID, user name, email address, and approval authority fields.
Based on the information identifying the third user, the server 10 searches the designated person data field in the confirmation table 1015 to obtain the confirming person email address of the user previously identified by the third user as an approver. Based on the obtained email address, the contract confirmation unit 1043 of the server 10 searches the email address field in the user table 1012 to obtain the user ID, user name, email address, and approval authority fields.
The contract confirmation unit 1043 of the server 10 transmits the user ID, user name, and email address of the user who has approval authority to the third user terminal 40. The display 4081 of the third user terminal 40 displays a list of the received user candidate information including the user name, email address, etc. in the user candidate presentation area 841.

<Modification 1>
In addition, when presenting user candidates based on a group, presenting user candidates based on history (first embodiment), presenting user candidates based on history (second embodiment), or presenting user candidates based on other information, one or more users who can approve the contract information may be presented as user candidates in priority over one or more users who cannot approve the contract information.
Specifically, the contract confirmation unit 1043 of the server 10 may be configured to transmit the user IDs, user names, and email addresses of users without approval authority, in addition to users with approval authority, to the third user terminal 40. In this case, the display 4081 of the third user terminal 40 may present user candidate information with approval authority higher in the list than user candidate information without approval authority, so that the third user can easily select the user candidate information with approval authority. In addition, when user candidate information is displayed in a carousel or by page forwarding, it is possible to display user candidate information with approval authority on a higher page.

<Modification 2>
The contract confirmation unit 1043 of the server 10 may be configured to present user candidates based on history (first embodiment) and history (second embodiment) in such a way that, among one or more fourth users, the fourth user that has been identified more frequently is presented as a user candidate with higher priority.
Specifically, in the presentation of user candidates based on history (first embodiment) and the presentation of user candidates based on history (second embodiment), the contract confirmation unit 1043 of the server 10 counts the number (number of times) of duplicate user candidate information for each user ID or email address of the user candidate for the acquired user candidate information, and prioritizes the count so that user candidate information with higher priority is presented higher in the list, thereby presenting user candidate information of users who have been selected and identified more frequently in the past by the third user or multiple users belonging to the second group so that the third user can easily select it.In addition, when user candidate information is displayed in a carousel or by page forwarding, it is possible to display user candidate information with higher priority on the first page.

<Modification 3>
It is also possible to combine presentation of user candidates based on groups, presentation of user candidates based on history (first embodiment), presentation of user candidates based on history (second embodiment), and presentation of user candidates based on other information to present one user candidate to a third user.

<Approver setting process>
The third user operates the input device 406 of the third user terminal 40 and presses the Add button 822 displayed on the second screen, thereby executing a process to send a request including the information entered in the email address 801, name 802, company name 803, language 804, and access code 805 to the server 10.
The contract confirmation unit 1043 of the server 10 stores the email address and document ID included in the received request in the confirmer email address and document ID fields of a new record in the confirmation table 1015, respectively, and stores the contract information in association with the email address of the fourth user. Note that the user ID or email address of the third user may also be stored in the designated person data field of the confirmation table 1015. This allows the third user to receive a presentation of user candidates based on their history.
At this time, the values of the confirmation order items of the users who will be the checkers are incremented by one and stored in the confirmation table 1015. This sets the circulation order of the checkers in the contract confirmation process. Note that setting the circulation order is not essential.
The third user can specify and set one or more approvers by repeatedly executing the processes of steps S307 and S308. When the third user has completed setting the approvers, the third user operates the input device 406 of the third user terminal 40 or the like to press the cancel button 821, thereby ending the approver setting process.

In this case, the contract confirmation unit 1043 of the server 10 may be configured to assign the input items assigned to the third user by the first user to the fourth user. In other words, the input item information assigned to the third user may be handed over to the approver designated by the third user.
Specifically, the contract confirmation unit 1043 of the server 10 searches the inputter ID field of the input item table 1016 based on the third user ID and stores the fourth user ID in the inputter ID field of the identified record. The contract confirmation unit 1043 of the server 10 may be configured to delete the third user ID from the inputter ID field of the identified record, store the fourth user ID, and overwrite the fourth user ID as the inputter ID. The contract confirmation unit 1043 of the server 10 may be configured to store the fourth user ID without deleting the third user ID from the inputter ID field of the identified record, and add the fourth user ID as the inputter ID.

In addition, if the third user identifies multiple fourth users as approvers, the third user may be configured to assign multiple different fourth users to each of the multiple input item information assigned to the third user by the first user.
Specifically, the third user operates the input device 406 of the third user terminal 40, etc., and selectively adds and stores the user IDs of multiple different fourth users in the inputter ID field of the record of input item information in which the third user ID is stored in the inputter ID field of the input item table 1016.

In step S309, the display 4081 of the third user terminal 40 presents the third screen, which accepts an operation to confirm the contract information, to the third user. The third user confirms the contract information displayed on the display 4081 of the third user terminal 40.
If there is no input item information assigned to the third user, step S309 may be omitted.

Figure 20 is an example of the third screen showing the operation of the contract confirmation process. The third screen 70B, which is displayed on the display 4081 of the third user terminal 40 and is used to confirm the contract information, differs from the first screen 70A only in that it does not display the Agree button 740 but instead displays the Save button 750. Since the rest of the configuration is the same, a description of it will be omitted. In other words, a third user who does not have approval authority cannot agree to or approve the contract information.

In step S309, the contract confirmation unit 1043 of the server 10 accepts input for one or more input items of the contract information.
Specifically, the third user operates the input device 406 of the third user terminal 40 or the like to input data into the input items 732, 733, 734, and 735 set in the contract information. In the present disclosure, input by the third user into the input item 736 is not assigned, and therefore, it is visually displayed that the third user cannot input input data.

The third user operates the input device 406 of the third user terminal 40 and presses the save button 750 to execute a process of transmitting a request including the document ID, information identifying the third user, and the input data for each input item entered in step S309 to the server 10. The information identifying the third user may be the third user ID 4011.
The contract confirmation unit 1043 of the server 10 stores the received input data in the input data item specified by the input item ID associated with the input data in the input item table 1016. As a result, in step S305, the input data entered by the third user is stored as input item information in the input item table 1016.
At this time, since the third user does not have approval authority, the value of True is not stored in the confirmation flag field of the record of the third user in the confirmation table 1015 .

In step S310, the contract confirmation unit 1043 of the server 10 receives an instruction from the third user to request the fourth user to conclude a contract based on the contract information.
Specifically, the contract creation unit 1042 of the server 10 sends a message to the fourth user notifying that a request for approval of the contract information has been sent from the third user. For example, the contract confirmation unit 1043 of the server 10 sends a message to the email address of the fourth user by a communication means such as email notifying that a request for approval of the contract information has been sent from the third user.
The message sent to the fourth user includes a URL (Uniform Resource Locator) containing a document ID for identifying the contract information. The URL may directly include the document ID, or may include information such as a string obtained by arbitrarily encrypting the document ID, or other information such as a string that can identify the document ID by referencing a table (not shown). The URL may also include information for identifying the fourth user. For example, if the fourth user is not registered with the service disclosed herein, the URL must include information for identifying the fourth user.
The message sent to the fourth user terminal 41 is the same as that shown in FIG. 16, and therefore a description thereof will be omitted.

If the third user sets an access code for the fourth user, the third user will separately communicate the access code to the fourth user by email or other means. This means that even if a third party obtains the message sent to the fourth user, the third party will not be able to execute the contract confirmation process unless they obtain the access code.

<Details of contract confirmation process (fourth user)>
In step S301, the fourth user, who is the first confirming user, operates the input device 416 of the fourth user terminal 41 to select the URL described in the received message, thereby opening the web page specified by the URL using the browser application of the fourth user terminal 41. As a result, the fourth user terminal 41 transmits a request to the server 10 to execute the contract confirmation process.
The contract confirmation process for the fourth user is the same as the contract confirmation process for the third user, and therefore will not be described here. The fourth user with approval authority can approve the contract information by executing steps S304, S305, and S306 of the contract confirmation process.

For example, in step S306, the contract confirmation unit 1043 of the server 10 can receive an instruction from one or more fourth users to approve the conclusion of the contract for the contract information received from the first user.
Then, the contract creation unit 1042 of the server 10 sends a message to the first user's email address via a communication means such as email, notifying the first user that the second user has completed confirmation of the contract information. In other words, the message notifies the first user that the second user has approved the contract conclusion. This allows the first user to know that the contract conclusion with the second user has been completed. The second user can complete the appropriate contract conclusion procedures without the first user knowing that the contract conclusion has been approved by the fourth user through the third user in the organization to which the second user belongs. Note that the message may also include content notifying the fourth user that the contract information has been confirmed. The message may also include content notifying the fourth user through the third user that the fourth user has completed confirmation of the contract information.

In step S306, the contract confirmation unit 1043 of the server 10 may execute a process of notifying the second user that an instruction to approve the conclusion of the contract has been received from the fourth user. Specifically, the contract confirmation unit 1043 of the server 10 sends a message to the email address of the second user by a communication means such as email, notifying that the fourth user has completed confirmation of the contract information.
This allows the second user to confirm through the notification that the contract information accepted with the second user as the contract conclusion target has been approved by the fourth user.

<Electronic signature processing>
An electronic signature process may be included in step S306. In response to the instruction to approve the conclusion of the contract received from the third user in step S306, the contract confirmation unit 1043 of the server 10 affixes an electronic signature to the contract information received from the first user, indicating that the conclusion of the contract information has been approved, and stores the contract information.
Specifically, the contract confirmation unit 1043 of the server 10 adds a digital signature to the contract information based on the received request and stores it. The contract confirmation unit 1043 of the server 10 searches the document ID item in the document table 1014 based on the document ID, and acquires the contract information.
The contract confirmation unit 1043 of the server 10 affixes an electronic signature to the acquired contract information and stores it in the document data item of the document table 1014. Note that the contract confirmation unit 1043 of the server 10 may update (overwrite) the document data item with the contract information affixed with the electronic signature, or may store the contract information before affixing the electronic signature in a separate storage device (not shown).
The contract confirmation unit 1043 of the server 10 may include in the electronic signature any of the following information: document ID, email address of the first user, email address of the third user, approval date and time, confirmation date and time, authentication method for the approval date and time, authentication method for the confirmation date and time, input data value for each input item, consent (approval) of the first user and third user, timestamp, etc.
As a result, the contract confirmation unit 1043 of the server 10 stores the contract information with an electronic signature indicating that the third user has approved the conclusion of the contract information, thereby preventing a third party from impersonating or tampering with the contract information.

Similarly, in response to an instruction to approve the contract conclusion received from the fourth user in step S306, the contract confirmation unit 1043 of the server 10 stores the contract information received from the first user with an electronic signature indicating that the contract conclusion of the contract information has been approved.
The contract confirmation unit 1043 of the server 10 may include in the electronic signature any of the following information: document ID, email address of the first user, email address of the fourth user, approval date and time, confirmation date and time, authentication method for the approval date and time, authentication method for the confirmation date and time, input data values for each input item, consent (approval) of the first user and the fourth user, timestamp, etc.
As a result, the contract confirmation unit 1043 of the server 10 adds a digital signature to the contract information indicating that the fourth user has approved the conclusion of the contract information, and stores the digital signature. This makes it possible to prevent a third party from impersonating or tampering with the contract information.

<Basic computer hardware configuration>
21 is a block diagram showing the basic hardware configuration of a computer 90. The computer 90 includes at least a processor 901, a main storage device 902, an auxiliary storage device 903, and a communication IF 991 (interface), which are electrically connected to one another by a communication bus 921.

The processor 901 is hardware that executes a set of instructions written in a program. The processor 901 is composed of an arithmetic unit, registers, peripheral circuits, etc.

The main memory device 902 is used to temporarily store programs and data processed by the programs. For example, it is a volatile memory such as DRAM (Dynamic Random Access Memory).

The auxiliary storage device 903 is a storage device for saving data and programs. Examples include flash memory, HDD (Hard Disc Drive), magneto-optical disk, CD-ROM, DVD-ROM, and semiconductor memory.

The communication IF 991 is an interface for inputting and outputting signals for communicating with other computers via a network using wired or wireless communication standards.
The network is composed of the Internet, a LAN, various mobile communication systems constructed by wireless base stations, etc. For example, the network includes 3G, 4G, and 5G mobile communication systems, LTE (Long Term Evolution), and wireless networks (e.g., Wi-Fi (registered trademark)) that can connect to the Internet via a predetermined access point. In the case of a wireless connection, communication protocols include, for example, Z-Wave (registered trademark), ZigBee (registered trademark), and Bluetooth (registered trademark). In the case of a wired connection, the network also includes a network that is directly connected using a USB (Universal Serial Bus) cable, etc.

In addition, computers 90 can be virtually realized by distributing all or part of each hardware configuration across multiple computers 90 and connecting them via a network. In this way, the concept of computer 90 includes not only computers 90 housed in a single housing or case, but also virtualized computer systems.

<Basic Functional Configuration of Computer 90>
The following describes the functional configuration of a computer realized by the basic hardware configuration (FIG. 21) of the computer 90. The computer includes at least the functional units of a control unit, a storage unit, and a communication unit.

The functional units of the computer 90 can also be realized by distributing all or part of each functional unit across multiple computers 90 interconnected via a network. The concept of computer 90 includes not only a single computer 90 but also a virtualized computer system.

The control unit is realized when the processor 901 reads various programs stored in the auxiliary storage device 903, expands them into the main storage device 902, and executes processing in accordance with the programs. The control unit can realize functional units that perform various types of information processing depending on the type of program. In this way, the computer is realized as an information processing device that performs information processing.

The storage unit is realized by a main storage device 902 and an auxiliary storage device 903. The storage unit stores data, various programs, and various databases. The processor 901 can also allocate a storage area corresponding to the storage unit in the main storage device 902 or the auxiliary storage device 903 in accordance with the programs. The control unit can also cause the processor 901 to add, update, and delete data stored in the storage unit in accordance with the various programs.

A database refers to a relational database, which manages data sets called masters and tables in a tabular format structurally defined by rows and columns, by relating them to each other. In a database, a table is called a table, a master, a column in a table is called a column, and a row in a table is called a record. In a relational database, relationships between tables and masters can be set and associated.
Typically, a column that serves as a primary key for uniquely identifying a record is set in each table and each master, but setting a primary key in a column is not essential. The control unit can cause the processor 901 to add, delete, or update records in specific tables and masters stored in the storage unit according to various programs.

Note that databases and masters in this disclosure may include any data structure in which information is structurally defined (lists, dictionaries, associative arrays, objects, etc.). Data structures also include data that can be considered as data structures by combining data with functions, classes, methods, etc. written in any programming language.

The communication unit is realized by the communication IF 991. The communication unit realizes the function of communicating with other computers 90 via a network. The communication unit can receive information sent from other computers 90 and input it to the control unit. The control unit can cause the processor 901 to execute information processing on the received information in accordance with various programs. The communication unit can also transmit information output from the control unit to other computers 90.

<Additional Notes>
The matters described in the above embodiments will be supplemented below.

(Appendix 1)
A program having a processor and a memory unit, for causing a computer to execute electronic contract procedures between users belonging to different organizations, the program causing the processor to execute a contract acceptance step (S101) of accepting contract information to be the subject of a contract from a first user, a recipient acceptance step (S102) of accepting second identification information from the first user as the recipient of the contract information accepted in the contract acceptance step, and a transfer step (S106) of transferring the contract information accepted in the contract acceptance step to one or more third users based on the second identification information accepted in the recipient acceptance step.
This allows the contract information transmitted in response to the second identification information to be forwarded to the third user, who is a designated contact point. The third user, who is the contact point, can approve the contract information himself or forward the contract information to an appropriate approver.

(Appendix 2)
A program as described in Appendix 1, wherein the second identification information is information for identifying the second user, the recipient receiving step (S102) is a step of receiving information from the first user that identifies the second user as the recipient of the contract information received in the contract receiving step, and the forwarding step (S106) is a step of forwarding the contract information received in the contract receiving step to one or more third users based on the information for identifying the second user received in the recipient receiving step.
This allows the contract information sent to the second user to be forwarded to the third user, who is a designated contact point, and the third user, who is the contact point, can approve the contract information himself or forward the contract information to an appropriate approver.

(Appendix 3)
3. The program according to claim 2, wherein the first user is a user who belongs to a different group from the second user, and the second user and the third user are users who belong to the same group.
This allows the contract information sent to the second user to be forwarded to the third user, who is a designated contact point, and the third user, who is the contact point, can approve the contract information himself or forward the contract information to an appropriate approver.

(Appendix 4)
The program is a program described in Appendix 2 or 3 that causes the processor to execute a transfer notification step (S107) of notifying the second user accepted in the recipient acceptance step that the contract information accepted in the contract acceptance step has been transferred to one or more third users.
This allows the second user to confirm through the notification that the contract information accepted with the second user as the contract conclusion target has been transferred to the third user.

(Appendix 5)
The program causes a processor to execute an approver reception step (S308) for receiving information from a third user identifying one or more fourth users as approvers of the contract information received in the contract reception step, and an approval step (S306) for receiving instructions from one or more fourth users to approve the contract conclusion of the contract information received in the contract reception step, wherein the third user is a user (S303) who is unable to approve the contract conclusion of the contract information received in the contract reception step. A program described in any of Appendices 2 to 4.
This allows the third user to avoid approving the contract if the third user is unable to approve the contract, and also allows the third user, who is the contact person, to transfer the contract information to the fourth user, who is the appropriate approver, based on the content of the contract information.

(Appendix 6)
The program described in Appendix 5 causes the processor to execute an approval notification step (S306) of notifying the second user accepted in the recipient acceptance step that an instruction to approve the contract conclusion has been accepted from the fourth user in the approval step.
This allows the second user to confirm through the notification that the contract information accepted with the second user as the contract conclusion target has been approved by the fourth user.

(Appendix 7)
The program described in Appendix 5 or 6 causes a processor to execute a signing step (S306) in which, in response to an instruction to approve the contract conclusion received from the fourth user in the approval step, an electronic signature indicating that the contract conclusion of the contract information has been approved is attached to the contract information received in the contract acceptance step and stored, and a completion notification step (S306) in which the first user is notified that the contract conclusion has been approved by the second user.
This allows the first user to know that the contract has been concluded with the second user. The second user can then complete the appropriate contract conclusion procedures without the first user knowing that the contract has been approved by the fourth user through the third user in the organization to which the second user belongs.

(Appendix 8)
The program according to appendix 7, wherein the signing step (S306) is a step of adding an electronic signature to the contract information indicating that the fourth user has approved the conclusion of the contract information and storing the contract information.
As a result, the fact that the fourth user, who is the actual person authorized to approve, has approved the contract information is stored in the contract information.

(Appendix 9)
A program described in any of Appendices 1 to 3, which causes a processor to execute an approval step (S306) of receiving an instruction from a third user to approve the conclusion of the contract for the contract information received in the contract acceptance step.
This allows the contract information sent to the second user to be forwarded to the third user, who is the designated contact point. The third user, who is the contact point, can then forward the contract information to an appropriate approver based on the content of the contract information.

(Appendix 10)
The program described in Appendix 9 causes a processor to execute a signing step (S306) in which, in response to an instruction to approve the contract conclusion received from the third user in the approval step, an electronic signature indicating that the contract conclusion of the contract information has been approved is attached to the contract information received in the contract acceptance step and stored, and a completion notification step (S306) in which the first user is notified that the contract conclusion has been approved by the second user.
This allows the first user to know that the contract has been concluded with the second user. The second user can then complete the appropriate contract conclusion procedures without the first user knowing that the contract conclusion has been approved by the third user in the organization to which the second user belongs.

(Appendix 11)
The program according to claim 10, wherein the signing step (S306) is a step of adding an electronic signature to the contract information indicating that the third user has approved the conclusion of the contract information and storing the contract information.
As a result, the fact that the third user, who is the actual person authorized to approve, has approved the contract information is stored in the contract information.

(Appendix 12)
A program described in any of Appendices 2 to 11, wherein the forwarding step (S106) is a step of forwarding the contract information accepted in the contract acceptance step to one or more third users identified based on specified conditions, based on the second user accepted in the recipient acceptance step.
This allows the contract information sent to the second user to be forwarded to the third user, who is a designated contact point, and the third user, who is the contact point, can approve the contract information himself or forward the contract information to an appropriate approver.

(Appendix 13)
An information processing device comprising a processor and a storage unit, the information processing device causing the processor to execute a program according to any one of Supplementary Notes 1 to 9.
This allows the contract information transmitted in response to the second identification information to be forwarded to the third user, who is a designated contact point. The third user, who is the contact point, can approve the contract information himself or forward the contract information to an appropriate approver.

(Appendix 14)
An information processing system including an information processing device having a processor and a memory unit, the information processing system causing the processor to execute a program according to any one of Supplementary Notes 1 to 9.
This allows the contract information transmitted in response to the second identification information to be forwarded to the third user, who is a designated contact point. The third user, who is the contact point, can approve the contract information himself or forward the contract information to an appropriate approver.

(Appendix 15)
An information processing method executed by a computer having a processor and a storage unit, the information processing method causing the processor to execute a program according to any one of Supplementary Notes 1 to 9.
This allows the contract information transmitted in response to the second identification information to be forwarded to the third user, who is a designated contact point. The third user, who is the contact point, can approve the contract information himself or forward the contract information to an appropriate approver.

1 System, 10 Server, 101 Memory unit, 104 Control unit, 106 Input device, 108 Output device, 20 First user terminal, 201 Memory unit, 204 Control unit, 206 Input device, 208 Output device, 30 Second user terminal, 301 Memory unit, 304 Control unit, 306 Input device, 308 Output device, 40 Third user terminal, 401 Memory unit, 404 Control unit, 406 Input device, 408 Output device, 41 Fourth user terminal, 411 Memory unit, 414 Control unit, 416 Input device, 418 Output device

Claims (5)

A program for causing a computer to execute an electronic contract procedure between users belonging to different organizations , the program comprising: a processor; and a storage unit,
The program causes the processor to:
a contract acceptance step of accepting contract information to be the subject of a contract conclusion from the first user;
a receiver receiving step of receiving, from a first user, information for identifying a second user who is a receiver of the contract information received in the contract receiving step;
a transfer step of acquiring information for specifying one or more third users that is pre-associated with the information for specifying the second user based on the information for specifying the second user received in the receiver receiving step, when information for specifying one or more third users to be forwarded is set in association with the information for specifying the second user, and forwarding the contract information received in the contract receiving step to one or more third users;
A program that executes the following. The program further causes the processor to
an approval step of accepting, from the third user, an instruction to approve the conclusion of the contract of the contract information accepted in the contract acceptance step;
2. The program according to claim 1, further comprising: a step of notifying the first user of information about the third user when the instruction to approve is received from the third user in the approval step. The program described in claim 1 or 2, wherein, if the contract information received in the contract reception step is of a predetermined contract type, the contract information received in the contract reception step is forwarded to a user who is the forwarding destination for the contract information of the predetermined contract type. A method for causing a computer to execute an electronic contract procedure between users belonging to different organizations , the method comprising:
The method further comprises the processor:
a contract acceptance step of accepting contract information to be the subject of a contract conclusion from the first user;
a receiver receiving step of receiving, from a first user, information for identifying a second user who is a receiver of the contract information received in the contract receiving step;
a transfer step of acquiring information for specifying one or more third users that is pre-associated with the information for specifying the second user based on the information for specifying the second user received in the receiver receiving step, when information for specifying one or more third users to be forwarded is set in association with the information for specifying the second user, and forwarding the contract information received in the contract receiving step to one or more third users;
How to perform. An information processing device for causing a computer to execute an electronic contract procedure between users belonging to different organizations , comprising:
a control unit of the information processing device,
a contract acceptance step of accepting contract information to be the subject of a contract conclusion from the first user;
a receiver receiving step of receiving, from a first user, information for identifying a second user who is a receiver of the contract information received in the contract receiving step;
a transfer step of acquiring information for specifying one or more third users that is pre-associated with the information for specifying the second user based on the information for specifying the second user received in the receiver receiving step, when information for specifying one or more third users to be forwarded is set in association with the information for specifying the second user, and forwarding the contract information received in the contract receiving step to one or more third users;
An information processing device that executes the above.