Program, information processing apparatus, and information processing method

Abstract

To provide a program, information processing apparatus, and an information processing method, configured to properly conclude an electronic contract according to approval authority on conclusion of a contract within an organization, even when a user who has received contract information is not authorized to approve the conclusion of the contract, in an electronic contract system that executes an electronic contract procedure between users belonging to different organizations.SOLUTION: A method includes: receiving contract information which is to be concluded between a first user and a second user; receiving, from the first user, information that specifies the second user as a receiver of the contract information received in a contract reception step; receiving, from the second user, information that specifies one or a plurality of third users as an approver for the contract information received in the contract reception step; and receiving, from the one or a plurality of third users, an instruction to approve the conclusion of the contract for the received contract information, the second user being a user who is not authorized to approve the conclusion of the contract for the received contract information.SELECTED DRAWING: Figure 12

Description

Technical Field

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

Background Art

[0002] With the development and spread of computer technology, documents that used to be on paper media are being digitized. For example, it is conceivable to manage documents such as contract documents that require the signature and seal of the parties in electronic data. Patent Document 1 discloses a data storage destination restriction device that can restrict the data storage destination in units of user groups within a company. Patent Document 2 discloses an information processing system related to digital contracts including a creator terminal, a confirmation company terminal, and a contract document management server.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0004] In an electronic contract system, there have been cases where contract conclusion is made even when a user who has received information related to an electronic contract (contract information) from a sender does not have the approval authority regarding contract conclusion in the organization. Therefore, the present disclosure has been made to solve the above problems, and an object thereof is to provide a technology for realizing appropriate conclusion of an electronic contract in accordance with the approval authority regarding contract conclusion in an organization even when a user who has received contract information does not have the approval authority regarding contract conclusion in an electronic contract system that executes an electronic contract procedure between users belonging to different organizations. [Means for solving the problem]

[0005] A program comprising a processor and a memory unit, for causing a computer to execute electronic contract procedures between users belonging to different organizations, wherein the program causes the processor to execute a contract acceptance step for receiving contract information that is the subject of a contract to be concluded between a first user and a second user; a recipient acceptance step for receiving information from the first user that identifies the second user as the recipient of the contract information received in the contract acceptance step; an approver acceptance step for receiving information from the second user that identifies one or more third users as approvers of the contract information received in the contract acceptance step; and an approval step for receiving instructions from one or more third users to approve the conclusion of the contract information received in the contract acceptance step, wherein the second user is a user who cannot approve the conclusion of the contract information received in the contract acceptance step. [Effects of the Invention]

[0006] According to this disclosure, in cases where the second user is a user who cannot approve the conclusion of the contract, it is possible to avoid the second user's approval of the conclusion of the contract, and the contract conclusion procedure can be carried out without sending it back to the first user, thereby reducing the procedural burden on the first user. [Brief explanation of the drawing]

[0007] [Figure 1] This is a diagram showing the overall configuration of information processing system 1. [Figure 2] This block diagram shows the functional configuration of Server 10. [Figure 3] This is a block diagram showing the functional configuration of the first user terminal 20. [Figure 4] This is a block diagram showing the functional configuration of the second user terminal 30. [Figure 5] This is a block diagram showing the functional configuration of the third user terminal 40. [Figure 6]This diagram shows the data structure of user table 1012. [Figure 7] This diagram shows the data structure of group table 1013. [Figure 8] This diagram shows the data structure of document table 1014. [Figure 9] This diagram shows the data structure of confirmation table 1015. [Figure 10] This diagram shows the data structure of input item table 1016. [Figure 11] This is a flowchart showing the steps involved in the contract creation process. [Figure 12] This is a flowchart showing the process of reviewing the contract. [Figure 13] This is an example screen showing the operation of the contract creation process. [Figure 14] This is an example screen showing a message notified to the second user terminal 30. [Figure 15] This is an example of the first screen (first embodiment) showing the operation of the contract confirmation process. [Figure 16] This is an example of the first screen (second embodiment) showing the operation of the contract confirmation process. [Figure 17] This is an example of the second screen, which demonstrates the operation of the contract verification process. [Figure 18] This is an example of the third screen, which demonstrates the operation of the contract verification process. [Figure 19] A block diagram showing the basic hardware configuration of Computer 90. [Modes for carrying out the invention]

[0008] The embodiments of this disclosure will be described below with reference to the drawings. In all the drawings illustrating the embodiments, common components are denoted by the same reference numerals, and repeated explanations are omitted. The following embodiments are not intended to unduly limit the content of this disclosure as described in the claims. Not all components shown in the embodiments are necessarily essential components of this disclosure. Also, each drawing is a schematic diagram and is not necessarily a strict illustration.

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

[0010] Each information processing device is composed of a computer including an arithmetic unit and a storage unit. The basic hardware configuration of the computer and the basic functional configuration of the computer realized by the hardware configuration will be described later. For each of server 10, first user terminal 20, second user terminal 30, and third user terminal 40, descriptions overlapping with the basic hardware configuration and the basic functional configuration of the computer to be described later are omitted.

[0011] <Configuration of Server 10> Server 10 is an information processing device that provides an electronic contract conclusion service among multiple users. Server 10 includes storage unit 101 and control unit 104.

[0012] <Configuration of Storage Unit 101 of Server 10> The storage unit 101 of server 10 includes application program 1011, user table 1012, group table 1013, document table 1014, confirmation table 1015, and input item table 1016.

[0013] The application program 1011 is a program that causes the control unit 104 of the server 10 to function as individual functional units.

[0014] 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, their information is stored in a new record in User Table 1012. This allows the user to use the service related to this disclosure. Note that users who use the service in this disclosure do not necessarily need to be registered in User Table 1012. User table 1012 is a table with User ID as the primary key and contains columns for User ID, Username, Email Address, Group ID, and Approval Authority. Figure 6 shows the data structure of user table 1012.

[0015] The User ID is an item that stores user identification information to identify a user. User identification information is an item that is set to a unique value for each user. The username field is used to store the user's real name. However, the username can also be a nickname or any other string of characters. The email address field is where the user's email address is stored. The Group ID is an item that stores the group identification information of the group to which the user belongs. A user may belong to multiple groups. Approval authority is an item that stores user authorization information regarding contract signing. Users who have the authority to approve contract signing (approval authority) will have information such as True stored in their records. On the other hand, users who do not have the authority to approve contract signing will have information such as False, blank, or null stored in their records.

[0016] It is also possible to configure the system so that approval permissions can be set for each piece of contract information. For example, user A may have approval permissions for a specific piece of contract information A, but not for a specific piece of contract information B. The system can be configured to allow approval authority to be set according to the type of contract information (contract information type), such as confidentiality agreements, joint research agreements, and contract work agreements. For example, User A may have approval authority for confidentiality agreements but not for contract work agreements.

[0017] Group table 1013 is a table that stores and manages information about the groups to which a user belongs (group information). A group can be any group to which a user belongs, such as a corporation, company, club, organization, or department within a company. Group table 1013 is a table with Group ID as the primary key and containing columns for Group ID, Group Name, and Administrator ID. Figure 7 shows the data structure of group table 1013.

[0018] The Group ID is an item that stores group identification information used to identify a group. This group identification information is a unique value assigned to each group. The group name is an item that stores the name of the group. The group name can be set to any string. The Administrator ID is an item that stores the user identification information of users who have administrator privileges within a group. Users with administrator privileges can arbitrarily define and set administrator IDs for users who have a certain level of status or authority or higher within a group such as an organization.

[0019] Document table 1014 is a table for storing and managing information (contract information) related to electronic contracts exchanged between the creator and the recipient. Document table 1014 is a table with Document ID as the primary key and containing columns for Document ID, Document Data, and Creator ID. Figure 8 shows the data structure of document table 1014.

[0020] The Document ID is an item that stores document identification information used to identify contract information. The document identification information is an item with a unique value assigned to each piece of contract information. Document data is an item that stores contract information (binary or text data). The Creator ID is a field that stores user identification information to identify the user who created the contract information.

[0021] Confirmation table 1015 is a table that stores and manages information (confirmer information) including the email address of the user who will be confirming the contract information. Confirmation table 1015 is a table that has columns for document ID, confirmation order, designator data, confirmor email address, confirmation flag, language data, access code, and date and time. Figure 9 shows the data structure of confirmation table 1015.

[0022] The document ID is an item that stores the document identification information of the contract information to be reviewed by the verifier. The "Verification Order" field stores information about the order in which contract information is reviewed by the reviewers. The contract information stored by the creator is circulated to the reviewers in the order of the verification order, and verification is performed accordingly. The designated user data is an item that stores information identifying the user who designated the person to review the contract information. Specifically, the designated user data includes information that identifies the user, such as an email address or user identification information. The verifier email address field stores the email address of the person who verifies the contract information. The verifier email address does not need to be registered beforehand to use the services related to this disclosure. In other words, the verifier email address does not need to be included in user table 1012. The confirmation flag is an item that stores confirmation identification information to determine whether the confirmation procedure for contract information has been completed by the verifier. When the confirmation of contract information is completed by the verifier, information indicating that the confirmation has been completed, such as a value of True, is stored in the confirmation flag item. Language data is an item that stores information about the verifier's language (language information). The access code is an item that stores the access code set for the verifier. The date and time field stores the date and time when the verifier performed the contract information verification procedure. Specifically, it stores the date and time when the verification identification information was stored in the verification flag field.

[0023] The input item table 1016 is a table that stores and manages information about input items associated with electronic contract information (input item information). Input item table 1016 is a table that has columns for input item ID, document ID, inputter ID, input data, input rules, and date and time. Figure 10 shows the data structure of the input item table 1016.

[0024] The input field ID is an item that stores input field identification information used to identify an input field. The document ID is an item that stores the document identification information of the electronic contract information to which the input field is associated. The Inputter ID is a field that stores the user identification information or email address of the person who entered the data into the input field. Specifically, the Inputter ID stores the Creator ID, the email address of the user identified by the Creator ID, and the Confirmer's email address. Input data is an item that stores the input data entered by the user into the input fields. An input rule field is an item that stores information about the input rules for an input item. Input rules can store information about data types such as date, datetime, text, and integer, as well as, for strings, the number of characters, regular expressions for strings, and other arbitrary input rules for any input item. The date and time field stores the date and time when the user entered data into the input field.

[0025] <Configuration of the control unit 104 of 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 realizes each functional unit by executing the application program 1011 stored in the storage unit 101.

[0026] The user registration control unit 1041 processes information of users who wish to use the services related to this disclosure and stores it in the user table 1012. Information stored in the user table 1012 is obtained when a user opens a web page operated by the service provider from any information processing terminal, enters information into a designated input form, and sends it to the server 10. The user registration control unit 1041 stores the received information in a new record in the user table 1012, and user registration is completed. As a result, users stored in the user table 1012 can use the service. Prior to the registration of user information in the user table 1012 by the user registration control unit 1041, the service provider may perform a prescribed review and restrict whether or not the user can use the service. The user ID may be any string or number that can identify the user, and may be any string or number that the user wishes, or may be automatically set by the user registration control unit 1041.

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

[0028] The contract verification unit 1043 executes the contract verification process. Details will be described later.

[0029] <Configuration of the first user terminal 20> The first user terminal 20 is an information processing device operated by a user of the service. The first user terminal 20 may be, for example, a stationary PC (Personal Computer), a laptop PC, or a mobile device such as a smartphone or tablet. It may also be a wearable device such as an HMD (Head Mount Display) or a smartwatch. The first user terminal 20 includes a storage unit 201, a control unit 204, an input device 206, and an output device 208.

[0030] <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.

[0031] 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 services related to this disclosure to the user. The first user ID 2011 includes information such as a session ID that is temporarily assigned by the server 10 to identify the user using the first user terminal 20.

[0032] The application program 2012 may be pre-stored in the memory unit 201, or it may be configured to be downloaded from a web server operated by the service provider via a communication interface. The application program 2012 includes applications such as a web browser application. 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.

[0033] <Configuration of the control unit 204 of the first user terminal 20> The control unit 204 of the first user terminal 20 comprises an input control unit 2041 and an output control unit 2042. The control unit 204 realizes each functional unit by executing the first user ID 2011 stored in the storage unit 201.

[0034] <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.

[0035] <Configuration of 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.

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

[0037] <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.

[0038] 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 services related to this disclosure to the user. The second user ID 3011 includes information such as a session ID that is temporarily assigned by the server 10 to identify the user using the second user terminal 30.

[0039] The application program 3012 may be pre-stored in the storage unit 301, or it may be configured to be downloaded from a web server operated by the service provider via a communication interface. The application program 3012 includes applications such as a web browser application. The application program 3012 includes an interpreted programming language such as JavaScript (registered trademark) that is executed on the web browser application stored in the second user terminal 30.

[0040] <Configuration of the control unit 304 of the second user terminal 30> The control unit 304 of the second user terminal 30 comprises an input control unit 3041 and an output control unit 3042. The control unit 304 realizes each functional unit by executing the second user ID 3011 stored in the storage unit 301.

[0041] <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.

[0042] <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.

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

[0044] <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.

[0045] 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 services related to this disclosure to the user. The third user ID 4011 includes information such as a session ID that is temporarily assigned by the server 10 to identify the user using the third user terminal 40.

[0046] The application program 4012 may be pre-stored in the memory unit 401, or it may be configured to be downloaded from a web server operated by the service provider via a communication interface. The application program 4012 includes applications such as a web browser application. The application program 4012 includes an interpreted programming language such as JavaScript® that is executed on the web browser application stored in the third user terminal 40.

[0047] <Configuration of the control unit 404 of the third user terminal 40> The control unit 404 of the third user terminal 40 comprises an input control unit 4041 and an output control unit 4042. The control unit 404 realizes each functional unit by executing the third user ID 4011 stored in the storage unit 401.

[0048] <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.

[0049] <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.

[0050] <Operation of Information Processing System 1> The following describes each process of Information Processing System 1. Figure 11 is a flowchart showing the operation of the contract creation process. Figure 12 is a flowchart showing the operation of the contract verification process. Figure 13 shows an example screen illustrating the operation of the contract creation process. Figure 14 shows an example screen displaying a message notified to the second user terminal 30. Figure 15 is an example of the first screen (first embodiment) showing the operation of the contract confirmation process. Figure 16 is an example of the first screen (second embodiment) showing the operation of the contract confirmation process. Figure 17 is an example of the second screen showing the operation of the contract confirmation process. Figure 18 shows an example of the third screen illustrating the operation of the contract confirmation process.

[0051] <Contract creation process> The contract creation process involves the creator creating contract information and sending it to the verifier. In this disclosure, the first user is the user who creates the contract information, and the second and third users are users who verify the contract information. It is possible to set multiple users as verifiers when creating the contract information. In this disclosure, the first user is a user belonging to a different organization, company, or other group than the second user, while the second user and the third user belong to the same organization, company, or other group.

[0052] Figure 13 shows an example screen illustrating the operation of the contract creation process. The screen 50 displayed on the display 2081 of the first user terminal 20, which is used to create contract information, displays a status 510 indicating the current status of contract information creation, buttons 521, 522, and 523 for specifying input items, a contract information display area 530, document data 531, input items 532, 533, and 534, and a send button 540.

[0053] <Overview of the contract creation process> The contract creation process is a series of steps in which the creator creates the contract information, sets the recipients of the contract information, sets the input fields for the contract information, sets the input rules for the input fields, receives the input data for the input fields from the creator, and sends the contract information to the set recipients.

[0054] <Details of the contract creation process> In step S101, the contract creation unit 1042 of the server 10 receives contract information from the creator that is to be concluded between the creator and the verifier. 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 PDF (Portable Document Format), Word, or XML (Extensible Markup Language), and can be included in the contract information. The first user operates the input device 206 of the first user terminal 20 and sends the created document data and the first user ID 2011 to the server 10. The contract creation unit 1042 of the server 10 receives the first user ID 2011 and the document data and stores them in the creator ID and document data fields of the 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.

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

[0056] In step S102, the first user operates the input device 206 of the first user terminal 20 to select and identify the user who will be the verifier (recipient) of the contract information. In this disclosure, the first user selects and identifies the second user as the recipient. The first user operates the input device 206 of the first user terminal 20 to enter the email address of the second user, who will act as the verifier, and sends 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 verifier email address and document ID fields of the verification table 1015, respectively, and stores the contract information in association with the second user's email address. The first user may also set the language and access code of the second user and store them in association with the second user's email address. At this time, the value 1 is stored in the "Confirmation Order" field of the confirmation table 1015. In step S102, the first user may select and set multiple users to be confirmers. In this case, the value in the "Confirmation Order" field of the users to be confirmers is incremented by one according to the selection order and stored. This sets the circulation order of the confirmers in the contract confirmation process described later. Note that setting the circulation order is not mandatory.

[0057] The configuration may also allow the first user to specify whether or not the second user has approval authority when designating the second user as the verifier. Specifically, if the first user knows in advance that the second user is the point of contact for the contract procedure and that the second user does not have approval authority within the organization to which the contract is concluded, the first user will designate and remember the second user as a user without approval authority for the contract information received in step S101. This allows the first user to designate the second user as the verifier for the contract information subject to the procedure, while avoiding the second user's approval of the conclusion of the contract.

[0058] In step S103, the first user operates the input device 206 of the first user terminal 20 to set the 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 fields for the contract information created and stored in step S101. The input fields can be any fields, such as a stamp field for stamping seal data, an input field for entering text data such as signature data, a checkbox field for selecting check items, and a date field for entering the date. The first user operates the input device 206 on the first user terminal 20 and sends a request to the server 10 to add an input item. When the contract creation unit 1042 of the server 10 receives the request, it stores the document ID of the contract information in the document ID of the new record in the input item table 1016. In this way, the newly added input item information is stored in association with the contract information. The first user can store multiple input item information in association with the contract information.

[0059] In step S104, the first user sets input rules for each input item to be added. The first user specifies the input rules for each input item information set in step S103 by operating the input device 206 of the first user terminal 20 and sends 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 of each input item information in the input item table 1016. This allows input rules to be set for each input item.

[0060] In step S105, the contract creation unit 1042 of the server 10 receives input data for multiple input items entered by the first user. Specifically, the first user inputs input data for each input item set in step S104 by operating the input device 206 of the first user terminal 20. For example, the first user may input data for a number used to manage contract information, such as a reference number within the group to which they belong, into the input item where a management number is set. The first user may also input data for the date of the contract signing of the contract information into the input item where a contract signing date is set. Once the first user has finished inputting data into the input items, they send the input item ID and input data for each input item to the server 10. The contract creation unit 1042 of server 10 receives and accepts the input item ID and input data for each input item. The contract creation unit 1042 of server 10 stores the received input data in the input data field of the input item information in the input item table 1016, which is 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.

[0061] In step S106, 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 regarding the contract information. Specifically, the first user operates the input device 206 of the first user terminal 20 and sends a request to the server 10 to send contract information by pressing the send button 540 displayed on the screen 50 for creating contract information. When the contract creation unit 1042 of the server 10 receives the request, it sends a message to the second user notifying them that the first user has sent a request to confirm contract information. For example, the contract creation unit 1042 of the server 10 sends a message to the second user's email address notifying them that the first user has sent a request to confirm contract information via email or other means of communication. The message sent to the second user will include a URL (Uniform Resource Locator) containing a document ID to identify the contract information. The URL may directly contain the document ID, or it may contain an encrypted string of the document ID, or other information that allows the document ID to be identified by referring to an unillustrated table. The URL may also contain information to identify the second user. For example, if the second user has not registered for the service related to this disclosure, the URL must contain information to identify the second user.

[0062] If the first user sets an access code for the second user, the first user will communicate the access code to the second user via email or other means. This ensures that even if the message sent to the second user is intercepted by a third party, the third party cannot perform the contract verification process unless they obtain the access code.

[0063] Figure 14 shows an example screen displaying a message notified to the second user terminal 30. The message screen 60 displayed on the display 3081 of the second user terminal 30 includes a message 61 and information about a URL 62 containing a document ID for identifying contract information.

[0064] <Variation> If the first user selects and sets multiple verifiers in step S102, the system may be configured to allow different input field information to be set independently for each of the multiple verifiers in step S103. For example, if the first user sets two users, the second user and the third user, as verifiers, the input fields for the contract start date and contract end date may be set for the second user, and the input field for the contract signing date may be set for the third user. In this case, in the contract confirmation process described later, the second user can input data for the contract start date and contract end date, but not for the contract signing date. On the other hand, the third user cannot input data for the contract start date and contract end date, but can input data for the contract signing date. The system may also be configured to allow multiple verifiers to be selected and set for a single input field.

[0065] On screen 50 for creating contract information, input fields 532, 533, and 534 are drawn as drawing objects. For input fields 532 and 533, the user identification information "USER-B" of the user who has been selected and set to input the input field is drawn as the assignment, and the input field type is drawn as "Text". For input field 534 related to stamping, the user identification information "USER-C" of the user who has been selected and set to stamp is drawn as the assignment, and the input field type is drawn as "Stamp".

[0066] <Contract Verification Process> The contract verification process is the process by which a verifier confirms the contents of the contract information received from the creator.

[0067] <Overview of contract verification process> The contract verification process is a series of operations that involves receiving access from the verifier, presenting the verifier with a second screen displaying the contract information, receiving input data from the verifier for the input fields, and receiving data from the verifier regarding the verification of the contract information. The contract review process involves a series of steps: if the reviewer does not have the authority to approve the contract information, the system presents the reviewer with a first screen to select and designate an approver; it receives the designation of the approver for the contract information from the reviewer; it receives the input data for the input fields from the reviewer; and it sends the contract information to the designated approver.

[0068] <Details of contract verification process> In step S301, the second user can open the web page specified by the URL by operating the input device 306 or the like of the second user terminal 30 and selecting the URL contained in the received message, thereby opening the web page specified by the URL in the browser application of the second user terminal 30. As a result, the second user terminal 30 sends a request to the server 10 to execute the contract confirmation process.

[0069] If the second user's record in the verification table 1015 contains an access code field, the system can request the second user to enter an access code and then compare the entered access code with the access code stored in the second user's record in the verification table 1015 to perform authentication for the second user. Specifically, server 10 sends an input screen for authenticating the access code to the second user terminal 30. The second user operates the input device 306 on the second user terminal 30, enters the access code, and sends it to server 10. The contract verification unit 1043 of server 10 determines whether the received access code matches the access code stored in the second user's record in the verification table 1015. If they match, the contract verification process continues. If they do not match, the contract verification process is terminated. Note that the authentication process using the access code may be omitted.

[0070] The contract verification unit 1043 of server 10 searches the document ID field in document table 1014 based on the document ID included in the received request and obtains contract information. The contract verification unit 1043 of server 10 searches the document ID field in verification table 1015 based on the document ID included in the received request and obtains verifier information. The contract verification unit 1043 of server 10 searches the document ID field in input item table 1016 based on the document ID included in the received request and obtains input item information associated with the contract information.

[0071] In step S302, the contract verification unit 1043 of the server 10 identifies the second user and obtains the second user's approval authority information. The second user may be identified based on the second user ID 3011 included in the request received from the second user terminal 30, or based on identification information for identifying the second user included in the URL. If the second user has not registered for the service related to this disclosure, it is necessary to identify the second user from the URL. For example, the URL may include information for identifying the second user, such as the second user's email address or user ID.

[0072] The contract verification unit 1043 of server 10 searches the user ID field in user table 1012 based on the user identification information of the identified second user and retrieves the approval authority field for the second user. In this disclosure, the approval authority for the second user is stored in user table 1012, but the approval authority for the second user may also be stored for each group to which the second user belongs, or for each contract information or contract information type. The contract verification unit 1043 of server 10 retrieves the approval authority information for the second user for the target contract information. Furthermore, if the second user has not registered for the service related to this disclosure, the processing may be carried out by treating the second user as a user without approval authority.

[0073] In step S303, the contract confirmation unit 1043 of the server 10 generates either the first or second screen based on the acquired contract information, verifier information (information identifying the second user), input item information, and verifier approval authority information, and sends it to the second user terminal 30.

[0074] Specifically, if the contract confirmation unit 1043 of server 10 finds that the approval authority information of the second user obtained in step S302 contains information indicating that the user has the authority to approve the conclusion of the contract, it presents the second screen to the second user and proceeds to step S304.

[0075] On the other hand, if the second user is a user who cannot approve the conclusion of the contract information received, the first screen is presented to the second user and the process proceeds to step S307. Specifically, if the contract confirmation unit 1043 of the server 10 finds that the approval authority information of the second user obtained in step S302 contains information indicating that the second user does not have the authority to approve the conclusion of the contract, it presents the first screen to the second user and proceeds to step S307.

[0076] In step S304, the display 3081 of the second user terminal 30 presents the second user with a second screen that accepts an operation to approve the contract information. The second user confirms and approves the contract information displayed on the display 3081 of the second user terminal 30. Furthermore, the second screen presented to the second user may be configured to be displayed to the second user in the language specified to the verifier, based on the language information stored in the language data field of the second user's record in the confirmation table 1015.

[0077] Figure 17 shows an example of the second screen illustrating the operation of the contract confirmation process. The second screen 70A, displayed on the display 3081 of the second user terminal 30 for approving contract information, displays the status 710 indicating the current status of contract information creation, the contract information display area 730, document data 731, input items 732, 733, 734, 735, 736, and an agreement button 740.

[0078] In step S305, the contract confirmation unit 1043 of the server 10 receives input for one or more input fields of contract information. Specifically, the second user operates the input device 306 of the second user terminal 30 to input data to input items 732, 733, 734, and 735 set in the contract information. In this disclosure, input item 736 is not assigned to input by the second user, so it is visually indicated that the second user cannot input data for that item.

[0079] In step S306, the contract confirmation unit 1043 of the server 10 receives an instruction from the second user to agree to and approve the conclusion of the contract requested by the first user. The second user confirms the contract information and input data displayed on the display 3081 of the second user terminal 30. If the second user agrees to or accepts the contents, they operate the input device 306 of the second user terminal 30 and press the consent button 740 displayed on the screen 70 for confirming the contract information. This causes the server 10 to execute a request that includes the document ID, information identifying the second user, and the input data for each input item entered in step S305. The information identifying the second user may also be the second user ID 3011. The contract verification unit 1043 of server 10 stores information indicating that the second user has confirmed the contract information based on the received request. Specifically, the contract verification unit 1043 of server 10 searches the verification table 1015 based on the received document ID and information identifying the second user, and stores the value of True in the verification flag field of the record. For example, if the information identifying the second user is an email address, it searches the document ID and verifier email address fields in the verification table 1015 and stores the value of True in the verification flag field of the record. If the information identifying the second user is user identification information, it searches the document ID and verifier email address fields in the verification table 1015 based on the email address of the second user identified by searching the user ID field in user table 1012, and stores the value of True in the verification flag field of the record. The contract confirmation unit 1043 of server 10 stores the received input data in the input data item of input item table 1016, which is identified by the input item ID associated with the input data. As a result, in step S305, the input data entered by the second user is stored as input item information in input item table 1016.

[0080] The contract verification unit 1043 of server 10 determines that the contract verification process has been performed by all verifiers with approval authority. Specifically, the contract verification unit 1043 of server 10 determines that the contract verification process has been performed by all verifiers with approval authority if the verification flag in the verification table 1015 of the verifiers with approval authority has a value of True. In other words, the value of the verification flag in the records of verifiers who do not have approval authority is ignored when making this determination. When the contract verification unit 1043 of server 10 has completed the contract verification process by all verifiers with approval authority, it sends a message to the first user notifying them that the contract verification process is complete. For example, the contract creation unit 1042 of server 10 sends a message to the first user's email address via email or other means of communication notifying the second user that they have completed the verification of the contract information. The message sent to the first user includes information about a URL containing a document ID to identify the contract information. If multiple users are set as verifiers, the contract verification unit 1043 of server 10 may send a message to all verifiers except the user who last performed the contract verification process, notifying them that the contract verification process is complete. This allows all verifiers to receive notification that the contract verification process has been completed by all verifiers. Furthermore, the contract verification unit 1043 of server 10 may send a message to a user with administrator-level privileges in a group to which multiple verifiers belong, notifying them that the contract verification process has been completed. This allows the administrator in the group to which the verifiers belong to be notified that the contract verification process has been completed. The contract verification unit 1043 of server 10 retrieves the group ID item by searching the user ID or email address item in the user table 1012 based on the user ID or email address. Based on the retrieved group ID item, the contract verification unit 1043 of server 10 retrieves the group ID item in the group table 1013, retrieves the administrator ID item, identifies a user with administrator-level privileges by searching the user ID in the user table 1012 based on the administrator ID, and sends a message notifying them that the contract verification process has been completed.

[0081] <First screen presentation process (first embodiment)> In step S307, the display 3081 of the second user terminal 30 presents the second user with a first screen (first embodiment) that accepts an operation to identify the user relating to one or more approvers. For example, if a second user has not registered for the service related to this disclosure, the configuration may be such that the first screen presentation process (first embodiment) is executed. Furthermore, the first screen presented to the second user may be configured to be displayed in the language specified to the verifier, based on the language information stored in the language data field of the second user's record in the verification table 1015.

[0082] Figure 15 is an example of the first screen (first embodiment) showing the operation of the contract confirmation process. The first screen 80, which is displayed on the display 3081 of the second user terminal 30 and accepts an operation to identify a user relating 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.

[0083] In step S308, the second user provides information identifying one or more third users as approvers. Specifically, the second user operates the input device 306 of the second user terminal 30 to enter the approver's email address, name, company name, language used by the approver, and access code into the email address 801, name 802, company name 803, language 804, and access code 805 displayed on the first screen 80, respectively. The second user may omit entering the company name, language, and access code.

[0084] <First screen presentation process (second embodiment)> In step S307, the display 3081 of the second user terminal 30 presents the second user with a first screen (second embodiment) that accepts an operation to identify the user relating to one or more approvers. For example, if a second user has registered for the service related to this disclosure, the configuration may be such that the first screen presentation process (second embodiment) is executed.

[0085] Figure 16 is an example of the first screen (second embodiment) showing the operation of the contract confirmation process. The first screen 80, which is displayed on the display 3081 of the second user terminal 30 and accepts an operation to identify a user relating 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 addition, it displays 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 second user can operate the input device 306 of the second user terminal 30 and press the switch button 861 displayed on the first screen 80 to selectively switch between four types of user candidates: "Group," "History," "Group History," and "Other," and present multiple user candidates in the user candidate presentation area 841. Furthermore, the toggle button 861 may be configured so that the "Group," "Group History," and "Other" options cannot be pressed if the second user does not belong to a designated group and is not associated with group identification information, or if the second user is unable to use group-related functions. In other words, the configuration may be such that only user candidates based on "History" can be presented to the second user.

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

[0087] In the first screen presentation process (second embodiment), the contract confirmation unit 1043 of the server 10 can accept an operation to identify one or more users relating to approvers from the user candidates presented in the user candidate presentation area 841. Specifically, the second user selects and identifies one or more user candidates presented in the user candidate presentation area 841 by operating the input device 306 of the second user terminal 30. The control unit 304 of the second user terminal inputs the information of the selected user candidate into input fields such as email address 801, name 802, company name 803, and language 804. This allows the second user to select a third user to act as approver from a list of presented user candidates, thereby reducing the input burden on the second user.

[0088] <Presenting user candidates based on groups> The contract verification unit 1043 of server 10 presents to the second user associated with the second group one or more users from among the multiple users associated with the second group who can approve the contract information as user candidates. In this case, it is also possible to configure the system so that one or more users from among the multiple users associated with the second group who cannot approve the contract information are not presented as user candidates. Specifically, the second user operates the input device 306 of the second user terminal 30, presses the "Group" button from the toggle button 861 displayed on the first screen 80, and sends a request to the server 10 to suggest user candidates based on the group. When the contract verification unit 1043 of server 10 receives a request, it searches the email address or user ID field in user table 1012 based on the email address or user ID of the second user, which is information that identifies the second user, and obtains the group ID field (second group ID). Based on the obtained second group ID, the contract verification unit 1043 of server 10 searches the group ID field in user table 1012 and obtains the user ID, username, email address, and approval authority fields. The contract verification unit 1043 of server 10 sends the user ID, username, and email address of the user with approval authority to the second user terminal 30. The display 3081 of the second user terminal 30 displays the received user candidate information, including username and email address, in a user candidate presentation area 841.

[0089] <Presentation of user candidates based on history (first example)> The contract verification unit 1043 of server 10 presents one or more third users previously identified by the second user as user candidates, based on the second user's history information. In this case, the system may be configured not to present one or more users who cannot approve the contract information as user candidates. Specifically, the second user operates the input device 306 of the second user terminal 30, presses the "History" button from the toggle button 861 displayed on the first screen 80, and sends a request to the server 10 to present user candidates based on the history. When the contract confirmation unit 1043 of the server 10 receives the request, it searches the designated user data items in the confirmation table 1015 based on the information that identifies the second user, and obtains the confirmer email address of a user that the second user has previously identified as an approver. Based on the obtained email address, the contract confirmation unit 1043 of the server 10 searches the email address item in the user table 1012 and obtains the user ID, username, email address, and approval authority items. The contract verification unit 1043 of server 10 sends the user ID, username, and email address of the user with approval authority to the second user terminal 30. The display 3081 of the second user terminal 30 displays the received user candidate information, including username and email address, in a user candidate presentation area 841.

[0090] <Presentation of user candidates based on history (Second example)> The contract verification unit 1043 of server 10 presents, as user candidates, one or more third users previously identified by multiple users, including the second user associated with the second group, based on the history information of the second group to which the second user is associated. In this case, the system may be configured not to present one or more users who cannot approve the contract information as user candidates. Specifically, the second user operates the input device 306 of the second user terminal 30, presses the "Group History" button from the toggle button 861 displayed on the first screen 80, and sends a request to the server 10 to suggest user candidates based on the group history. When the contract verification unit 1043 of server 10 receives a request, it searches the email address or user ID field in user table 1012 based on the email address or user ID of the second user, which is information that identifies the second user, and retrieves the group ID field (second group ID). Based on the retrieved second group ID, the contract verification unit 1043 of server 10 searches the group ID field in user table 1012 and retrieves the user ID and email address fields. This makes it possible to retrieve multiple users associated with the second group. The contract verification unit 1043 of server 10 searches the designated person data field in the verification table 1015 based on the user IDs and email addresses of multiple users associated with the acquired second group, and obtains the verifier email addresses of users previously identified as approvers by the multiple users associated with the second group. Based on the obtained email addresses, the contract verification unit 1043 of server 10 searches the email address field in the user table 1012, and obtains the user ID, username, email address, and approval authority fields. The contract verification unit 1043 of server 10 sends the user ID, username, and email address of the user with approval authority to the second user terminal 30. The display 3081 of the second user terminal 30 displays the received user candidate information, including username and email address, in a user candidate presentation area 841.

[0091] <Suggesting user candidates based on other information> The contract verification unit 1043 of server 10 presents multiple users as user candidates based on contract information, the first user associated with the first group, and the first group itself. In this case, it is also possible to configure the system so that one or more users who cannot approve the contract information are not presented as user candidates. Specifically, the second user operates the input device 306 of the second user terminal 30, presses the "Other" button from the toggle button 861 displayed on the first screen 80, and sends a request to the server 10 to suggest user candidates based on other information. When the contract confirmation unit 1043 of the server 10 receives the request, it 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. Based on the document ID contained in the contract information, it searches the document ID item in the confirmation table 1015 and obtains the confirmer email address item of the user previously identified as an approver in the contract information. At this time, it is also possible to refer to the user table 1012 and the group table 1013 and obtain only the confirmer email addresses of users associated with the second group to which the second user belongs. Based on the obtained email addresses, the contract confirmation unit 1043 of the server 10 searches the email address item in the user table 1012 and obtains the user ID, username, email address, and approval authority items. Based on the information identifying the second user, the system searches the designated user data field in the confirmation table 1015 to obtain the verifier email address of a user previously identified as an approver by the second user. The contract confirmation unit 1043 of the server 10 searches the email address field in the user table 1012 based on the obtained email address to obtain the user ID, username, email address, and approval authority fields. The contract verification unit 1043 of server 10 sends the user ID, username, and email address of the user with approval authority to the second user terminal 30. The display 3081 of the second user terminal 30 displays the received user candidate information, including username and email address, in a user candidate presentation area 841.

[0092] <Example 1> Furthermore, in the presentation of user candidates based on groups, user candidates based on history (first embodiment), user candidates based on history (second embodiment), and user candidates based on other information, one or more users who can approve contract information may be presented as user candidates with priority over one or more users who cannot approve contract information. Specifically, the contract verification unit 1043 of server 10 may be configured to send the user ID, username, and email address of users who do not have approval authority, in addition to users who do have approval authority, to the second user terminal 30. In this case, the display 3081 of the second user terminal 30 may present the user candidate information with approval authority higher in the list than the user candidate information without approval authority, making it easier for the second user to select the user candidate information with approval authority. In addition, if the user candidate information is displayed in a carousel or by pagination, it is conceivable to display the user candidate information with approval authority on the first page.

[0093] <Modification 2> The contract confirmation unit 1043 of server 10 may be configured to present user candidates in the first embodiment and the second embodiment based on the history, prioritizing the third user who has been identified more frequently among one or more third users. 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 server 10 counts the number of duplicate user candidate information entries for each user ID or email address of the acquired user candidate information, and uses this number as a priority to present user candidate information with higher priority higher up in the list. This allows the second user to easily select user candidate information of users that have been selected and identified more frequently by multiple users belonging to the second user or second group in the past. In addition, when displaying user candidate information using a carousel or pagination, it is conceivable to display user candidate information with higher priority on the first page.

[0094] <Variation 3> The configuration may also involve presenting a single user candidate to a second user by combining the presentation of user candidates based on groups, user candidates based on history (first embodiment), user candidates based on history (second embodiment), and user candidates based on other information.

[0095] <Approver setting process> The second user operates the input device 306 of the second user terminal 30 and presses the add button 822 displayed on the first screen, thereby causing the server 10 to execute a process that sends a request containing the information entered in the email address 801, name 802, company name 803, language 804, and access code 805. The contract verification unit 1043 of server 10 stores the email address and document ID included in the received request in the verification table 1015, in the fields for the verifyer's email address and document ID, respectively, and stores the contract information in association with the third user's email address. Alternatively, the second user's user ID or email address may be stored in the field for the designated person data in the verification table 1015. This allows the second user to receive suggestions for user candidates based on their history. At this time, the "Confirmation Order" field in confirmation table 1015 is incremented by one from the "Confirmation Order" field of the user who will be the confirmer, and stored. This sets the circulation order of the confirmers in the contract confirmation process. Note that setting the circulation order is not mandatory. The second user can identify and set up one or more approvers by repeatedly performing the processes in steps S307 and S308. Once the approver setting is complete, the second user terminates the approver setting process by operating the input device 306 of the second user terminal 30 and pressing the cancel button 821.

[0096] In this case, the contract confirmation unit 1043 of the server 10 may be configured to assign input items that the first user has assigned to the second user to the third user. In other words, the system may be configured to pass on the input item information assigned to the second user to the approver designated by the second user. Specifically, the contract verification unit 1043 of server 10 searches the inputter ID field in the input field table 1016 based on the second user ID, and stores the third user ID in the inputter ID field of the identified record. Alternatively, the contract verification unit 1043 of server 10 may be configured to delete the second user ID from the inputter ID field of the identified record, store the third user ID, and overwrite the inputter ID with the third user ID. Alternatively, the contract verification unit 1043 of server 10 may be configured to store the third user ID without deleting the second user ID from the inputter ID field of the identified record, and add the third user ID as the inputter ID.

[0097] Furthermore, if the second user has identified multiple third users as approvers, the system may be configured to assign multiple different third users to each of the multiple input fields assigned to the second user by the first user. Specifically, the second user operates the input device 306 of the second user terminal 30 to selectively add and store the user IDs of multiple different third users in the input user ID field of the input item information record in the input item table 1016 where the second user ID is stored.

[0098] In step S309, the display 3081 of the second user terminal 30 presents the second user with a third screen that accepts an operation to confirm the contract information. The second user confirms the contract information displayed on the display 3081 of the second user terminal 30. If there is no input field information assigned to the second user, step S309 may be omitted.

[0099] Figure 18 shows an example of the third screen illustrating the operation of the contract confirmation process. The third screen 70B, displayed on the display 3081 of the second user terminal 30 for confirming contract information, differs from the second screen 70A only in that the consent button 740 is not displayed and the save button 750 is displayed; otherwise, the configuration is the same and therefore will not be explained.

[0100] In step S309, the contract confirmation unit 1043 of the server 10 receives input for one or more input fields of contract information. Specifically, the second user operates the input device 306 of the second user terminal 30 to input data to input items 732, 733, 734, and 735 set in the contract information. In this disclosure, input item 736 is not assigned to input by the second user, so it is visually indicated that the second user cannot input data for that item.

[0101] The second user operates the input device 306 of the second user terminal 30 and presses the save button 750, thereby executing a process that sends a request to the server 10 containing the document ID, information identifying the second user, and input data for each input item entered in step S309. The information identifying the second user may also be the second user ID 3011. The contract confirmation unit 1043 of server 10 stores the received input data in the input data item of input item table 1016, which is identified by the input item ID associated with the input data. As a result, in step S305, the input data entered by the second user is stored as input item information in input item table 1016. In this case, since the second user does not have approval authority, the value of True is not stored in the confirmation flag field of the second user's record in confirmation table 1015.

[0102] In step S310, the contract confirmation unit 1043 of the server 10 receives an instruction from the second user to request the third user to conclude a contract regarding the contract information. Specifically, the contract creation unit 1042 of server 10 sends a message to the third user notifying them that a request for approval of contract information has been sent by the second user. For example, the contract confirmation unit 1043 of server 10 sends a message to the third user's email address via email or other means notifying them that a request for approval of contract information has been sent by the second user. Messages sent to third-party users must include a URL (Uniform Resource Locator) containing a document ID to identify contract information. The URL may directly contain the document ID, or it may contain an encrypted string of the document ID, or other information that allows the document ID to be identified by referring to an unillustrated table. The URL may also include information to identify the third-party user. For example, if the third-party user has not registered for the service related to this disclosure, the URL must include information to identify the third-party user. The message notified to the third user terminal 40 is the same as in Figure 14, so its explanation is omitted.

[0103] If the second user sets an access code for the third user, they will communicate the access code to the third user via email or other means. This ensures that even if the message sent to the third user is intercepted by a third party, the third party cannot execute the contract verification process unless they obtain the access code.

[0104] In step S301, the third user can open the web page specified by the URL by operating the input device 406 or the like on the third user terminal 40 and selecting the URL contained in the received message, thereby opening the web page specified by the URL in the browser application of the third user terminal 40. As a result, the third user terminal 40 sends a request to the server 10 to execute the contract confirmation process. The contract verification process for the third user is the same as that for the second user, so the explanation is omitted. The third user, who has approval authority, can approve the contract information by executing steps S304, S305, and S306 of the contract verification process.

[0105] <Basic Computer Hardware Configuration> Figure 19 is a block diagram showing the basic hardware configuration of computer 90. Computer 90 includes at least a processor 901, main memory 902, auxiliary memory 903, and a communication interface IF991. These are electrically connected to each other by a communication bus 921.

[0106] The processor 901 is hardware for executing the instruction set written in a program. The processor 901 consists of an arithmetic unit, registers, peripheral circuits, etc.

[0107] Main memory 902 is used to temporarily store programs and data processed by programs, etc. For example, it is a volatile memory such as DRAM (Dynamic Random Access Memory).

[0108] Auxiliary storage device 903 refers to 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.

[0109] The IF991 communication interface is an interface for inputting and outputting signals for communication with other computers via a network using wired or wireless communication standards. A network consists of various mobile communication systems, such as the internet, LANs, and wireless base stations. For example, a network includes 3G, 4G, and 5G mobile communication systems, LTE (Long Term Evolution), and wireless networks that can connect to the internet via designated access points (e.g., Wi-Fi®). When connecting wirelessly, communication protocols include, for example, Z-Wave®, ZigBee®, and Bluetooth®. When connecting via a wired connection, the network also includes connections made directly via USB (Universal Serial Bus) cables, etc.

[0110] Furthermore, by distributing all or part of each hardware configuration across multiple computers 90 and connecting them to each other via a network, a computer 90 can be virtually realized. Thus, the concept of computer 90 includes not only a computer 90 housed in a single enclosure or case, but also a virtualized computer system.

[0111] <Basic Functional Configuration of Computer 90> The functional configuration of the computer realized by the basic hardware configuration of computer 90 (Figure 19) is described below. The computer comprises at least one functional unit: a control unit, a memory unit, and a communication unit.

[0112] Furthermore, the functional units of 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.

[0113] The control unit is realized when the processor 901 reads various programs stored in the auxiliary storage device 903, loads them into the main memory device 902, and executes processing according to those programs. The control unit can realize various functional units that perform information processing depending on the type of program. In this way, the computer is realized as an information processing device that performs information processing.

[0114] The memory unit is implemented by the main memory 902 and the auxiliary memory 903. The memory unit stores data, various programs, and various databases. The processor 901 can also reserve memory areas corresponding to the memory unit in the main memory 902 or the auxiliary memory 903 according to the program. The control unit can also cause the processor 901 to perform operations such as adding, updating, and deleting data stored in the memory unit according to the various programs.

[0115] A database, specifically a relational database, is used to manage and link together tabular data sets called masters, which are structurally defined by rows and columns. In a database, tables are called tables, masters are called masters, the columns of tables are called columns, and the rows of tables are called records. In a relational database, relationships can be established and linked between tables and masters. Typically, each table and master has a primary key column to uniquely identify records, but setting a primary key column is not mandatory. The control unit can instruct the processor 901 to add, delete, or update records in specific tables and masters stored in the memory unit, according to various programs.

[0116] Furthermore, the databases and masters in this disclosure may include any data structures (lists, dictionaries, associative arrays, objects, etc.) in which information is structurally defined. 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.

[0117] The communication unit is implemented by the communication IF991. The communication unit provides the functionality to communicate with other computers 90 via the network. The communication unit can receive information transmitted from other computers 90 and input it to the control unit. The control unit can cause the processor 901 to perform information processing on the received information according to various programs. The communication unit can also transmit information output from the control unit to other computers 90.

[0118] <Note> The details described in each of the above embodiments are noted below.

[0119] (Note 1) A program comprising a processor and a memory unit, for causing a computer to execute electronic contract procedures between users belonging to different organizations, wherein the program causes the processor to execute a contract acceptance step (S101) for receiving contract information that is the subject of a contract to be concluded between a first user and a second user; a recipient acceptance step (S102) for receiving information from the first user that identifies the second user as the recipient of the contract information received in the contract acceptance step; an approver acceptance step (S308) for receiving information from the second user that identifies one or more third users as approvers of the contract information received in the contract acceptance step; and an approval step (S306) for receiving instructions from one or more third users to approve the conclusion of the contract information received in the contract acceptance step, wherein the second user is a user who cannot approve the conclusion of the contract information received in the contract acceptance step. This allows the second user to avoid approving the contract if they are not authorized to do so, and also allows the contract signing process to proceed without being returned to the first user, thereby reducing the procedural burden on the first user.

[0120] (Note 2) The program described in Appendix 1, where the first user is a user belonging to a different group than the second user, and the second and third users are users belonging to the same group. This allows the second user to avoid approving the contract if they are not authorized to do so, and also allows the contract signing process to proceed without being returned to the first user, thereby reducing the procedural burden on the first user.

[0121] (Note 3) The program, as described in Appendix 1 or 2, causes the processor to perform a first presentation step (S307) in which it presents a first screen to the second user that accepts an operation to identify one or more approvers based on information identifying the second user received in the recipient reception step, and a second presentation step (S304) in which it presents a second screen to the one or more third users that accepts an operation to approve contract information based on information identifying one or more third users received in the approver reception step, wherein the approver reception step is a step in which the program receives information identifying one or more third users as approvers of the contract information received in the contract reception step based on an operation from the second user to the first screen, and the approval step is a step in which the program receives instructions from one or more third users to approve the contract information received in the contract reception step based on an operation from one or more third users to the second screen. This allows the second user to avoid approving the contract if they are not authorized to do so, and also allows the contract signing process to proceed without being returned to the first user, thereby reducing the procedural burden on the first user.

[0122] (Note 4) The program described in Appendix 3 includes a first presentation step of presenting multiple users to a second user as user candidates, and a first screen that accepts the user's operation to identify one or more users who are approvers from among the user candidates. This allows the second user to select a third user from several presented user candidates, thereby reducing the procedural burden on the third user.

[0123] (Note 5) The program as described in Appendix 4, wherein the first presentation step includes presenting to the second user associated with the second group one or more users from among the multiple users associated with the second group who can approve the contract information received in the contract acceptance step, as user candidates. This allows the second user to select a third user from several presented user candidates, thereby reducing the input burden on the second user.

[0124] (Note 6) The program as described in Appendix 4 or 5, wherein the first presentation step includes a step of presenting to the second user, based on the second user's history information, one or more third users previously identified by the second user in the approver acceptance step, as user candidates. This allows the second user to select a third user from several user candidates previously identified, thereby reducing the input burden on the second user.

[0125] (Note 7) The program described in any of Appendix 4 to 6, wherein the first presentation step includes, to a second user associated with the second group, the step of presenting, in the approver acceptance step, one or more third users previously identified by multiple users, including the second user associated with the second group, as user candidates, based on the historical information of the second group. This allows the second group of users to select a third user from several user candidates previously identified by other users in the second group, thereby reducing the input burden on the second user.

[0126] (Note 8) The first presentation step is to present to the second user, among the one or more third users previously identified, the third users who have been identified more frequently are given priority as potential users, as described in Appendix 6 or 7 of the program. This reduces the input burden on the second user.

[0127] (Note 9) The first presentation step is a program as described in any of Appendix 4 to 8, which includes a step of presenting multiple users as user candidates based on the contract information received in the contract acceptance step, the first user associated with the first group, and the first group itself. This allows the second user to select a third user from several presented user candidates, thereby reducing the input burden on the second user.

[0128] (Note 10) The program, as described in any of Appendix 4 to 9, includes a first presentation step in which the program presents to the second user, as a candidate user, one or more users who can approve the contract information received in the contract acceptance step, with priority given to one or more users who cannot approve the contract information. This reduces the input burden on the second user.

[0129] (Note 11) The first presentation step is a step in which, to a second user associated with a second group, one or more users from among the multiple users associated with the second group who are unable to approve the contract information received in the contract acceptance step are not presented as user candidates, as described in any of the programs described in Appendix 4 to 10. This reduces the input burden on the second user.

[0130] (Note 12) The program is one of the programs described in any of Appendix 1 to 11, which includes an input setup step in which the processor sets input fields for contract information, and an approver acceptance step in which the input fields assigned to the second user in the input setup step are set to be assigned to the third user. This allows input fields assigned to a second user to be passed on to a third user. Since the third user can also input data into the fields assigned to the second user, convenience is improved.

[0131] (Note 13) An information processing device comprising a processor and a memory unit, wherein the processor is configured to execute a contract acceptance step (S101) for receiving contract information that is the subject of a contract to be concluded between a first user and a second user; a recipient acceptance step (S102) for receiving information from the first user that identifies the second user as the recipient of the contract information received in the contract acceptance step; an approver acceptance step (S308) for receiving information from the second user that identifies one or more third users as approvers of the contract information received in the contract acceptance step; and an approval step (S306) for receiving instructions from one or more third users to approve the conclusion of the contract information received in the contract acceptance step, wherein the second user is a user who cannot approve the conclusion of the contract information received in the contract acceptance step. This allows the second user to avoid approving the contract if they are not authorized to do so, and also allows the contract signing process to proceed without being returned to the first user, thereby reducing the procedural burden on the first user.

[0132] (Note 14) An information processing method comprising a processor and a memory unit, wherein the processor is made to execute a contract acceptance step (S101) for receiving contract information that is the subject of a contract to be concluded between a first user and a second user; a recipient acceptance step (S102) for receiving information from the first user that identifies the second user as the recipient of the contract information received in the contract acceptance step; an approver acceptance step (S308) for receiving information from the second user that identifies one or more third users as approvers of the contract information received in the contract acceptance step; and an approval step (S306) for receiving instructions from one or more third users to approve the conclusion of the contract information received in the contract acceptance step, wherein the second user is a user who cannot approve the conclusion of the contract information received in the contract acceptance step. This allows the second user to avoid approving the contract if they are not authorized to do so, and also allows the contract signing process to proceed without being returned to the first user, thereby reducing the procedural burden on the first user. [Explanation of Symbols]

[0133] 1 System, 10 Servers, 101 Storage Unit, 104 Control Unit, 106 Input Device, 108 Output Device, 20 First User Terminal, 201 Storage Unit, 204 Control Unit, 206 Input Device, 208 Output Device, 30 Second User Terminal, 301 Storage Unit, 304 Control Unit, 306 Input Device, 308 Output Device, 40 Third User Terminal, 401 Storage Unit, 404 Control Unit, 406 Input Device, 408 Output Device

Claims

1. A program for causing a computer to execute an electronic contract procedure between users, the program comprising: a processor; and a storage unit. The program causes the processor to: receiving, from a first user, an operation for designating contract information to be a target of contract conclusion and an operation for designating a second user who does not belong to a group to which the first user belongs as a recipient of the contract information; presenting to the second user designated by the first user a first screen for accepting an operation to identify a user who does not belong to a group to which the first user belongs and who is associated with one or more approvers for the contract information designated by the first user; receiving, from the second user, an operation to specify one or more third users as approvers of the specified contract information based on an operation on the first screen; presenting a second screen for accepting an operation to approve the contract information to the one or more third users involved in the specified operation; receiving, from the one or more third users, an instruction to approve the conclusion of a contract for the contract information designated by the first user based on an operation on the second screen; A program to execute.

2. In the step of accepting an operation from the first user, a designation of the second user is accepted from the first user as a user who does not have approval authority for the contract information related to the designation; 2. The program according to claim 1, wherein, in the step of presenting the first screen, if the second user is designated by the first user as a user who does not have the approval authority, the operation to approve the contract information is not accepted from the second user, and the first screen is presented to the second user.

3. The program described in claim 1, wherein, when the second user approves the contract information specified by the first user, a second screen is presented including an area for displaying the contract information and an operating member for agreeing to and approving the displayed contract information, and an instruction to approve the contract information by operating the operating member is accepted from the second user.

4. A method for causing a computer to execute an electronic contract procedure between users, the method comprising: The method further comprises the processor: receiving, from a first user, an operation for designating contract information to be a target of contract conclusion and an operation for designating a second user who does not belong to a group to which the first user belongs as a recipient of the contract information; presenting to the second user designated by the first user a first screen for accepting an operation to identify a user who does not belong to a group to which the first user belongs and who is associated with one or more approvers for the contract information designated by the first user; receiving, from the second user, an operation to specify one or more third users as approvers of the specified contract information based on an operation on the first screen; presenting a second screen for accepting an operation to approve the contract information to the one or more third users involved in the specified operation; receiving, from the one or more third users, an instruction to approve the conclusion of a contract for the contract information designated by the first user based on an operation on the second screen; A method for performing.

5. An information processing device, the information processing device executing an electronic contract procedure between users, A control unit of the information processing device receiving, from a first user, an operation for designating contract information to be a target of contract conclusion and an operation for designating a second user who does not belong to a group to which the first user belongs as a recipient of the contract information; presenting to the second user designated by the first user a first screen for accepting an operation to identify a user who does not belong to a group to which the first user belongs and who is associated with one or more approvers for the contract information designated by the first user; receiving, from the second user, an operation to specify one or more third users as approvers of the specified contract information based on an operation on the first screen; presenting a second screen for accepting an operation to approve the contract information to the one or more third users involved in the specified operation; receiving, from the one or more third users, an instruction to approve the conclusion of a contract for the contract information designated by the first user based on an operation on the second screen; An information processing device that executes the above.

Images