JP7675902B2 - Electronic contract program, information processing device, and information processing method - Google Patents

Description

This disclosure relates to an electronic contract program, an information processing device, and an information processing method.

There is technology that allows contracts to be concluded by exchanging electronic data of contracts over the Internet and signing them electronically, and then storing the electronic data on a company's server or in cloud storage.

Patent document 1 describes how an administrator registers and manages the electronic identification card information of users who enter into electronic contracts, and also describes how the identity of the user is displayed to the other party to prove identity when entering into an electronic contract.

Special Publication No. 2014-529371

However, when identity verification is performed based on an electronic identification card when concluding an electronic contract as in Patent Document 1, there are problems such as (1) the complexity of managing the electronic identification card, (2) the reliability of the electronic identification card itself, and (3) the costs of obtaining and maintaining the electronic identification card.

For example, from the administrator's perspective, the maintenance work required to ensure accuracy by checking that information on electronic ID cards is entered correctly and that there are no input errors is cumbersome.

Furthermore, from the perspective of the other party to a contract, they must determine whether the identity recorded on the electronic identification card is genuine and must decide at their own risk whether or not to enter into an electronic contract with the owner of the card. Even if the electronic identification card is credible, there is a possibility that the person in question may enter into an electronic contract without having the authority to do so, and this must be prevented.

Furthermore, for both you and the other party, obtaining and maintaining an electronic ID card can require time, effort, and possibly even fees, due to the screening process that requires identity verification and the presentation of identification documents.

The present disclosure therefore aims to provide another technology that can prevent users of an electronic contract system, such as people belonging to an organization, from entering into electronic contracts without authorization, using a simple configuration and at low cost.

According to one embodiment, an electronic contract program is provided that is executed by a computer having a processor and a memory. The electronic contract program causes the processor to execute the following steps: storing in memory first information that identifies one or more recipients capable of concluding an electronic contract, the first information being an email address that identifies an organization and the individual recipient within the organization; comparing the first information with information that identifies the recipient requesting the conclusion of a contract, designated by the sender; sending a notice to the recipient requesting the conclusion of a contract, if the comparison indicates that the requested recipient is capable of concluding an electronic contract; and suspending the conclusion of the electronic contract, regardless of the will of the recipient or the organization to which the recipient belongs, if the comparison indicates that the requested recipient does not have the authority to conclude an electronic contract.

According to the present disclosure, in an electronic contract system in which contracts are concluded via the Internet using email addresses, it is possible to prevent users of the electronic contract system, such as those belonging to an organization, from concluding electronic contracts without authorization using a simple configuration at low cost.

A diagram showing the overall configuration of an electronic contract system 1. FIG. 1 is a block diagram of a terminal device 10 constituting the electronic contract system 1 of embodiment 1. FIG. 2 is a diagram showing the functional configuration of a server 20. FIG. 1 is a conceptual diagram for explaining an electronic contract. 2 is a diagram showing a structure of data stored in the server 20. FIG. 13 is a flowchart showing a process for registering persons who can conclude an electronic contract. 13 is a flowchart showing a process for requesting an electronic contract. FIG. 13 is a diagram showing an example of a screen displayed when canceling a request for an electronic contract to an unauthorized recipient. FIG. 13 is a diagram showing an example of a screen displaying a list of recipients who can enter into an electronic contract and those who cannot. FIG. 13 is a diagram for explaining the transfer of a request for an electronic contract depending on the presence or absence of authority.

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

<1 Overall configuration of the electronic contract system>
FIG. 1 is a diagram showing the overall configuration of an electronic contract system 1.

As shown in FIG. 1, the electronic contract system 1 includes multiple terminal devices (terminal device 10A and terminal device 10B are shown in FIG. 1. Hereinafter, they may be collectively referred to as "terminal devices 10") and a server 20. The terminal devices 10 and the server 20 are connected for communication via a network 80.

The terminal device 10 is a device operated by each user. The terminal device 10 is realized by a mobile terminal such as a smartphone or tablet compatible with a mobile communication system. In addition, the terminal device 10 may be, for example, a stationary PC (Personal Computer) or a laptop PC. As shown as terminal device 10B in FIG. 1, the terminal device 10 includes a communication IF (Interface) 12, an input device 13, an output device 14, a memory 15, a storage unit 16, and a processor 19. The server 20 includes a communication IF 22, an input/output IF 23, a memory 25, a storage 26, and a processor 29.

The terminal device 10 is connected to the server 20 via the network 80 so as to be able to communicate with the server 20. The terminal device 10 is connected to the network 80 by communicating with communication devices such as a wireless base station 81 that supports communication standards such as 5G and LTE (Long Term Evolution) and a wireless LAN router 82 that supports wireless LAN (Local Area Network) standards such as IEEE (Institute of Electrical and Electronics Engineers) 802.11.

The communication IF 12 is an interface for inputting and outputting signals so that the terminal device 10 can communicate with external devices. The input device 13 is an input device (e.g., a touch panel, a touch pad, a pointing device such as a mouse, a keyboard, etc.) for receiving input operations from a user. The output device 14 is an output device (a display, a speaker, etc.) for presenting information to a user. The memory 15 is for temporarily storing programs and data processed by the programs, etc., and is a volatile memory such as a DRAM (Dynamic Random Access Memory). The storage unit 16 is a storage device for saving data, such as a flash memory or a HDD (Hard Disc Drive). The processor 19 is hardware for executing an instruction set described in a program, and is composed of an arithmetic unit, a register, peripheral circuits, etc.

The communication IF 22 of the server 20 is an interface for inputting and outputting signals so that the server 20 can communicate with external devices. The input/output IF 23 functions as an interface with an input device for accepting input operations from a user and an output device for presenting information to the user. The memory 25 is for temporarily storing programs and data processed by the programs, etc., and is a volatile memory such as a DRAM (Dynamic Random Access Memory). The storage 26 is a storage device for saving data, such as a flash memory or a HDD (Hard Disc Drive). The processor 29 is hardware for executing a set of instructions written in a program, and is composed of an arithmetic unit, registers, peripheral circuits, etc.

In the illustrated example, the terminal devices 10 are capable of communicating with each other via the server 20, but multiple terminal devices 10 may also communicate with each other directly via short-range wireless communication without going through the server 20.

<1.1 Configuration of terminal device 10>
FIG. 2 is a block diagram of the terminal device 10 constituting the electronic contract system 1 of the first embodiment. As shown in FIG. 2, the terminal device 10 includes a plurality of antennas (antenna 111, antenna 112), wireless communication units (first wireless communication unit 121, second wireless communication unit 122) corresponding to each antenna, an operation reception unit 130 (including a touch-sensitive device 131 and a display 132), a voice processing unit 140, a microphone 141, a speaker 142, a position information sensor 150, a camera 160, a storage unit 180, and a control unit 190. The terminal device 10 also has functions and configurations (e.g., a battery for storing power, a power supply circuit for controlling the supply of power from the battery to each circuit, etc.) that are not particularly shown in FIG. 2. Each block included in the terminal device 10 is electrically connected by a bus or the like.

The antenna 111 emits the signal emitted by the terminal device 10 as a radio wave. The antenna 111 also receives the radio wave from space and provides the received signal to the first wireless communication unit 121.

The antenna 112 emits the signal emitted by the terminal device 10 as a radio wave. The antenna 112 also receives the radio wave from space and provides the received signal to the second wireless communication unit 122.

The first wireless communication unit 121 performs modulation and demodulation processing and the like for transmitting and receiving signals via the antenna 111 so that the terminal device 10 can communicate with other wireless devices. The second wireless communication unit 122 performs modulation and demodulation processing and the like for transmitting and receiving signals via the antenna 112 so that the terminal device 10 can communicate with other wireless devices. The first wireless communication unit 121 and the second wireless communication unit 122 are communication modules including a tuner, an RSSI (Received Signal Strength Indicator) calculation circuit, a CRC (Cyclic Redundancy Check) calculation circuit, a high-frequency circuit, and the like. The first wireless communication unit 121 and the second wireless communication unit 122 perform modulation and demodulation and frequency conversion of wireless signals transmitted and received by the terminal device 10, and provide the received signals to the control unit 190.

The operation reception unit 130 has a mechanism for receiving input operations from the user. Specifically, the operation reception unit 130 includes an input device such as a keyboard. The operation reception unit 130 may be configured as a pointing device such as a mouse, a touchpad, or a touch panel. The operation reception unit 130 is also configured as a touch screen and includes a touch-sensitive device 131 and a display 132. The touch-sensitive device 131 receives input operations from the user of the terminal device 10. The touch-sensitive device 131 detects the user's touch position on the touch panel, for example, by using a capacitive touch panel. The touch-sensitive device 131 outputs a signal indicating the user's touch position detected by the touch panel to the control unit 190 as an input operation.

The display 132 displays data such as images, videos, and text in response to the control of the control unit 190. The display 132 is realized, for example, by an LCD (Liquid Crystal Display) or an organic EL (Electro-Luminescence) display.

The audio processing unit 140 modulates and demodulates audio signals. The audio processing unit 140 modulates a signal provided by the microphone 141 and provides the modulated signal to the control unit 190. The audio processing unit 140 also provides the audio signal to the speaker 142. The audio processing unit 140 is realized, for example, by a processor for audio processing. The microphone 141 accepts audio input and provides an audio signal corresponding to the audio input to the audio processing unit 140. The speaker 142 converts the audio signal provided by the audio processing unit 140 into audio and outputs the audio to the outside of the terminal device 10.

The position information sensor 150 is a sensor that detects the position of the terminal device 10, and is, for example, a GPS (Global Positioning System) module. The GPS module is a receiving device used in a satellite positioning system. In a satellite positioning system, signals are received from at least three or four satellites, and the current position of the terminal device 10 in which the GPS module is installed is detected based on the received signals.

Camera 160 is a device that receives light using a light receiving element and outputs the light as a captured image. Camera 160 is, for example, a depth camera that can detect the distance from camera 160 to the subject being photographed.

The storage unit 180 is configured, for example, with a flash memory, and stores data and programs used by the terminal device 10. In one aspect, the storage unit 180 stores user information 181. The user information 181 is information about a user who uses the electronic contract system 1.

The control unit 190 controls the operation of the terminal device 10 by reading a program stored in the storage unit 180 and executing instructions contained in the program. The control unit 190 is, for example, an application processor. By operating according to the program, the control unit 190 fulfills the functions of an input operation reception unit 191, a transmission/reception unit 192, a data processing unit 193, and a notification control unit 194.

The input operation reception unit 191 performs processing to receive a user's input operation on an input device such as the touch-sensitive device 131. The input operation reception unit 191 determines the type of operation, such as whether the user's operation is a flick operation, a tap operation, or a drag (swipe) operation, based on information on the coordinates where the user touches the touch-sensitive device 131 with a finger or the like.

The transmission/reception unit 192 performs processing for the terminal device 10 to transmit and receive data to and from an external device such as the server 20 in accordance with a communication protocol. The data processing unit 193 performs processing for data received as input by the terminal device 10 in accordance with a program and outputs the results of the calculation to a memory or the like.

The data processing unit 193 performs calculations on the data received by the terminal device 10 according to a program, and outputs the calculation results to a memory or the like.

The notification control unit 194 performs processing to notify the user of information through the five senses, including sight and hearing. The notification control unit 194 performs processing to display a display image on the display 132, to output sound to the speaker 142, and to generate vibrations from the vibrator.

<1.2 Functional configuration of server 20>
Fig. 3 is a diagram showing the functional configuration of the server 20. As shown in Fig. 3, the server 20 fulfills the functions of a communication unit 201, a storage unit 202, and a control unit 203.

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

The storage unit 202 stores data and programs used by the server 20. The storage unit 202 stores user information 281, organization information 282, contractable user information 283, notification information 284, contract information 285, etc.

User information 281 is a database for holding information about users of electronic contract system 1.

Organization information 282 is information that indicates the organization (e.g., a corporate organization such as a company) to which the user who is making an electronic contract belongs.

Contractable user information 283 is information that indicates the individuals who have the authority to enter into electronic contracts in each organization to which the user belongs.

Notification information 284 is information regarding a request to conclude an electronic contract, and is information for managing the date and time when the request was notified and linked to the contract.

The contract information 285 is information that indicates the state of agreement between the sender and receiver to enter into an electronic contract, the contents of the electronic contract, etc.

The control unit 203 performs functions shown as various modules by the processor of the server 20 performing processing according to a program. The operation content acquisition module 2041 of the control unit 203 acquires the user's operation content. The reception control module 2042 controls the process in which the server 20 receives a signal from an external device according to a communication protocol. The transmission control module 2043 controls the process in which the server 20 transmits a signal to an external device according to a communication protocol.

The authority management module 2044 and the contract conclusion processing module 2045 will be explained following the conceptual diagram of an electronic contract below.

Figure 4 is a conceptual diagram for explaining electronic contracts. In this embodiment, an "electronic contract" refers to the exchange of electronic contract data over the Internet, the contracting parties expressing their intention to agree, and the application of their electronic signatures to the electronic contract data. Also, an "electronic signature" refers to a mechanism for indicating the creator of electronic data and proving that the electronic data has not been tampered with, as defined in Article 2, Paragraph 1 of the Electronic Signatures Act.

First, the contract sender operates the terminal device 10A to upload the electronic data of the contract to, for example, the server 20 on the cloud. The terminal device 10 accepts an operation from the user of the terminal device 10 indicating agreement to the contract. The server 20 affixes the contract sender's digital signature to the electronic data of the contract that the contract sender has agreed to.

Next, the contract sender performs an operation to request the contract recipient to conclude an agreement. The electronic contract system 1 sends the contract recipient information (link) for accessing the electronic contract data by email.

The contract recipient can click on the link in the email received on the terminal device 10B, check the contents of the electronic contract data on the server 20 online, and enter into an agreement. If at this point the contract contains unintended conditions or defects, the server 20 may accept an operation from the contract recipient indicating that the contract is not agreed to.

If the contract recipient agrees, the electronic data of the contract is affixed with the contract recipient's digital signature. The electronic data of the contract is stored on server 20. As both contracting parties have digital signatures, the contract is prevented from being tampered with.

This embodiment realizes such a cloud-based electronic contract service. In the following embodiment, a technology is described that prevents members of an organization from entering into an electronic contract without authorization regarding the authority to enter into a contract.

For this reason, the authority management module 2044 of the server 20 (see FIG. 3) manages information on those who can enter into contracts within the organization (i.e., what is called authority information in this embodiment) and performs processing to prevent those who do not have the authority from operating to enter into an agreement.

The contract conclusion processing module 2045 is responsible for all electronic contract processing other than the authority management described above. That is, the contract conclusion processing module 2045 performs the process of recording the electronic contract data in the server 20 based on the operation of the contract sender as described above, the process of generating a link for accessing the electronic contract data, the process of sending an email for contract conclusion to the contract recipient, the process of accepting access based on the link from the contract recipient and accepting operations for contract conclusion, and other processes.

<2 Data Structure>
FIG. 5 shows the data structures of the user information 281, organization information 282, contractable user information 283, notification information 284, and contract information 285 stored in the server 20. As shown in FIG.

As shown in FIG. 5, each record of user information 281 includes an item "ID", an item "user name", an item "organization ID", etc., for each piece of information that identifies a user.

The "ID" item is information (user ID) that identifies each piece of user information 281. A row in the table of user information 281 identified by a user ID represents one user of the electronic contract system 1 (who can be a sender, recipient, or organizational administrator). The "user name" item is display information such as the name of that user ID. The "organization ID" item is an organization ID in organization information 282, and user information 281 is associated with organization information 282 by this organization ID.

In addition to the examples of user information shown in the figure, user information 281 includes information specific to the user, such as the user's email address and password, as well as various user attributes that should be managed in relation to the use of services provided by the electronic contract system 1 according to this embodiment.

Each piece of organizational information 282 includes an item "ID", an item "organization name", etc. The item "ID" is information (organization ID) that identifies each piece of organizational information 282. A row in the table of organizational information 282 identified by an organization ID represents an organization to which a user of the electronic contract system 1 belongs. The item "organization name" is display information such as the name of the organization ID.

In addition to the examples shown in the figure, organizational information 282 may include information specific to the organization, such as the company address, and information on various organizational attributes (e.g., organizational structure, department names, etc.) that should be managed in relation to the use of the services of the electronic contract system 1 according to this embodiment.

Each contractable user information 283 includes the items "ID" and "email address", etc.

The "ID" item is information (contractable user ID) that identifies each piece of contractable user information 283. A row in the table of contractable user information 283 identified by a contractable user ID represents a single email address of a person (sometimes called a "contractable user") in the organization who is capable of concluding an electronic contract.

When no contract-eligible user information has been registered, the table of contract-eligible user information 283 is empty. By performing registration in the electronic contract system 1 through the processing according to this embodiment, information about users who can conclude electronic contracts, identified by the item "ID", is added.

When the registration of a contractable user is deleted in this system 1 by instruction from an administrator, etc., the corresponding item "ID" is deleted from the contractable user information 283. The item "Email address" is the email address of the contractable user.

Each notification information 284 includes an item "ID", an item "sender ID", an item "recipient ID", an item "request notification date and time", an item "contract ID", etc.

The item "ID" is information (notification ID) that identifies each piece of notification information 284. One row in the table of notification information 284 identified by the notification ID represents one notification regarding a request for contract conclusion in this system 1.

The "sender ID" item indicates the user ID of the sender in the notification requesting contract agreement. The "recipient ID" item is the user ID of the recipient of the notification. The "request notification date and time" item indicates the date and time when the notification related to the request was made. The "contract ID" item is the contract ID in the contract information 285, and the notification information 284 is associated with the contract information 285 by this contract ID.

Each piece of contract information 285 includes an item "ID", an item "sender ID", an item "sender agreement", an item "recipient ID", an item "recipient agreement", an item "contract details", etc.

The item "ID" is information (contract ID) that identifies each piece of contract information 285. One row in the table of contract information 285 identified by a contract ID represents one contract in this system 1.

The item "Sender ID" is the user ID of the user (i.e., the sender) who uploads the electronic data of the contract to the server 20 to conclude the contract and requests the recipient to conclude the contract. The item "Sender Agreement" indicates whether the sender indicated in the item "Sender ID" has agreed to the contents of the contract (i.e., the contract) or has not yet done so (uncompleted).

The "Recipient ID" item is the user ID of the user (i.e., the recipient) who accepts the request for contract agreement upon notification from the sender. The "Recipient Agreement" item indicates whether the recipient indicated in the "Recipient ID" item has agreed to the contents of the contract (i.e., the contract) or has not yet done so (uncompleted).

The "Contract Content" item is information detailing the contract contents, such as the title and terms of the contract, related to this contract. Although not shown in the figure, this includes link information to the contract and the actual electronic data of the contract.

<3 Operation>
6 is a flowchart showing the process of registering persons who can enter into an electronic contract. This registration is performed in advance by a user in the electronic contract system 1 according to the present embodiment before entering into a contract using the system.

In step S601, on the user's terminal device 10, the user, for example an administrator or employee of an organization, inputs the email address of a person who can enter into an electronic contract.

In step S602, the authority management module 2044 of the server 20 receives from the terminal device 10 the email address of the user who is capable of concluding the electronic contract that was entered in step S601, and registers it in the contract-eligible user information 283 in the memory unit 202.

As a result, as shown in FIG. 5, the server 20 registers in the contractable user information 283 the email address "miya@dnameA.jp" of "Mshita Maki" of "A Co., Ltd.", the email address "yama@dnameB.jp" of "Yguchi Jiko" of "B Co., Ltd.", and the email address "hira@dnameC.jp" of "Hoka Myoshio" of "C Co., Ltd.".

In this example, "Nzawa Tyuki" of "B Co., Ltd." is not registered in the contractable user information 283 and does not have the authority to enter into an electronic contract.

Figure 7 is a flowchart showing the process of requesting an electronic contract. In the following explanation, it is assumed that the terminal device 10A of the sending user, which is the trigger for the contract conclusion, and the terminal device 10B of the receiving user conclude the contract via the server 20.

In step S701, the sender's terminal device 10A specifies the recipient user requesting a contract. For example, the terminal device 10A accesses the server 20 using a browser or the like to display on the display 132 of the terminal device 10A a screen for specifying the email address of the recipient user requesting a contract. The terminal device 10A transmits to the server 20 information on the email address of the recipient user that has been specified by the sender's user.

In step S702, the authority management module 2044 of the server 20 compares the recipient user specified in the sender's terminal device 10A with the information of the recipient user who can enter into an electronic contract. Specifically, the server 20 determines whether the email address of the recipient user specified by the sender's user matches the email address in the list of email addresses registered in the contract-enabled user information 283 of the server 20.

In step S703, if the authority management module 2044 of the server 20 determines that the email address registered in the contractable user information 283 matches the email address registered in the contractable user information 283 as a result of the comparison in step S702 (if there is a match in step S702), it determines that the recipient user who has been requested to conclude a contract can conclude an electronic contract. The server 20 sends a notification requesting the conclusion of the contract to the recipient's terminal device 10B. For example, this is done by sending an email containing the notification from the server 20 constituting the electronic contract system 1 to the email address. The server 20 also sends the email address containing the notification to the recipient's user's terminal device 10B, and records information regarding the notification in the notification information 284.

In step S704, the receiver's terminal device 10B processes the contract requested by the notification in step S703. Specifically, the terminal device 10B displays an e-mail containing the notification on the display 132 in response to the operation of the receiver's user. The terminal device 10B accesses the server 20 by accepting an operation from the receiver's user to select a link contained in the e-mail received from the electronic contract system 1, and displays information regarding the contract conclusion related to the notification (such as the contents of the contract documents). The terminal device 10B transmits information indicating that the receiver's user has agreed to the contract conclusion to the server 20 by accepting an operation from the receiver's user indicating that the receiver's user has agreed to the contents of the contract documents. The server 20 updates the contract information 285 by receiving information indicating that the receiver's user has agreed to the contract conclusion from the terminal device 10B, and transmits a notification to the sender's user's e-mail address indicating that the receiver's user has agreed to the contract conclusion.

In step S705, if the comparison in step S702 above shows that there is no email address in the list of email addresses registered in the contractable user information 283 of the server 20 that matches the email address of the recipient specified by the sender (no match in step S702), the authority management module 2044 of the server 20 determines that the recipient user related to the request does not have the authority to enter into an electronic contract. The server 20 suspends the execution of the electronic contract. This suspension may be performed regardless of the intentions of the recipient or the organization to which the recipient belongs.

When performing such suspension, server 20 may identify a user of the organization associated with the email address (e.g., an administrator) based on information about the domain of the email address of the user designated as the recipient, and notify the administrator that the conclusion of the electronic contract has been suspended (e.g., by sending the notification to the administrator's email address). This allows the administrator of the recipient's organization to recognize that the user of the email address designated by the sending user does not have the authority to conclude a contract, and that there has been business activity to conclude a contract with the sending user's organization, making the management of electronic contracts even easier.

Here, when the recipient user suspends the conclusion of an electronic contract because he or she does not have the authority to enter into a contract, the server 20 may store in the contract information 285 whether or not the conclusion of an electronic contract has been suspended, and the timing of the suspension. This allows the sender user to be notified that there is a contract for which the conclusion of an electronic contract has been suspended when the sender user accesses the server 20 with the terminal device 10A, and a reminder or other notification may be sent when a certain period of time has passed since the conclusion of the electronic contract was suspended. This allows the sender user to consider whether to continue with the conclusion of the electronic contract (e.g., by having the recipient user assign a user who has the authority to enter into a contract).

In step S706, the sender's terminal device 10A notifies the sender's user on the display 132 or the like that the recipient user does not have the authority to conclude an electronic contract, or that there has been an error in concluding the electronic contract, without notifying the sender's user whether or not the recipient user has the authority to conclude an electronic contract. The terminal device 10A accepts from the sender's user an operation to redesignate a recipient user who is able to conclude an electronic contract, an operation to cancel the contract itself, etc.

<4 Screen example>
FIG. 8 is a diagram showing an example of a screen displayed when canceling a request for an electronic contract to an unauthorized recipient.

The example screen in Figure 8 is displayed when the sender requests an electronic contract from the recipient and accidentally specifies a person who does not have the authority to enter into an electronic contract as the recipient (i.e., step S705 in Figure 7).

For example, suppose that "Company A" requests "Company B" to enter into an agreement, and "Mshita Maki" of "Company A" is the sender, who designates "Nzawa Tyuki" of "Company B" as the recipient. As mentioned above, "Nzawa Tyuki" of "Company B" does not have the authority to agree to the contract.

At this time, a message 300A is displayed on the dialog screen 300 of the terminal device 10A of the sender "Mshita Maki", stating "The specified Mr. Nzawa Tyuki (nishi@dnameB.jp) does not have the authority to enter into a contract, so processing cannot continue."

The sender, "Mshita Maki", can only press the OK button 300B to confirm the message and cannot continue processing the request.

Figure 9 shows an example of a screen that displays a list of recipient users who can enter into electronic contracts and those who cannot.

As shown in the example screen in FIG. 9, when a sender requests an electronic contract from a receiver, the sender may explicitly indicate to the sender whether each user on the receiver's side has the authority to agree to the contract. For example, the server 20 accepts an operation from an administrator of each organization to set whether or not information about users who have the authority to conclude a contract will be made public to other organizations. For example, information about users who have the authority to conclude a contract in a certain organization may be made public to a specific company (e.g., a contract between group companies).

For example, suppose that "Company A" is requesting "Company B" to conclude an agreement, and the sender is "Mshita Maki" of Company A.

Since this sender is requesting the conclusion of an agreement at "Company B," the dialog screen 400 may be displayed when the recipient is specified.

Dialog screen 400 displays message 400A saying "Person who can enter into a contract with B Co., Ltd.: Yguchi Jiko (yama@dnameB.jp)..." and "Person who does not have the authority to enter into a contract: Nzawa Toyuki (nishi@dnameB.jp)..."

Here, the sender can press the selection button 400B to select "Yguchi Jko (yama@dnameB.jp)" with whom a contract can be concluded at "B Co., Ltd.".

The example screen shown in FIG. 8 allows the sender to cancel a request for an electronic contract with an unauthorized recipient, and the example screen shown in FIG. 9 indicates to the sender whether each user on the recipient's side has the authority to agree to the contract. However, convenience may be improved by allowing the sender to proceed with the process without being aware of whether the recipient to whom the contract is being requested has the authority. The transfer of an electronic contract request depending on the presence or absence of authority, which is applied to such an embodiment, will be described with reference to FIG. 10.

Sender A (500A) requests the conclusion of an electronic contract to recipient B (500B) via server 20. Recipient B (500B) does not have the authority to conclude a contract. At sender A (500A), this conclusion request is accepted by server 20.

The contract management module 2044 of the server 20 determines that the recipient B (500B) does not have the authority to enter into a contract based on the contractable user information 283. Here, the contract management module 2044 transfers the contract conclusion request to the recipient X (500X) in the same organization as the recipient B (500B). The recipient X belongs to the legal department, for example, and has the authority to enter into a contract. In response to receiving an operation to agree to the contract conclusion from the recipient B (500B) who does not have the authority to enter into a contract, the contract management module 20 records in the server 20 that the recipient B (500B) has performed the operation to agree, and notifies the recipient X (500X) who has the authority to enter into a contract whether or not he or she agrees to enter into the contract. The server 20 is configured to manage the status of whether or not the organization has finally agreed to the contract conclusion for each contract. Recipient X (500X), who has the authority to enter into a contract, accesses server 20 using a browser or the like to display on the recipient X (500X) terminal a list of contracts to which recipient B (500B), who does not have the authority, has agreed but which have not yet reached the status of final agreement to enter into a contract as an organization.

This transfer may be performed automatically by a transfer function provided in the contract conclusion processing module 2045 of the server 20, or may be performed by manual intervention in response to an instruction from the user prompted by the contract conclusion processing module 2045. Recipient X (500X), who has received the transfer, expresses his/her intention to agree to the transfer to sender A on behalf of recipient B (500B). Specifically, he/she presses the Agree button.

The example in Figure 10 achieves the effect of this embodiment of preventing unauthorized recipient B from concluding an agreement, while also avoiding confusion for the user and disruption of the contract conclusion flow.

As described above, the electronic contract system 1 according to this embodiment can prevent users of the electronic contract system, such as those belonging to an organization, from concluding electronic contracts without authorization. This embodiment can have a simple configuration, unlike systems that use electronic identification cards to verify identity when concluding an electronic contract. In addition, in systems that use electronic identification cards, it is expected that the acquisition and maintenance of the card will require time and effort for the screening process based on identity verification and the presentation of identification documents, and that fees will also be charged. However, this embodiment does not require such things and can be realized at low cost.

<5. Modifications>
Modifications of this embodiment will now be described.

(1) Authority by Domain The e-mail address of the contractable user information 283 may include domain information corresponding to an organization. If the domain information of the recipient specified by the sender user matches the domain information specified in advance, a notification requesting an electronic contract may be sent to the recipient user.

In this case, the pre-specified domain information may be, for example, a top-level domain in an organization, or a sub-domain that corresponds to a specific department within the organization. A specific example of such a sub-domain is the legal department. In the example of "Company B" described above, a sub-domain that corresponds to the legal department, for example, "legal.dnameB.jp", may be registered in the contractable user information 283.

This reduces the effort required to register the email addresses of each user eligible to enter into a contract, allows specific departments within an organization to be given the authority to enter into a contract all at once, and prevents contracts from being entered into by individuals who do not have the authority described in this embodiment.

(2) Modification of Data Structure (Contractable User Information)
The information for identifying the recipient may be recipient identification information linked to the email address instead of the email address. That is, the contractable user information 283 can be modified in various ways to be other information linked to the email address. The recipient identification information may be the above-mentioned user ID itself, or an ID managed by an external ID management system separate from the present system 1, and in either case, it is managed in the user information 281.

In this variant (2), the following two system examples are possible:

System example 1: The sender specifies an email address. The electronic contract system 1 determines whether the sender has authority based on the recipient's identification information.

System example 2: The sender specifies the recipient's identification information. The electronic contract system 1 determines whether the recipient has authority based on the email address.

(2-1) In system example 1, contractable user information 283 stores recipient identification information. The authority management module 2044 of the server 20 identifies an email address linked to the recipient identification information based on the user information 281. Next, the authority management module 2044 compares this identified email address with the email address specified by the sender to determine whether the sender has authority.

(2-2) In system example 2, the sender specifies the recipient identification information. The contractable user information 283 stores the email address.

The authority management module 2044 of the server 20 identifies the email address linked to the recipient identification information specified by the sender based on the user information 281. The authority management module 2044 then compares this identified email address with the email addresses stored in the contractable user information 283 to determine whether the user has authority.

In this way, the determination of authority is not limited to using an email address, but can be configured to use other identification information instead.

(3) Updating Information on Users Who Can Enter into a Contract An organization may have new employees and employees who resign. In response to an update to the database of employees of the organization, the information on users who can enter into an electronic contract (contractable user information 283) may be updated.

For example, the human resources and labor department of an organization updates a database that manages employee information (such as name, affiliation, and employee number). In response to a user's operation on terminal device 10B (or when the employee database managed by the organization's computer is updated or at regular intervals), server 20 may obtain information on email addresses of users who are able to conclude electronic contracts and update contractable user information 283.

For example, in response to an organization manager or the like specifying information on a retired employee, an employee on leave, or the like on the terminal device 10B, the server 20 may update the contractable user information 283 so as to revoke the authority to conclude a contract for the email address of the user. On the other hand, in response to an organization manager or the like specifying information on an employee who has newly joined a specific organization (e.g., the legal department, the business management department, etc.) or an employee who has taken up a new position (the organization manager, etc.) on the terminal device 10B, information such as the email address of the employee may be sent to the server 20. The server 20 may update the contractable user information 283 so as to grant the authority to conclude a contract for the email address of the user.

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

(Supplementary Note 1) An electronic contract program is provided that is executed by a computer (20) that includes a processor (29) and a memory (25). The electronic contract program causes the processor (29) to execute the steps of: storing in the memory (25) first information that identifies one or more recipients capable of concluding an electronic contract, the first information being an email address that identifies an organization and the individual recipient within the organization (S702); comparing the first information with information that identifies the recipient requesting the conclusion of a contract, designated by the sender; sending a notice requesting the conclusion of a contract to the recipient, if the comparison indicates that the requested recipient is capable of concluding an electronic contract; and suspending the conclusion of the electronic contract, regardless of the will of the recipient or the organization to which the recipient belongs, if the comparison indicates that the requested recipient does not have the authority to conclude an electronic contract (S705).

This makes it possible to prevent users of an electronic contract system, such as people belonging to an organization, from entering into electronic contracts without authorization, at low cost and with a simple configuration.

(Appendix 2) An electronic contract program described in (Appendix 1) in which the email address includes domain information corresponding to the organization.

(Appendix 3) An electronic contract program as described in (Appendix 2) that includes a step (S703) of sending a notification to the recipient requesting an electronic contract if the domain information of the recipient specified by the sender matches the domain information specified in advance.

(Appendix 4) An electronic contract program described in any one of (Appendix 1) to (Appendix 3), further including a step (S703) of outputting a message (300) indicating that the recipient does not have the authority to enter into an electronic contract.

(Appendix 5) An electronic contract program described in any one of (Appendix 1) to (Appendix 4), in which the information specifying the recipient is recipient identification information linked to the email address instead of the email address.

(Appendix 6) An electronic contract program described in (Appendix 5) that determines the presence or absence of authority by comparing the email address specified by the sender with the email address linked to the recipient identification information.

(Appendix 7) An electronic contract program described in (Appendix 5) that determines the presence or absence of authority by comparing an email address linked to the recipient identification information specified by the sender with an email address stored in memory.

(Appendix 8) An electronic contract program as described in any one of (Appendix 1) to (Appendix 7), further including a step of displaying (400) a person who has the authority to enter into an electronic contract and a person who does not have the authority to enter into an electronic contract, based on the first information.

(Appendix 9) An electronic contract program described in any one of (Appendix 1) to (Appendix 8), further including a step (S602) of receiving first information from a recipient and updating the memory (25).

10A, 10B terminal device, 12 communication IF, 13 input device, 14 output device, 15 memory, 16 storage unit, 19 processor, 20 server, 22 communication IF, 23 input/output IF, 25 memory, 26 storage, 29 processor, 80 network, 81 wireless base station, 82 wireless LAN base station, 130 operation reception unit, 132 display

Claims (3)

An electronic contract program executed by a computer having a processor and a storage unit,
The processor,
storing in the storage unit first information that identifies one or more recipients who are capable of concluding an electronic contract among users belonging to an organization, the first information being information that identifies the organization and the individual recipient within the organization;
A step of matching the first information with second information, which is information specifying a recipient belonging to the organization designated by the sender and for which a contract is requested;
sending a notification to the recipient requesting the recipient to enter into a contract when the matching has determined that the recipient has the authority to enter into the electronic contract;
a step of suspending the conclusion of the electronic contract, regardless of the intention of the recipient or the organization to which the recipient belongs, when it is determined by the comparison that the recipient related to the request does not have the authority to conclude the electronic contract;
When the conclusion of the electronic contract is suspended, notifying an administrator of the recipient's organization associated with the first information that the conclusion of the electronic contract has been suspended;
updating the first information stored in the storage unit by referring to a database that manages information on employees of the organization;
An electronic contract program that causes a computer to execute the above. An information processing method for causing an information processing device having a control unit and a storage unit to execute a process, the method comprising:
storing in the storage unit first information that identifies one or more recipients who are capable of concluding an electronic contract among users belonging to an organization, the first information being information that identifies the organization and the individual recipient within the organization;
A step of matching the first information with second information, which is information specifying a recipient belonging to the organization designated by the sender and for which a contract is requested;
sending a notification to the recipient requesting the recipient to enter into a contract when the matching has determined that the recipient has the authority to enter into the electronic contract;
a step of suspending the conclusion of the electronic contract, regardless of the intention of the recipient or the organization to which the recipient belongs, when it is determined by the comparison that the recipient related to the request does not have the authority to conclude the electronic contract;
When the conclusion of the electronic contract is suspended, notifying an administrator of the recipient's organization associated with the first information that the conclusion of the electronic contract has been suspended;
updating the first information stored in the storage unit by referring to a database that manages information on employees of the organization;
An information processing method for executing the above. An information processing device including a control unit and a storage unit,
storing in the storage unit first information that identifies one or more recipients who are capable of concluding an electronic contract among users belonging to an organization, the first information being information that identifies the organization and the individual recipient within the organization;
A step of matching the first information with second information, which is information specifying a recipient belonging to the organization designated by the sender and for which a contract is requested;
sending a notification to the recipient requesting the recipient to enter into a contract when the matching has determined that the recipient has the authority to enter into the electronic contract;
a step of suspending the conclusion of the electronic contract, regardless of the intention of the recipient or the organization to which the recipient belongs, when it is determined by the comparison that the recipient related to the request does not have the authority to conclude the electronic contract;
When the conclusion of the electronic contract is suspended, notifying an administrator of the recipient's organization associated with the first information that the conclusion of the electronic contract has been suspended;
updating the first information stored in the storage unit by referring to a database that manages information on employees of the organization;
An information processing device that executes the above.