Information processing device, method, program

Abstract

In the trading of goods and services, there is a need for technology that facilitates matching between sellers and buyers, while also providing both parties with information to help them decide which trading partner to choose, thereby promoting the completion of transactions. [Solution] The program causes one or more computer processors to perform the following steps: acquire information on the content of a transaction that each of several users wishes to be either a seller or a buyer in a transaction; extract a first user who will be a seller and a second user who will be a buyer based on the information on the content of the transaction that each user wishes to be in a transaction with; make the information on the content of the transaction that each extracted user wishes to be in a transaction with mutually viewable among the extracted users; and accept the specification of the transaction content to be traded among the extracted users and complete the transaction.

Description

Technical Field

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

[0002] There are services that support user transactions. For example, there are services that compare selling prices on electronic commerce platforms. This allows users to select a transaction partner based on price when purchasing products or the like. Further, as a service that supports transactions between users, there are also services that match sellers who list products with buyers who purchase the listed items.

[0003] Patent Document 1 points out that the problem is "enabling users to receive urgent notification emails earlier in an auction service via a network", and as means for solving the problem, it describes that "in an auction system using a network, user data including status data and user ID data, as well as pre-purchase point data and past transaction evaluation data associated with the user ID data are registered in a user database", and "in response to a status change request from a user, the status data of the user data is changed without losing the association between the user ID data and the pre-purchase point data and transaction evaluation data". Patent Document 1 states that with these configurations, "even if a status change between an individual and a legal entity is performed, the pre-purchase points and transaction evaluation data previously owned can be maintained, thereby improving the convenience of status change. Further, such a status change function can contribute to the activation and soundness of auction venues". Prior Art Documents Patent Documents

[0004] Patent Document 1 Japanese Unexamined Patent Publication No. 2001-043690 [Overview of the project] [Problems that the invention aims to solve]

[0005] As mentioned above, while the platform facilitates matching buyers and sellers of goods and services, from the seller's perspective, the buyer's information may be limited to past purchase history and buyer ratings. Furthermore, since the seller's selling price is fixed and the purchase is completed once the buyer completes the transaction, the buyer's ability to judge whether the trading partner is reasonable is also limited.

[0006] Therefore, in the trading of goods and services, there is a need for technology that facilitates the matching of buyers and sellers, provides both buyers and sellers with information to help them decide which trading partner to choose, and ultimately promotes the completion of transactions. [Means for solving the problem]

[0007] According to one embodiment, a program is provided for operating a computer having one or more computer processors. The program causes one or more computer processors to perform the following steps: acquire information on the content of a transaction that each of several users wishes to be at least one of either the seller or the buyer of the transaction; extract a first user who will be the seller and a second user who will be the buyer based on the information on the content of the transaction that each user wishes to be involved in; make the information on the content of the transaction that each extracted user wishes to be involved in mutually viewable among the extracted users; and accept the specification of the transaction content to be traded among the extracted users and complete the transaction. [Effects of the Invention]

[0008] According to this disclosure, by making it possible for each user to view the details of the transactions they wish to conduct, it is possible to provide each user with information to help them decide whether to engage in a transaction with that person, thereby further promoting the completion of transactions. [Brief explanation of the drawing]

[0009] [Figure 1] Figure 1 shows the configuration of System 1. [Figure 2] Figure 2 shows the configuration of server 20. [Figure 3] Figure 3 shows the configuration of terminal 10. [Figure 4] Figure 4 shows the data structure of the user database 211. [Figure 5] Figure 5 shows the data structure of the wish list database 212. [Figure 6] Figure 6 shows the data structure of the transaction history database 213. [Figure 7] Figure 7 shows the data structure of the review history database 214. [Figure 8] Figure 8 shows the data structure of the contract management database 215. [Figure 9] Figure 9 shows the data structure of the document management database 216. [Figure 10] Figure 10 shows the process flow for retrieving the details of transactions that each user wishes to conduct as a seller or buyer and generating a list. [Figure 11] Figure 11 shows the process flow for matching users based on a list of items they wish to trade as either a seller or a buyer, and for accepting the operations related to the transaction. [Figure 12] Figure 12 shows the process flow for concluding a contract through payment of consideration for the transaction. [Figure 13] Figure 13 shows an example of an operation screen that accepts user-to-user transactions based on a list of items that users wish to trade as either a seller or a buyer. [Modes for carrying out the invention]

[0010] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In all drawings illustrating the embodiments, common components are denoted by the same reference numerals, and repeated description is omitted. Note that the following embodiments do not unreasonably limit the content of the present disclosure described in the claims. In addition, not all of the components shown in the embodiments are essential components of the present disclosure. Furthermore, each drawing is a schematic diagram, and is not necessarily strictly illustrated.

[0011] Also, in the following description, a "processor" is one or more processors. At least one processor is typically a microprocessor such as a CPU (Central Processing Unit), but may also be another type of processor such as a GPU (Graphics Processing Unit). The at least one processor may be single-core or multi-core.

[0012] Also, the at least one processor may be a processor in a broad sense such as a hardware circuit (e.g., FPGA (Field-Programmable Gate Array) or ASIC (Application Specific Integrated Circuit)) that performs part or all of the processing.

[0013] Also, in the following description, expressions such as "xxx table" may be used to describe information that yields an output in response to an input, but this information may be data of any structure, or may be a learning model such as a neural network that generates an output corresponding to an input. Accordingly, "xxx table" may also be referred to as "xxx information".

[0014] Also, in the following description, the configuration of each table is an example; one table may be divided into two or more tables, and all or part of two or more tables may be combined into one table.

[0015] In addition, in the following description, processing may be described with a "program" as the subject. However, since a program is executed by a processor to perform predetermined processing while appropriately using a storage unit and / or an interface unit or the like, the subject of the processing may be the processor (or a device such as a controller including the processor).

[0016] The program may be installed in a device such as a computer, or may be stored in, for example, a program distribution server or a computer-readable (e.g., non-transitory) recording medium. In addition, in the following description, two or more programs may be implemented as a single program, and a single program may be implemented as two or more programs.

[0017] In addition, in the following description, identification numbers are used as identification information for various objects, but other types of identification information (for example, identifiers including alphabetic characters and codes) may be employed instead of identification numbers.

[0018] In addition, in the following description, reference signs (or common codes among reference signs) are used when describing elements of the same type without distinguishing them, and identification numbers (or reference signs) of the elements may be used when describing elements of the same type with distinction.

[0019] In addition, in the following description, control lines and information lines are those considered necessary for explanation, and not all control lines and information lines are necessarily shown in the product. All configurations may be mutually connected.

[0020] <Outline of Embodiment> Embodiments will be described below.

[0021] <First Embodiment> <1.1 Configuration Diagram of Entire System> FIG. 1 is a diagram showing the configuration of system 1.

[0022] System 1, shown in Figure 1, includes a contract signing and document management service server 20, a user terminal 10, a business support system service server 92, a document review service server 93, an artificial intelligence (large-scale language model) service server 95, a document creation service server 96, a sales support system service server 97, and a messaging service server 98. These devices communicate with each other via a network 80.

[0023] In the illustrated example, terminal 10 is shown as the terminal used by users of the contract signing and document management service provided by server 20, but each user operates their own terminal.

[0024] Server 20 is a device that provides services for concluding contracts electronically and for managing document data concluded electronically. It should be noted that in System 1, the contract conclusion service provided by Server 20 and the document data management service may be provided by separate devices or different service providers. For example, Server 20 provides a document management service and, in addition to electronically signed contract data, may also optically scan paper contracts with seals to extract information such as the contract period and whether the contract is automatically renewed, and manage this information along with the scanned contract data. This allows for notifications to be sent to the user when the contract period expires.

[0025] Server 20 may also be a server that provides services to support tasks such as submitting approval requests to organizations (business companies, etc.) that conduct business activities. For example, Server 20 provides a service to users that enables them to design a workflow for obtaining budget approval with multiple users.

[0026] Terminal 10 is a device operated by the user.

[0027] The business support system service server 92 provides users with tools that can be used for the organization's business operations. The business support system service server 92 provides users with a system for submitting approval requests as part of the organization's business operations. The business support system service server 92 may also communicate with server 20 to provide server 20 with data accumulated by the approval request service.

[0028] The document review service server 93 accepts document data such as contracts and term sheets that define contract terms, and provides users with information on whether each clause is advantageous or disadvantageous to the company, whether there are any missing clauses, and the importance of the review items, thereby supporting the review of the document data. The document review service server 93 provides the above review support service using rule-based or pre-trained models. As a rule-based approach, for example, it may be possible to perform rule-based reviews of document data by associating specific wording or expressions with pre-defined information on whether the conditions are advantageous or disadvantageous, and explanations. Alternatively, for example, it may be possible to provide the above review service by generating a pre-trained model that responds with review results to document data input, using data from expert reviews of contracts, term sheets, etc., as training data. Furthermore, the document review service server 93 can also summarize the contents of contracts and generate review comments using a large-scale language model, and provide the results to the user. For example, the document review service server 93 may prompt the large-scale language model service server 95 with the document data to be reviewed (such as contract data) and information indicating the review criteria, and instruct the server 95 to perform the review according to the review criteria. By receiving the output of the large-scale language model service server 95, the server 93 may generate review comments for the document data. The document review service server 93 may also communicate with server 20 to provide the server 20 with data accumulated by the document review service.

[0029] Server 95 of the Large-Scale Language Model Service is a server that executes language processing tasks using language models built through learning processes including artificial intelligence (AI). An LLM (Large Language Model) is a model that has been pre-trained on large amounts of data (such as text data), for example, a large amount of web content on the internet, or a large amount of data stored in a designated database, and can perform various language processing tasks by being given a task.

[0030] The AI ​​service server 95 (sometimes referred to as the "large-scale language model service server 95") accepts prompt input in the form of text, images, audio, etc., and generates and responds with answers to those prompts. Examples of LLMs include GPT-3, GPT-4, and GPT-4o developed by OpenAI, and Gemini developed by Google.

[0031] The document creation service server 96 provides a service for managing document data such as meeting minutes in organizations conducting business activities. Server 96 can issue URLs (Uniform Resource Locators) for accessing document data, and for example, if the user account of a user of the document creation service has access rights to the document data, the document data can be accessed via the URL. The document creation service server 96 may also be linked with a server that provides a schedule management service with calendar functionality, so that user accounts are common to both services. For example, having a user account may allow access to both the schedule management service and the document creation service. In this case, if document data from the document creation service is associated with a schedule, access rights to that document data may be set for users participating in the schedule.

[0032] The document creation service server 96 may communicate with server 20 to provide server 20 with data accumulated by the document creation service.

[0033] The sales support system service server 97 provides services to support sales activities. For example, the sales support system service server 97 provides the following to the user: • For each sales project, manage information such as the client, transaction details (amount, goods), transaction history (memos, meeting minutes, etc.), and responsible person (our company, the other party, etc.). • Provide analysis results of sales performance for each sales team (e.g., trends in closing rates). The server 97 of the sales support system service may communicate with the server 20 to provide the server 20 with the data accumulated by the sales support system service.

[0034] The messaging service server 98 provides users with a service that allows them to send and receive various types of messages, such as text and files, between users. The service provided by the messaging service server 98 may be an SNS-type service in which an unspecified number of users can participate. In an SNS, users may be able to view posts from other users even if they do not follow them, or they may be able to view posts by following other users. Accounts may also be issued in association with information issued after identity verification, such as a phone number. Furthermore, it may be a service in which members of an organization can participate, or it may provide email sending and receiving functionality. Furthermore, users may send and receive messages one-on-one, or multiple users may form a group (sometimes called a channel) to send and receive messages. Each user may be able to post replies to each user's post in a thread format.

[0035] The messaging service server 98 may issue a unique URL for each message posted by each user, allowing other services to access each user's posts via that URL.

[0036] In this embodiment, each device (terminal device, server, etc.) can also be considered as an information processing device. That is, the collection of each device can be considered as a single "information processing device," and System 1 may be formed as a collection of multiple devices. The way in which the multiple functions required to realize System 1 according to this embodiment are distributed to one or more hardware can be appropriately determined in view of the processing capacity of each hardware and / or the specifications required for System 1.

[0037] Terminal 10 can be implemented, for example, as follows: • Handheld mobile devices such as smartphones and tablets • Stationary PCs (Personal Computers), Laptop PCs • Wearable devices worn by the user (watch-type, glasses-type, etc.) Terminal 10 includes a communication interface (IF) 12, an input device 13, an output device 14, memory 15, storage 16, and a processor 19.

[0038] The communication interface 12 is an interface for inputting and outputting signals so that terminal 10 can communicate with an external device.

[0039] The input device 13 is a device for receiving input operations from the user (for example, a touch panel, touchpad, pointing device such as a mouse, keyboard, etc.).

[0040] The output device 14 is a device (such as a display or speaker) for presenting information to the user.

[0041] Memory 15 is for temporarily storing programs and data processed by programs, etc., and is a volatile memory such as DRAM (Dynamic Random Access Memory).

[0042] Storage 16 is for storing data, and can be, for example, flash memory or an HDD (Hard Disk Drive).

[0043] The processor 19 is hardware for executing the instruction set described in the program, and consists of an arithmetic unit, registers, peripheral circuits, etc.

[0044] The server 20 includes a communication interface 22, an input / output interface 23, memory 25, storage 26, and a processor 29.

[0045] Communication IF22 is an interface for inputting and outputting signals so that the server 20 can communicate with external devices.

[0046] Input / Output IF23 functions as an interface between an input device for receiving user input operations and an output device for presenting information to the user.

[0047] Memory 25 is for temporarily storing programs and data processed by programs, etc., and is a volatile memory such as DRAM (Dynamic Random Access Memory).

[0048] Storage 26 is for storing data, and can be, for example, flash memory or an HDD (Hard Disk Drive).

[0049] The processor 29 is hardware for executing the instruction set described in the program, and consists of an arithmetic unit, registers, peripheral circuits, etc.

[0050] <1.2 Functional Configuration of Server 20> Figure 2 shows the configuration of server 20. As shown in Figure 2, server 20 functions as a communication unit 201, a storage unit 202, and a control unit 203.

[0051] The communications unit 201 performs processing to enable the server 20 to communicate with external devices.

[0052] The memory unit 202 stores various databases, such as the user database 211, the wish list database 212, the transaction history database 213, the review history database 214, the contract signing management database 215, and the document management database 216.

[0053] User database 211 is a database for managing users.

[0054] The user database 211 contains information necessary for using the services provided by server 20, such as the user's name and contact information. Further details will be provided later.

[0055] The wish list database 212 is a database in which each user manages the details of transactions they wish to conduct, either as a seller or as a buyer. Further details will be provided later.

[0056] The transaction history database 213 is a database that manages the details of each user's transactions and the progress of those transactions (extraction of contract terms, contract signing, etc.). Further details will be provided later.

[0057] Review History Database 214 is a database that manages the history of reviews performed on document data such as contracts. Further details will be provided later.

[0058] The contract signing management database 215 is a database that manages the contract signing process carried out by the electronic contract service provided by server 20. Further details will be described later.

[0059] The document management database 216 is a database for managing document data and includes information for managing document data concluded through the electronic contract service provided by server 20. Further details will be described later.

[0060] The control unit 203 is realized when the processor 29 reads a program stored in the memory unit 202 and executes instructions contained in the program. By operating according to the program, the control unit 203 performs the functions shown as the reception control module 2041, transmission control module 2042, user management module 2043, contract signing processing module 2044, document management module 2045, approval processing module 2046, LLM utilization module 2047, review processing module 2048, transaction request management module 2049, and transaction processing module 2050.

[0061] The receive control module 2041 controls the process by which the server 20 receives signals from external devices according to a communication protocol.

[0062] The transmission control module 2042 controls the process by which the server 20 transmits signals to external devices according to a communication protocol.

[0063] The user management module 2043 is a module for managing information for each user using System 1. Specifically, the user management module 2043 accepts registration of each user's information and updates the user database 211.

[0064] The contract signing module 2044 controls the process of parties approving document data as part of the process of concluding a contract electronically. Specifically, the contract signing module 2044 notifies each user approving the document data and updates the contract signing management database 215 in response to the operation of approving the document data.

[0065] The document management module 2045 controls the process of managing document data by referring to the document management database 216. Specifically, based on the contract period information set in the document data, the document management module 2045 notifies the user of whether to renew the contract upon the expiration of the contract period, and updates the document management database 216 in response to user actions (such as renewing the contract).

[0066] The approval processing module 2046 receives requests from users to submit approval requests and controls the process by which approvers approve those requests. Specifically, the approval processing module 2046 notifies each user who approves an approval request and updates the database of approval requests in response to the approval operation.

[0067] The LLM utilization module 2047 is a program module that performs processing related to the use of LLM, such as generating prompts to send to the server 95 of the large-scale language model service, sending the generated prompts as instructions to the server 95 of the large-scale language model service, receiving the results output by the server 95 of the large-scale language model service in response to the instructions (prompts), and performing processing using the received results.

[0068] The review processing module 2048 records reviews of the document data to be reviewed (for example, each clause of a contract) and updates the review history database 214. The review processing module 2048 communicates with the document review service server 93 and sends the document data to be reviewed, causing the server 93 to perform the review process. The module receives the results and updates the review history database 214. The review processing module 2048 also accepts operations from the user performing the review (for example, operations to input comments in association with the entire contract or each clause of the contract) and updates the review history database 214.

[0069] The transaction request management module 2049 is a program module that extracts the details of transactions that each user wishes to do and updates the request list database 212.

[0070] The transaction processing module 2050 is a program module that updates the transaction history database 213 by performing processes such as sending and receiving messages, extracting contract terms, creating contracts, acknowledging the contract terms stipulated in the contracts, and evaluating each user, in order to support each user's transactions.

[0071] <1.3 Configuration of Terminal 10> Figure 3 shows the configuration of terminal 10.

[0072] As shown in Figure 3, terminal 10 includes multiple antennas (antenna 111, antenna 112), communication units corresponding to each antenna (first communication unit 120, second communication unit 121), an input device 130 (including a touch-sensitive device 131), a display 132, an audio processing unit 140, a microphone 141, a speaker 142, a position information sensor 150, a camera 160, a motion sensor 170, a storage unit 180, and a control unit 190. Terminal 10 also has functions and configurations not specifically shown in Figure 3 (for example, a battery for maintaining power, a power supply circuit for controlling the supply of power from the battery to each circuit, etc.). As shown in Figure 3, each block included in terminal 10 is electrically connected by a bus or the like.

[0073] Antenna 111 radiates signals emitted by terminal 10 as radio waves. Antenna 111 also receives radio waves from space and provides the received signals to first communication unit 120.

[0074] Antenna 112 radiates signals emitted by terminal 10 as radio waves. Antenna 112 also receives radio waves from space and provides the received signals to the second communication unit 121.

[0075] The first communication unit 120 performs modulation and demodulation processing, etc., for the terminal 10 to transmit and receive signals via the antenna 111 in order to communicate with other wireless devices. The second communication unit 121 also performs modulation and demodulation processing, etc., for the terminal 10 to transmit and receive signals via the antenna 112 in order to communicate with other wireless devices. The first communication unit 120 and the second communication unit 121 are a communication module that includes a tuner, an RSSI (Received Signal Strength Indicator) calculation circuit, a CRC (Cyclic Redundancy Check) calculation circuit, a high-frequency circuit, etc. The first communication unit 120 and the second communication unit 121 perform modulation and demodulation, frequency conversion, etc., of the wireless signals transmitted and received by the terminal 10, and provide the received signal to the control unit 190.

[0076] The input device 130 has a mechanism for receiving user input operations. Specifically, the input device 130 is configured as a touchscreen and includes a touch-sensitive device 131. The touch-sensitive device 131 receives user input operations of the terminal 10. The touch-sensitive device 131 detects the user's contact position with the touch panel, for example, by using a capacitive touch panel. The touch-sensitive device 131 outputs a signal indicating the user's contact position detected by the touch panel to the control unit 190 as an input operation.

[0077] The display 132 displays data such as images, videos, and text in accordance with the control of the control unit 190. The display 132 is implemented by, for example, an LCD or an organic EL display.

[0078] The audio processing unit 140 modulates and demodulates the audio signal. The audio processing unit 140 modulates the signal received 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 implemented, for example, by an audio processing processor. The microphone 141 receives an audio input and provides the audio signal corresponding to that audio input to the audio processing unit 140. The speaker 142 converts the audio signal received from the audio processing unit 140 into sound and outputs the sound to the outside of the terminal 10.

[0079] The location information sensor 150 is a sensor that detects the location of the terminal 10, and is, for example, a GPS (Global Positioning System) module. A 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 location of the terminal 10, which is equipped with a GPS module, is detected based on the received signals.

[0080] Camera 160 is a device that receives light using a photodetector and outputs it as an image. Camera 160 is, for example, a depth camera that can detect the distance from camera 160 to the object being photographed.

[0081] The motion sensor 170 includes an acceleration sensor, an angular velocity sensor, etc., and detects the movement of the terminal 10.

[0082] The storage unit 180 is composed of, for example, flash memory and stores data and programs used by the terminal 10. The various types of information stored in the storage unit 180 will be described later.

[0083] The control unit 190 controls the operation of the terminal 10 by reading the program stored in the memory unit 180 and executing the 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 performs the functions of an operation reception unit 191, a transmission / reception unit 192, a data processing unit 193, a notification control unit 194, and a memory control unit 195.

[0084] The operation reception unit 191 processes input operations from the user to an input device such as a touch-sensitive device 131. Based on the coordinate information of the touch-sensitive device 131 where the user's finger or the like has made contact, the 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.

[0085] The transmitting / receiving unit 192 performs processing to enable the terminal 10 to send and receive data with an external device such as a server 20 in accordance with a communication protocol.

[0086] The data processing unit 193 performs calculations on the data received as input by the terminal 10 according to the program and outputs the calculation results to memory or other locations.

[0087] The notification control unit 194 performs the following processes: displaying the display image on the display 132, outputting sound to the speaker 142, and generating vibrations.

[0088] The memory control unit 195 controls the storage of data to the memory unit 180.

[0089] The various types of information stored by the memory unit 180 will now be explained. In a given scenario, the memory unit 180 stores various types of information, such as user information 181.

[0090] User information 181 is information about a user who uses the services of server 20. User information 181 includes, for example, the user's name.

[0091] <2 Data Structure> Figure 4 shows the data structure of the user database 211. The user database 211 includes the following fields: "User ID", "Username", "Email Address", "Phone Number", "Account Creation Date", "SNS Account", "User Type", "Trust Rating Score", "Account Status", "Profile Picture", and "Fraud Detection Flag".

[0092] The "User ID" field is information that identifies each user.

[0093] The "Username" field contains information about the user's display name or real name.

[0094] The "Email Address" field contains the user's email address contact information.

[0095] The "Phone Number" field contains the user's phone number contact information.

[0096] The "Account Creation Date" field contains information about the date and time the user created their account.

[0097] The item "SNS Account" refers to information about the social networking services (SNS) that the user uses, as well as information about the user's account on those SNS platforms.

[0098] The "User Type" field contains information about the user's attributes as a seller, buyer, or both.

[0099] The "Reliability Rating Score" item is information about the evaluation result of the reliability of the user's transactions (for example, a higher number indicates higher reliability).

[0100] The "Account Status" field contains information about the current state of the account.

[0101] More specifically, the "Account Status" item refers to the state of the account, including active, suspended, frozen, etc.

[0102] The item "Profile Picture" contains information from the user's profile picture data file.

[0103] More specifically, the "Profile Picture" item should include the file path or URL of the image.

[0104] The item "Fraud Detection Flag" contains information about flags used when fraudulent activity is detected.

[0105] More specifically, the "Fraud Detection Flag" item contains information indicating that the flag has been enabled (for example, "true" indicates that caution is needed).

[0106] Figure 5 shows the data structure of the wish list database 212. The wish list database 212 includes the following items: "Wish ID", "User ID", "Transaction Type", "Product Name", "Product Details", "Posting Date and Time", "SNS Post URL", "SNS Post Content", "Matching Priority Score", "Fraud Detection Flag", and "Product Image".

[0107] The "Desired ID" field is information that identifies each transaction request.

[0108] The "User ID" field is information that identifies the user who registered the transaction request.

[0109] The item "User ID" may be associated with the item "User ID" in user database 211.

[0110] The "Transaction Type" field indicates whether the user is a seller or a buyer, providing information about the attributes of the transaction.

[0111] The "Product Name" field contains information about the name of the product or service you wish to purchase.

[0112] The "Product Details" field contains detailed information about the product or service you wish to purchase.

[0113] The "Posting Date and Time" field indicates the timing when the transaction request was registered or analyzed.

[0114] The item "SNS Post URL" contains information about the URL used to refer to the SNS post that was the target of the transaction request analysis.

[0115] The item "SNS Post Content" contains information about the user's desired transaction details, analyzed from their SNS posts.

[0116] The "Matching Priority Score" item is information about the evaluation result of the priority (for example, a higher score means higher priority) used to match your transaction requests with those of other users.

[0117] The "Fraud Detection Flag" item contains information about flags indicating a potential fraudulent transaction.

[0118] More specifically, the "Fraud Detection Flag" item contains information indicating that the flag has been enabled (for example, "true" means caution is advised).

[0119] The item "Product Image" contains information about the data file containing the product's image.

[0120] More specifically, the item "Product Image" includes the path or URL of the image file.

[0121] Figure 6 shows the data structure of the transaction history database 213. The transaction history database 213 includes the following items: "Transaction ID", "Seller User ID", "Buyer User ID", "Desired ID", "Transaction Items", "Contract Terms", "Review History ID", "Contract Signing ID", "Transaction Status", "Contract Signing Date and Time", "Payment Completion Date and Time", "Shipping Date and Time", "Contract Data", "Transaction Satisfaction Rating Score", and "Problem Occurrence Flag".

[0122] The "Transaction ID" field is information that identifies each transaction.

[0123] The item "Seller User ID" is information that identifies the seller's user in the transaction.

[0124] The item "Seller User ID" may be associated with the item "User ID" in user database 211.

[0125] The item "Buyer User ID" is information that identifies the buyer user in the transaction.

[0126] The item "Buyer User ID" may be associated with the item "User ID" in user database 211.

[0127] The "Desired ID" field is information that identifies the item each user wishes to trade.

[0128] The item "Desired ID" may be associated with the item "Desired ID" in the desired list database 212.

[0129] The item "Transaction Items" contains information about the names of the goods and services that were the subject of the transaction.

[0130] The item "Contract Terms" contains information about the contract terms of a transaction, such as price, delivery date, and payment method.

[0131] The item "Review History ID" is information that identifies each review in the service that reviews contract terms.

[0132] The item "Review History ID" may be associated with the item "Review ID" in the review history database 214.

[0133] The item "Contract Signing ID" is information that identifies each contract signing for a service that is concluded based on a contract document.

[0134] The item "Contract Signing ID" may be associated with the item "Signing ID" in the contract management database 215.

[0135] The "Transaction Status" field provides information about the progress of a transaction.

[0136] More specifically, the item "Transaction Status" includes statuses such as "Negotiating," "Contract Signed," "Waiting for Payment," "Waiting for Shipment," and "Completed."

[0137] The item "Contract Signing Date and Time" contains information about when the contract was signed.

[0138] The item "Payment Completion Date and Time" indicates the timing when payment from the buyer was confirmed.

[0139] The "Shipping Date and Time" field contains information about when the seller shipped the item.

[0140] The item "Contract Data" contains information about the contract data file.

[0141] More specifically, the item "Contract Data" includes the path or URL of the contract data file.

[0142] The item "Transaction Satisfaction Rating Score" contains information on the user's evaluation after the transaction is completed.

[0143] More specifically, the item "Transaction Satisfaction Evaluation Score" includes evaluation scores, such as those where a higher number indicates higher satisfaction.

[0144] The "Problem Occurrence Flag" item contains information about flags indicating problems or troubles that occurred during a transaction.

[0145] More specifically, the "Problem Flag" item contains information about a flag that has been activated due to a problem related to the transaction (for example, "true" means action is required).

[0146] Figure 7 shows the data structure of the review history database 214. The review history database 214 includes the following items: "Review ID", "Document Data", "Document Management ID", "Review Date and Time", "Reviewing User", "Review Content", and "Review Requester's Rating".

[0147] The "Review ID" field is information that identifies each review performed on the document data.

[0148] The item "Document Data" contains information about the document data that will be reviewed.

[0149] The "Document Management ID" field is information that identifies each document data being managed.

[0150] Specifically, the item "Document Management ID" may be associated with information (Document Management ID) that identifies each document data managed in the document management database 216.

[0151] The "Review Date and Time" field contains information about the date and time the review was performed.

[0152] The item "Reviewing User" contains information about the user who conducted the review.

[0153] The item "Review Content" contains information that shows the results of the review.

[0154] Specifically, the item "Review Content" may include the following as a result of the review: • Results of the review by server 93 of the document review service (e.g., advantages / disadvantages of conditions, importance, proposed revisions) • Comments and suggested revisions entered by users (including information about the user who entered the review comment) The item "Review Requester's Rating" is information that shows the user's rating of the reviewer's review content.

[0155] Specifically, the item "Review Requester's Rating" includes the results of the user who requested the review evaluating the reviewer based on the actions they took with respect to the review results, and may include the following: • The user who requested the review sets a score for the review results. • The number of "likes" and other reactions on posts made to contact users about reviewing a product via messaging tools, etc. Figure 8 shows the data structure of the contract management database 215. The contract management database 215 includes the following fields: "Contract ID", "Sender ID", "Recipient ID", "Contract Target Data", "First Email Address", "Second Email Address", "Sending Date and Time", "User Signature Date and Time", "Contract Completion Date and Time", and "Status".

[0156] The item "Contract Signing ID" is information that identifies each step in the contract signing process.

[0157] Specifically, the item "Contract ID" includes identification information issued by server 20 when a new registration is accepted for the process of concluding an electronic contract by specifying an approver for document data subject to approval by the parties.

[0158] The "Sender ID" field is information that identifies the party who will be sending the document data when the party approves it.

[0159] Specifically, the item "Sender ID" may be associated with information about a business operator (Business ID) or information about a user (User ID) managed in the user database 211.

[0160] The "Recipient ID" field is information that identifies the recipient when they approve document data.

[0161] Specifically, the item "Recipient ID" is information that identifies the party designated as the recipient by the sender's user, and like the sender ID, it may be associated with information about a business operator (business operator ID) or information about a user (user ID) managed in the user database 211.

[0162] The item "Data Subject to Agreement" refers to the document data that the parties are required to approve.

[0163] Specifically, the item "Data subject to conclusion" refers to data (files such as PDFs) of transaction documents such as contracts, application forms, and quotations.

[0164] The item "First Email Address" is information that identifies the user who will be the sender in the process of concluding a contract by approving document data, and is the email address that serves as the contact address for that user.

[0165] Specifically, the item "First Email Address" is the email address of the user who performs the operation of sending the document data as the sender.

[0166] The item "Second Email Address" is information that identifies the user who approves the document data as the recipient in the process of concluding a contract by approving the document data, and is the email address that serves as the contact address for that user.

[0167] Specifically, the item "Second Email Address" is the email address of the user who approves the document data as the recipient. Note that there may be multiple users approving the document on each party's side, and if the user sending the document data specifies the email addresses of multiple users who will approve the document data, the contract management database 215 will also manage each of the specified email addresses.

[0168] The "Sending Date and Time" field contains information about the date and time when the sender, a user, initiated the process of requesting approval of the document data from each user.

[0169] The "User Signature Date and Time" field contains information about the date and time when the user performed an approval operation on the document data.

[0170] Specifically, the item "User Signature Date and Time" includes information about the timing when a user who has been requested to approve the document data reviews and approves the document data, and the server 20 accepts this operation, thereby electronically signing the document data. The server 20 electronically signs the document data each time a user performs the approval operation, and stores the timing information in the signing management database 215.

[0171] The item "Date and Time of Contract Completion" contains information about the date and time when the contract was completed.

[0172] Specifically, the item "Contract Completion Date and Time" is recorded in the contract management database 215 when the contract is concluded using the electronic contract service provided by server 20. The contract is considered concluded when all users designated to approve the document data complete the approval process.

[0173] The "Status" field indicates the stage in the contract signing process.

[0174] Specifically, the item "Status" may include the following as stages in the contract signing process: • Before sending: Indicates that the document data has been registered on server 20 by the sender, but has not yet been sent to the recipient. • In Progress: Indicates that the document data has been sent, but approval by each user has not yet been completed. • Completed: Indicates that the contract has been finalized. • Rejected, Returned: Indicates a situation where the contract was not finalized due to circumstances such as the user not approving the document data, or a timeout occurring after a certain period of time had elapsed before approval was complete. Figure 9 shows the data structure of the document management database 216. The document management database 216 includes the following items: "Document Management ID", "Contract Signing ID", "Document Title", "Contract Start Date", "Contract Expiration Date", "Automatic Renewal Status", and "Viewing Permission".

[0175] The "Document Management ID" field is information that identifies each document data being managed.

[0176] The "Contract Signing ID" field is information that identifies each contract signing procedure performed by the parties to approve the document data.

[0177] Specifically, the item "Contract Signing ID" may be associated with information (Contract Signing ID) that identifies each contract signing, which is managed in the contract signing management database 215.

[0178] The "Document Title" field contains information about the title of the document data being managed.

[0179] Specifically, the item "Document Title" may be a term used as the type or name of a contract, such as a confidentiality agreement, a sales agreement, or a license agreement.

[0180] The item "Contract Start Date" is the information shown in the document data as the contract start date.

[0181] Specifically, the item "Contract Start Date" may be set to the following value: • When the contract is finalized, Server 20 reads the contract start date from the contract data. • Information received from the user as the contract start date The same applies to the following items: "Contract Expiration Date" and "Automatic Renewal Status".

[0182] The item "Contract Expiration Date" is the information shown in the document data as the contract's expiration date.

[0183] The item "Automatic Renewal Status" indicates, in the document data, whether or not the contract period will be automatically extended (automatically renewed) without the parties specifically renegotiating a new contract upon the expiration of the contract period.

[0184] The item "Viewing Permission" is information about users who are set to have viewing permission for documents (e.g., contracts) managed in the document management database 216. Server 20 may allow users set as stakeholders of a document to view the document, and may not allow users who are not set to view the document to view it.

[0185] Specifically, the "Viewing Permissions" item may be used to manage the following users as stakeholders in the document data. - Users recorded in the contract management database 215 as users who approve document data. Note that the server 20 may identify the parties involved in the document data by referring to the users who approved the document data in the contract management database 215, rather than retaining the information of the parties involved in the document management database 216. • In the contract signing service provided by Server 20, in addition to the user who approves the document data, the server also accepts the designation of users to whom the data will be shared once the contract is signed. These designated users (the users to whom the data is transferred) are the ones specified. For example, in the case of minutes of a board meeting, a director may approve the document data, and then share the approved minutes with other users such as executive officers. • Other users designated by users who approve the document data, users who have permission to view the document data, etc. Furthermore, the "Viewing Permissions" item may be configured to include information that identifies departments or divisions within an organization, rather than individuals. For example, when managing user "department" information in user database 211, it may be possible to configure information corresponding to that "department." In other words, by defining which departments or divisions can view documents, users in those departments or divisions of the organization can view the documents.

[0186] <3 operations> Figure 10 shows the process flow for retrieving the details of transactions that each user wishes to conduct as a seller or buyer and generating a list.

[0187] The process is outlined below. • Terminal-side processing: The user accesses the system and performs actions to authorize SNS integration. • Server-side processing: Analyzes data obtained from SNS to generate a list of potential customers and evaluate user reliability. The following points should be considered when evaluating reliability. • Are users making offers to provide or purchase goods or services at different locations at the same time? • Check past posts for any suspicious patterns or signs of fraudulent activity. Through the above process, a list of desired transactions is automatically generated from users' social media posts, allowing users to review and edit their desired transaction details. This series of processes enables users to view each other's transaction requests and reliability information, allowing them to confidently select trading partners. This processing flow provides detailed information and reliability assessments of trading partners that were not available on conventional C2C platforms, potentially promoting safer and more appropriate transactions.

[0188] The following describes the processing of each device.

[0189] In step S1011, terminal 10 accesses the system's app or website and accepts an operation from server 20 to authenticate the system and the user's own SNS account. Terminal 10 accepts an operation from the user to allow the system to access the SNS posting data.

[0190] In step S1021, the transaction preference management module 2049 of server 20 obtains information on the details of transactions that each of the multiple users wishes to be either a seller or a buyer in. More specifically, the transaction preference management module 2049 obtains each user's posts on a Social Network Service (SNS) where users can view each other's posts.

[0191] The Transaction Request Management Module 2049 receives authentication information for linking SNS accounts and obtains access permissions to the user's SNS posts via the API provided by the SNS. The Transaction Request Management Module 2049 retrieves the user's past SNS posts.

[0192] In step S1022, the transaction request management module 2049 of server 20 extracts the transaction details that users wish to "sell" and the transaction details they wish to "buy". The transaction request management module 2049 analyzes the user's posted content using natural language processing (NLP), text analysis, etc., to extract the transaction details that users wish to "sell" and the transaction details they wish to "buy". Based on the information of the transaction details that each user wishes to buy, the transaction request management module 2049 extracts a first user who will be the seller and a second user who will be the buyer.

[0193] Here, we will explain in more detail how to extract the content that each user wishes to trade from their social media posts.

[0194] (1) Detect specific words or phrases contained in the post. For example, a user may include a specific tag (also called a hashtag) in their social media post, or associate a specific tag with a post. For instance, the tag itself may indicate whether the user is a seller or a buyer, or the tag itself may be a specific tag indicating a desire to trade (e.g., "#buyandsell"), and the user's intention to sell or buy may be determined from the content of the post (e.g., if words like "want to sell" or "want to acquire" are included, it may be determined that the user is a seller).

[0195] For example, a social networking service (SNS) could be one where users can view each other's posts regardless of whether they follow each other or not.

[0196] Furthermore, the transaction request management module 2049 may detect posts containing content indicating a desire to trade as a buyer, such as "I want to buy" or "I want to acquire," regardless of whether the post content includes tags. It may also detect posts containing content indicating a desire to trade as a seller, such as "I want to sell" or "I want to give away."

[0197] Furthermore, the Transaction Request Management Module 2049 may also extract transaction content by detecting posts that contain requests for bartering, in addition to buying and selling goods and offering and applying for services (for example, "I have item A. Anyone with item B, would you like to trade?"). The Transaction Request Management Module 2049 may also extract transaction content by detecting posts that contain requests for exchanging services (for example, "I can offer service C. I would like to trade with someone who can provide service D"). Furthermore, the Transaction Request Management Module 2049 may also detect posts that contain requests for exchanging goods and services (for example, "I have item E. I would like to trade with someone who can provide service F").

[0198] (2) Post in association with a specific account For example, one could accept posts containing the request for a transaction while mentioning a specific account, or one could accept posts containing the request for a transaction by sending a direct message to that specific account.

[0199] (3) Generate a list of desired transactions from the user's posted content. For example, a prompt is generated that includes the content of a user's post, and also includes instructions to generate a list of items the user wants to sell and buy. Server 20 may send the generated prompt to the server 95 of the large-scale language model service, thereby generating a list of items that each user wishes to trade.

[0200] As described above, the transaction preference management module 2049 analyzes the content of each user's SNS posts obtained in step S1021 to obtain information on the content of at least one of the transactions that each user wishes to sell or buy.

[0201] In step S1023, the transaction request management module 2049 of the server 20 generates a user transaction request list based on the extracted transaction request information and updates the request list database 212.

[0202] In step S1024, the transaction request management module 2049 of the server 20 evaluates the reliability of the transaction requests based on the content of the transactions each user requests and the SNS posting patterns, and updates various databases such as the request list database 212 and the user database 211.

[0203] Here, we will explain how to evaluate the reliability of the terms of the transaction you wish to pursue.

[0204] The Transaction Request Management Module 2049 checks for potential fraudulent transactions, such as whether a user is requesting a transaction at different locations at the same time. The Transaction Request Management Module 2049 may also evaluate the reliability of a transaction by assigning a lower reliability rating if the user, as a seller, is offering to provide goods or services at different locations at the same time, or if the user, as a buyer, is offering to purchase goods or services at different locations at the same time. Based on this, the Transaction Request Management Module 2049 calculates a reliability score and updates the user database 211 and the request list database 212.

[0205] Thus, the transaction request management module 2049 analyzes the content of each SNS user's posts to evaluate the reliability of the transactions each user desires, and then processes the information based on the evaluated reliability.

[0206] In step S1025, the transaction request management module 2049 of the server 20 refers to the request list database 212 and notifies the user of the transaction request list generated in step S1023 and the results of the reliability evaluation in step S1024.

[0207] In step S1012, terminal 10 displays the user's own list of desired transactions and a score that evaluates reliability.

[0208] Figure 11 shows the process flow for matching users based on a list of items they wish to trade as either a seller or a buyer, and for accepting the operations related to the transaction.

[0209] The process is outlined below. • Matching Process: Compares the wish lists of sellers and buyers and calculates similarity in terms of product type, price range, conditions, etc. By considering information from both sellers and buyers, more accurate matching is possible. In addition, a score that evaluates user reliability is considered, and reliable users are prioritized for matching. • Negotiation and extraction of contract terms: Analyzes messaging data between users in real time and automatically extracts transaction terms. By utilizing natural language processing, contract terms can be identified even from unstructured messages. • Contract generation and conclusion: Based on the extracted contract terms, the system automatically generates a contract. The user reviews the contract on their terminal and records their consent with an electronic signature. For example, the electronic contract mechanism could be a "business signature type (witness type)," where a third party who is not a party to the contract affixes an electronic signature based on the instructions of the parties (for example, server 20 provides the witness type electronic contract system), or a "party signature type," where the parties to the contract prepare equipment or authentication IC chip cards, etc., and affix an electronic signature without the assistance of a business. Furthermore, as will be described later, confirmation of payment related to the transaction may be considered as consent to the contract. • Transaction execution and recording: After the contract is signed, server 20 manages the progress of the transaction and records payments and transfer of ownership of goods. After the transaction is completed, the user's reliability score may be updated and taken into consideration in future matching. • User Feedback: Users can enter ratings and feedback on trading partners. This feedback is used to assess the user's trustworthiness. These processing flows allow users to efficiently match with the most suitable trading partners and smoothly navigate the process from negotiation to contract signing. By automatically analyzing negotiation data and extracting contract terms, the effort required for manual contract creation can be eliminated, resulting in faster and more accurate transactions.

[0210] The following describes the processing of each device.

[0211] In step S1121, the transaction processing module 2050 of the server 20 refers to the wish list database 212 and identifies the similarity of each user based on the content of the transactions each user wishes to conduct, based on each user's wish list. The transaction processing module 2050 may also identify the similarity of users by considering both the seller's list and the buyer's list for each user's wish list.

[0212] For example, the similarity between transaction requests included in both the seller and buyer lists of a first user may be identified, and between transaction requests included in both the seller and buyer lists of other users. In this way, the similarity between users may be identified based on the entire range of items each user wishes to trade.

[0213] For example, the similarity between a first user's seller list and another user's buyer list could be identified. Alternatively, the similarity between a first user's buyer list and another user's seller list could be identified. In this way, the greater the degree to which the supply and demand for transactions desired by the users match, the higher the similarity between the users can be considered.

[0214] In step S1122, the transaction processing module 2050 of the server 20 extracts matching candidates from users with high similarity. Here, the transaction processing module 2050 may also refer to various databases such as the wish list database 212 and the user database 211, and rank the matching candidates by considering a score that evaluates the reliability of the users. For example, users with higher reliability may be given a higher priority as matching candidates, and a higher priority may be given to displaying them as trading partners to each other.

[0215] As described above, the transaction processing module 2050 obtains information on both the type of transaction a user desires as a seller and the type of transaction a user desires as a buyer. Based on both the type of transaction a user desires as a seller and the type of transaction a user desires as a buyer, it may extract similar users.

[0216] In step S1123, the transaction processing module 2050 of the server 20 presents the matching results to the user based on the ranking of the matching candidates.

[0217] The transaction processing module 2050 makes information about the transactions that each extracted user wishes to trade available for mutual viewing among the extracted users.

[0218] In step S1111, terminal 10 displays the matching results between users based on the transaction request list. Terminal 10 accepts the user's operation to select a partner with whom they wish to conduct a transaction. Terminal 10 uses the messaging function to send and receive messages for negotiating transaction terms. This allows users to start negotiations about the transaction. Terminal 10 also allows the user to view the transaction requests and reliability scores of their trading partners.

[0219] In step S1124, the transaction processing module 2050 of the server 20 presents a list of transaction details that the transaction partner desires, either as a seller or a buyer, and accepts the selection of transaction details from the list. The transaction processing module 2050 acquires negotiation data sent and received between users related to the transaction. Specifically, the transaction processing module 2050 acquires negotiation message data sent and received between users in real time. For example, the transaction processing module 2050 may use a messaging function that allows sending and receiving messages via SNS to allow users to send and receive messages related to the negotiation of transaction terms, and acquire the negotiation data sent and received via SNS.

[0220] In step S1125, the transaction processing module 2050 of server 20 extracts contract terms by analyzing the negotiation message. For example, the transaction processing module 2050 analyzes the negotiation message using natural language processing (NLP) to extract contract terms (price, quantity, delivery date, payment method, etc.).

[0221] The transaction processing module 2050 generates a contract that includes contract terms corresponding to the transaction details. The transaction processing module 2050 generates a contract that reflects the contract terms extracted above. For example, the transaction processing module 2050 may generate a contract by applying the extracted contract terms to a contract template. Alternatively, the transaction processing module 2050 may generate a prompt that includes the extracted contract terms (and may also include a contract template), and that includes instructions to generate a contract based on the contract terms, and send this prompt to the server 95 of the large-scale language model service, thereby obtaining the generated contract from the server 95.

[0222] As described above, the transaction processing module 2050 identifies contract terms based on the acquired negotiation data and generates a contract document that includes the identified contract terms.

[0223] In step S1126, the transaction processing module 2050 of the server 20 sends the generated contract to both users involved in the transaction (the user as the seller and the user as the buyer). The transaction processing module 2050 requests each user to confirm and agree to the contents of the contract. For example, an electronic contract system may be used to accept approval of the contract from each user, and an electronic signature may be attached when each user performs the approval operation.

[0224] In step S1112, terminal 10 confirms the contents of the contract and accepts an operation from the user to agree to the contents of the contract. As a result, server 20 or the like performs an electronic signature on the contract.

[0225] In step S1127, the transaction processing module 2050 of server 20 records that the contract has been concluded because the users of the parties have approved the contract, and updates the contract management database 215. The transaction processing module 2050 then records that the generated contract has been presented to each user involved in the transaction and that the user has agreed to the contract by electronically signing it.

[0226] As described above, the transaction processing module 2050 accepts the specification of transaction details to be exchanged between the extracted users and completes the transaction. The transaction processing module 2050 stores information related to the conclusion of the contract in various databases such as the transaction history database 213 and the conclusion management database 215, and manages the progress of the transaction. The transaction processing module 2050 initiates the payment processing of consideration between users related to the transaction and the transfer of ownership of goods as necessary.

[0227] In step S1113, terminal 10 receives a request from the user to make a payment for the transaction. Terminal 10 allows the user to check the progress of the transaction according to the user's actions. Terminal 10 also receives a request from the user to input an evaluation or feedback for the trading partner.

[0228] In step S1128, when the transaction processing module 2050 of the server 20 obtains information indicating that payment for the transaction has been made, it records the transaction status, updates the transaction history database 213, and completes the transaction. After the transaction is completed, the transaction processing module 2050 may also update the reliability scores of both users. For example, the reliability of each user may be evaluated to improve upon completion of the transaction.

[0229] Figure 12 shows the process flow for concluding a contract through payment of consideration for the transaction.

[0230] The process is outlined below. • Payment of consideration and contract formation: Once the buyer completes the payment, the system triggers this, deeming the buyer to have agreed to the contract terms and electronically signing it. This formally forms the contract, allowing the seller to confidently proceed with shipping the goods and providing the services. • Transaction progress and performance record: The seller ships the goods (or provides the service) and enters a notification into the system. Server 20 then records the shipping information (or service provision) in the transaction history and notifies the buyer. Once the buyer receives the goods (or confirms the service has been provided), they confirm receipt in the system. This completes the fulfillment of the contractual obligations (delivery of goods and payment of consideration) by both parties. • Transfer of ownership: Upon conclusion of the contract and confirmation of receipt of the goods, Server 20 records that ownership of the goods / items has been transferred to the buyer. • Reliability rating update: After a transaction is completed, the system updates the reliability score for each user based on the transaction results and user feedback. This system addresses the issue in conventional C2C platforms where the purchase operation automatically constitutes a confirmed purchase, making it difficult to adequately assess the reliability of the trading partner. By providing multifaceted information such as payment confirmation and ownership transfer records, this system creates an environment where users can trade with peace of mind. Furthermore, it may improve the accuracy of matching and the reliability assessment in future transactions, potentially enhancing the overall health of the platform.

[0231] The following describes the processing of each device.

[0232] In step S1221, the transaction processing module 2050 of server 20 sends the generated contract to each user who is a party to the transaction. This prompts each user to confirm the contract details and proceed with payment.

[0233] In step S1211, the buyer user's terminal 10 displays the contents of the contract to the buyer user. The buyer user's terminal 10 accepts an operation from the buyer user to pay the consideration using the presented payment method.

[0234] In step S1222, the transaction processing module 2050 of the server 20 obtains information indicating that payment of consideration from the buyer user has been completed. The transaction processing module 2050 may electronically sign the generated contract, acknowledging that the users involved in the transaction have agreed to the terms and conditions of the contract once the payment of consideration for the transaction has been made between the users involved in the transaction. Upon completion of payment of consideration for the transaction, the transaction processing module 2050 electronically signs the contract, acknowledging that the buyer user has agreed to the contract terms, records the conclusion of the contract, and updates various databases. For example, the transaction processing module 2050 may monitor the payment status of the buyer user in real time through a payment system or a financial institution's API. The transaction processing module 2050 detects that payment has been made, updates the information on the conclusion of the contract in the transaction history database 213, and changes the transaction status to "Contract Concluded".

[0235] In step S1223, the transaction processing module 2050 of the server 20 notifies the seller user that payment for the transaction has been completed and the contract has been concluded.

[0236] In step S1212, the seller's user terminal 10 accepts an operation from the seller's user confirming the contract details and fulfilling their obligations. For example, the seller's user terminal 10 accepts an operation from the seller's user preparing the goods for shipment, shipping the goods to the buyer, and entering a shipment completion notification into the system.

[0237] In step S1224, the transaction processing module 2050 of the server 20 receives information from the seller user indicating that the obligation has been fulfilled and updates the transaction history database 213. The transaction processing module 2050 notifies the buyer user that the seller user has fulfilled the obligation. For example, the transaction processing module 2050 receives notification from the seller user that the goods have been shipped and records the shipping information in the transaction history database 213. The transaction processing module 2050 then notifies the buyer user that the goods have been shipped.

[0238] As described above, the transaction processing module 2050 obtains information indicating that contractual obligations under the contract have been fulfilled, and records, in association with the contract, that the obtained obligations have been fulfilled.

[0239] In step S1213, the buyer's user terminal 10 receives an operation from the buyer's user indicating that the obligation has been fulfilled. For example, the buyer's user terminal 10 receives an operation from the buyer's user indicating that they have received the goods and entered a receipt confirmation into the system.

[0240] In step S1225, the transaction processing module 2050 of server 20 obtains information from the buyer user indicating that the obligation has been fulfilled, and records in the transaction history database 213 that the contractual obligation has been fulfilled. For example, the transaction processing module 2050 obtains information from the buyer user, such as confirmation of receipt of goods, changes the transaction status to "transaction completed," and updates the transaction history database 213.

[0241] Thus, transactions include those involving the transfer of goods between users. The transaction processing module 2050 may record that ownership of the goods involved in the transaction has been transferred between users by recording that the users have agreed to the contract.

[0242] In step S1226, the transaction processing module 2050 of the server 20 updates the reliability scores of the seller user and the buyer user upon completion of the transaction and reflects them in the user database 211. For example, the seller user's evaluation may be improved if the fulfillment of obligations was carried out within the period specified in the contract. In the case of the buyer user, the buyer user's evaluation may be improved if the buyer user performs actions such as confirming that the payment for the transaction was made within a specified period after the conclusion of the contract, and confirming the fulfillment of obligations, within a certain period after the obligations have been fulfilled.

[0243] In step S1214, terminal 10 receives evaluations and feedback from the user regarding the trading partner. These evaluations and feedback are stored in various databases on server 20.

[0244] <4 Screen Examples> Figure 13 shows an example of an operation screen that accepts user-to-user transactions based on a list of items that users wish to trade as either a seller or a buyer.

[0245] Operation screen 1300 is the screen used to conduct transactions while referring to a list of matched partners.

[0246] The operation screen 1300 corresponds to each process in Figure 12.

[0247] The matching user list display area 1302 is an area that displays a list of matching trading partners.

[0248] In the illustrated example, the matching user list display area 1302 displays the username, transaction request details, reliability evaluation score, etc., providing information for the user to select a trading partner.

[0249] The trading partner designation unit 1304 is an operating component that accepts the designation of a trading partner that the user wishes to trade with from among the matched trading partners.

[0250] In the illustrated example, the trading partner designation unit 1304 displays a list of potential trading partners and accepts the selection of multiple or a single trading partner using checkboxes or radio buttons.

[0251] The transaction details display area 1306 is an area that displays detailed information about the transaction with the selected trading partner.

[0252] In the illustrated example, the transaction details display area 1306 allows the user to view details of the goods or services the other party wishes to trade, the proposed transaction terms, and the other party's past transaction history.

[0253] The transaction terms specification unit 1308 is an operating component that accepts the specification of transaction terms such as price, quantity, and delivery date.

[0254] In the illustrated example, the transaction conditions specification section 1308 accepts input in a form format, allowing the user to specifically enter their desired conditions.

[0255] The transaction initiation operation unit 1310 is an operating component that receives an operation to initiate a transaction with a selected trading partner.

[0256] In the illustrated example, the transaction initiation operation unit 1310 transitions to a screen for entering transaction details in response to user input, thereby initiating concrete negotiations.

[0257] The transaction terms proposal operation unit 1312 is an operation component that accepts the operation to propose the entered transaction terms to the other party.

[0258] In the illustrated example, the transaction terms proposal operation unit 1312 sends the proposed terms to the other party in response to the user's operation. This facilitates negotiations on transaction terms between the users.

[0259] The proposal acceptance / rejection designation unit 1314 is an operating member that receives a designation to accept or reject the terms of trade proposed by the other party.

[0260] In the illustrated example, the proposal acceptance / rejection designation unit 1314 can also accept designation of a re-proposal as necessary.

[0261] The file acquisition unit 1316 is an operation member that accepts an operation of acquiring files (images, documents, etc.) related to a transaction.

[0262] In the illustrated example, the file acquisition unit 1316 can be used when sharing photographs of products, etc. that are subject to a transaction, or contract documents.

[0263] The message history display area 1318 is an area that displays exchanges of messages with a transaction counterpart.

[0264] In the illustrated example, the message history display area 1318 displays chats between users. For example, messages are displayed in chronological order, allowing users to check the communication history.

[0265] The message designation unit 1320 is an operation member that accepts designation of text or the like for transmitting a message to a transaction counterpart.

[0266] In the illustrated example, the message designation unit 1320 accepts input of messages as text. This allows users to freely communicate with each other about the transaction.

[0267] The message transmission operation unit 1322 is an operation member that accepts an operation for transmitting an input message to the counterpart.

[0268] In the illustrated example, the message transmission operation unit 1322 enables real-time exchange of messages in a chat format.

[0269] The contract status display area 1324 is an area that displays the contract status of a transaction.

[0270] In the illustrated example, the contract status display area 1324 displays transaction statuses such as "Negotiating," "Payment pending," and "Contract concluded." This allows users to grasp the current progress of the transaction at a glance.

[0271] The contract content confirmation and consent operation unit 1326 is an operating component that accepts operations to confirm the contents of an automatically generated contract and record consent by electronic signature.

[0272] In the illustrated example, the contract content confirmation and consent operation unit 1326 can formally conclude the contract in response to user operations.

[0273] The payment completion / contract formation notification display area 1328 is an area that displays that payment has been completed or that the contract has been formed.

[0274] In the illustrated example, the payment completion / contract formation notification display area 1328 notifies the user of the payment status. This clearly communicates important milestones in the transaction.

[0275] The payment method specification unit 1330 is an operating member that accepts the specification of a payment method.

[0276] In the illustrated example, the payment method selection unit 1330 accepts the selection of a payment method in a dropdown format. For example, it accepts the user's selection of a payment method from options such as credit card, bank transfer, or electronic money.

[0277] The payment procedure operation unit 1332 is an operating component that accepts the operation to proceed with the payment procedure using the selected payment method.

[0278] In the illustrated example, the payment procedure operation unit 1332 transitions to the payment screen in response to user input.

[0279] The trading partner evaluation / feedback display area 1334 is an area that displays evaluations and feedback from past trading partners.

[0280] In the illustrated example, the trading partner evaluation / feedback display area 1334 provides the user with information to judge the trading partner's reliability and trading attitude.

[0281] The evaluation / feedback designation unit 1336 is an operating component that accepts designations for evaluations and feedback to the trading partner after the transaction is completed.

[0282] In the illustrated example, the evaluation / feedback designation unit 1336 accepts user evaluations and feedback designations in a form format. This allows user evaluations and feedback to be reflected in the reliability evaluation of the other party.

[0283] <Variation> The matters described in the above embodiments can be combined in various ways.

[0284] (1) In the above description of the embodiment, it was explained that the desired transaction content is extracted based on the content posted by each user's SNS account and the desired list database 212 is updated accordingly.

[0285] In addition, the system may also update the wish list database 212 by extracting posts from messaging tools used within the organization (messaging service server 98) regarding requests for work (corresponding to the "buyers" mentioned above), things that people want to do, and things they can do (corresponding to the "sellers" mentioned above), such as requests for work within a business company. This allows for matching requests for work or posts of insights within the organization with members who have solutions.

[0286] (2) Requirements for transactions based on posted content to be possible In the above example, restrictions may be imposed on transactions between users depending on whether an account is issued based on information issued after identity verification (e.g., a telephone number) or whether the account has undergone identity verification. For example, as restrictions, it may be configured such that a list of desired transactions is not generated, or even though a list of desired transactions is generated, transactions cannot be initiated with other users (e.g., the list of desired transactions of other users cannot be browsed, or even though the list can be browsed, a transaction cannot be initiated). This allows transactions to be conducted only between users who have completed identity verification, thereby further improving the safety of transactions.

[0287] (3) Billing upon completion of a transaction In the above example, when a transaction is completed through matching between a seller user and a buyer user (e.g., when the parties agree on contract terms, or when obligations based on the contract content are performed), a fee may be charged to at least either the seller or the buyer.

[0288] (4) Warranties and insurance for provision of goods or services In the above example, when the content of each user's transaction desire list is checked, and the volume of identical or similar goods or services reaches or exceeds a certain level (e.g., when there are more than a certain number of people who want to buy or sell a device), acceptance of warranty or insurance applications for the provision of these goods or services may be performed (e.g., acceptance of warranty applications may be performed for a device transaction).

[0289] Although several embodiments of the present disclosure have been described above, these embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included in the scope and spirit of the invention, and are also intended to be included within the scope of the invention defined in the claims and the scope of equivalents thereof.

[0290] The functions realized by the components described herein may be implemented in a circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (a Central Processing Unit), conventional circuits, and / or combinations thereof, programmed to realize the functions described herein. A processor includes transistors and other circuits and is considered a circuitry or processing circuitry. A processor may be a programmed processor that executes a program stored in memory.

[0291] In this specification, circuitry, unit, and means are hardware programmed to perform or execute the functions described herein. Such hardware may be any hardware disclosed herein, or any hardware known to be programmed to perform or execute the functions described herein.

[0292] If the hardware is a processor that is considered to be a type of circuitry, then the circuitry, means, or unit is a combination of hardware and software used to constitute the hardware and / or processor.

[0293] (Note) The details described in each of the above embodiments are noted below.

[0294] (Note 1) A program for operating a computer having one or more computer processors, the program causing one or more computer processors to perform the following steps: obtaining information on the content of a transaction that each of several users wishes to be at least one of either the seller or the buyer of a transaction; extracting a first user to be the seller and a second user to be the buyer based on the information on the content of the transaction that each user wishes to be the seller of; making the information on the content of the transaction that each extracted user wishes to be the seller of mutually viewable among the extracted users; and accepting the specification of the content of the transaction to be traded among the extracted users and completing the transaction.

[0295] (Note 2) The program described in Appendix 1 generates a contract document containing contract terms appropriate to the transaction, presents the generated contract document to each user involved in the transaction, and records that the user has agreed to the contract document by having them electronically sign it, in the step of completing a transaction.

[0296] (Note 3) The program described in Appendix 2 acquires negotiation data exchanged between users involved in a transaction during the step of completing the transaction, identifies contract terms based on the acquired negotiation data, and generates a contract document containing the identified contract terms.

[0297] (Note 4) A program described in any of the appendices 2 to 3, which, in the step of completing a transaction, electronically signs the generated contract, indicating that the users involved in the transaction have agreed to the terms and conditions of the contract, when the payment of consideration for the transaction is made between the users involved in the transaction.

[0298] (Note 5) The program is one of the programs described in any of Appendix 2 to 4, which further performs on one or more computer processors the acquisition of information indicating that an obligation under the contract has been fulfilled, and records, in association with the contract, that the acquired obligation has been fulfilled.

[0299] (Note 6) Transactions include transfers of goods between users, and the program is one of the programs described in any of Appendix 2 to 5, which further records that ownership of the goods in a transaction has been transferred between users by recording that the users have agreed to the contract on one or more computer processors.

[0300] (Note 7) A program as described in any of the appendices 1 to 6, which in the acquisition step acquires each user's posts on a Social Network Service (SNS) where users can view each other's posts, and analyzes the content of each user's acquired SNS posts to acquire information on the content of at least one of the transactions that each user wishes to sell or buy.

[0301] (Note 8) The program is the program described in Appendix 7, which further performs the following on one or more computer processors: evaluating the reliability of the transactions desired by each user by analyzing the content of each SNS user's posts, and processing based on the evaluated reliability information.

[0302] (Note 9) The program described in Appendix 8, which evaluates the reliability of a transaction by giving a lower rating to transactions when a user, as a seller, offers to provide goods or services at different locations and at the same time, or when a user, as a buyer, offers to purchase goods or services at different locations and at the same time.

[0303] (Note 10) A program as described in any of Appendix 1 to 9, which, in the acquisition step, acquires information on both the type of transaction a user desires as a seller and the type of transaction a user desires as a buyer, and in the extraction step, extracts similar users based on both the type of transaction a user desires as a seller and the type of transaction a user desires as a buyer.

[0304] (Note 11) The program described in Appendix 10, which, in the step of completing a transaction, presents a list of transaction details desired by the transaction partner, either as a seller or a buyer, and accepts the selection of transaction details from that list.

[0305] (Note 12) The program described in Appendix 11 performs the following steps in the acquisition step: acquires each user's posts on a social networking service (SNS) where users can view each other's posts, and analyzes the content of each user's acquired SNS posts to obtain information on the content of at least one of the transactions that each user desires as a seller or as a buyer; and in the transaction completion step: uses the messaging function available on the SNS to send and receive messages between users regarding negotiations on transaction terms, acquires negotiation data sent and received via the SNS, identifies contract terms based on the acquired negotiation data, and generates a contract including the identified contract terms.

[0306] (Note 13) A method for operating a computer having one or more computer processors, the method comprising: one or more computer processors performing the steps of: obtaining information on the content of a transaction that each of several users wishes to be at least one of either the seller or the buyer of the transaction; extracting a first user to be the seller and a second user to be the buyer based on the information on the content of the transaction that each user wishes to be the seller of; making the information on the content of the transaction that each of the extracted users wishes to be the seller of mutually viewable among the extracted users; and accepting the specification of the content of the transaction to be traded among the extracted users and completing the transaction.

[0307] (Note 14) An information processing device wherein the control unit of the information processing device performs the following steps: acquiring information on the content of a transaction that each of a plurality of users desires to be at least one of either the seller or the buyer of the transaction; extracting a first user to be the seller and a second user to be the buyer based on the information on the content of the transaction that each user desires; making the information on the content of the transaction that each extracted user desires to be traded mutually viewable among the extracted users; and receiving the specification of the content of the transaction to be traded among the extracted users and completing the transaction.

Claims

1. A program for operating a computer having one or more computer processors, The program is configured on one or more computer processors. For each of the multiple users, the steps include obtaining information about the type of transaction they wish to participate in, either as a seller or a buyer, and Based on the information regarding the transaction details desired by each user, the process involves extracting a first user who will be the seller and a second user who will be the buyer. The steps include making the information on the details of the transactions that each user extracted in the extraction step wishes to trade mutually viewable among the extracted users, A program that accepts the specification of transaction details between extracted users and executes the steps to complete the transaction.

2. In the step of completing the aforementioned transaction, To generate a contract that includes contract terms corresponding to the aforementioned transaction details, The program according to claim 1, which presents the generated contract to each user involved in the transaction and records that the user has agreed to the contract by having them electronically sign it.

3. In the step of completing the aforementioned transaction, To obtain negotiation data sent and received between users in relation to transactions, The program according to claim 2, which identifies the contract terms based on the acquired negotiation data and generates a contract including the identified contract terms.

4. In the step of completing the aforementioned transaction, The program according to claim 2, wherein, with respect to the generated contract, when payment for the transaction is made between the users involved in the transaction, the program electronically signs the contract, indicating that the users involved in the transaction have agreed to the terms and conditions of the contract.

5. The program further provides the following to one or more computer processors: To obtain information indicating that the contractual obligations under the aforementioned contract have been fulfilled, The program according to claim 2, which, in association with the contract, records that the acquired obligation has been fulfilled.

6. The aforementioned transactions include the transfer of goods between users, The program further provides the following to one or more computer processors: The program according to claim 2, which records that the user has agreed to the contract, thereby recording that ownership of the goods related to the transaction has been transferred between users.

7. In the acquisition step described above, This involves retrieving each user's posts on a Social Network Service (SNS) where users can view each other's posts, The program according to claim 1, which analyzes the content of each user's SNS posts to obtain information on the content of at least one of the transactions that each user wishes to sell or buy.

8. The program further provides the following to one or more computer processors: By analyzing the content of posts from each user on the aforementioned SNS, the reliability of the transactions desired by each user can be evaluated. The program according to claim 7, which performs processing based on the evaluated reliability information.

9. In order to evaluate the reliability of the aforementioned transaction, If a user, as a seller, offers to provide goods or services at different locations at the same time, or When a user, as a buyer, receives offers to purchase goods or services at different locations and at the same time, The program according to claim 8, which includes underestimating the reliability of a transaction.

10. In the aforementioned acquisition step, information is obtained regarding both the type of transaction the user desires as a seller and the type of transaction the user desires as a buyer. The program according to claim 1, wherein in the extraction step, similar users are extracted based on both the type of transaction each user desires as a seller and the type of transaction each user desires as a buyer.

11. The program according to claim 10, which, in the step of completing the transaction, presents a list of transaction details desired by the counterparty to the transaction, either as a seller or a buyer, and accepts the selection of transaction details from the list.

12. In the acquisition step described above, Retrieving each user's posts on a social networking service where users can view each other's posts, By analyzing the content of each user's SNS posts, we obtain information on the content of at least one type of transaction that each user wishes to sell or buy. In the step of completing the transaction, the messaging function that can be sent and received on the SNS is used to allow users to send and receive messages regarding the negotiation of transaction terms. To acquire the negotiation data transmitted and received via the aforementioned SNS, Based on the data obtained from the aforementioned negotiations, the contract terms will be identified, The program according to claim 11, which generates a contract including the specified contract terms.

13. A method for operating a computer having one or more computer processors, The above method involves one or more computer processors, For each of the multiple users, the steps include obtaining information about the type of transaction they wish to participate in, either as a seller or a buyer, and Based on the information regarding the transaction details desired by each user, the process involves extracting a first user who will be the seller and a second user who will be the buyer. The steps include making the information on the details of the transactions that each user extracted in the extraction step wishes to trade mutually viewable among the extracted users, A method for receiving and executing the steps of specifying the transaction details between extracted users and completing the transaction.

14. An information processing device, The control unit of the information processing device, For each of the multiple users, the steps include obtaining information about the type of transaction they wish to participate in, either as a seller or a buyer, and Based on the information regarding the transaction details desired by each user, the process involves extracting a first user who will be the seller and a second user who will be the buyer. The steps include making the information on the details of the transactions that each user extracted in the extraction step wishes to trade mutually viewable among the extracted users, An information processing device that accepts the specification of transaction details to be exchanged between extracted users and executes the step of completing the transaction.

Images