Program, information processing device, information processing method, and information processing system

Abstract

To provide a program, an information processing device, a method and a system with which, in an electronic contract system, it is possible to determine whether a counterparty user who is a party to contract conclusion has an appropriate right to approve in a counterparty organization.SOLUTION: A program causes the steps to be executed, including: a step in which when an electronic contract procedure between users belonging to different organizations accepts contract information from a first user that is an object of contract conclusion, a second user is accepted as a recipient of the contract information having been accepted from the first user in a contract information acceptance step; a step for accepting from the second user an indication to approve the contract conclusion of the contract information; a step for acquiring user information of the other, to at least one of the first and the second users, from an external social networking service; and a step for presenting the other user information having been acquired in the information acquisition step, to the at least one of the users.SELECTED DRAWING: Figure 14

Description

Technical Field

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

Background Art

[0002] With the development and spread of computer technology, documents that have hitherto been in paper form 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 data storage destinations for each user group 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 that executes an electronic contract procedure between the creator (sender) of information related to an electronic contract (contract information) and the confirmor (receiver) of the contract information, it has often been difficult to determine whether the partner user who is a party to the contract conclusion is a user who has appropriate approval authority in the partner organization. In addition, it has been difficult to confirm whether the partner user who is a party to the contract conclusion is a trustworthy person when concluding a contract, and whether they are involved in anti-social forces, crimes, or suspicious incidents.

Means for Solving the Problems

[0005] A program for causing a computer, comprising a processor and a memory unit, to execute electronic contract procedures between users belonging to different organizations, wherein the program causes the processor to execute: a contract acceptance step of receiving contract information subject to contract conclusion from a first user; a recipient acceptance step of receiving a second user from the first user as the recipient of the contract information received in the contract acceptance step; an approval step of receiving an instruction from the second user, received in the recipient acceptance step, to approve the conclusion of the contract information; an information acquisition step of obtaining user information of the other user from an external social networking service for at least one of the first or second users; and an information presentation step of presenting the user information of the other user obtained in the information acquisition step to at least one of the users. [Effects of the Invention]

[0006] According to this disclosure, when executing electronic contract procedures, the parties to the contract can securely execute the contract procedures by taking into account the credit information of the other party's 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 SNS server 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]It is a diagram showing the data structure of the document table 1014. [Figure 9] It is a diagram showing the data structure of the confirmation table 1015. [Figure 10] It is a diagram showing the data structure of the input item table 1016. [Figure 11] It is a diagram showing the data structure of the approval authority master 1017. [Figure 12] It is a diagram showing the data structure of the SNS user table 4012. [Figure 13] It is a diagram showing the data structure of the SNS group table 4013. [Figure 14] It is a flowchart showing the operation of the contract creation process. [Figure 15] It is a flowchart showing the operation of the contract confirmation process. [Figure 16] It is an example screen showing the operation of the contract creation process. [Figure 17] It is an example screen showing the operation of the contract creation process. [Figure 18] It is an example screen showing the operation of the contract creation process. [Figure 19] It is an example screen showing the message notified to the second user terminal 30. [Figure 20] It is an example screen showing the operation of the contract confirmation process. [Figure 21] It is an example screen showing the operation of the contract confirmation process. [Figure 22] It is a block diagram showing the basic hardware configuration of the computer 90.

Embodiments for Carrying Out the Invention

[0008] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In all the drawings for describing the embodiments, common components are denoted by the same reference numerals, and repeated descriptions are omitted. Note that the following embodiments do not unduly limit the content of the present disclosure described in the claims. Also, not all of the components shown in the embodiments are essential components of the present disclosure. Further, each drawing is a schematic diagram and is not necessarily drawn precisely.

[0009] <Configuration of System 1> System 1 in the present disclosure is an information processing system for realizing an electronic contract conclusion service among a plurality of users. System 1 includes information processing devices of server 10, first user terminal 20, second user terminal 30, and SNS server 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 SNS server 40.

[0010] Each information processing device is composed of a computer including an arithmetic device and a storage device. 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 SNS server 40, descriptions overlapping with the basic hardware configuration and the basic functional configuration of the computer described later are omitted.

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

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

[0013] 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 services related to this disclosure. User table 1012 is a table with User ID as the primary key and contains columns for User ID, Username, Email Address, Group ID, Approval Authority, and SNS User Data. Figure 6 shows the data structure of user table 1012.

[0014] 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. It is also possible to configure the system so that approval permissions can be set according to the contract information. For example, user A may have approval permissions for a specific contract information A, but not for a specific 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. Alternatively, the system could be configured to store multiple levels (ranks) of permission information depending on the user's department, position, etc. For example, temporary staff could be assigned rank C, regular employees rank B, managers rank A, and executives rank S in the approval permission field. Then, based on the contract information, such as contract type and contract amount, only users with a predetermined rank or higher (for example, A or higher for non-disclosure agreements) could approve the conclusion of a contract. SNS user data is an item that stores information about users (SNS user information) on social networking services (SNS services) of users who use the services related to this disclosure. SNS user information includes the user's name, affiliation, position, work history, etc., stored in the SNS user table 5012 and SNS group table 5013 described below for users who use the services related to this disclosure. SNS user information may include not only the user information of the user using the service related to this disclosure on the SNS service, but also information such as the job titles and work history of other users with whom the user is connected on the SNS service. SNS user information includes credit information, which indicates the user's creditworthiness in transactions, including the user's affiliation, job title, and work history. Credit information includes job title, work history, and credit scores calculated based on the job titles, work history, and credit information of other users connected to the user through social networking services.

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

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

[0017] Document table 1014 is a table for storing and managing information (electronic 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.

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

[0019] 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 electronic contract information. Confirmation table 1015 is a table that has columns for document ID, confirmation order, confirmer email address, confirmation flag, date and time, language data, access code, and date and time. Figure 9 shows the data structure of confirmation table 1015.

[0020] The document ID is an item that stores the document identification information of the electronic contract information to be reviewed by the verifier. The "Verification Order" field stores information about the order in which electronic contract information is reviewed by the reviewers. The electronic contract information stored by the creator is circulated to the reviewers in the order of the verification order, and verification is performed accordingly. The verifier email address field stores the email address of the verifier of the electronic contract information. The verifier's email address does not need to be registered in advance to use the services related to this disclosure. In other words, the verifier's 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 process for the electronic contract information has been completed by the verifier. When the verifier has completed the confirmation of the electronic contract information, information indicating that the confirmation has been completed, such as a value of True, is stored in the confirmation flag item. The date and time field stores the date and time when the verifier performed the verification procedure for the electronic contract information. Specifically, it stores the date and time when the verification identification information was stored in the verification flag field. 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.

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

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

[0023] Approval Authority Master 1017 is a table that stores rule information regarding approval authority for approving contract information within the group to which a user belongs. Approval authority master 1017 is a table that has columns for group ID, approval authority, and score threshold. Figure 11 shows the data structure of the approval authority master 1017.

[0024] The group ID is an item that stores group identification information used to identify a group. Approval authority is an item that stores user authorization information related to the authorization process. Multiple levels (levels, ranks) of authorization information are stored depending on the user's department, position, etc. The score threshold is an item that stores the credit score threshold (score threshold) of a trading partner that a user can approve for each level of approval authority. A user can only proceed with contract procedures with a trading partner if the trading partner's credit score is greater than the score threshold determined by their approval authority.

[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, a contract confirmation unit 1043, and a contract judgment unit 1044. 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 can be any string or number that can identify the user, and may be any string or number that the user wishes, or the user registration control unit 1041 may automatically set any string or number.

[0027] <Configuration of the first user terminal 20> The first user terminal 20 is an information processing device operated by the first user who uses 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.

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

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

[0030] 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 an interpreted programming language such as JavaScript® that is executed on a web browser application stored in the first user terminal 20.

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

[0032] <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 keyboard 2065.

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

[0034] <Configuration of the second user terminal 30> The second user terminal 30 is an information processing device operated by a second user utilizing 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.

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

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

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

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

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

[0040] <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. <00(00259> <Configuration of the SNS server 40> The SNS server 40 is an information processing device that provides an SNS service. The SNS service according to the present disclosure is preferably a business SNS that stores and manages information such as a user's affiliated organization, position in the affiliated organization, work history, and academic background. A business SNS constructs a social network among users who mutually hold contact information and have common elements such as work history and academic background, and provides an SNS service that enables mutual business communication. In the SNS service according to the present disclosure, by registering the business cards owned by the user with the SNS server 40, information such as the user's affiliated organization, position in the affiliated organization, work history, and contact information can be stored and managed in the SNS server 40 without complicated registration procedures. The SNS server 40 includes a storage unit 401 and a control unit 404.

[0042] <Configuration of the storage unit 401 of the SNS server 40> The storage unit 401 of the SNS server 40 includes an application program 4011, an SNS user table 4012, and an SNS group table 4013.

[0043] The SNS user table 4012 is a table for storing and managing information of member users (hereinafter referred to as users) who use the SNS service. By registering for the service, the user's information is stored in a new record in the SNS user table 4012. As a result, the user can use the SNS service according to the present disclosure. In the SNS service according to the present disclosure, the user can read the business card owned by the user with an optical reading device such as a scanner, and store information such as the name and affiliated information described on the business card as user information. The SNS user table 4012 is a table having columns of SNS user ID, SNS user name, SNS email address, SNS group ID, work history data, and educational background data with the SNS user ID as the primary key. FIG. 12 is a diagram showing the data structure of the SNS user table 4012.

[0044] The SNS user ID is an item for storing user identification information for identifying a user who uses the SNS service. The user identification information is an item for which a unique value is set for each user. The SNS user name is an item for storing the name of a user who uses the SNS service. The user name may be set to any string such as a nickname instead of the real name. The SNS email address field is a field that stores the email address of a user who uses an SNS service. The SNS Group ID is an item that stores the group identification information of the group to which a user of the SNS service belongs. A user may belong to multiple groups. Employment history data is an item that stores information about the current and past employment history of users of SNS services. Employment history data stores information about the user's past employment history, such as the organization they belong to (corporation, company, club, group, or department within a company), their job title, length of employment, and awards received. Educational background data is an item that stores information about the current and past educational background of users of the SNS service. This data includes information about the user's past work history, such as the schools they attended, graduated from, period of enrollment, and awards received.

[0045] The SNS group table 4013 is a table that stores and manages information about the groups to which users of the SNS service belong (group information). Groups can be defined as any group to which a user belongs, such as corporations, companies, clubs, organizations, or departments within a company. The SNS group table 4013 is a table with SNS group ID as its primary key and containing columns for SNS group ID, SNS group name, and SNS administrator ID. Figure 13 shows the data structure of the SNS group table 4013.

[0046] The SNS Group ID is an item that stores group identification information used to identify groups using the SNS service. This group identification information is a unique value assigned to each group. The SNS group name is an item that stores the name of the group using the SNS service. The group name can be set to any string of characters. The SNS administrator ID is an item that stores the user identification information of users with administrator privileges in a group using the SNS service. The user with administrator privileges can arbitrarily determine and set users with a certain status or authority or higher in a group such as an organization.

[0047] <Configuration of the control unit 404 of the SNS server 40> The control unit 404 of the SNS server 40 includes an SNS user registration control unit 4041. The control unit 404 realizes each functional unit by executing the application program 4011 stored in the storage unit 401.

[0048] The SNS user registration control unit 4041 performs a process of storing information of a user who wishes to use the SNS service according to the present disclosure in the SNS user table 4012. The information stored in the SNS user table 4012 is such that a user using the SNS service opens a web page or the like operated by the service provider from an arbitrary information processing terminal, enters information in a predetermined input form, and transmits it to the SNS server 40. The SNS user registration control unit 4041 stores the received information in a new record of the SNS user table 4012, and the user registration is completed. As a result, the user stored in the SNS user table 4012 can use the service. Prior to the registration of user information in the SNS user table 4012 by the SNS user registration control unit 4041, the SNS service provider may perform a predetermined review to restrict whether the user can use the SNS service. The SNS user ID may be any character string or number that can identify the user, any character string or number desired by the user, or the SNS user registration control unit 4041 may automatically set any character string or number.

[0049] <Operation of the information processing system 1> Hereinafter, each process of the information processing system 1 will be described. FIG. 14 is a flowchart showing the operation of the contract creation process. Figure 15 is a flowchart showing the operation of the contract verification process. Figure 16 shows an example screen illustrating the operation of the contract creation process. Figure 17 shows an example screen illustrating the operation of the contract creation process. Figure 18 shows an example screen illustrating the operation of the contract creation process. Figure 19 is an example screen showing a message notified to the second user terminal 30. Figure 20 shows an example screen illustrating the operation of the contract verification process. Figure 21 shows an example screen illustrating the operation of the contract verification process.

[0050] <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 user is the user who verifies the contract information. It is possible to set multiple users as verifiers when creating contract information. In this disclosure, the first user is a user belonging to a different organization, company, or other group from the second user.

[0051] Figure 16 shows an example screen illustrating the operation of the contract creation process. The creation screen 50 displayed on the display 2081 of the first user terminal 20 shows the 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.

[0052] <Overview of the contract creation process> The contract creation process involves the creator creating contract information, setting a recipient (the verifier) ​​for the contract information, obtaining and presenting the verifier's SNS user information to the creator, and determining whether the contract procedure is feasible based on the SNS user information. If it is determined that the contract procedure cannot be performed, the first guidance information is presented. If it is determined that the contract procedure can be performed, the process involves setting input fields for the contract information, setting input rules for those fields, receiving input data from the creator, and sending the contract information to the verifier.

[0053] <Details of the contract creation process> In step S101, the contract creation unit 1042 of the server 10 executes a contract acceptance step in which it receives contract information to be concluded from the first user. 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.

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

[0055] In step S102, the contract creation unit 1042 of the server 10 executes a recipient acceptance step in which the first user accepts the second user as the verifier (recipient) of the contract information received in the contract acceptance step. In this disclosure, the first user selects and identifies the second user as the recipient. Specifically, the first user operates the input device 206 of the first user terminal 20 to enter the email address and username of the second user, who will act as the verifier, and sends this information to the server 10.

[0056] In step S102, the contract creation unit 1042 of the server 10 may perform a candidate acquisition step to obtain user candidates from a social networking service. The recipient acceptance step performs a step of accepting a second user as a recipient of contract information from the user candidates obtained in the candidate acquisition step. Specifically, the first user operates the input device 206 of the first user terminal 20 and sends a request to the server 10 to inquire about user candidates. The request sent to the server 10 may also include information about the organization to which the contracting party belongs.

[0057] When the contract creation unit 1042 of server 10 receives a request, it sends a request to the SNS server 40 to query for user candidates. When the control unit 406 of SNS server 40 receives the request, it searches the SNS user table 4012, the SNS group table 4013, etc., and sends a response to server 10 that includes the SNS user ID, SNS username, and SNS email address of the user candidates. For example, the control unit 406 of SNS server 40 may select users connected to the first user as user candidates. The control unit 406 of SNS server 40 may select users connected to the first user who belong to the organization to which the contracting party belongs as user candidates. The control unit 406 of SNS server 40 may select users connected to the first user who belong to the organization to which the contracting party belongs and who have the authority to approve the conclusion of the contract for the target contract information as user candidates. The control unit 406 of SNS server 40 may select users connected to the first user who belong to the organization to which the contracting party belongs and who hold a certain position or higher as user candidates.

[0058] The contract creation unit 1042 of server 10 identifies and retrieves the username and email address of a candidate user from the user table 1012 based on the SNS user ID, SNS username, and SNS email address included in the received response. Alternatively, the contract creation unit 1042 of server 10 may search the email address column in the user table 1012 based on the SNS email address to retrieve the user ID and username. In addition, considering information such as the organization to which the user belongs and their position, the unit may identify the user ID corresponding to the SNS user ID and retrieve the email address and username of the candidate user from the user table 1012. The contract creation unit 1042 of server 10 sends the username and email address of the acquired candidate user to the first user terminal 20. The display 2081 of the first user terminal 20 displays the received username and email address of the candidate user to the first user. The first user operates the input device 206 of the first user terminal 20 to select a second user to act as verifier from the multiple candidate users presented, and sends the username and email address of the second user to server 10.

[0059] This allows the first user to select a second user with appropriate approval authority as a verifier, based on user candidates obtained from social networking services, when designating a second user as a verifier.

[0060] In step S102, the contract creation unit 1042 of the server 10 may perform a candidate acquisition step to acquire candidate users who have the authority to approve contract information in the group to which the second user belongs, based on the second user, from the social networking service. The recipient acceptance step performs a step of accepting a third user as a recipient of contract information from the candidate users acquired in the candidate acquisition step. Specifically, the first user operates the input device 206 of the first user terminal 20 and sends a request to the server 10 to inquire about user candidates. The request sent to the server 10 includes information about the second user, who is the counterparty to the contract information, such as the user identification information and email address. In other words, at this point, the first user has already added the second user as a verifier.

[0061] When the contract creation unit 1042 of server 10 receives a request, it sends a request to the SNS server 40 to inquire about user candidates. When the control unit 406 of SNS server 40 receives the request, it searches the SNS user table 4012, the SNS group table 4013, etc., based on information about the second user, and sends a response to server 10 that includes the SNS user ID, SNS username, and SNS email address of the user candidate. For example, the control unit 406 of SNS server 40 may select users belonging to the same organization as the second user as user candidates. The control unit 406 of SNS server 40 may also select users who belong to the same organization as the second user and have the authority to approve the conclusion of the contract for the target contract information as user candidates. For example, the control unit 406 of SNS server 40 may select users who belong to the same organization as the second user, refer to the work history data in the SNS user table 4012, etc., and select users with a certain position or higher as user candidates.

[0062] The contract creation unit 1042 of server 10 identifies and retrieves the username and email address of a candidate user from user table 1012 based on the SNS user ID, SNS username, and SNS email address included in the received response. Alternatively, the contract creation unit 1042 of server 10 may search the email address column in user table 1012 based on the SNS email address to retrieve the user ID and username. In addition, considering information such as the organization to which the user belongs and their position, the unit may identify the user ID corresponding to the SNS user ID and retrieve the email address and username of the candidate user from user table 1012. The contract creation unit 1042 of server 10 sends the username and email address of the acquired candidate user to the first user terminal 20. The display 2081 of the first user terminal 20 displays the received username and email address of the candidate user to the first user. The first user operates the input device 206 of the first user terminal 20 to select a third user to act as verifier from the multiple candidate users presented, and sends the third user's username, email address, etc. to server 10.

[0063] This allows the first user, based on the second user already received, to include a third user with appropriate approval authority as a verifier of the contract information, based on a list of potential users with approval authority within the second user's group, obtained from the social networking service.

[0064] In step S103, the contract creation unit 1042 of the server 10 performs an information acquisition step for the first user to obtain the user information of the second user from an external social networking service. The same procedure is followed for the third user. Specifically, the information acquisition step involves obtaining the second user's credit information from an external social networking service. When the contract creation unit 1042 of server 10 receives the second user's email address and username, it sends a request to the SNS server 40 to query SNS user information, including the second user's email address and username. The request may also include information such as the second user's affiliated organization. The SNS server 40 searches the SNS user table 4012 for items such as the SNS email address and SNS username based on the email address and username included in the received request, and retrieves the SNS user information of the second user, including profile information such as the second user's name, affiliated organization, and position. The SNS user information of the second user may also include information such as the second user's credit information and credit score. The control unit 406 of the SNS server 40 sends the retrieved SNS user information to the server 10. The contract creation unit 1042 of server 10 stores the received SNS user information in the SNS user data field of the second user's record in user table 1012. As a result, the SNS user information for the second user is stored in server 10's user table 1012, associated with the second user's user identification information.

[0065] The contract creation unit 1042 of server 10 transmits the SNS user information of the second user to the first user terminal 20. The display 2081 of the first user terminal 20 displays the received SNS user information to the first user.

[0066] Figure 17 shows an example of the additional screen 55 used to add a verifier (recipient) of contract information during the contract creation process. The additional screen 55, displayed on the display 2081 of the first user terminal 20, displays input fields for the verifier's email address 551, name 552, organization name 553, and access code 554. The SNS information display area 561 displays the SNS user information of the user designated as the verifier. The SNS user information displays the organization to which the user designated as the verifier belongs in the SNS service, credit score 5612, credit information 5613, a cancel button 571, and an add button 572. Specifically, the contract creation unit 1042 of server 10 displays the received SNS email address, SNS username, and SNS user information in the fields for email address 551, name 552, and SNS information display area 561 of the additional screen 55, respectively.

[0067] The information acquisition step involves a second user acquiring user information, including information about the user's name and the frequency of updates to their affiliation information, by scanning a business card on a social networking service. Specifically, SNS information may include information regarding the frequency of updates to the second user's SNS user information, such as their name, affiliated organization, and job title, obtained when the second user reads their business card on a social networking service. This allows the parties to execute electronic contract procedures more securely, taking into account the credit information of the other party user based on their activity on social networking services. Furthermore, the contract creation unit 1042 of server 10 may present to the first user information regarding the update frequency of the second user's SNS user information that it has acquired.

[0068] In step S104, the contract determination unit 1044 of the server 10 executes a determination step to determine whether or not to proceed with a contract with the second user based on the credit information of the second user obtained in the information acquisition step. The determination step executes a step to determine whether or not to proceed with a contract with the second user based on the approval authority information of the first user and the credit information of the second user. The determination step involves comparing a score threshold corresponding to the approval authority information of the first user with the credit score of the second user to determine whether or not to proceed with the contract procedure with the second user. The same procedure applies to the third user.

[0069] Specifically, the determination step executes a step to determine whether or not to proceed with the contract procedure with the second user, based on the credit information of the second user obtained in the information acquisition step.

[0070] Specifically, the contract determination unit 1044 of server 10 determines that it cannot proceed with the contract procedure if the second user's employment history, etc., included in the second user's SNS user information, contains a history of working for inappropriate companies, etc. In addition, the contract determination unit 1044 of server 10 may also determine whether or not to proceed with the contract procedure with the second user based on any information, including the user information of other users connected to the second user on social networking services, which is included in the SNS user information.

[0071] Specifically, the contract determination unit 1044 of server 10 searches the approval authority item in the approval authority master 1017 based on the approval authority information of the first user stored in the user table 1012 and obtains a score threshold. The contract determination unit 1044 of server 10 compares the credit score of the second user with the obtained score threshold. If the credit score of the second user is greater than the score threshold, it determines that it is possible to enter into a contract with the second user. If the score is less than or equal to the score threshold, it determines that it is not possible to enter into a contract with the second user. In this disclosure, users with approval authority rank S have a score threshold of 0, and therefore can enter into contract procedures with all users regardless of the second user's credit score.

[0072] Furthermore, if the recipient acceptance step determines in the determination step that it is not possible to enter into a contract with the second user, the recipient acceptance step will not accept the second user as the recipient of the contract information. Specifically, if the contract determination unit 1044 of server 10 determines that it cannot perform the contract procedure with the second user, the first user will be unable to add the second user as a verifier, and the process will proceed to step S109. In other words, the contract creation unit 1042 of server 10 will not store the second user as a verifier in the verification table 1015.

[0073] On the other hand, if the contract determination unit 1044 of server 10 determines that it can perform the contract procedure with the second user, it proceeds to step S105 and can proceed with the contract procedure. Specifically, the contract creation unit 1042 of server 10 stores the email address received in step S102 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 confirmation 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 steps S102 to S104, 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.

[0074] In step S109, if the contract determination unit 1044 of the server 10 determines in the determination step that it is not possible to enter into a contract with the second user, it executes a first presentation step in which it presents the first user with first guidance information for entering into a contract with the second user.

[0075] Figure 18 shows an example of the additional screen 55 used in the contract creation process when it is determined that a contract procedure cannot be performed with the second user, and an additional screen 55 is used to add a verifier (recipient) of the contract information. Explanations of configurations that overlap with Figure 17 are omitted. The additional screen 55 for adding a verifier, displayed on the display 2081 of the first user terminal 20, displays the first guidance information 5614. The first guidance information 5614 includes information indicating that the first user does not have the approval authority to proceed with contract conclusion with the second user as a verifier. The first guidance information 5614 may also include a display that guides users who can proceed with contract conclusion with the second user as a verifier, or users belonging to other departments or groups. This allows the first user to request the contract creation process from another user who can proceed with contract conclusion with the second user as a verifier. Furthermore, on the addition screen 55, the add button 572 is presented to the first user in a state where it cannot be selected. In other words, the first user cannot add the second user as a verifier. Alternatively, on the additional screen 55, the first guidance information 5614 may only be presented to the first user as a warning or alert, while the add button 572 remains selectable. In this case, the first user can add the second user as a verifier, taking into account the warning and alert content of the first guidance information 5614.

[0076] In step S105, 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.

[0077] In step S106, 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 S105 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.

[0078] In step S107, 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 S106 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.

[0079] The contract creation unit 1042 of 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 creation screen 50 for creating contract information.

[0080] In step S108, the contract creation unit 1042 of the server 10 sends a message to the second user notifying them that a request for confirmation of contract information has been sent by the first user. Specifically, the contract creation unit 1042 of the server 10 searches the confirmation order column in the confirmation table 1015 and identifies the user who will be the first confirmer (first confirming user) with the smallest value stored in the confirmation order column. In this disclosure, the first confirming user is, for example, the second user. The contract creation unit 1042 of the server 10 sends a message to the first confirming user's email address notifying them that a request for confirmation of contract information has been sent by the first user, via email or other means of communication. The message sent to the first verifying user will include information about 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 information such as an encrypted string of the document ID, or a string that can identify the document ID by referring to an unillustrated table. The URL may also contain information to identify the first verifying user. For example, if the first verifying user has not registered for the service related to this disclosure, the URL must contain information to identify the first verifying user.

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

[0082] Figure 19 shows an example screen displaying a message sent 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.

[0083] <Variation> The first user can select and set multiple verifiers by executing the processes from steps S102 to S104 for each of the multiple verifiers. When selecting and setting multiple verifiers, the system can be configured to allow different input field information to be set independently for each of the multiple verifiers in step S105. For example, if the first user sets two users, the second user and the ninth user, as verifiers, the input fields for the contract start date and contract end date can be set for the second user, and the input field for the contract signing date can be set for the ninth 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 ninth user cannot input data for the contract start date and contract end date, but can input data for the contract signing date. The system can also be configured to allow multiple verifiers to be selected and set for a single input field.

[0084] On the creation 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".

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

[0086] <Overview of contract verification process> The contract verification process accepts access from the verifier, presents a verification screen displaying the contract information to the verifier, retrieves and displays the SNS user information of the contract information creator, and determines whether the contract procedure can be carried out based on the SNS user information. If it is determined that the contract procedure cannot be carried out, a second set of guidance information is presented. If it is determined that the contract procedure can be carried out, the process involves receiving input data for the input fields from the verifier and receiving data regarding the verification of the contract information from the verifier.

[0087] <Details of contract verification process> In step S301, the second user, who will act as the verifier, can open the webpage specified by the URL by operating the input device 306 or the like on the second user terminal 30 and selecting the URL contained in the received message. This allows the browser application on the second user terminal 30 to open the webpage specified by the URL. As a result, the second user terminal 30 sends a request to the server 10 to execute the contract verification process.

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

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

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

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

[0092] In step S303, the display 3081 of the second user terminal 30 presents the second user with a confirmation 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 confirmation screen presented to the second user may be configured to display the screen 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 confirmation table 1015.

[0093] In step S304, the contract creation unit 1042 of the server 10 performs an information acquisition step for the second user, which involves obtaining the first user's user information from an external social networking service. Specifically, the information acquisition step involves obtaining the credit information of the first user from an external social networking service. Note that the information acquisition step is the same as the information acquisition step in step S103 of the contract creation process, except that the user from whom the information is acquired is the first user instead of the second user, so redundant explanations will be omitted.

[0094] Figure 20 shows an example of a confirmation screen illustrating the operation of the contract confirmation process. The confirmation screen 70 for approving contract information, displayed on the display 3081 of the second user terminal 30, displays the status 710 indicating the current status of contract information creation, a contract information display area 730, document data 731, input items 732, 733, 734, 735, 736, an agreement button 740, and an SNS information display area 761. The SNS information display area 761 displays the creator's SNS user information. The SNS user information displays the creator's affiliated organization in the SNS service, credit score 7612, and credit information 7613.

[0095] In step S305, the contract verification unit 1043 of the server 10 executes a determination step to determine whether or not to proceed with the contract procedure with the first user based on the credit information of the second user obtained in the information acquisition step. The determination step executes a step to determine whether or not to proceed with the contract procedure with the first user based on the approval authority information of the second user and the credit information of the first user. The determination step is the same process as the determination step in step S104 of the contract creation process, except that the user from whom information is obtained is the first user instead of the second user, and the approval authority information of the second user is used instead of the approval authority information of the first user. Therefore, redundant explanations will be omitted.

[0096] Specifically, the contract determination unit 1044 of server 10 searches the approval authority item in the approval authority master 1017 based on the approval authority information of the second user stored in the user table 1012 and obtains a score threshold. The contract determination unit 1044 of server 10 compares the credit score of the first user with the obtained score threshold. If the credit score of the first user is greater than the score threshold, it determines that it is possible to enter into a contract with the first user. If the score is less than or equal to the score threshold, it determines that it is not possible to enter into a contract with the first user.

[0097] Furthermore, the approval step will not accept instructions to approve the conclusion of the contract information if the determination step determines that it is not possible to enter into a contract with the first user. Specifically, if the contract determination unit 1044 of server 10 determines that it cannot perform the contract procedure with the first user, the second user will be unable to approve the contract information, and the process will proceed to step S308.

[0098] In step S308, if the contract confirmation unit 1043 of the server 10 determines in the determination step that it is not possible to perform contract procedures with the first user, it executes a second presentation step in which it presents the second user with second guidance information for performing contract procedures with the first user.

[0099] Figure 21 is an example of a confirmation screen 70 that accepts an operation to approve contract information when it is determined during the contract confirmation process that it is not possible to proceed with the contract procedure with the first user. The explanation of the configuration that overlaps with Figure 20 is omitted. The confirmation screen 70, which accepts the operation to approve contract information and is displayed on the display 3081 of the second user terminal 30, displays second guidance information 7614. The second guidance information 7614 includes information indicating that the second user does not have the approval authority to approve the contract information created by the first user. The second guidance information 7614 may also include a display that guides the user to other users or users belonging to other departments or groups who can approve the conclusion of the contract with the first user as the creator. This allows the second user to request the contract procedure from other users who can proceed with the conclusion of the contract with the first user as the creator. For example, the second user may be configured to transfer the contract information to another fourth user who belongs to the same group or organization and can proceed with the conclusion of the contract with the first user as the creator. In this case, the fourth user who receives the transferred contract information can approve the contract information created by the first user. Furthermore, on confirmation screen 70, the consent button 740 is presented to the second user in a state where it cannot be selected. In other words, the second user cannot approve the contract signing with the first user as the creator. Alternatively, on the confirmation screen 70, the second information 7614 may be presented to the second user only as a warning or alert, while the consent button 740 remains selectable. In this case, the second user can approve the contract signing with the first user as the creator, taking into consideration the warning and alert content of the second information 7614.

[0100] In step S306, 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] In step S307, the contract confirmation unit 1043 of the server 10 executes an approval step in which it receives instructions from the second user, who was received in the recipient reception step, to agree to and approve the conclusion of the contract information. 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 confirmation 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 S306. 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 S306, the input data entered by the second user is stored as input item information in input item table 1016.

[0102] The contract verification unit 1043 of server 10 determines that the contract verification process has been performed by all verifiers. Specifically, the contract verification unit 1043 of server 10 determines that the contract verification process has been performed by all verifiers if the verification flag in the verifier's record in the verification table 1015 is set to True. Once all verifiers have completed the contract verification process, the contract verification unit 1043 of server 10 sends a message to the first user notifying them that the contract verification process is complete. Specifically, 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 them that the second user has completed the confirmation of the contract information. In other words, it notifies the first user that the second user has approved the conclusion of the contract. As a result, the first user can be informed that the conclusion of the contract with the second user has been completed. The message sent to the first user may include 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.

[0103] <Electronic signature processing> Step S307 may include an electronic signature process. In response to the instruction to approve the conclusion of the contract received from the second user in step S307, the contract confirmation unit 1043 of the server 10 stores the contract information received from the first user with an electronic signature indicating that the conclusion of the contract information has been approved. Specifically, the contract verification unit 1043 of server 10 attaches an electronic signature to the contract information and stores it based on the received request. Based on the document ID, the contract verification unit 1043 of server 10 searches the document ID field in the document table 1014 and retrieves the contract information. The contract verification unit 1043 of server 10 affixes an electronic signature to the acquired contract information and stores it in the document data item of the document table 1014. The contract verification unit 1043 of server 10 may update (overwrite) the document data item with the electronically signed contract information, or it may store the contract information before the electronic signature was added in a separate storage device (not shown). The contract verification unit 1043 of server 10 may include any of the following information in the electronic signature: document ID, email address of the first user, email address of the second user, approval date and time, confirmation date and time, authentication method for the approval date and time, authentication method for the confirmation date and time, input data values ​​for each input item, consent (approval) of the first user and the second user, and a timestamp. As a result, the contract verification unit 1043 of the server 10 stores the contract information with an electronic signature indicating that the second user has approved the conclusion of the contract. This prevents impersonation or tampering of the contract information by a third party.

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

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

[0106] 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).

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

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

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

[0110] <Basic Functional Configuration of Computer 90> The functional configuration of the computer realized by the basic hardware configuration of computer 90 (Figure 22) will be explained. The computer comprises at least one functional unit: a control unit, a memory unit, and a communication unit.

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

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

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

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

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

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

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

[0118] (Note 1) A program for causing a computer, comprising a processor and a memory unit, to execute electronic contract procedures between users belonging to different organizations, wherein the program causes the processor to execute: a contract acceptance step (S101) in which it receives contract information subject to contract conclusion from a first user; a recipient acceptance step (S102) in which it receives a second user from the first user as a recipient of the contract information received in the contract acceptance step; an approval step (S307) in which it receives an instruction from the second user, received in the recipient acceptance step, to approve the conclusion of the contract information; an information acquisition step (S103, S304) in which it obtains user information of the other user from an external social networking service for at least one of the first or second users; and an information presentation step (S103, S304) in which it presents the user information of the other user obtained in the information acquisition step to at least one of the users. This allows the parties to enter into an electronic contract to confidently carry out the contract process while taking into account the information of the other party's user.

[0119] (Note 3) The information acquisition step (S103, S304) is a step of acquiring user information, including the credit information of the other user, as described in Appendix 1 or 2 of the program. This allows the parties to enter into an electronic contract to securely carry out the contract process while taking into account the credit information of the other party's user.

[0120] (Note 4) The information acquisition step (S103, S304) is a step of acquiring user information, including the credit score of the other user, as described in any of the programs described in Appendix 1 to 3. This allows parties to securely execute electronic contract procedures by taking into account the credit score of the other party's user.

[0121] (Note 5) The information acquisition step (S103, S304) is a step of acquiring user information including job title, work history, and the job title, work history, and credit score of other users who are connected to the other user via social networking services, as well as the credit information of other users, as described in any of the programs described in Appendix 1 to 4. This allows parties to securely execute electronic contract procedures by taking into account the credit score of the other party's user.

[0122] (Note 6) A social networking service is a service that builds a social network among multiple users based on the name and affiliation information of the user written on the business card by reading the business card held by the user, and the information acquisition step (S103, S304) is a step of acquiring user information including the name and affiliation information of the other user, as described in any of the programs in Appendix 1 to 5. This allows parties to execute electronic contract procedures more securely by considering reliable credit information based on the business card information of the other party user.

[0123] (Note 7) The information acquisition step (S103, S304) is a step in the program described in Appendix 6, in which the other user acquires user information, including information regarding the frequency of updates of the user's name and affiliation information by reading a business card on a social networking service. This allows the parties to execute electronic contract procedures more securely, taking into account the credit information of the other party user based on their activity on social networking services.

[0124] (Note 8) The program is one of the programs described in any of Appendix 1 to 7, wherein the program causes the processor to perform a candidate acquisition step (S102) to acquire user candidates from a social networking service, and the recipient acceptance step (S102) is a step in which the program accepts a second user as a recipient of contract information from the user candidates acquired in the candidate acquisition step. This allows the first user to select a second user with appropriate approval authority as a verifier, based on user candidates obtained from social networking services, when designating a second user as a verifier.

[0125] (Note 9) The program is one of the programs described in any of Appendix 1 to 8, wherein the program causes the processor to perform a candidate acquisition step (S102) to acquire candidate users who have the authority to approve contract information in the group to which the second user belongs, based on the second user, from a social networking service, and the recipient acceptance step (S102) is a step in which the program accepts a third user as a recipient of contract information from the candidate users acquired in the candidate acquisition step. This allows the first user, based on the second user already received, to include a third user with appropriate approval authority as a verifier of the contract information, based on a list of potential users with approval authority within the second user's group, obtained from the social networking service.

[0126] (Note 10) The program is one of the programs described in any of Appendix 1 to 9, which causes the processor to execute a determination step (S104, S305) that determines whether or not to proceed with a contract with the other user based on the credit information of the other user obtained in the information acquisition step. This allows parties to suspend contract procedures based on the credit information of the other party when executing electronic contract procedures. This enables users to avoid entering into contracts with parties who are deemed unsafe.

[0127] (Note 11) The program described in Appendix 10 is a program in which the determination step (S104) determines whether or not to proceed with the contract procedure with the other user based on the approval authority information of one user and the credit information of the other user. This allows parties to suspend contract procedures based on the credit information of the other party, according to their approval authority, when executing electronic contract procedures. This enables users to avoid entering into contracts with parties who are not considered secure.

[0128] (Note 12) The program described in Appendix 11 includes a determination step (S104) in which the program determines whether or not to proceed with a contract with the other user by comparing a score threshold corresponding to the approval authority information of one user with the credit score of the other user. This allows parties to suspend contract procedures based on the credit score of the other party, corresponding to their approval authority, when executing electronic contract procedures. This enables users to avoid entering into contracts with parties who are deemed unsafe.

[0129] (Note 13) The program as described in Appendix 11 or 12, wherein the information acquisition step (S103) is a step of acquiring the credit information of the second user from an external social networking service, the determination step (S104) is a step of determining whether or not to proceed with a contract with the second user based on the credit information of the second user acquired in the information acquisition step, and the recipient acceptance step (S102) is a step of not accepting the second user as a recipient of contract information if it is determined in the determination step that it is not possible to proceed with a contract with the second user. This allows the first user to stop designating the second user as a recipient of contract information based on the second user's credit information. This allows the first user to avoid entering into contracts with parties who are less secure.

[0130] (Note 14) The program is the program described in Appendix 13, which causes the processor to execute a first presentation step (S109) in which, if it is determined in the determination step that it is not possible to enter into a contract with the second user, the first presents the first guidance information for entering into a contract with the second user. This allows the first user to stop designating the second user as a recipient of contract information based on the second user's credit score. This allows the first user to avoid entering into contracts with less secure parties.

[0131] (Note 15) The program is as described in any of Appendix 10 to 14, wherein the information acquisition step (S304) is a step of acquiring the credit information of the first user from an external social networking service, the determination step (S305) is a step of determining whether or not to enter into a contract with the first user based on the credit information of the first user acquired in the information acquisition step, and the approval step (S307) is a program that does not accept an instruction to approve the conclusion of a contract if it is determined in the determination step that it is not possible to enter into a contract with the first user. This allows the second user to stop approving contract information received from the first user based on the first user's credit information. This enables the second user to avoid entering into contracts with less secure parties.

[0132] (Note 16) The program is the program described in Appendix 15, which causes the processor to execute a second presentation step (S308) in which, if it is determined in the determination step that it is not possible to enter into a contract with the first user, the second presentation step presents the second user with second guidance information for entering into a contract with the first user. This allows the second user to stop approving contract information received from the first user based on the first user's credit score. This enables the second user to avoid entering into contracts with less secure parties.

[0133] (Note 17) An information processing apparatus comprising a processor and a memory unit, wherein the processor is made to execute a program described in any of the appendices 1 to 16. This allows the parties to enter into an electronic contract to confidently carry out the contract process while taking into account the information of the other party's user.

[0134] (Note 18) An information processing method performed by a computer comprising a processor and a memory unit, wherein the processor is made to execute a program described in any of the appendices 1 to 16. This allows the parties to enter into an electronic contract to confidently carry out the contract process while taking into account the information of the other party's user.

[0135] (Note 19) An information processing system including a computer comprising a processor and a memory unit, wherein the processor is made to execute a program described in any of the appendices 1 to 16. This allows the parties to enter into an electronic contract to confidently carry out the contract process while taking into account the information of the other party's user. [Explanation of Symbols]

[0136] 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 SNS Server, 401 Storage Unit, 404 Control Unit, 406 Input Device, 408 Output Device

Claims

1. A program for causing a computer having a processor and a storage unit to execute an electronic contract procedure between different users, The program causes the processor to: a contract acceptance step of accepting contract information to be the subject of a contract from a first user; a recipient receiving step of receiving, from a first user, a designation of a second user as a recipient of the contract information received in the contract receiving step; a contract presentation step of presenting the contract information to the second user in response to a designation of a second user from the first user and acceptance of the contract information, without requiring an operation of returning the contract information accepted from the first user to the first user and confirming the contract information by the first user; an approval step of accepting, from the second user accepted in the recipient acceptance step, an instruction to approve the conclusion of the contract of the contract information; an information acquisition step of acquiring, for at least one of the first user and the second user, user information of the other user from a service that realizes mutual business communication between users; an information presenting step of presenting the other user information acquired in the information acquiring step to the at least one user; A program to execute.

2. The program described in claim 1, wherein, in the information presentation step, information of the other user including at least a username for the service is presented to the at least one user.

3. The program described in claim 2, wherein a screen that presents the contract information to the second user in the contract presentation step displays the contract information, an operating member that accepts an operation to agree to the contract information, and the user information that includes at least the user name of the first user for the service.

4. A method for causing a computer having a processor and a memory unit to execute an electronic contract procedure between different users, comprising: The method further comprises the processor: a contract acceptance step of accepting contract information to be the subject of a contract from a first user; a recipient receiving step of receiving, from a first user, a designation of a second user as a recipient of the contract information received in the contract receiving step; a contract presentation step of presenting the contract information to the second user in response to a designation of a second user from the first user and acceptance of the contract information, without requiring an operation of returning the contract information accepted from the first user to the first user and confirming the contract information by the first user; an approval step of accepting, from the second user accepted in the recipient acceptance step, an instruction to approve the conclusion of the contract of the contract information; an information acquisition step of acquiring, for at least one of the first user and the second user, user information of the other user from a service that realizes mutual business communication between users; an information presenting step of presenting the other user information acquired in the information acquiring step to the at least one user; A method for performing.

5. An information processing device for executing electronic contract procedures between different users, comprising: A control unit of the information processing device a contract acceptance step of accepting contract information to be the subject of a contract from a first user; a recipient receiving step of receiving, from a first user, a designation of a second user as a recipient of the contract information received in the contract receiving step; a contract presentation step of presenting the contract information to the second user in response to a designation of a second user from the first user and acceptance of the contract information, without requiring an operation of returning the contract information accepted from the first user to the first user and confirming the contract information by the first user; an approval step of accepting, from the second user accepted in the recipient acceptance step, an instruction to approve the conclusion of the contract of the contract information; an information acquisition step of acquiring, for at least one of the first user and the second user, user information of the other user from a service that realizes mutual business communication between users; an information presenting step of presenting the other user information acquired in the information acquiring step to the at least one user; An information processing device that executes the above.

Images