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

Abstract

To limit a range in which a user can refer and edit a contract document in an electronic contract system for exchanging the contract document with an outside person.SOLUTION: A processor is caused to perform: a storing step of storing the contract document data associated with the first user identification information and a second mail address; a step of acquiring the third group identification information associated with the contract document data; and a query step of performing the process on an inquiry request from a fourth user having the fourth user identification information associated with the fourth group identification information. The query step is made to display the contact document data when the fourth group identification information matches the third group identification information, and made not to display the contract document data to a fourth user when the fourth group identification information does not match the third group identification information.SELECTED DRAWING: Figure 1

Description

There is an application for exception to loss of novelty

The present disclosure relates to a program, an information processing device, and an information processing method.

2. Description of the Related Art With the development and spread of computer technology, documents that used to be paper media are being digitized. For example, documents such as contracts that require the signatures and seals of parties are also being managed as electronic data. Japanese Patent Application Laid-Open No. 2002-200002 discloses a data storage destination limiting device capable of limiting data storage destinations for each user group within a company. Patent Literature 2 discloses an information processing system relating to a digital contract, which consists of a creator terminal, a confirmation company terminal, and a contract management server.

Japanese Patent Application Laid-Open No. 2021-51345 JP 2017-10096

In the field of such document management, it has been difficult to limit the range in which a user can refer to and edit a contract in an electronic contract system for exchanging contracts with outside parties.

Accordingly, the present disclosure has been made to solve the above problems. The purpose is to limit the scope of the user's ability to refer to and edit contracts in an electronic contract system that exchanges contracts with outside parties.

According to one embodiment, a program for causing a computer comprising a processor and a storage unit to execute electronic contract procedures between users belonging to different organizations, the program causes the processor to provide first user identification information and a saving step of saving the contract data linked to the second email address; a step of obtaining third group identification information linked to the contract data; and a fourth group identification information linked to the fourth group identification information. an inquiry step of processing an inquiry request from a fourth user having the user identification information, wherein the inquiry step includes, if the fourth group identification information matches the third group identification information, the contract data is displayed, and if the fourth group identification information does not match the third group identification information, the contract data is not displayed to the fourth user, and the contract data linked to the first user identification information and the second email address a step of obtaining third group identification information linked to contract data; and a query request from a fourth user having fourth user identification information linked to the fourth group identification information an inquiry step of performing processing on the third group identification information, the inquiry step displaying contract data if the fourth group identification information matches the third group identification information, and A program is provided that prevents the contract data from being displayed to the fourth user if it does not match the group identification information.

According to the present disclosure, in an electronic contract system for exchanging contracts with outside parties, it is possible to limit the scope of the user's ability to refer to and edit contracts.

1 is a diagram showing an overall configuration of an information processing system 1; FIG. 2 is a block diagram showing the functional configuration of a contract management server 2; FIG. 3 is a block diagram showing the hardware configuration of creator terminal 3. FIG. 3 is a block diagram showing a functional configuration of creator terminal 3. FIG. 4 is a diagram showing the data structure of a contract database 211. FIG. (A) is a diagram showing the data structure of the contract group database 212, and (B) is a diagram showing the data structure of the cabinet database 213. FIG. 3 is a diagram showing the data structure of a user database 214; FIG. FIG. 4 is a diagram showing the data structure of a group master 215; FIG. It is a flowchart which shows the operation|movement of contract preparation processing (1st Example). It is a flowchart which shows the operation|movement of a contract confirmation process (1st Example). It is a flowchart which shows the operation|movement of a group display process (1st Example). FIG. 10 is a diagram showing an example of a display screen of the creator terminal 3 by contract creation processing; FIG. 10 is a diagram showing an example of a display screen of the creator terminal 3 by contract creation processing; FIG. 10 is a diagram showing an example of a display screen of the creator terminal 3 by contract creation processing; 4 is a diagram showing an example of a display screen of an e-mail sent to the confirmer terminal 4; FIG. FIG. 10 is a diagram showing an example of a display screen of the checker terminal 4 in the contract confirmation process; FIG. 10 is a diagram showing an example of a display screen of the checker terminal 4 in the contract confirmation process; FIG. 10 is a diagram showing an example of a display screen of the checker terminal 4 in the contract confirmation process; FIG. 10 is a diagram showing an example of a display screen of the checker terminal 4 in the contract confirmation process; FIG. 10 is a diagram showing an example of a display screen of the checker terminal 4 in the contract confirmation process; It is a figure which shows the list display screen by group display processing (1st Example). It is a flowchart which shows the operation|movement of contract preparation processing (2nd Example). It is a flowchart which shows the operation|movement of contract confirmation processing (2nd Example). It is a flowchart which shows the operation|movement of a group display process (2nd Example). It is a figure which shows the list display screen by group display processing (2nd Example). It is a block diagram which shows the hardware constitutions of a computer.

Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In all the drawings for explaining the embodiments, common constituent elements are given the same reference numerals, and repeated explanations are omitted. It should be noted that the following embodiments do not unduly limit the content of the present disclosure described in the claims. Also, not all the components shown in the embodiments are essential components of the present disclosure. Each figure is a schematic diagram and is not necessarily strictly illustrated.

<Overview of information processing system 1>
FIG. 1 is a diagram showing the overall configuration of an information processing system 1. As shown in FIG. An information processing system 1 according to the present disclosure is a system for executing electronic contract procedures between users belonging to different organizations.

<Basic Configuration of Information Processing System 1>
FIG. 1 shows an information processing system 1 according to the present disclosure. The information processing system 1 includes a contract management server 2, a plurality of creator terminals 3, a plurality of confirmer terminals 4, and a displayer terminal 5, which are connected via a network N. FIG. 2 is a block diagram showing the functional configuration of the contract management server 2. As shown in FIG. FIG. 3 is a block diagram showing the hardware configuration of the creator terminal 3. As shown in FIG. FIG. 4 is a block diagram showing the functional configuration of the creator terminal 3. As shown in FIG.

The contract management server 2 is an information processing device that manages contracts. The creator terminal 3 is an information processing device operated by a user who creates a contract. The confirmer terminal 4 is an information processing device operated by a user who confirms the contents of the contract created by the preparer terminal 3 . The displayer terminal 5 is an information processing device operated by a user that displays the content of the contract created by the creator terminal 3 .

Each information processing device is composed of a computer having 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. Descriptions of the contract management server 2, the creator terminal 3, the confirmer terminal 4, and the display person terminal 5 that overlap with the basic hardware configuration of the computer and the basic functional configuration of the computer, which will be described later, will be omitted.

The configuration and operation of each device will be described below.

<Overview of Contract Management Server 2>
The contract management server 2 is an information processing device operated by a service provider that provides services related to contract management. For example, a computer that provides services such as managing contracts with signatures, seals, and other data entries.

<Functional Configuration of Contract Management Server 2>
A functional configuration realized by the hardware configuration of the contract management server 2 is shown in FIG.

<Configuration of Storage Unit of Contract Management Server 2>
The storage unit 21 of the contract management server 2 includes a contract database 211 , a contract group database 212 , a cabinet database 213 , a user database 214 and a group master 215 . Note that each database and master may be distributed to a plurality of servers. Further, some of them may be distributed to the creator terminal 3, the confirmer terminal 4, and the display person terminal 5, and any configuration may be adopted as long as the function of the storage section can be exhibited as a system.

FIG. 5 is a diagram showing the data structure of the contract database 211. As shown in FIG. The contract database 211 uses a contract ID, which is an item that uniquely identifies a contract, as a key to store contract data (binary or text data), user ID of the creator of the contract, e-mail address of the confirmer, input area , the confirmation flag is stored as a record.

User ID stores a user ID for identifying the user who is the creator of the contract. The user ID is managed in association with the user's name in the user database 214, which will be described later.

The e-mail address stores the e-mail address of the user who confirmed the contract. The email address is included in the user database 214 if the verifier has already registered as a user with the service according to the present disclosure. However, the confirmer does not necessarily have to be registered as a user of the service according to the present disclosure, and in that case, the user's email address is not included in the user database 214 .

The input area stores data relating to an input area in which a user (confirmer) who confirms the contract can input data when confirming the contract, and data input to the input area by the confirmer.

The confirmation flag stores information for identifying the completion of the confirmation procedure for each confirmer. When confirmation of the contract by the confirmation person is completed, TRUE is stored in the confirmation flag item.

FIG. 6A shows the data structure of the contract group database 212. As shown in FIG. The contract group database 212 stores the contract ID as a key and the cabinet ID as a record.

FIG. 6B shows the data structure of the cabinet database 213. As shown in FIG. The cabinet database 213 stores the group ID as a record using the cabinet ID as a key. The cabinet database 213 may include a cabinet label item that indicates the name of the cabinet.

FIG. 7 is a diagram showing the data structure of the user database 214. As shown in FIG. The user database 214 stores names, email addresses, organization IDs, and group IDs as records using user IDs as keys.

FIG. 8 is a diagram showing the data structure of the group master 215. As shown in FIG. Using the group ID as a key, the group master 215 stores, as a record, a label such as a department name corresponding to the group ID, and an organization ID such as a company or school to which the group ID belongs. The group master 215 can be edited by an administrator or the like in the organization.

<Configuration of Control Unit of Contract Management Server 2>
The control unit 22 of the contract management server 2 includes functional units of a contract creation control unit 221 , a contract confirmation control unit 222 , and a group display control unit 223 . In addition, each control unit may be distributed to a plurality of servers. In addition, each control unit may be partially distributed to the creator terminal 3, the confirmer terminal 4, and the display person terminal 5, and any configuration may be adopted as long as the function of the control unit can be exhibited as a system. Also good.

The contract creation control unit 221 performs contract creation processing according to instructions from the creator terminal 3 .

The contract confirmation control unit 222 performs contract confirmation processing according to instructions from the confirmer terminal 4 .

The group display control unit 223 performs group display processing according to instructions from the displayer terminal 5 .

<Overview of creator terminal 3>
The creator terminal 3 is an information processing device operated by a user who uses services related to contract management. It is an information processing device operated by a “creator” who performs an operation to create a contract managed by the contract management server 2 .
The creator terminal 3 is a computer such as a smart phone, a mobile phone, a PHS, a computer, a PDA, a head-mounted display, or an image generation device.

<Hardware Configuration of Creator Terminal 3>
FIG. 3 shows the hardware configuration of the creator terminal 3. As shown in FIG. The creator terminal 3 has an input interface, an output interface, an input device, and an output device.

The input interface is an interface for connecting an input device for accepting input operations from a user and a computer. An input device is a device that receives an input operation from a user. The input device includes, for example, a touch panel, a touch pad, a pointing device such as a mouse, a keyboard, a microphone, a sensor, and the like.

An output interface is an interface for connecting an output device for presenting information to a user and a computer. An output device is a device that presents information to a user. Output devices are, for example, displays, monitors, printers, speakers, and the like.

<Functional Configuration of Creator Terminal 3>
A functional configuration realized by the hardware configuration of the creator terminal 3 is shown in FIG. The storage unit 31 of the creator terminal 3 stores the user ID. The control unit 32 of the creator terminal 3 includes an input control unit 321 , an output control unit 322 and a user ID acquisition unit 323 . The user ID includes information for identifying the user using the creator terminal 3, such as a session ID.

The input control unit 321 receives the operation content from the user on the input device via the input interface and inputs it to the creator terminal 3 .

The output control unit 322 outputs the output contents of the creator terminal 3 to the output device via the output interface, and presents them to the user via the output device.

The user ID acquisition section 323 acquires the user ID stored in the storage section 31 of the creator terminal 3 .

The creator operates the input device provided in the creator terminal 3 to create the contract.

<Overview of confirmer terminal 4>
The checker terminal 4 is an information processing device operated by a user who uses services related to contract management. It is an information processing device operated by a "confirmer" who performs data operations such as confirmation, signature, and sealing of contracts managed by the contract management server 2 . Generally, the creator and the confirmer belong to different organizations such as companies or schools, but the creator and the confirmer may belong to the same organization.
The checker terminal 4 is a computer such as a smart phone, a mobile phone, a PHS, a computer, a PDA, a head-mounted display, or an image generating device.

<Hardware Configuration and Functional Configuration of Checker Terminal 4>
The hardware configuration and functional configuration of the confirmer terminal 4 are the same as the hardware configuration and functional configuration of the creator terminal 3 shown in FIGS.

The confirmer operates the input device provided in the confirmer terminal 4 to perform data operations such as confirmation, signature, and sealing of the contract.

<Overview of Displayer Terminal 5>
The displayer terminal 5 is an information processing device operated by a user who uses a contract management service. It is an information processing device operated by a “displayer” who displays a contract managed by the contract management server 2 . Viewers may include creators and reviewers.
The display terminal 5 is a computer such as a smart phone, a mobile phone, a PHS, a computer, a PDA, a head-mounted display, or an image generation device.

<Hardware Configuration and Functional Configuration of Displayer Terminal 5>
The hardware configuration and functional configuration of the display person's terminal 5 are the same as the hardware configuration and functional configuration of the creator's terminal 3 shown in FIGS.

The displayer displays the contract by operating the input device provided in the displayer's terminal 5 .

<Operation of information processing system 1>
Hereinafter, each process of the information processing system 1 in the embodiment will be described with reference to FIGS. 9 to 11. FIG.

FIG. 9 is a flow chart showing the operation of the contract creation process (first embodiment) by the contract management server 2. As shown in FIG. FIG. 10 is a flow chart showing the operation of contract confirmation processing (first embodiment) by the contract management server 2 . FIG. 11 is a flow chart showing the operation of group display processing (first embodiment) by the contract management server 2 .

<Contract creation processing (first embodiment)>
A contract creation process (first embodiment) in which the creator terminal 3 accesses the contract management server 2 to create a contract will be described with reference to the flowchart of FIG. 9 and the display screens of FIGS. 12 to 14. do. 9 is a flow chart showing the processing operation by the contract creation control unit 221 of the contract management server 2. As shown in FIG. 12 to 14 are diagrams showing examples of display screens displayed on the preparer terminal 3 as a result of the contract preparation process by the contract management server 2. FIG. FIG. 15 is a diagram showing an example of a display screen of the e-mail sent to the confirmer terminal by the contract creation process by the contract management server 2. As shown in FIG.

It is assumed that the user ID "user A1" stored in the user database 214 is stored in the storage unit 31 of the creator terminal 3 and is associated with the user A1.

In step S11, the contract creation control unit 221 of the contract management server 2 creates contract data in response to an instruction from the creator terminal 3 accessed, and creates the contract data items in the contract database 211. The user ID of the user "user A1" is linked and stored. When the process of storing in the contract database 211 is performed, a new record is added to the contract database 211, and the contract ID "CONTRACT1" is newly linked to the record. The contract ID is an identifier that uniquely identifies the contract in the contract database 211 . The contract ID may be automatically linked by the contract creation control unit 221, or may be linked as an arbitrary character string or number according to an instruction from the creator terminal 3.

The contract data includes, for example, template data selected from the creator's terminal 3 out of pre-stored template data, or a document input from the creator's terminal 3 . The generated contract data 62 is controlled to be displayed on the display screen of the creator terminal 3 from the contract management server 2, as shown in FIG.

In step S12, the contract creation control unit 221 of the contract management server 2, in response to an instruction from the creator terminal 3, causes the contract data to be viewed by a "confirmer (user)", A process of setting an “input area” in which data can be input by the “confirmer” and storing it in the contract database 211 is performed. Specifically, the creator terminal 3 first inputs address data such as the mail address "UB1@xxxxxx.xx" of the user B1 as the "confirmer" who is allowed to view the contract data. 12, the contract creation control unit 221 of the contract management server 2 sets a "confirmer" to view the contract data, and enters the information of the "confirmer" into the contract. It is stored in the mail address field of the contract database 211 in association with the document data. In addition to the address data described above, the contractor's name and company name may be set as the "confirmer" information set in the contract data.

In the example of FIG. 12, only the "confirmer" who is allowed to view the contract data is set, and the "input area" is not set. That is, in this example, user B1 only confirms the contents of the contract data, as will be described later.

When creator terminal 3 adds a "confirmer" to view the contract data (Yes in step S13), the mail address of user B2 is added as a "confirmer" to view contract data as a confirmer addition operation. Enter "UB2@xxxxxx.xx" (step S12). 13, the contract creation control unit 221 of the contract management server 2 stores the mail address of the user B2 in the mail address item of the contract database 211 as a confirmation person for viewing the contract data. to add.

At this time, if there are items to be input by the user B2 in the contract data, the creator terminal 3 designates an "input area" and instructs an input place. For example, in the example of FIG. 13, the creator terminal 3 selects a desired "input area" (input tag) from the input area list 60 of "input areas" and drags it to a desired location in the contract data 62. to drop. Then, as indicated by reference numeral 621 in FIG. 13, the contract creation control unit 221 of the contract management server 2 displays an "input area" ( 621) is set and stored in the input area item of the contract database 211 in association with the contract data.

Here, the "input area" in the example of FIG. 13 is a column for stamping a seal. As a result, as will be described later, the set user B2 can stamp the seal stamp data in the stamp field (reference numeral 621) that is the set "input area". The "input area" includes, for example, a field for inputting signature data and other text data, a check box field for inputting data for selecting a certain check item, etc., as shown in the input area list 60 of FIG. It may be an item into which any data is entered.

If creator terminal 3 further adds a "confirmer" to view the contract data (Yes in step S13), enter user C1's email address "UC1@xxxxxx.xx" as the "confirmer", The "input area" to be input by the "confirmer" is specified (step S12). Then, the contract creation control unit 221 of the contract management server 2 sets a new "confirmer" as indicated by reference numeral 613 in FIG. is set and stored in the contract database 211 in association with the contract data.

At this time, in the example of FIG. 14, the “input area” 622 for user C1 indicated by reference numeral 613 is set, but the contract data displayed on the creator terminal 3 from the contract management server 2 already includes the user The "input area" 621 set in B2 is also displayed. However, the "input area" of user B2, which is not currently set, is displayed in a different display format such as grayout or dotted line, and can be distinguished from the "input area" to be set.

As described above, in the present embodiment, three persons indicated by user B1, user B2, and user C1 are set as "confirmers" of the contract data, and among them, user B1 has an "input area". It is not set, and an "input area" is set for each of the two "confirmers", user B2 and user C1.

In this disclosure, an embodiment is described in which a record is added to the contract database 211 when contract data is created in step S12. Records may be added and stored in book database 211 .

When the addition of the "confirmer" to view the contract data is completed (No in step S13), the creator terminal 3 instructs the contract management server 2 to request confirmation in step S14. Then, the contract creation control unit 221 of the contract management server 2 issues a contract data viewing request notification addressed to the mail addresses of all set "confirmers". In this embodiment, all the set "confirmers" are requested to read by e-mail. The contract creation control unit 221 of the contract management server 2 sends an e-mail 70 as shown in FIG.

At this time, the contract creation control unit 221 of the contract management server 2 generates the access address 51 for accessing the contract data for each “confirmer” who issues the viewing request notification, and includes it in the viewing request notification. to send. The access address is, for example, an address such as a URL that allows access to the contract data, and is information that includes an identifier that identifies the "confirmer". By doing so, the contract management server 2 can recognize the "confirmer" who made the access based on the notified access address, as will be described later.

However, the access address is not limited to the format described above, and any information that can identify the contract data to be viewed and the "confirmer" who has accessed to view the contract data. , any form of information. Also, the access address may be anything as long as it identifies the contract data, and does not necessarily have to identify the "confirmer". In that case, the "confirmer" who has accessed may be identified by another method.

<Contract confirmation process (first embodiment)>
The contract confirmation process (first embodiment) in which confirmer terminals 4A, 4B, and 4C access the contract management server 2 and confirm the contract is shown in the flowchart of FIG. 10 and the display screens of FIGS. will be described with reference to User IDs "user B1", "user B2", and "user C1" are stored in the storage units of checker terminals 4A, 4B, and 4C, respectively, and are associated with the respective user IDs. The checker terminals 4A, 4B, and 4C can view the e-mail sent to each user.

FIG. 10 is a flow chart showing a processing operation by the contract confirmation control unit 222 of the contract management server 2. As shown in FIG. FIG. 15 is a diagram showing a display screen example of an e-mail sent to confirmer terminals 4A, 4B, and 4C by contract confirmation processing by contract management server 2. As shown in FIG. 16 to 20 are diagrams showing examples of display screens displayed on the checker terminals 4A, 4B, and 4C by the contract confirmation processing by the contract management server 2. FIG.

When the e-mail is sent in step S14 of the contract creation process, the checker terminals 4A, 4B, and 4C receive the confirmation request notification sent from the contract creation control unit 221 of the contract management server 2 in FIG. Each receive an email 70 as shown. Each confirmer terminal 4A, 4B, 4C can access the contract management server 2 by selecting the access address 71 such as the URL included in the e-mail.

In step S21, the contract confirmation control unit 222 of the contract management server 2 receives access from the confirmer terminals 4A, 4B, and 4C.

In step S22, the contract confirmation control unit 222 of the contract management server 2 identifies the user accessing from the access address 71 as the "confirmer". As described above, the contract confirmation control unit 222 of the contract management server 2 includes an identifier for identifying the "confirmer" in the access address 71 generated when notifying the viewing request. From the identifiers in the access addresses 71 used when the terminals 4A, 4B, and 4C access, the "confirmers" who have made access are identified as user B1, user B2, and user C1.

Note that the contract confirmation control unit 222 of the contract management server 2 may identify the confirmer terminals 4A, 4B, and 4C that have made access by other methods. For example, the contract confirmation control unit 222 of the contract management server 2 receives information identifying each user such as a user ID when receiving access from the confirmer terminals 4A, 4B, and 4C, and stores the information in the user database 214. By matching with the registered information such as the user ID and the e-mail address, the "confirmer" who has made the access may be specified. In this way, the contract confirmation control unit 222 of the contract management server 2 determines that the "confirmers" are the users B1, B2, and C1 based on the access status from the confirmer terminals 4A, 4B, and 4C. identify.

In step S23, the contract confirmation control unit 222 of the contract management server 2 reads the contract data specified by the access address 71 from the contract data items of the contract database 211, , to be displayed in 4C. At this time, if an "input area" corresponding to the accessed "confirmer" is set in the contract data, the contract confirmation control unit 222 of the contract management server 2 Data is read out from the input area items of the contract database 211 for each, and the contract data is displayed so that each "confirmer" can input data in the "input area".

<Processing at confirmer terminal 4A>
Here, with reference to FIGS. 16 to 20, a state of contract data confirmation processing by each "confirmer" will be described. First, FIG. 16 shows a confirmation screen displayed and output from the contract confirmation control section 222 of the contract management server 2 to the confirmer terminal 4A when accessed from the confirmer terminal 4A (step S21). (Steps S22, 23).

As shown in this screen, the contract data is displayed on the confirmation screen, but since the "input area" is not set for the user B1, the "input area" in which data can be input is not displayed. However, since "input areas" 621 and 622 are set for users B2 and C1, these "input areas" 621 and 622 are displayed so that data cannot be input from the confirmer terminal 4A of user B1. (e.g. greyed out or dotted). In addition, on the confirmation screen, information of users B1, B2, and C1 who are "confirmers" who confirm this contract data is displayed at the top. This allows the user B1 to recognize the other confirmers and the input areas by the other confirmers.

In step S24, the contract confirmation control unit 222 of the contract management server 2 receives confirmation completion input from the confirmer terminal 4A.

In step S25, the contract confirmation control unit 222 of the contract management server 2 associates the information to that effect with the contract data, and sets the confirmation flag item of the contract database 211 to TRUE. Since "input area" is not set for user B1, only the confirmation of the contract data is stored.

<Processing in confirmer terminal 4B>
17 and 18, when access is received from the confirmer terminal 4B of the "confirmer" set as indicated by reference numeral 612 (step S21), the contract confirmation control of the contract management server 2 is performed. The confirmation screen output from the unit 222 to the confirmer terminal 4B is shown (steps S22 and S23).

As shown in the screen of FIG. 17, the contract data is displayed on the confirmation screen. It is displayed so that it can be input (step S23). On the other hand, since the "input area" 622 is the "input area" 622 set for the user C1, the "input area" 622 is designed so that data cannot be input from the confirmer terminal 4B of the user B2. Is displayed. Further, on the confirmation screen, information of users B1, B2, and C1 who confirm the contract data is displayed at the top.

Then, user B2 confirms the contents of the contract data on the screen shown in FIG. 17, and performs data input operation to the "input area" 621 in which data can be input to himself/herself. In this example, since the "input area" 621 is a column for affixing a seal, when the user B2 performs a predetermined operation from the confirmer terminal 4B, the contract confirmation control unit 222 of the contract management server 2 displays the 18, the seal stamp data is stamped in the "input area" 621 (step S24). Here, the seal stamp data is registered in advance corresponding to the user B2, or created and authenticated by the user B2 at the time of stamping. The data input by the "confirmer" may be text data or signature data depending on the "input area".

Then, when the contract confirmation control unit 222 of the contract management server 2 receives the confirmation completion input from the confirmer terminal 4B, it associates the information to that effect with the contract data, and adds it to the confirmation flag item of the contract database 211. TRUE is set (step S25). In the case of user B2, the seal data entered in the "input area" is stored in the input area item of the contract database 211 in association with the contract data.

<Processing in confirmer terminal 4C>
19 to 20 are displayed and output from the contract confirmation control unit 222 of the contract management server 2 to the confirmer terminal 4C when access is received from the confirmer terminal 4C of the user C1 (step S21). This shows a confirmation screen (steps S22, S23).

As shown in the screen of FIG. 19, the contract data is displayed on the confirmation screen. It is displayed so that it can be input (step S23). On the other hand, since the "input area" 621 is the "input area" 621 set for the user B2, data cannot be input to the "input area" 621 from the confirmer terminal 4C of the user C1. Is displayed. Furthermore, if data has already been input and stored in the "input area" 621 set for user B2, the data that has already been input (here, the stamp data of user B2) is also displayed. Further, on the confirmation screen, information of users B1, B2, and C1 who confirm the contract data is displayed at the top.

Then, the user C1 confirms the content of the contract data on the screen shown in FIG. 19, and performs data input operation to the "input area" 622 in which data can be input to the user C1. In this example, the "input area" 622 is a column for stamping a seal. 20, the seal stamp data is stamped in the "input area" 622 (step S24). Here, the seal stamp data is registered in advance corresponding to the user C1, or created and authenticated by the user C1 at the time of stamping. The data input by the "confirmer" may be text data or signature data depending on the "input area".

Then, when the contract confirmation control unit 222 of the contract management server 2 receives the confirmation completion input from the confirmer terminal 4C, it associates the information to that effect with the contract data and adds it to the confirmation flag item of the contract database 211. TRUE is set (step S25). In the case of user C<b>1 , the seal data entered in the “input area” is stored in the input area item of contract database 211 in association with the contract data.

After that, when the contract management server 2 receives input and confirmation completion operations in the "input area" from all "confirmers" set in the contract data, it sets it as contract data for confirmation processing completion, Store in contract database 211 .

<Group display processing (first embodiment)>
Group display processing (first embodiment) in which the displayer terminal 5 accesses the contract management server 2 and displays contracts will be described with reference to the flowchart of FIG. 11 and the list display screen of FIG. It is assumed that user Z is the user (displayer) associated with the displayer terminal 5 . User Z who is the displayer includes arbitrary users including user A1 who is the "creator", user B1 who is the "confirmer", user B2, and user C1. Note that FIG. 11 is a flow chart showing processing operations by the group display control unit 223 . FIG. 21 is a diagram showing a display example of a list display screen displayed on the display terminal 5 by the group display processing by the contract management server 2. As shown in FIG.

In the group display process, user Z can refer to the contract management server 2 for contract data for which he is not the "creator" or "confirmer" based on the group (team, department) to which he belongs, and cause it to be displayed. can be done. This makes it possible to display contract data of other users.

First, the displayer terminal 5 selects a predetermined access address for group display processing and accesses the contract management server 2 .

In step S<b>31 , the group display control unit 223 of the contract management server 2 receives access from the displayer terminal 5 . The displayer terminal 5 transmits a user ID for identifying itself to the contract management server 2 .

In step S<b>32 , the group display control unit 223 of the contract management server 2 receives the user ID from the displayer terminal 5 . The group display control unit 223 of the contract management server 2 searches the user database 214 using the user Z's user ID as a search key to acquire the group ID item set for the user Z (hereinafter referred to as group Z).

In step S33, the group display control unit 223 of the contract management server 2 searches the cabinet database 213 using the group Z, which is the group ID of the user Z, as a search key. Get an ID. Next, by searching the contract group database 212 using the cabinet ID as a search key, the contract data in which the group Z is associated with the group ID is acquired and added to the display target list.

In step S34, the group display control unit 223 of the contract management server 2 searches the contract group database 212 for contract data not associated with a cabinet ID. By searching the user database 214 using the user ID of the "creator" and the e-mail address of the "confirmer" as search keys, the "creator" and the "confirmer" of the contract data not associated with the cabinet ID are retrieved. group ID (hereinafter referred to as extended group ID).
Among the contract data not associated with the cabinet ID, the contract data including the group Z in the extended group ID is added to the display target list.
In addition to the case where the contract data is not included in the contract group database 212, information indicating that the contract data is not associated with a cabinet ID such as a NULL value or 0 is stored. In addition to the case where the system stores a uniform value for all contract data, even if a uniform value is stored for each organization ID, the contract is not linked to the cabinet ID. included in the data.

In step S35, the group display control unit 223 of the contract management server 2 searches for contract data that is associated with the cabinet ID and is not included in the display target list. If the user ID of user Z is included in the user ID of the “creator” linked to contract data among the contract data searched, the contract data is added to the display target list.

In step S36, the group display control unit 223 of the contract management server 2 searches for contract data that is associated with the cabinet ID and is not included in the display target list. If the e-mail address of user Z is included in the e-mail address of the "confirmer" linked to contract data among the contract data retrieved, the contract data is added to the display target list.

After that, the group display control unit 223 of the contract management server 2 causes the terminal 5 of the displayer to display the obtained display target list.

<Group display processing display screen (first embodiment)>
FIG. 21 is a diagram showing a list display screen of contract data included in the display target list obtained by group display processing when user Z is user B1 to user B5 in group display processing (first embodiment). is. The processing contents will be explained using the following cases as representative examples.

The contract display process for the contract ID "CONTRACT1" when the user Z is the user B1 will be described. User B1 is associated with "BCOMPANY-A" and "BCOMPANY-B" as group IDs (FIG. 7). The contract ID "CONTRACT1" is associated with "ACABINET-A" as the cabinet ID. Also, the cabinet ID "ACABINET-A" is associated with group IDs "ACOMPANY-A" and "BCOMPANY-A" (FIG. 6).
In step S33, since the group ID of the contract ID "CONTRACT1" includes "BCOMPANY-A" which is the group ID of user B1, it is added to the display target list and displayed to user B1.

The contract display process for the contract ID "CONTRACT2" when the user Z is the user B1 will be described. Since the contract ID "CONTRACT2" is not associated with the cabinet ID, it is not added to the display target list in step S33.
In step S34, the extended group IDs "BCOMPANY-C" and "BCOMPANY-A" are specified based on the confirmers User B2 and User B4, respectively. Since the group ID of user B1 is included in the extended group ID, it is added to the display target list and displayed to user B1.

The contract display process for the contract ID "CONTRACT1" when the user Z is the user B2 will be described. In step S33, the group ID associated with the contract ID "CONTRACT1" via the cabinet ID does not include the group ID of user B2, so it is not added to the display target list in step S33. Since the contract ID "CONTRACT1" is associated with the cabinet ID, it is not added to the display target list in step S34. In step S35, since the mail address of the "confirmer" of the contract ID "CONTRACT1" includes the mail address of user B2, it is added to the display target list and displayed to user B2.

The contract display process for the contract ID "CONTRACT5" when the user Z is the user B2 will be described. The contract ID "CONTRACT5" is associated with the group ID "BCOMPANY-B" through the cabinet ID (Fig. 6).
In step S33, the group ID associated with the contract ID "CONTRACT5" via the cabinet ID does not include the group ID of user B2, so it is not added to the display target list in step S33. Since the contract ID "CONTRACT5" is associated with the cabinet ID, it is not added to the display target list in step S34. In step S35, since the user B2 is included in the user ID of the "creator" of the contract ID "CONTRACT5", it is added to the display target list and displayed to the user B2.

<Contract creation processing (second embodiment)>
FIG. 22 is a flow chart showing the processing operation by the contract creation control unit 221 of the contract management server 2 in the contract creation process (second embodiment). Since the processing from steps S11 to S14 is the same as the contract creation processing (first embodiment), description thereof is omitted.

In step S15, the contract creation control unit 221 of the contract management server 2 links user A1, user B1, user B2, and user C1 to user A1, user B1, user B2, and user C1 using the email addresses of user A1, user B1, user B2, and user C1 as search keys. Identify the assigned group ID.

In step S16, the contract creation control unit 221 of the contract management server 2 refers to the cabinet database 213 and identifies the cabinet ID from the group ID identified in step S15. The contract creation control unit 221 of the contract management server 2 stores the contract ID and cabinet ID of the contract data in the contract ID item and cabinet ID item of the contract group database 212 .

Note that in steps S15 and S16, only the cabinet ID of either the creator or the confirmer may be stored.

By performing such control, even if user Z is a "creator" or "confirmer", if the user Z is not included in the group linked to the contract data via the cabinet, Display can be restricted. For example, this corresponds to a case where user Z was initially engaged in work related to contract data as a "confirmer", but later changed to belong to a different group.

<Contract Confirmation Processing (Second Embodiment)>
FIG. 23 is a flow chart showing the processing operation of the contract confirmation control unit 222 of the contract management server 2 in the contract confirmation process (second embodiment). Since the processing from steps S21 to S25 is the same as the contract confirmation processing according to the first embodiment, the explanation is omitted.

<Processing at confirmer terminal 4A>
Upon receiving access from the confirmer terminal 4A, the contract confirmation control unit 222 of the contract management server 2 transfers the contract ID of the contract data specified by the access address 71 and the email address of user B1 to the contract Read from the database 211 (step S26).

In step S27, the contract confirmation control unit 222 of the contract management server 2 reads out the group ID associated with the user B1 using the email address of the user B1 as a search key.

In step S28, the contract confirmation control unit 222 of the contract management server 2 refers to the cabinet database 213 based on the group ID read out in step S27 to identify the cabinet ID. The contract ID and cabinet ID of the contract data are stored in the contract ID item and cabinet ID item of the contract group database 212 .

As a result, the cabinet ID linked to the group ID of the user B1 can be set as the cabinet ID of the contract data, and the operation of linking the contract data with the cabinet ID by the operator can be omitted. Mistakes such as forgetting to attach can be prevented. In addition, based on the operation of the user B1 who is the confirmer, the group ID of the user B1 is linked to the contract data via the cabinet ID, which is desirable in terms of security for the organization to which the user B1 belongs.

<Processing in confirmer terminal 4B>
Upon receiving access from the confirmer terminal 4B, the contract confirmation control unit 222 of the contract management server 2 transfers the contract ID of the contract data specified by the access address 71 and the email address of user B2 to the contract Read from the database 211 (step S26).

In step S27, the contract confirmation control unit 222 of the contract management server 2 reads out the group ID associated with the user B2 using the email address of the user B2 as a search key.

In step S28, the contract confirmation control unit 222 of the contract management server 2 refers to the cabinet database 213 based on the group ID read out in step S27 to identify the cabinet ID. The contract ID and cabinet ID of the contract data are stored in the contract ID item and cabinet ID item of the contract group database 212 .

<Processing in confirmer terminal 4C>
Upon receiving access from the confirmer terminal 4C, the contract confirmation control unit 222 of the contract management server 2 transfers the contract ID of the contract data specified by the access address 71 and the email address of user C1 to the contract Read from the database 211 (step S26).

In step S27, the contract confirmation control unit 222 of the contract management server 2 reads out the group ID associated with the user B2 using the email address of the user C1 as a search key.

In step S28, the contract confirmation control unit 222 of the contract management server 2 refers to the cabinet database 213 based on the group ID read out in step S27 to identify the cabinet ID. The contract ID and cabinet ID of the contract data are stored in the contract ID item and cabinet ID item of the contract group database 212 .
In the contract confirmation process (second embodiment), the processes of steps S26 to S28 may be configured to be executed after any one of steps S23, S24, and S25.
For example, it may be performed after the confirmation process of the contract by the user in step S25 is completed. In addition, if there are multiple "confirmers", the process of steps S26 to S28 may be executed for some or all of the multiple "confirmers" after confirmation by the last "confirmer" is completed. can be configured to
As a result, it is possible to automatically assign a cabinet ID to the contract data that has been confirmed by the "confirmer" and store it. Colleagues and superiors of the confirmer can refer to the contract data that has been confirmed by the "confirmer".

<Group display processing (second embodiment)>
Processing for displaying a contract according to the second embodiment will be described with reference to the flowchart of FIG. 24 and the list display screen of FIG. Note that FIG. 24 is a flowchart showing processing operations by the group display control unit 223 . FIG. 25 is a diagram showing a display example of a list display screen displayed on the displayer terminal 5 by the group display processing by the contract management server 2. As shown in FIG.

Note that the processing from steps S31 to S34 is the same as the contract confirmation processing according to the first embodiment, so the explanation is omitted.

The group display process in the second embodiment does not include steps S35 and S36. In other words, even if user Z is the creator or confirmer of the contract data, if the group ID is linked to the contract data via the cabinet ID, user Z's group ID will be included in the group ID. Not displayed if not included.

By performing such control, even if user Z is a "creator" or "confirmer", if the user Z is not included in the group set in the contract data, the display of the contract can be restricted. can be done. For example, this corresponds to a case where user Z was initially engaged in work related to contract data as a "confirmer", but later changed to belong to a different group.

<Group display processing display screen (second embodiment)>
FIG. 25 is a diagram showing a list display screen of contract data included in the display target list obtained by group display processing when user Z is user B1 to user B5 in group display processing (second embodiment). is. The processing contents will be explained using the following cases as representative examples.

The contract display process for the contract ID "CONTRACT1" when the user Z is the user B2 will be described. In step S33, the group ID linked via the cabinet ID of the contract ID "CONTRACT1" does not include the group ID of user B2, so it is not added to the display target list in step S33. Since the contract ID "CONTRACT1" is associated with the cabinet ID, it is not added to the display target list in step S34. Since the contract ID "CONTRACT1" is not included in the display target list, it is not displayed to user B2.

The contract display process for the contract ID "CONTRACT5" when the user Z is the user B2 will be described. The contract ID "CONTRACT5" is associated with the group ID "BCOMPANY-B" through the cabinet ID (Fig. 6).
In step S33, the group ID linked via the cabinet ID of the contract ID "CONTRACT5" does not include the group ID of user B2, so it is not added to the display target list in step S33. Since the contract ID "CONTRACT5" is associated with the cabinet ID, it is not added to the display target list in step S34. Since the contract ID "CONTRACT5" is not included in the display target list, it is not displayed to user B2.

<Basic computer hardware configuration>
FIG. 26 is a block diagram showing the basic hardware configuration of a computer. A computer includes a processor, a main memory, an auxiliary memory, and a communication interface. These are electrically connected to each other by a communication bus.
It should be noted that computers can be virtually realized by distributing all or part of each hardware configuration to a plurality of computers and connecting them to each other via a network. In this way, a computer is a concept that includes not only a computer housed in a single housing or case, but also a virtualized computer system.

A processor is hardware for executing a set of instructions written in a program. The processor is composed of arithmetic units, registers, peripheral circuits, and the like.

The main memory is for temporarily storing programs and data processed by the programs. For example, it is a volatile memory such as a DRAM (Dynamic Random Access Memory).

Auxiliary storage is a storage device for storing data and programs. For example, flash memory, HDD (Hard Disc Drive), magneto-optical disk, CD-ROM, DVD-ROM, semiconductor memory, and the like.

A communication interface is an interface for inputting and outputting signals for communicating with an external device using a wired or wireless communication standard.

<Basic functional configuration of the computer>
A functional configuration of the computer realized by the basic hardware configuration of the computer (FIG. 26) will be described. The computer includes a control section, a communication section, and a storage section.

The processor reads the program from the auxiliary storage device, develops it in the main storage device, and executes processing according to the program. This allows the controller to function as various functional units. Moreover, when a program is delivered to a computer via a network, the computer receiving the delivery may load the program into a main storage device and execute processing according to the program.
The functional units provided in the computer can also be implemented by distributing all or part of each functional unit to a plurality of computers interconnected by a network. A computer is a concept that includes not only a single computer but also a virtualized computer system.

A communication unit is realized by a communication interface. The communication unit implements a function for communicating with other computers via a network. It can receive information sent from other computers and send information to other computers. The network includes the Internet, LAN, and various mobile communication systems constructed by wireless base stations (not shown). Examples include 3G, 4G, 5G mobile communication systems, LTE (Long Term Evolution), wireless networks (for example, Wi-Fi (registered trademark)) that can be connected to the Internet through a predetermined access point, and the like. When connecting wirelessly, for example, Z-Wave (registered trademark), ZigBee (registered trademark), Bluetooth (registered trademark), etc. may be used as a communication protocol. The communication unit may be connected by a USB (Universal Serial Bus) cable or the like when connected by wire.

The storage unit is implemented by a main storage device and an auxiliary storage device. The storage unit implements a function of storing data, programs, and various databases. The processor can secure a storage area corresponding to the storage unit in the main storage device or the auxiliary storage device according to the program.

<Appendix>
The items described in the above embodiments will be added below.

(Appendix 1)
A program for causing a computer comprising a processor and a storage unit to execute electronic contract procedures between users belonging to different organizations, the program causing the processor to bind first user identification information and a second mail address. a saving step (S11) for saving the attached contract data; a step (S33) for acquiring the third group identification information associated with the contract data; and a fourth group identification information associated with the fourth group identification information. and an inquiry step (S31) of processing an inquiry request from a fourth user having user identification information, and the inquiry step, if the fourth group identification information matches the third group identification information, a program for displaying the contract data (S33) and not displaying the contract data to the fourth user if the fourth group identification information does not match the third group identification information (S33);
As a result, it is possible to efficiently limit the scope of the user's ability to refer to and edit the contract on a group-by-group basis.

(Appendix 2)
a step of acquiring second user identification information linked to the second email address (S26); a step of acquiring second group identification information linked to the second user identification information (S27); The program according to Supplementary Note 1 for executing an attachment step (S28) for linking the second group identification information to.
As a result, groups can be automatically set for contracts created by "creators" belonging to different organizations, and omissions and omissions in contract management can be suppressed.

(Appendix 3)
a step (S14) of sending an e-mail containing an address for accessing the contract data to the second e-mail address; The program according to appendix 1 or 2, for linking group identification information (S28).
As a result, at a newer timing when the "confirmer" confirms the contract, the group set for the "confirmer" can be automatically set as the contract group. After the "creator" creates the contract, even if the group of the "confirmer" is changed due to a change in department, etc., the latest "confirmer" group can be set for the contract.

(Appendix 4)
a step of acquiring the first group identification information linked to the first user identification information (S15); and a storing step of linking the first group identification information to the contract data (S16). 4. The program according to any one of 1 to 3.
As a result, when the "creator" creates the contract and the "confirmer" confirms the contract, the groups set for each of the "creator" and "confirmer" are added to the contract. Groups can be set automatically. Omissions and omissions in contract management can be suppressed.

(Appendix 5)
a step of acquiring the first group identification information linked to the first user identification information; If the fourth group identification information matches the first group identification information, the contract data is displayed to the fourth user (S34), and if the fourth group identification information does not match the first group identification information, the contract 5. The program according to any one of appendices 1 to 4, wherein the data is not displayed to the fourth user (S34).
As a result, it is possible to limit the scope of the user's ability to refer to and edit the contract to users belonging to the same group as the "creator" of the contract.

(Appendix 6)
obtaining second user identification information linked to the second email address; and obtaining second group identification information linked to the second user identification information; 3. If the group identification information does not exist and the second group identification information exists, and if the fourth group identification information matches the second group identification information, the contract data is displayed to the fourth user (S34). 6. The program according to any one of Appendices 1 to 5, wherein if the fourth group identification information does not match the second group identification information, the contract data is not displayed to the fourth user (S34).
As a result, it is possible to limit the scope of the user's ability to refer to and edit the contract to users belonging to the same group as the "confirmer" of the contract.

(Appendix 7)
a first querying step of processing a query request from a first user having the first user identification, wherein the first querying step, if a third group identification is present, is performed by the first group; 7. The program according to any one of Appendices 1 to 6, wherein the contract data is displayed to the first user even if the identification information does not match the third group identification information (S35).
As a result, the "creator" can refer to the contract even if the "creator"'s own group is not included in the groups set in the contract.

(Appendix 8)
a first querying step of processing a query request from a first user having the first user identification, wherein the first querying step, if a third group identification is present, is performed by the first group; 7. The program according to any one of appendices 1 to 6, wherein the contract data is not displayed to the first user even if the identification information matches the third group identification information.
As a result, even if the "creator" own group is not included in the group set for the contract, even the "creator" cannot view the contract, improving security. can.

(Appendix 9)
a second querying step of processing a query request from a second user having the second user identification, the second querying step performing the second group identification if the third group identification is present; 9. The program according to any one of Appendices 1 to 8, wherein the contract data is displayed to the second user even if the identification information does not match the third group identification information (S36).
As a result, the "confirmer" can refer to the contract even if the "confirmer"'s own group is not included in the groups set in the contract.

(Appendix 10)
a second querying step of processing a query request from a second user having a second user identification, the second querying step performing a fourth group identification if a third group identification is present; 9. The program according to any one of appendices 1 to 8, wherein the contract data is not displayed to the second user even if the identification information matches the third group identification information.
As a result, if the group set in the contract does not include the group of the "confirmer", even the "confirmer" cannot view the contract, improving security. can.

1 information processing system 2 contract management server 21 storage unit 22 control unit 3 creator terminal 31 storage unit 32 control unit 4A, 4B, 4C confirmation person terminal 5 display person terminal

Claims (12)

A program for causing a computer comprising a processor and a storage unit to execute electronic contract procedures between users belonging to different organizations,
The program causes the processor to:
a saving step of saving the contract data linked to the first user identification information and the second email address;
a step of acquiring third group identification information linked to the contract data;
an inquiry step of processing an inquiry request from a fourth user having fourth user identification information linked to fourth group identification information;
and
The querying step includes:
if the fourth group identification information matches the third group identification information, display the contract data;
if the fourth group identification information does not match the third group identification information, the contract data is not displayed to the fourth user;
program. obtaining second user identification information associated with the second email address;
a step of obtaining second group identification information linked to the second user identification information;
a step of linking second group identification information to the contract data;
2. The program according to claim 1, causing the execution of sending an email to a second email address that includes an address for accessing the contract data;
and
The providing step associates the second group identification information with the contract data after accessing the address.
3. A program according to claim 1 or 2. obtaining the first group identification information linked to the first user identification information;
and
The storing step associates first group identification information with the contract data,
A program according to any one of claims 1 to 3. obtaining the first group identification information linked to the first user identification information;
and
The querying step includes:
If the third group identification information does not exist and the first group identification information exists,
if the fourth group identification information matches the first group identification information, displaying the contract data to the fourth user;
if the fourth group identification information does not match the first group identification information, the contract data is not displayed to the fourth user;
A program according to any one of claims 1 to 4. obtaining second user identification information associated with the second email address;
a step of obtaining second group identification information linked to the second user identification information;
and
The querying step includes:
If the third group identification information does not exist and the second group identification information exists,
if the fourth group identification information matches the second group identification information, displaying the contract data to the fourth user;
if the fourth group identification information does not match the second group identification information, the contract data is not displayed to the fourth user;
A program according to any one of claims 1 to 5. a first inquiry step of processing an inquiry request from a first user having a first user identification;
and
The first inquiry step is
If the third group identification information exists,
displaying the contract data to the first user even if the first group identification information does not match the third group identification information;
A program according to any one of claims 1 to 6. a first inquiry step of processing an inquiry request from a first user having a first user identification;
and
The first inquiry step is
If the third group identification information exists,
preventing the contract data from being displayed to the first user even when the first group identification information matches the third group identification information;
A program according to any one of claims 1 to 6. a second inquiry step of processing an inquiry request from a second user having the second user identification;
and
The second inquiry step includes:
If the third group identification information exists,
displaying the contract data to the second user even if the second group identification information does not match the third group identification information;
A program according to any one of claims 1 to 8. a second inquiry step of processing an inquiry request from a second user having the second user identification;
and
The second inquiry step includes:
If the third group identification information exists,
not displaying the contract data to the second user even if the fourth group identification information matches the third group identification information;
A program according to any one of claims 1 to 8. An information processing device comprising a processor and a storage unit,
to the processor;
a saving step of saving the contract data linked to the first user identification information and the second email address;
a step of acquiring third group identification information linked to the contract data;
an inquiry step of processing an inquiry request from a fourth user having fourth user identification information linked to fourth group identification information;
and
The querying step includes:
if the fourth group identification information matches the third group identification information, display the contract data;
if the fourth group identification information does not match the third group identification information, the contract data is not displayed to the fourth user;
Information processing equipment. An information processing method for causing a computer comprising a processor and a storage unit to execute electronic contract procedures between users belonging to different organizations,
The information processing method includes:
a saving step of saving the contract data linked to the first user identification information and the second email address;
a step of acquiring third group identification information linked to the contract data;
an inquiry step of processing an inquiry request from a fourth user having fourth user identification information linked to fourth group identification information;
and
The querying step includes:
if the fourth group identification information matches the third group identification information, display the contract data;
if the fourth group identification information does not match the third group identification information, the contract data is not displayed to the fourth user;
Information processing methods.

Images