Electronic contract program, information processing apparatus, and information processing method

Abstract

To provide an electronic contract program, an information processing apparatus, and an information processing method for preventing, with simple arrangement, a person belonging to an organization from entering into an electronic contract without any authority.SOLUTION: An electronic contract program according to the present invention causes a processor of a server to execute: a step of storing, in a memory, first information for use in specifying one or a plurality of receivers who can enter into an electronic contract and serving as an electronic mail address for use in identification of an organization and an individual receiver in the organization; a step of collating information designated by a sender for use in specifying a receiver who is requested to enter into a contract and the first information; a step of, through the collation, if the requested receiver has authority to enter into an electronic contract, transmitting notification to the receiver to request for entering in an electronic contract; and a step of, through the collation, if the requested receiver has no authority to enter into an electronic contract, stopping entering into the electronic contract regardless of intention of the receiver or the organization to which the receiver belongs.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to an electronic contract program, an information processing device, and an information processing method. [Background technology]

[0002] There is technology that allows contracts to be concluded by exchanging electronic data of contracts over the Internet and applying electronic signatures, and then storing the electronic data on a company's server or cloud storage.

[0003] 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 verified when entering into an electronic contract by displaying the user's identity to the other party. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Special Publication No. 2014-529371 Summary of the Invention [Problem to be solved by the invention]

[0005] However, if 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 management of electronic identification cards becoming cumbersome, (2) the reliability of the electronic identification cards themselves, and (3) the cost of acquiring and maintaining the electronic identification cards.

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

[0007] Furthermore, from the perspective of the other party entering into a contract, they will have to determine for themselves whether the identity recorded on the electronic identification card is genuine and will decide at their own risk whether or not to enter into an electronic contract with the cardholder. Even if the electronic identification card is trustworthy, there is a possibility that the person in question may enter into an electronic contract without having the authority to do so, and it is necessary to prevent this.

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

[0009] Therefore, the present disclosure aims to provide another technology that can prevent users of an electronic contract system, such as those belonging to an organization, from concluding electronic contracts without authorization using a simple configuration and at low cost. [Means for solving the problem]

[0010] According to one embodiment, there is provided an electronic contract program 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 identifying one or more recipients capable of concluding an electronic contract, the first information being information identifying an organization and an email address identifying the individual recipient within the organization; comparing the first information with information identifying the recipient designated by the sender and requesting contract conclusion; sending a notice to the recipient requesting contract conclusion 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 is not authorized to conclude an electronic contract. [Effects of the Invention]

[0011] 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. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram showing the overall configuration of an electronic contract system 1. [Figure 2] 1 is a block diagram of a terminal device 10 constituting an electronic contract system 1 according to a first embodiment. [Figure 3] FIG. 2 is a diagram showing the functional configuration of a server 20. [Figure 4] FIG. 1 is a conceptual diagram for explaining an electronic contract. [Figure 5] 3 is a diagram showing the structure of data stored in the server 20. FIG. [Figure 6] 10 is a flowchart showing a process for registering a person who can conclude an electronic contract. [Figure 7] 10 is a flowchart showing a process for requesting an electronic contract. [Figure 8] FIG. 10 is a diagram showing an example of a screen displayed when canceling a request for an electronic contract to an unauthorized recipient. [Figure 9] FIG. 10 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. [Figure 10] FIG. 10 is a diagram for explaining the transfer of an electronic contract request depending on the presence or absence of authority. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. In the following description, the same components are denoted by the same reference numerals. The names and functions of the components are also the same. Therefore, detailed description thereof will not be repeated.

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

[0015] As shown in Fig. 1, the electronic contract system 1 includes a plurality of terminal devices (Fig. 1 shows terminal device 10A and terminal device 10B; hereinafter, these 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.

[0016] 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. Alternatively, the terminal device 10 may be, for example, a desktop personal computer (PC) 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.

[0017] The terminal device 10 is communicatively connected to the server 20 via a network 80. The terminal device 10 is connected to the network 80 by communicating with communication devices such as a wireless base station 81 conforming to communication standards such as 5G and LTE (Long Term Evolution), and a wireless LAN router 82 conforming to a wireless LAN (Local Area Network) standard such as IEEE (Institute of Electrical and Electronics Engineers) 802.11.

[0018] 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 (e.g., 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 an HDD (Hard Disc Drive). The processor 19 is hardware for executing an instruction set written in a program, and is composed of an arithmetic unit, registers, peripheral circuits, etc.

[0019] 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 receiving 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 an HDD (Hard Disc Drive). The processor 29 is hardware for executing an instruction set written in a program, and is composed of an arithmetic unit, registers, peripheral circuits, etc.

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

[0021] <1.1 Configuration of the 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 multiple antennas (antenna 111, antenna 112), wireless communication units (first wireless communication unit 121, second wireless communication unit 122) corresponding to the respective antennas, 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 memory unit 180, and a control unit 190. The terminal device 10 also has functions and configurations not specifically shown in FIG. 2 (e.g., a battery for storing power, a power supply circuit for controlling the supply of power from the battery to each circuit, etc.). The blocks included in the terminal device 10 are electrically connected by a bus or the like.

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

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

[0024] The first wireless communication unit 121 performs modulation / 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 / 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, etc. The first wireless communication unit 121 and the second wireless communication unit 122 perform modulation / 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.

[0025] The operation reception unit 130 has a mechanism for receiving input operations from a 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 may also be configured as a touch screen and include a touch-sensitive device 131 and a display 132. The touch-sensitive device 131 receives input operations from a 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.

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

[0027] The audio processing unit 140 modulates and demodulates audio signals. The audio processing unit 140 modulates a signal provided from 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 from the audio processing unit 140 into audio and outputs the audio to the outside of the terminal device 10.

[0028] 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. The satellite positioning system receives signals from at least three or four satellites, and detects the current position of the terminal device 10 equipped with the GPS module based on the received signals.

[0029] The camera 160 is a device that receives light with a light receiving element and outputs the received light as a captured image. The camera 160 is, for example, a depth camera that can detect the distance from the camera 160 to a subject being photographed.

[0030] The storage unit 180 is configured, for example, with a flash memory or the like, 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 users who use the electronic contract system 1.

[0031] The control unit 190 reads a program stored in the storage unit 180 and executes instructions included in the program to control the operation of the terminal device 10. The control unit 190 is, for example, an application processor. By operating in accordance with 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.

[0032] Input operation reception unit 191 performs processing to receive a user's input operation on an input device such as touch-sensitive device 131. Based on information about the coordinates where the user has touched touch-sensitive device 131 with a finger or the like, 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.

[0033] The transmitting / receiving unit 192 performs processing for the terminal device 10 to transmit and receive data in accordance with a communication protocol to and from an external device such as the server 20. The data processing unit 193 performs processing for performing calculations on data received as input by the terminal device 10 in accordance with a program and outputting the calculation results to a memory or the like.

[0034] The data processing unit 193 performs calculations on data that the terminal device 10 has received as input in accordance with a program, and outputs the calculation results to a memory or the like.

[0035] The notification control unit 194 performs processing to notify the user of information through the five senses, such as hearing and sight. 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 in the vibrator.

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

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

[0038] 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, and the like.

[0039] The user information 281 is a database for storing information about users of the electronic contract system 1.

[0040] The organization information 282 is information indicating the organization (for example, a business organization such as a company) to which the user who is making the electronic contract belongs.

[0041] The contractable user information 283 is information indicating the person who has the authority to conclude an electronic contract in each organization to which the user belongs.

[0042] The notification information 284 is information relating to a request for the conclusion of an electronic contract, and is information for managing the date and time when the request was notified in association with the contract.

[0043] The contract information 285 is information indicating the state of agreement between the sender and receiver on the conclusion of an electronic contract, the contents of the electronic contract, and the like.

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

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

[0046] 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. Furthermore, an "electronic signature" refers to a mechanism for indicating the creator of electronic data and certifying that the electronic data has not been tampered with, as defined in Article 2, Paragraph 1 of the Electronic Signatures Act.

[0047] First, the contract sender operates terminal device 10A to upload the electronic data of the contract to, for example, server 20 on the cloud. Terminal device 10 receives an operation from the user of terminal device 10 indicating agreement to the contract. Server 20 affixes the contract sender's digital signature to the electronic data of the contract agreed to by the contract sender.

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

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

[0050] If the contract recipient agrees, the contract recipient's digital signature is added to the electronic data of the contract. The electronic data of the contract is stored on the server 20. Adding digital signatures from both contracting parties prevents the contract from being tampered with.

[0051] This embodiment realizes such a cloud-based electronic contract service. In the following embodiment, a technology for preventing a person belonging to an organization from concluding an electronic contract without authorization will be described.

[0052] For this reason, the authority management module 2044 of the server 20 (see Figure 3) manages information on persons who are authorized to enter into contracts within the organization (i.e., what is referred to as authority information in this embodiment), and performs processing to prevent persons who do not have the authority from entering into agreements.

[0053] The contract conclusion processing module 2045 is responsible for all electronic contract processing other than the above-mentioned authority management. 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.

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

[0055] As shown in FIG. 5, each record of the user information 281 includes an item "ID," an item "user name," an item "organization ID," and the like, for each piece of information that identifies a user.

[0056] 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, receiver, or organizational administrator). The "user name" item is display information such as the name of the user ID. The "organization ID" item is the organization ID in the organization information 282, and the user information 281 is associated with the organization information 282 by this organization ID.

[0057] 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 regarding the use of services provided by the electronic contract system 1 of this embodiment.

[0058] Each piece of organization information 282 includes an item "ID", an item "organization name", etc. The item "ID" is information (organization ID) that identifies each piece of organization information 282. One row in the table of organization information 282 identified by the organization ID represents one 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.

[0059] In addition to the examples shown in the figure, organizational information 282 may also include information specific to the organization, such as 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 services provided by the electronic contract system 1 of this embodiment.

[0060] Each of the contractable user information 283 includes an item "ID", an item "email address", and the like.

[0061] The item "ID" is information (contractable user ID) that identifies each contractable user information 283. One row in the table of contractable user information 283 identified by the contractable user ID represents one email address of a person (sometimes called a "contractable user") who is able to conclude an electronic contract in the organization.

[0062] 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 are eligible to conclude electronic contracts, identified by the item "ID", is added.

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

[0064] Each piece of notification information 284 includes an item "ID", an item "sender ID", an item "receiver ID", an item "request notification date and time", an item "contract ID", and the like.

[0065] 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 the system 1.

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

[0067] Each of the contract information 285 includes an item "ID", an item "sender ID", an item "sender agreement", an item "receiver ID", an item "receiver agreement", an item "contract details", and the like.

[0068] 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 the present system 1.

[0069] 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 (unsettled).

[0070] The "Receiver ID" item is the user ID of the user (i.e., the receiver) who accepts the request for contract agreement through notification from the sender. The "Receiver Agreement" item indicates whether the receiver indicated in the "Receiver ID" item has agreed to the content of the contract (i.e., the contract) or not (unsettled).

[0071] The item "Contract Content" is information detailing the contract content, such as the title and terms of the contract, etc. Although not shown, it also includes link information to the contract and the actual electronic data of the contract.

[0072] <3 operations> 6 is a flowchart showing the process of registering persons who can conclude an electronic contract. This registration is performed in advance by the user in the electronic contract system 1 according to this embodiment before entering into a contract using the system 1.

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

[0074] 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 entered in step S601, and registers it in the contract-eligible user information 283 in the memory unit 202.

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

[0076] In this example, "Nzawa Tyuki" of "Corporation B" is not registered in the contractable user information 283 and does not have the authority to conclude an electronic contract.

[0077] 7 is a flowchart showing the process of requesting an electronic contract. In the following explanation, it is assumed that the contract is concluded between the terminal device 10A of the user on the sending side, which is the trigger for concluding the contract, and the terminal device 10B of the user on the receiving side, via the server 20.

[0078] 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, which has been specified by the sender's user.

[0079] In step S702, the authority management module 2044 of the server 20 compares the recipient user specified on the sender's terminal device 10A with the information of recipient users who are able to conclude 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-eligible user information 283 of the server 20.

[0080] In step S703, if the authority management module 2044 of the server 20 determines, through the comparison in step S702, that there is a match with the email address registered in the contract-eligible user information 283 (if there is a match in step S702), it determines that the recipient user who has been requested to conclude a contract is able to conclude an electronic contract. The server 20 sends a notification requesting the conclusion of the contract to the recipient's terminal device 10B. This is done, for example, 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 terminal device 10B, and records information regarding the notification in the notification information 284.

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

[0082] In step S705, if the comparison in step S702 above shows that the email address of the recipient specified by the sender does not exist in the list of email addresses registered in the contractable user information 283 of the server 20 (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 conclude an electronic contract. The server 20 suspends the conclusion of the electronic contract. This suspension can be carried out regardless of the intentions of the recipient or the organization to which the recipient belongs.

[0083] When suspending the electronic contract, the server 20 may identify the user (e.g., administrator) of the organization associated with the email address based on the domain information 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 (for example, by sending the notification to the administrator's email address). This allows the administrator of the recipient's organization to recognize that the user with the email address designated by the sending user does not have the authority to conclude a contract, and that there has been business activity attempting to conclude a contract with the sending user's organization, making the management of electronic contracts even easier.

[0084] 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 may also send a reminder or other notification 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 (for example, by asking the recipient user to assign a user who has the authority to enter into a contract).

[0085] In step S706, the sender's terminal device 10A notifies the sender's user on the display 132, etc., that the recipient user does not have 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 the recipient user has authority to conclude an electronic contract. The terminal device 10A accepts, from the sender's user, an operation to re-designate a recipient user who is able to conclude an electronic contract, an operation to cancel the contract itself, etc.

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

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

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

[0089] 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. / Ms. Nzawa Tyuki (nishi@dnameB.jp) does not have the authority to enter into a contract, so processing cannot continue."

[0090] The sender, "M Akira, M under M," can only press the OK button 300B to confirm this message, and cannot continue processing the request.

[0091] FIG. 9 is a diagram showing an example of a screen displaying a list of recipient users who can conclude an electronic contract and those who cannot.

[0092] As shown in the example screen in Figure 9, when a sender requests a receiver to enter into an electronic contract, the sender may specify 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 enter into a contract will be made public to other organizations. For example, information about users who have the authority to enter into a contract in a certain organization may be made public to a specific company (e.g., a contract between group companies).

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

[0094] Since this sender requests the conclusion of an agreement at "Company B," a dialog screen 400 may be displayed when the receiver is designated.

[0095] Dialog screen 400 displays message 400A, which reads "Person who can conclude a contract with B Co., Ltd.: Yguchi Jko (yama@dnameB.jp)..." and "Person who does not have the authority to conclude a contract: Nzawa Tyuki (nishi@dnameB.jp)...."

[0096] Here, the sender can select "Yguchi Jko (yama@dnameB.jp)" with whom a contract can be concluded at "Co. B" by pressing selection button 400B.

[0097] The example screen shown in Figure 8 allows the sender to cancel a request for an electronic contract to an unauthorized recipient, while the example screen shown in Figure 9 clearly indicates to the sender whether or not 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 or not the recipient to whom the contract is 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 Figure 10.

[0098] Sender A (500A) requests recipient B (500B) to conclude an electronic contract via server 20. Recipient B (500B) does not have the authority to conclude a contract. This request for conclusion is received by server 20 from sender A (500A).

[0099] 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 contract-eligible user information 283. Here, the contract management module 2044 transfers the contract entry 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 entry 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 enter into the contract for each contract. A recipient X (500X) who has the authority to enter into a contract accesses the 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.

[0100] 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 manually in response to a user instruction 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.

[0101] 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 delays in the contract conclusion flow.

[0102] As described above, the electronic contract system 1 according to this embodiment can prevent unauthorized electronic contracts between users of the electronic contract system, such as those belonging to an organization. This embodiment, unlike systems that require identity verification based on an electronic identification card when concluding an electronic contract, can simplify the configuration. Furthermore, in systems that use electronic identification cards, obtaining and maintaining the card requires time and effort for identity verification and the screening process based on the presentation of identification documents, and fees may also be charged. However, this embodiment eliminates these issues and can be implemented at low cost.

[0103] <5 Variations> A modification of this embodiment will now be described.

[0104] (1) Domain authority The email address in the contractable user information 283 may include domain information corresponding to the 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.

[0105] In this case, the pre-specified domain information may be, for example, a top-level domain in an organization or a subdomain corresponding to a specific department within the organization. A specific example of such a subdomain is the legal department. In the example of "Corporation B" mentioned above, a subdomain corresponding to the legal department, for example, "legal.dnameB.jp", may be registered in the contractable user information 283.

[0106] This reduces the effort required to register the email addresses of each user eligible for contracts, allows specific departments within an organization to be given the authority to enter into contracts in one go, and also prevents contracts from being entered into by persons who do not have the authority required in this embodiment.

[0107] (2) Data structure modification (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 different information linked to the email address. The recipient identification information may be the above-mentioned user ID itself, or an ID managed in an external ID management system separate from the present system 1, and in either case, it is managed in the user information 281.

[0108] In this modified example (2), the following two system examples are possible.

[0109] System Example 1: The sender specifies an email address. The electronic contract system 1 determines whether or not the sender is authorized based on the recipient's identification information.

[0110] System Example 2: The sender specifies the recipient's identification information. The electronic contract system 1 determines whether or not the recipient is authorized based on the email address.

[0111] (2-1) In system example 1, the 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 is authorized.

[0112] (2-2) In the system example 2, the sender specifies the recipient identification information. The contractable user information 283 stores the e-mail address.

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

[0114] In this way, the determination of whether or not authority exists is not limited to the use of an email address, and other identification information can be used instead.

[0115] (3) Update of information on eligible users An organization may have new employees joining it, or employees retiring. Therefore, in response to an update to the organization's employee database, the information on users who are eligible to enter into electronic contracts (contractable user information 283) may be updated.

[0116] For example, the human resources department of an organization updates a database that manages employee information (such as names, affiliations, and employee numbers). The server 20 may acquire information on email addresses of users who are eligible to enter into electronic contracts and update the contractable user information 283 in response to a user's operation on the terminal device 10B (or whenever the employee database managed by the organization's computer is updated or at regular intervals).

[0117] For example, in response to an organization administrator or the like specifying information about 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 that user. Meanwhile, in response to an organization administrator or the like specifying information about an employee who has newly joined a specific organization (for example, a legal department, a business management department, or the like) or an employee who has taken on a new position (an organization administrator, or the like) on the terminal device 10B, information such as the email address of that employee may be transmitted 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 that user.

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

[0119] (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 following steps: storing in the memory (25) first information (S702), the first information being information that identifies one or more recipients capable of concluding an electronic contract and 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, as specified by the sender; sending a notice requesting the conclusion of the 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 is not authorized to conclude an electronic contract.

[0120] This makes it possible to prevent users of an electronic contract system, such as people belonging to an organization, from concluding electronic contracts without authorization, using a simple configuration at low cost.

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

[0122] (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.

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

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

[0125] (Appendix 6) An electronic contract program described in (Appendix 5) that determines whether or not the sender has authority by comparing the email address specified by the sender with the email address linked to the recipient identification information.

[0126] (Appendix 7) An electronic contract program as described in (Appendix 5) that determines whether or not authority exists by comparing the email address linked to the recipient identification information specified by the sender with the email address stored in memory.

[0127] (Appendix 8) An electronic contract program as described in any of (Appendix 1) to (Appendix 7), further comprising a step of displaying (400) a distinction between persons authorized to enter into electronic contracts and persons not authorized to enter into electronic contracts based on the first information.

[0128] (Supplementary Note 9) The electronic contract program according to any one of (Supplementary Note 1) to (Supplementary Note 8), further comprising a step (S602) of receiving first information from a recipient and updating the memory (25). [Explanation of symbols]

[0129] 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

1. An electronic contract program executed by a computer having a processor and a memory, the processor, storing in the memory first information identifying one or more recipients with whom an electronic contract can be entered into, the first information being an organization and an email address identifying the individual recipient within the organization; a step of matching the first information with information specified by the sender that identifies the recipient to whom a contract is requested to be concluded; If the recipient of the request is able to enter into the electronic contract as a result of the verification, sending a notice to the recipient requesting the recipient to enter into the 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, if the verification reveals that the recipient according to the request does not have the authority to conclude the electronic contract; An electronic contract program that causes a computer to execute the above.

2. The electronic contract program according to claim 1 , wherein the email address includes domain information corresponding to the organization.

3. 3. The electronic contract program of claim 2, further comprising a step of sending a notification to the recipient requesting the electronic contract if the domain information of the recipient specified by the sender matches pre-specified domain information.

4. 4. The electronic contract program according to claim 1, further comprising the step of outputting a message indicating that the recipient is not authorized to enter into an electronic contract.

5. 5. The electronic contract program according to claim 1, wherein the information for identifying the recipient is recipient identification information linked to the email address instead of the email address.

6. The electronic contract program according to claim 5, wherein the authority is determined by comparing the email address specified by the sender with the email address linked to the recipient identification information.

7. The electronic contract program of claim 5, wherein the authority is determined by comparing an email address linked to the recipient identification information specified by the sender with an email address stored in the memory.

8. An electronic contract program as described in any one of claims 1 to 7, further comprising a step of distinguishing and displaying persons who have the authority to enter into an electronic contract from persons who do not have the authority to enter into an electronic contract based on the first information.

9. 9. The electronic contract program according to claim 1, further comprising the step of accepting the first information from the recipient and updating the memory.

10. An information processing device including a control unit and a memory, The control unit storing in the memory first information identifying one or more recipients with whom an electronic contract can be entered into, the first information being an organization and an email address identifying the individual recipient within the organization; a step of matching the first information with information specified by the sender that identifies the recipient to whom a contract is requested to be concluded; If the recipient of the request is able to enter into the electronic contract as a result of the verification, sending a notice to the recipient requesting the recipient to enter into the 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, if the verification reveals that the recipient according to the request does not have the authority to conclude the electronic contract; An information processing device that executes the above.

11. storing first information identifying one or more recipients with whom electronic contracts can be concluded, the first information being an organization and an email address identifying the recipient individual within the organization; a step of matching the first information with information specified by the sender that identifies the recipient to whom a contract is requested to be concluded; If the recipient of the request is able to enter into the electronic contract as a result of the verification, sending a notice to the recipient requesting the recipient to enter into the 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, if the verification reveals that the recipient according to the request does not have the authority to conclude the electronic contract; An information processing method including:

Images