WO2019064406A1 - 情報処理方法、プログラム及び情報処理装置 - Google Patents

情報処理方法、プログラム及び情報処理装置 Download PDF

Info

Publication number
WO2019064406A1
WO2019064406A1 PCT/JP2017/035158 JP2017035158W WO2019064406A1 WO 2019064406 A1 WO2019064406 A1 WO 2019064406A1 JP 2017035158 W JP2017035158 W JP 2017035158W WO 2019064406 A1 WO2019064406 A1 WO 2019064406A1
Authority
WO
WIPO (PCT)
Prior art keywords
condition
borrowing
lending
unit
terminal
Prior art date
Application number
PCT/JP2017/035158
Other languages
English (en)
French (fr)
Inventor
賢二 野上
松本　安英
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to JP2019545472A priority Critical patent/JP6943286B2/ja
Priority to PCT/JP2017/035158 priority patent/WO2019064406A1/ja
Priority to EP17927212.5A priority patent/EP3690786A1/en
Publication of WO2019064406A1 publication Critical patent/WO2019064406A1/ja
Priority to US16/828,116 priority patent/US20200226674A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0645—Rental transactions; Leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0283—Price estimation or determination
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0623—Item investigation
    • G06Q30/0625—Directed, with specific intent or strategy

Definitions

  • the present invention relates to technology for mediating a provider or a recipient regarding a service or product.
  • lending and borrowing of vehicles between users is supported. It can be understood that lending and borrowing of vehicles between users is a form of car sharing. Thus, an activity that supports the lending and borrowing of assets among users is called sharing economy.
  • sharing economy in addition to movable property, real estate such as land and buildings may be targeted for loan.
  • Lending such as sharing is an example of a service, and may have similar circumstances in providing other services and products.
  • An object of the present invention in one aspect, facilitates establishing a compromise agreement between a recipient or a provider.
  • the information processing method includes: (A) a first storage that stores a plurality of provision conditions of a service or a product when receiving a provided condition from a terminal of a service or product recipient; The provision condition selected in the first storage unit is searched based on the provided condition when there is no provided condition meeting the provided condition (B). The first proposal data for promoting the first agreement is transmitted to the terminal of the recipient, and (C) the second agreement is promoted according to the above-mentioned provision condition when it is determined that the recipient has refused the first agreement. 2 includes a process of transmitting proposal data to a terminal of a provider who has registered the selected provision condition.
  • FIG. 1 is a diagram showing an example of a network configuration.
  • FIG. 2 is a diagram showing an example of a sequence.
  • FIG. 3 is a diagram showing an example of the lending screen.
  • FIG. 4 is a diagram showing an example of the borrowing screen.
  • FIG. 5 is a diagram showing an example of the application screen.
  • FIG. 6 is a diagram showing an example of the update screen.
  • FIG. 7 is a diagram illustrating an example of a sequence.
  • FIG. 8 is a diagram showing an example of the module configuration of the mediation server.
  • FIG. 9 is a diagram showing an example of a lender table.
  • FIG. 10 is a diagram showing an example of the borrower table.
  • FIG. 11 is a diagram showing an example of the lending condition table.
  • FIG. 12 is a diagram showing an example of the borrowing condition table.
  • FIG. 1 is a diagram showing an example of a network configuration.
  • FIG. 2 is a diagram showing an example of a sequence.
  • FIG. 3 is
  • FIG. 13 is a diagram showing an example of a transaction table.
  • FIG. 14 is a diagram showing a lender processing flow.
  • FIG. 15 is a diagram showing a lender processing flow.
  • FIG. 16 is a diagram showing a lender processing flow.
  • FIG. 17 is a diagram showing a first search processing flow.
  • FIG. 18 is a diagram showing a lender processing flow.
  • FIG. 19 is a diagram showing a second search processing flow.
  • FIG. 20 is a diagram showing a contract processing flow.
  • FIG. 21 is a diagram showing a lender processing flow.
  • FIG. 22 is a diagram showing a borrower processing flow.
  • FIG. 23 is a diagram showing a borrower processing flow.
  • FIG. 24 is a diagram showing a third search processing flow.
  • FIG. 25 is a diagram showing a borrower processing flow.
  • FIG. 25 is a diagram showing a borrower processing flow.
  • FIG. 26 is a diagram showing a fourth search processing flow.
  • FIG. 27 is a diagram showing a borrower processing flow.
  • FIG. 28 is a diagram showing an update screen processing flow.
  • FIG. 29 is a diagram showing an application screen processing flow.
  • FIG. 30 is a functional block diagram of a computer.
  • FIG. 1 shows an example of the network configuration.
  • the present embodiment relates to a service that mediates the loan of a vehicle.
  • the lender terminals 101a to 101c connect to the mediation server 105 via the Internet.
  • the lender terminals 101a to 101c are terminals used by a user who lends a vehicle (hereinafter, referred to as a lender).
  • the lender terminals 101a to 101c are, for example, a smartphone or a personal computer.
  • the lender terminals 101a to 101c have a browser that displays a screen based on data of various screens described later.
  • the borrower terminals 103 p to r connect to the mediation server 105 via the Internet.
  • the borrower terminals 103p to 103r are terminals used by a user who borrows a vehicle (hereinafter, referred to as a borrower).
  • the borrower terminals 103p to 103r are, for example, a smartphone or a personal computer.
  • the borrower terminals 103p to 103r have a browser that displays a screen based on data of various screens described later.
  • the intermediary server 105 When the intermediary server 105 receives the lending condition from the lender terminal 101, the intermediary server 105 searches for a borrowing condition that matches the lending condition. Then, the intermediary server 105 recommends the lender a transaction according to the borrowing condition.
  • the broker server 105 when the broker server 105 receives the borrowing condition from the borrower terminal 103, the broker server 105 searches for a lending condition that matches the borrowing condition. Then, the intermediary server 105 recommends the transaction according to the lending conditions to the borrower.
  • the intermediary server 105 recommends the transaction according to the lending conditions to the borrower.
  • FIG. 2 shows an example of the sequence.
  • the lender terminal 101a registers the lending conditions to the intermediary server 105 (S201). Specifically, the lending condition is transmitted to the intermediation server 105 by inputting the lending condition on the lending screen displayed on the lender terminal 101a and performing the registration operation.
  • FIG. 3 shows an example of a lending screen displayed on the lender terminal 101a.
  • a sentence prompting the lender to enter lending conditions is displayed.
  • the lending conditions in this example relate to the type of rental car, the lending location, the lending period and the set amount.
  • the rental screen has an area for inputting a rental car type.
  • the rental vehicle type is the type of vehicle to be lent out.
  • a rental car type registered in advance by the lender is displayed as an initial value.
  • the lender may change the rental car type.
  • the lending screen has an area for inputting a lending location.
  • the lending place is a place where there is a vehicle to lend.
  • a lending place registered in advance by the lender is displayed as an initial value.
  • the lender may change the lending place.
  • the lending screen has an area for inputting a lending target period.
  • the loan target period is a period during which the lender responds to the vehicle loan.
  • the lending period is specified by the start date and the end date.
  • the lending screen has an area for entering a set amount.
  • the set amount is the amount of rent set by the lender. That is, it means that the lender has an intention to lend a vehicle with the set amount.
  • the rent in this example is assumed to be set on an hourly basis. In the example shown in FIG. 3, the set amount is 700 yen.
  • the intermediary server 105 stores the received lending conditions.
  • the intermediary server 105 searches for borrowing conditions that match the received lending conditions. In this example, the intermediary server 105 determines that there is no matching borrowing condition (S203).
  • the borrower terminal 103p registers the borrowing condition in the intermediation server 105 (S205). Specifically, the borrowing condition is transmitted to the intermediation server 105 by inputting the borrowing condition in the borrowing screen displayed on the borrower terminal 103p and performing the registration operation.
  • FIG. 4 shows an example of a borrowing screen displayed on the borrower terminal 103p.
  • the borrowing screen displays a sentence prompting the borrower to enter the terms of the borrowing.
  • the borrowing conditions in this example relate to the car type, place of borrowing, borrowing period and desired amount.
  • the borrowing screen has an area for inputting a borrowed car type.
  • the borrowed vehicle type is the type of vehicle that the borrower wants to borrow.
  • the borrowing screen has an area for inputting a borrowing place.
  • the borrowing place is a place to borrow a vehicle.
  • the borrowing place registered in advance by the borrower is displayed as an initial value.
  • the borrower may change the borrowing place.
  • the borrowing screen has an area for inputting a borrowing period.
  • the borrowing period is a period during which the borrower wants to borrow a vehicle.
  • the borrowing period is specified by the start date and the end date.
  • the borrowing screen has an area for inputting a desired amount.
  • the desired amount is the amount of rent desired by the borrower. In other words, it means that the borrower has an intention to borrow a vehicle at or below the desired amount. In the example shown in FIG. 4, the desired amount of money is 650 yen.
  • the borrowing conditions (car type, borrowing place, borrowing period, desired amount) displayed on the borrowing screen are transmitted to the intermediation server 105.
  • the intermediary server 105 searches for lending conditions that match the received borrowing conditions.
  • the intermediary server 105 determines that there is no matching lending condition (S207).
  • the mediation server 105 makes a proposal to urge the borrower to make a compromise (S209).
  • the borrower is considered to compromise on the desired amount and respond to the transaction based on the lending condition.
  • FIG. 5 shows an example of the application screen displayed on the borrower terminal 103p in accordance with the proposal of S209.
  • a sentence prompting the borrower to compromise is displayed on the application screen.
  • the lending conditions registered in S201 satisfy the conditions relating to the type of vehicle, location and period of borrowing. Therefore, the borrowing car type, the borrowing place and the borrowing period displayed on the application screen are as registered by the borrower. Then, the desired amount registered by the borrower and the set amount under the proposed lending conditions are displayed. In this way, the borrower can easily grasp the degree of compromise regarding the amount.
  • an application response is sent to the intermediary server 105.
  • the response to the application means that the transaction for the set amount has been agreed.
  • rejection button when the rejection button is selected, a rejection response is sent to the mediation server 105.
  • a denial response means that you did not agree to a transaction at the set amount.
  • the mediation server 105 makes a proposal to urge the lender to compromise (S213).
  • the lender is considered to compromise on the set amount and respond to the transaction based on the borrowing condition. In other words, the user is urged to update the set amount.
  • FIG. 6 shows an example of the update screen displayed on the lender terminal 101a according to the proposal of S213.
  • the update screen displays a statement urging the lender to compromise.
  • the borrowing conditions registered in S205 satisfy the conditions relating to the rental car type, the lending location, and the lending period. Therefore, the rental car type and the rental location displayed on the update screen are as registered by the lender.
  • the lending period is included in the lending period registered by the lender, and is the same as the borrowing period. Then, the set amount registered by the lender and the desired amount in the proposed borrowing conditions are displayed. In this way, the lender can easily capture the degree of compromise regarding the amount.
  • the update response means that the set amount is updated to the desired amount and the transaction is agreed.
  • a rejection response means that the set amount has not been updated and the transaction has not been agreed.
  • the intermediation server 105 updates the set amount from 700 yen to 650 yen, and establishes a transaction between the lender and the borrower.
  • FIG. 7 shows another example of the sequence.
  • the borrowing conditions are registered first.
  • the borrower terminal 103p registers the borrowing condition in the intermediation server 105 (S701).
  • the borrowing condition is transmitted to the intermediation server 105 by inputting the borrowing condition on the borrowing screen displayed on the borrower terminal 103p and performing the registration operation as described above.
  • the intermediary server 105 searches for lending conditions that match the received borrowing conditions. In this example, the intermediary server 105 determines that there are no matching lending conditions (S703).
  • the lender terminal 101a registers the lending conditions in the intermediary server 105 (S705).
  • the lending condition is transmitted to the intermediary server 105 by inputting the lending condition on the lending screen displayed on the lender terminal 101a and performing the registration operation as described above.
  • the intermediary server 105 searches for borrowing conditions that match the received lending conditions.
  • the intermediary server 105 determines that there is no matching borrowing condition (S 707).
  • the intermediary server 105 makes a proposal to urge the lender to make a compromise (S709).
  • the lender is considered to compromise on the set amount and respond to the transaction based on the borrowing condition.
  • the data of the update screen shown in FIG. 6 is sent to the lender terminal 101a.
  • the mediation server 105 makes a proposal to urge the borrower to compromise (S713).
  • the borrower is considered to compromise on the desired amount and respond to the transaction based on the loan condition.
  • Data of the application screen shown in FIG. 5 is sent to the borrower terminal 103p.
  • the intermediary server 105 establishes a transaction between the lender and the borrower at 700 yen of the set amount.
  • the lender and the borrower are provided with an opportunity to make a financial compromise. In this way, it is easy to make a deal. This is the end of the description of the outline in the present embodiment.
  • FIG. 8 shows an example of the module configuration of the intermediary server 105.
  • the intermediary server 105 includes a reception unit 801, a transmission unit 803, an access reception unit 805, an authentication unit 807, a control unit 809, a first condition reception unit 811, a second condition reception unit 813, a proposal unit 815, a search unit 817, and a contracting unit. It has 819.
  • the receiving unit 801 receives various data.
  • the transmission unit 803 transmits various data.
  • the access acceptance unit 805 accepts access to a predetermined URL (Uniform Resource Locator).
  • the authentication unit 807 performs user authentication.
  • the control unit 809 controls processing in the mediation server 105.
  • the first condition receiving unit 811 receives the lending conditions.
  • the second condition receiving unit 813 receives the borrowing condition.
  • the proposal unit 815 makes a proposal to the borrower and the lender.
  • the search unit 817 searches for a borrowing condition and a lending condition.
  • the contracting part 819 processes a contract based on the borrowing condition and the lending condition.
  • the intermediary server 105 further includes a lender table storage unit 831, a borrower table storage unit 833, a first condition table storage unit 835, a second condition table storage unit 837, a transaction table storage unit 839, and an internal parameter storage unit 841.
  • a lender table storage unit 831 stores the lender table.
  • the lender table will be described later with reference to FIG.
  • the borrower table storage unit 833 stores the borrower table.
  • the borrower table will be described later with reference to FIG.
  • the first condition table storage unit 835 stores the lending condition table.
  • the lending condition table will be described later with reference to FIG.
  • the second condition table storage unit 837 stores a borrowing condition table.
  • the borrowing condition table will be described later with reference to FIG.
  • the transaction table storage unit 839 stores a transaction table.
  • the transaction table will be described later with reference to FIG.
  • the internal parameter storage unit 841 stores the borrowing conditions extracted from the borrowing condition table in the process of the first search process and the process of the second search process described later.
  • the internal parameter storage unit 841 stores the lending conditions extracted from the lending condition table in the process of the third search process and the process of the fourth search process described later.
  • the reception unit 801, transmission unit 803, access reception unit 805, authentication unit 807, control unit 809, first condition reception unit 811, second condition reception unit 813, proposal unit 815, search unit 817, and contract unit 819 described above It is realized using hardware resources (for example, FIG. 30) and a program that causes a central processing unit (CPU) 2503 to execute the processing described below.
  • CPU central processing unit
  • the lender table storage unit 831, the borrower table storage unit 833, the first condition table storage unit 835, the second condition table storage unit 837, the transaction table storage unit 839, and the internal parameter storage unit 841 are hardware resources (for example, 30).
  • FIG. 9 shows an example of the lender table.
  • the lender table in this example has a record corresponding to the lender.
  • the records in the lender table are fields for storing the lender ID, fields for storing the account name, fields for storing the password, fields for storing the name, fields for storing the mail address, and lending. It has a field in which a vehicle type is stored and a field in which a rental location is stored.
  • the lender ID identifies the lender.
  • the account name and password are used for user authentication of the lender.
  • the name is the lender's name.
  • the email address is the lender's email address. Rental car types and locations are as described above. When the lender performs user registration, a record of the lender is provided.
  • FIG. 10 shows an example of the borrower table.
  • the borrower table in this example has records corresponding to the borrower.
  • the borrower table records are fields for storing borrower IDs, fields for storing account names, fields for storing passwords, fields for storing names, fields for storing e-mail addresses, and borrowing. It has a field in which a place is stored.
  • the borrower ID identifies the borrower.
  • the account name and password are used for user authentication of the borrower.
  • the name is the name of the borrower.
  • the email address is the borrower's email address. The borrowing place is as described above.
  • FIG. 11 shows an example of the lending condition table.
  • the lending condition table in this example has a record corresponding to the lending condition.
  • the records of the lending condition table include a field in which the lending condition ID is stored, a field in which the lender ID is stored, a field in which the rental car type is stored, a field in which the lending location is stored, and a field of the lending period. , And a field in which the set amount is stored.
  • the lending condition ID identifies the lending condition.
  • the lender ID identifies the lender who has registered the lending conditions.
  • the rental car type, the lending location and the lending period are as described above.
  • the fields of the lending period have a field in which the start date and time are stored and a field in which the end date and time are stored.
  • the set amount is as described above.
  • FIG. 12 shows an example of the borrowing condition table.
  • the borrowing condition table in this example has a record corresponding to the borrowing condition.
  • the records of the borrowing condition table are a field in which the borrowing condition ID is stored, a field in which the borrower ID is stored, a field in which the borrowing car type is stored, a field in which the borrowing place is stored, and a field of the borrowing period. And a field in which a desired amount of money is stored.
  • the borrowing condition ID identifies the borrowing condition.
  • the borrower ID specifies the borrower who has registered the borrowing conditions.
  • the borrowing vehicle type, the borrowing location and the borrowing period are as described above.
  • the field of the borrowing period has a field in which the start date and time is stored, and a field in which the end date and time is stored. The desired amount is as described above.
  • FIG. 13 shows an example of the transaction table.
  • the transaction table in this example has a record corresponding to the transaction relating to the lease.
  • the record of the transaction table includes a field for storing a transaction ID, a field for storing a lender ID, a field for storing a borrower ID, a field for storing a rental car type, and a field for storing a lending location. , A lending period field, and a field in which a fixed amount is stored.
  • the transaction ID identifies the transaction involved in the rental.
  • the lender ID identifies the lender in the transaction.
  • the borrower ID identifies the borrower in the transaction.
  • the rental vehicle type is the type of vehicle lent out by the transaction.
  • a lending place is a place where a vehicle is lent out by the transaction.
  • the lending period is a period in which a vehicle is lent out by the transaction.
  • the loan period field has a field in which the start date and time is stored, and a field in which the end date and time is stored.
  • the fixed amount specifies the rent of the loan in the transaction.
  • the access receiving unit 805 receives an access to the URL dedicated to the lender through the receiving unit 801 (S1401). Here, it is assumed that the lender terminal 101 accesses the URL.
  • the authentication unit 807 transmits the login screen data to the lender terminal 101 via the transmission unit 803 (S1403).
  • the login screen accepts input of an account name and password.
  • the receiving unit 801 receives the account name and password from the lender terminal 101 (S1405), and the authenticating unit 807 obtains the account name and password.
  • the authentication unit 807 executes the user authentication process based on the account name and the password (S1407).
  • the authentication unit 807 determines, based on the lender table, whether the account name and password are valid. If the account name and password are valid, the authentication unit 807 specifies a lender ID corresponding to the account name and password.
  • the control unit 809 determines whether user authentication has succeeded (S1409). If it is determined that the user authentication is not successful, the control unit 809 transmits data of the user authentication failure screen to the lender terminal 101 via the transmission unit 803 (S1411). Then, the process returns to the process shown in S1401 and repeats the above-described process.
  • the control unit 809 transmits the data of the menu screen to the lender terminal 101 via the transmission unit 803 (S1413).
  • the menu screen receives an instruction of “registration of lending conditions” and an end instruction.
  • the description of other instructions on the menu screen is omitted.
  • the receiving unit 801 receives an instruction on the menu screen from the lender terminal 101 (S1415), and the control unit 809 obtains the instruction.
  • the control unit 809 determines whether an instruction of “registration of lending conditions” has been received (S1417).
  • control unit 809 determines whether an end instruction has been received (S1419). If it is determined that the end instruction has been obtained, the lender processing is ended.
  • the first condition receiving unit 811 acquires a rental car type corresponding to the lender ID specified by the user authentication from the lender table, and sets the rental car type as an initial value in the data of the lending screen (S1501).
  • the first condition receiving unit 811 acquires the lending place corresponding to the lender ID from the lender table, and sets the lending place to an initial value in the data of the lending screen (S1503).
  • the first condition receiving unit 811 transmits the data of the lending screen to the lender terminal 101 via the transmitting unit 803 (S1505).
  • the receiving unit 801 receives the lending conditions (a rental car type, a lending place, a lending target period, and a set amount) from the lender terminal 101 (S1507), and the first condition accepting unit 811 obtains the lending conditions.
  • the first condition receiving unit 811 sets a new record in the lending condition table, and sets the received lending condition (S1509).
  • the first condition receiving unit 811 assigns the lending condition ID to the new record.
  • the first condition receiving unit 811 stores the lender ID specified by the user authentication in the new record.
  • the processing shifts to the processing of S1601 shown in FIG. 16 via the terminal B.
  • the search unit 817 executes a first search process (S1601).
  • the search unit 817 searches for a borrowing condition that matches the lending condition received in S1507 of FIG.
  • FIG. 17 shows a first search processing flow.
  • the searching unit 817 identifies one borrowing condition in the borrowing condition table (S1701). Specifically, the search unit 817 identifies one record in the borrowing condition table.
  • the searching unit 817 determines whether or not the borrowed car type of the specified borrowing condition matches the loaned car type of the lending condition received in S1507 of FIG. 15 (S1703). If it is determined that the borrowing vehicle type does not match the rental vehicle type, the processing proceeds to S1713.
  • the searching unit 817 determines whether the borrowing place of the specified borrowing condition matches the lending place of the lending condition (S1705) . If it is determined that the borrowing place does not coincide with the lending place, the processing proceeds to step S1713.
  • the searching unit 817 determines whether the borrowing period of the specified borrowing condition is included in the lending target period of the lending condition (S1707). If it is determined that the borrowing period is not included in the lending period, the processing proceeds to step S1713.
  • the searching unit 817 determines whether the desired amount of the specified borrowing condition is equal to or more than the set amount of the lending condition ( S1709). If it is determined that the desired amount is less than the set amount, the process proceeds to the process of S1713.
  • the search unit 817 stores the specified borrowing condition in the internal parameter storage unit 841 (S1711).
  • the searching unit 817 determines whether there is an unspecified borrowing condition in S1701 (S1713). If it is determined that there is an unspecified borrowing condition, the process returns to the process shown in S1701 and repeats the above-described process.
  • the proposing unit 815 determines whether there is a matching borrowing condition as a result of the first search processing (S1603). Specifically, the proposal unit 815 determines whether or not the borrowing condition is stored in the internal parameter storage unit 841 in the first search process.
  • the proposal unit 815 identifies one matching borrowing condition (S1605). Specifically, the proposal unit 815 identifies one borrowing condition stored in the internal parameter storage unit 841 in the first search process.
  • the proposal unit 815 generates data of the application screen based on the specified borrowing condition (S1607).
  • the application screen generated at this time displays the registered borrowing conditions and accepts an application by user operation.
  • the proposal unit 815 activates the application screen process.
  • the application screen process will be described later with reference to FIG.
  • the proposal unit 815 generates a proposal e-mail with a link to the application screen attached (S1609). That is, the URL of the application screen is described in the proposal email. In the proposal email, it is described that the lending condition that satisfies the borrowing condition is registered.
  • the proposing unit 815 transmits a proposal e-mail addressed to the borrower terminal 103 corresponding to the borrowing condition via the transmitting unit 803 (S1611). Specifically, an email with a borrower's email address set as the destination is sent to the email server.
  • the proposing unit 815 determines whether or not there is an unspecified borrowing condition in S1605 (S1613). If it is determined that there is an unspecified borrowing condition, the process returns to the process shown in S1605 and repeats the above-described process.
  • the search unit 817 executes the second search process (S1801).
  • the search unit 817 searches for a borrowing condition that satisfies the conditions other than the desired amount in the second search process.
  • FIG. 19 shows a second search processing flow.
  • the searching unit 817 identifies one borrowing condition in the borrowing condition table (S1901). Specifically, the search unit 817 identifies one record in the borrowing condition table.
  • the searching unit 817 determines whether the borrowing car type of the specified borrowing condition matches the lending car type of the lending condition received in S1507 of FIG. 15 (S1903). If it is determined that the borrowed vehicle type does not match the loaned vehicle type, the process proceeds to S1911.
  • the searching unit 817 determines whether the borrowing place of the specified borrowing condition matches the lending place of the lending condition (S1905) . If it is determined that the borrowing place does not match the lending place, the process proceeds to the process of S1911.
  • the searching unit 817 determines whether the borrowing period of the specified borrowing condition is included in the lending target period of the lending condition (S1907). ). If it is determined that the borrowing period is not included in the lending period, the process proceeds to the processing of S1911.
  • the searching unit 817 stores the specified borrowing condition in the internal parameter storage unit 841 (S1909).
  • the searching unit 817 determines whether there is an unspecified borrowing condition in S1901 (S1911). If it is determined that there is an unspecified borrowing condition, the process returns to the process shown in S1901 and repeats the above-described process.
  • the search unit 817 determines whether the internal parameter storage unit 841 stores the borrowing condition (S1913).
  • the searching unit 817 specifies the borrowing condition having the highest desired amount among the stored borrowing conditions (S1915). Then, after the second search processing is completed, the processing returns to the lender processing.
  • the searching unit 817 determines that there is no corresponding borrowing condition (S1917). Then, after the second search processing is completed, the processing returns to the lender processing.
  • the proposing unit 815 determines whether or not there is a corresponding borrowing condition as a result of the second search process (S1803).
  • the proposal unit 815 generates data of the update screen (S1805). For example, data of the update screen shown in FIG. 6 is generated.
  • the proposal unit 815 transmits the data of the update screen to the lender terminal 101 via the transmission unit 803 (S1807). Thereafter, the proposal unit 815 determines whether the reception unit 801 has received an update response from the lender terminal 101 (S1809).
  • the contracting unit 819 executes contract processing (S1811).
  • the contracting part 819 concludes a transaction in the contract processing on the basis of the applicable borrowing conditions.
  • FIG. 20 shows the process flow of the agreement.
  • the contracting part 819 generates a new record of the transaction table (S2001). At this time, the contracting part 819 assigns a transaction ID.
  • the lender ID specified by user authentication is stored.
  • the borrower ID In the field of the borrower ID, the borrower ID corresponding to the corresponding borrowing condition is stored.
  • the loan vehicle type field stores the borrowing vehicle type of the borrowing condition.
  • the lending place field stores the borrowing place of the borrowing condition.
  • the start date and time of the loan period is stored in the field of the start date and time of the loan period.
  • the ending date and time of the borrowing period is stored in the field of the ending date and time of the lending period.
  • the fixed amount field stores the desired amount of borrowing conditions.
  • the contracting unit 819 transmits the notification e-mail addressed to the e-mail address corresponding to the lender ID through the transmitting unit 803 (S2003).
  • the notification mail describes that the transaction has been established with the updated set amount.
  • the contracting unit 819 deletes the record of the lending condition provided in the lending condition table in S1509 of FIG. 15 (S2005). However, the contracting unit 819 may correct the lending target period under the corresponding lending condition without deleting the record.
  • the contracting unit 819 transmits a notification e-mail addressed to the e-mail address corresponding to the borrower ID via the transmitting unit 803 (S2007).
  • the notification mail describes that the transaction based on the registered borrowing conditions is established.
  • the process returns to the calling party's lender process.
  • the contracting part 819 deletes the record of the corresponding borrowing condition in the borrowing condition table (S 1813). Then, the lender processing is finished.
  • the proposing unit 815 generates the data of the application screen shown in FIG. 5 based on the borrowing conditions determined to be applicable in S1803 of FIG. 18 (S2101). At this time, the proposal unit 815 activates the application screen process.
  • the application screen process will be described later with reference to FIG.
  • the proposal unit 815 generates a proposal e-mail with a link to the application screen attached (S2103). That is, the URL of the application screen is described in the proposal email. In the proposal e-mail, it is described that the lending conditions that satisfy the borrowing conditions other than the desired amount have been registered.
  • the proposing unit 815 transmits the proposal e-mail addressed to the borrower terminal 103 corresponding to the borrowing condition via the transmitting unit 803 (S2105). Specifically, an email with a borrower's email address set as the destination is sent to the email server. Then, the lender processing is finished.
  • the access acceptance unit 805 accepts access to the borrower-specific URL via the reception unit 801 (S2201).
  • the borrower terminal 103 accesses the URL.
  • the authentication unit 807 transmits the login screen data to the lender terminal 101 via the transmission unit 803 (S2203).
  • the login screen accepts input of an account name and password.
  • the receiving unit 801 receives the account name and password from the lender terminal 101 (S2205), and the authenticating unit 807 obtains the account name and password.
  • the authentication unit 807 executes the user authentication process based on the account name and the password (S2207).
  • the authentication unit 807 determines whether the account name and password are valid based on the borrower table. If the account name and password are valid, the authentication unit 807 identifies the borrower ID.
  • the control unit 809 determines whether user authentication has succeeded (S2209). If it is determined that the user authentication is not successful, the control unit 809 transmits data of a user authentication failure screen addressed to the borrower terminal 103 via the transmission unit 803 (S2211). Then, the process returns to the process shown in S2201, and the above process is repeated.
  • the control unit 809 transmits the data of the menu screen to the borrower terminal 103 via the transmission unit 803 (S2213).
  • the menu screen receives an instruction of “registration of borrowing conditions” and an end instruction.
  • the description of other instructions on the menu screen is omitted.
  • the receiving unit 801 receives an instruction on the menu screen from the borrower terminal 103 (S2215), and the control unit 809 obtains the instruction.
  • the control unit 809 determines whether an instruction of “registration of borrowing conditions” has been received (S2217).
  • control unit 809 determines whether or not the end instruction has been obtained (S2219). If it is determined that the end instruction has been obtained, the borrower process is ended.
  • the second condition receiving unit 813 acquires the borrowing place corresponding to the borrower ID specified by the user authentication from the borrower table, and sets the rental car type as the initial value in the data of the borrowing screen (S2301).
  • the second condition reception unit 813 transmits the data of the borrowing screen to the borrower terminal 103 via the transmission unit 803 (S2303).
  • the receiving unit 801 receives the borrowing condition (car type, place, period and desired amount) (S2305), and the second condition receiving unit 813 obtains the borrowing condition.
  • the search unit 817 executes the third search process (S2307).
  • the search unit 817 searches for a lending condition that matches the borrowing condition received in S2305 of FIG.
  • FIG. 24 shows a third search processing flow.
  • the searching unit 817 identifies one lending condition in the lending condition table (S2401). Specifically, the search unit 817 identifies one record in the lending condition table.
  • the searching unit 817 determines whether the rental car type of the specified rental condition matches the borrowing vehicle type of the borrowing condition received in S2305 of FIG. 23 (S2403). If it is determined that the rental car type does not match the borrowing car type, the processing proceeds to S2413.
  • the search unit 817 determines whether the specified lending condition of the lending condition matches the borrowing location of the borrowing condition (S2405). If it is determined that the lending place does not match the borrowing place, the processing proceeds to step S2413.
  • the searching unit 817 determines whether the lending target period of the specified lending condition includes the borrowing period of the borrowing condition (S2407). . If it is determined that the lending target period does not include the borrowing period, the processing proceeds to step S2413.
  • the search unit 817 determines whether the set amount of the specified lending condition is less than or equal to the desired amount of the borrowing condition (S2409). If it is determined that the set amount exceeds the desired amount, the process proceeds to the process of S2413.
  • the search unit 817 stores the specified lending condition in the internal parameter storage unit 841 (S2411).
  • the searching unit 817 determines whether there is an unspecified lending condition in S2401 (S2413). If it is determined that there are unspecified lending conditions, the process returns to the process shown in S2401 and repeats the above-described process. On the other hand, when it is determined that there is no unspecified lending condition, the third search processing is finished, and the processing is returned to the calling source borrower processing.
  • the proposing unit 815 determines whether there is a matching lending condition (S2309). Specifically, the proposal unit 815 determines whether the lending condition is stored in the internal parameter storage unit 841 in the third search process.
  • the proposal unit 815 If it is determined that there is a matching lending condition, the proposal unit 815 generates data of an application screen relating to the matching lending condition (S2311). Data of the application screen shown in FIG. 5 is generated. When there are a plurality of matching lending conditions, the proposal unit 815 selects one lending condition and generates data of an application screen relating to the one lending condition. The method of selecting one lending condition is arbitrary. The proposing unit 815 may select, for example, a lending condition with the lowest setting amount.
  • the proposal unit 815 transmits data of the application screen to the borrower terminal 103 via the transmission unit 803 (S2313).
  • the proposing unit 815 determines whether the receiving unit 801 has received an application response from the borrower terminal 103 within a predetermined time (S2315). If the receiving unit 801 determines that the application response has been received from the borrower terminal 103, the contracting unit 819 executes contract processing (S2317). The contracting unit 819 establishes a transaction in contract processing based on the borrowing condition received in S2305 of FIG. 23 and the matching lending condition.
  • the execution unit 819 generates a new record of the transaction table (S2001).
  • the contracting part 819 assigns a transaction ID.
  • a lender ID corresponding to the matching lending condition is stored.
  • the borrower ID specified in the user authentication is stored in the field of the borrower ID.
  • the loan vehicle type field stores the borrowing vehicle type of the borrowing condition.
  • the lending place field stores the borrowing place of the borrowing condition.
  • the start date and time of the loan period is stored in the field of the start date and time of the loan period.
  • the ending date and time of the borrowing period is stored in the field of the ending date and time of the lending period.
  • the fixed amount field stores the set amount of the matching lending conditions.
  • the contracting unit 819 transmits the notification e-mail addressed to the e-mail address corresponding to the lender ID through the transmitting unit 803 (S2003).
  • the notification e-mail it is described that the transaction has been established with the set amount of the matching lending conditions.
  • the contracting part 819 deletes the record of the lending condition in the lending condition table (S2005). However, the contracting unit 819 may correct the lending target period under the corresponding lending condition without deleting the record.
  • the contracting unit 819 transmits a notification e-mail addressed to the e-mail address corresponding to the borrower ID via the transmitting unit 803 (S2007).
  • the notification mail describes that the transaction based on the accepted borrowing condition is established. After completion of the execution process, the process returns to the caller borrower process.
  • the proposing unit 815 transmits the data of the non-corresponding screen to the borrower terminal 103 via the transmitting unit 803 (S2501). In the not applicable screen, it is displayed that the lending conditions that meet the borrowing conditions are not registered. Further, the non-applicable screen receives an instruction requiring proposal and an instruction not requiring proposal.
  • the receiving unit 801 receives an instruction on the non-applicable screen from the borrower terminal 103 (S2503), and the proposal unit 815 obtains the received instruction.
  • the proposing unit 815 determines whether an instruction requiring proposal has been obtained (S2505). If it is determined that the instruction requiring proposal is not obtained, that is, if the instruction not requiring proposal is obtained, the process returns to the process of S2213 shown in FIG.
  • the search unit 817 executes the fourth search process (S2507).
  • the search unit 817 searches for a lending condition that satisfies the conditions other than the set amount. Note that the process from S2501 to S2505 may be omitted, and the process may move from the terminal H to the process of S2507.
  • FIG. 26 shows a fourth search processing flow.
  • the searching unit 817 identifies one lending condition in the lending condition table (S2601). Specifically, the search unit 817 identifies one record in the lending condition table.
  • the searching unit 817 determines whether the rental car type of the specified lending condition matches the borrowing car type of the borrowing condition received in S2305 of FIG. 23 (S2603). If it is determined that the rental car type does not match the borrowing car type, the processing proceeds to S2611.
  • the search unit 817 determines whether the specified lending condition of the lending condition matches the borrowing location of the borrowing condition (S2605). If it is determined that the lending place does not coincide with the borrowing place, the processing proceeds to step S2611.
  • the searching unit 817 determines whether the lending target period of the specified lending condition includes the borrowing period of the borrowing condition (S2607). If it is determined that the lending target period does not include the borrowing period, the processing proceeds to S2611.
  • the searching unit 817 stores the identified lending condition in the internal parameter storage unit 841 (S2609).
  • the searching unit 817 determines whether there is an unspecified lending condition in S2601 (S2611). If it is determined that there are unspecified lending conditions, the process returns to the process shown in S2601 and repeats the above-described process.
  • the search unit 817 determines whether the lending condition is stored in the internal parameter storage unit 841 (S2613).
  • the searching unit 817 specifies the lending condition having the lowest setting amount among the stored lending conditions (S2615). Then, after the fourth search processing is finished, the processing returns to the borrower processing.
  • the searching unit 817 determines that there is no corresponding lending condition (S2617). Then, after the fourth search processing is finished, the processing returns to the borrower processing.
  • the proposing unit 815 determines whether there is a corresponding lending condition (S2509).
  • the proposal unit 815 transmits data of the non-applicable screen to the borrower terminal 103 via the transmission unit 803 (S2511).
  • the N / A screen displays that there are no proposed loan conditions.
  • the non-appearance screen receives a user operation of confirmation.
  • the proposing unit 815 waits for the reception of the confirmation response by the receiving unit 801 (S2513), sets a new record in the borrowing condition table, and sets the borrowing condition received in S2305 of FIG. 23 (S2515). At this time, the proposal unit 815 assigns the borrowing condition ID to the new record. Also, the proposal unit 815 stores the borrower ID specified by the user authentication in the new record. The process returns to the process of S2213 shown in FIG.
  • the proposing unit 815 generates data of the application screen (S 2701). Data of the application screen shown in FIG. 5 is generated.
  • the proposing unit 815 transmits data of the application screen to the borrower terminal 103 via the transmitting unit 803 (S2703).
  • the proposing unit 815 determines whether the receiving unit 801 has received an application response from the borrower terminal 103 (S2705).
  • the contracting unit 819 executes contract processing (S2707). Returning from the contract processing to the borrower processing ends the borrower processing.
  • the proposing unit 815 determines whether the receiving unit 801 has received a rejection response from the borrower terminal 103. (S2709). If the receiving unit 801 determines that the refusal response has not been received from the borrower terminal 103, the process returns to the process shown in S2705, and the above-described process is repeated.
  • the proposing unit 815 provides a new record in the borrowing condition table, and sets the borrowing condition received in S2305 of FIG. S2711). At this time, the proposal unit 815 assigns the borrowing condition ID to the new record. Also, the proposal unit 815 stores the borrower ID specified by the user authentication in the new record.
  • the proposal unit 815 generates data of the update screen (S2713). Data of the update screen shown in FIG. 6 is generated. At this time, the proposal unit 815 activates the update screen process. The update screen process will be described later with reference to FIG.
  • the proposal unit 815 generates a proposal email with a link to the update screen attached (S2715). That is, the URL of the update screen is described in the proposal email. In the proposal email, it is described that the transaction is established if the set amount is updated to the same amount as the desired amount.
  • the proposal unit 815 transmits, via the transmission unit 803, the proposal mail addressed to the lender terminal 101 corresponding to the lending condition determined to be applicable in the fourth search process (S2717). Specifically, an e-mail with the lender's e-mail address set as the destination is sent to the e-mail server. Then, the processing returns to the processing shown in S2213 of FIG. 22 through the terminal G, and the above-described processing is repeated.
  • FIG. 28 shows the update screen processing flow.
  • the access acceptance unit 805 accepts access to the URL of the update screen via the reception unit 801 (S2801).
  • the lender terminal 101 accesses the URL.
  • the access receiving unit 805 specifies the borrowing condition ID and the lending condition ID, for example, by the parameter added to the URL.
  • the borrowing condition is specified by the borrowing condition ID
  • the lending condition is specified by the lending condition ID.
  • the proposal unit 815 transmits the data of the update screen to the lender terminal 101 via the transmission unit 803 (S2803).
  • the proposing unit 815 determines whether the receiving unit 801 receives an update response from the lender terminal 101 (S2805).
  • the contracting unit 819 executes a contracting process (S2807).
  • the contracting unit 819 deletes the record corresponding to the borrowing condition ID in the borrowing condition table (S2809). Then, the update screen process ends.
  • the proposing unit 815 determines whether the receiving unit 801 has received a rejection response from the lender terminal 101. (S2811).
  • the process returns to the process shown in S2805, and the above-described process is repeated.
  • the receiving unit 801 determines that the refusal response has been received from the lender terminal 101, the update screen process is finished as it is.
  • FIG. 29 shows the application screen processing flow.
  • the access acceptance unit 805 accepts access to the URL of the application screen via the reception unit 801 (S2901).
  • the borrower terminal 103 accesses the URL.
  • the access receiving unit 805 specifies the borrowing condition ID and the lending condition ID, for example, by the parameter added to the URL. Then, the borrowing condition is specified by the borrowing condition ID, and the lending condition is specified by the lending condition ID.
  • the proposing unit 815 transmits data of the application screen to the borrower terminal 103 via the transmitting unit 803 (S2903).
  • the proposing unit 815 determines whether the receiving unit 801 has received an application response from the borrower terminal 103 (S2905).
  • the contracting unit 819 executes contract processing (S2907). Also, the contracting part 819 deletes the record corresponding to the borrowing condition ID in the borrowing condition table (S2909). Then, the application screen process ends.
  • the proposing unit 815 determines whether the receiving unit 801 has received a rejection response from the borrower terminal 103. (S2911).
  • the receiving unit 801 determines that the refusal response has not been received from the borrower terminal 103, the process returns to the process shown in S2905, and the above-described process is repeated.
  • the application screen processing ends.
  • the present embodiment it is easy to make a deal by compromise of the borrower or the lender.
  • the borrower is an example of a service provider.
  • the application for borrowing is an example of an agreement with the provider of the service.
  • the present embodiment may be applied to the value for the product when the product is provided.
  • the present invention is not limited to this.
  • the functional block configuration described above may not match the program module configuration.
  • each storage area described above is an example, and the configuration is not necessarily as described above. Furthermore, in the processing flow, as long as the processing result does not change, the order of the processing may be changed or a plurality of processing may be executed in parallel.
  • the above-described intermediary server 105 is a computer device, and as shown in FIG. 30, a display control connected to the memory 2501, the CPU 2503, the hard disk drive (HDD: Hard Disk Drive) 2505 and the display device 2509.
  • a bus 2519 is connected to the unit 2507, the drive device 2513 for the removable disk 2511, the input device 2515, and the communication control unit 2517 for connecting to the network.
  • An operating system (OS: Operating System) and an application program for performing processing in the present embodiment are stored in the HDD 2505 and read out from the HDD 2505 to the memory 2501 when executed by the CPU 2503.
  • the CPU 2503 controls the display control unit 2507, the communication control unit 2517, and the drive device 2513 according to the processing content of the application program to perform a predetermined operation. Further, data in the middle of processing is mainly stored in the memory 2501, but may be stored in the HDD 2505.
  • an application program for performing the above-described processing is stored and distributed in a computer readable removable disk 2511 and installed from the drive device 2513 into the HDD 2505. It may be installed in the HDD 2505 via a network such as the Internet and the communication control unit 2517.
  • Such a computer device realizes various functions as described above by organic cooperation between hardware such as the CPU 2503 and the memory 2501 described above and programs such as the OS and application programs. .
  • the information processing method includes: (A) the first storage unit storing a plurality of provision conditions of the service or the product when the provided condition is received from the terminal of the service or the recipient of the product; The first agreement according to the provided condition selected in the first storage unit is searched based on the provided condition when there is no provided condition meeting the provided condition (B). The first proposal data to be prompted is transmitted to the terminal of the recipient, and (C) the second proposal data to prompt the second agreement according to the above-mentioned provision condition when it is determined that the recipient has refused the first agreement And transmitting the selected provision conditions to the terminal of the registered provider.
  • the above information processing method further conforms to the provision condition in the second storage unit that stores a plurality of provided conditions of the service or the product when the provision condition is received from the terminal of the provider of the (D) service or the product.
  • a process of searching for a provided condition may be included.
  • the above information processing method further includes (E) promoting the third agreement based on the provided conditions selected in the second storage unit based on the provided conditions when there is no provided condition meeting the provided conditions.
  • a process of transmitting the proposal data to the terminal of the provider may be included.
  • the above information processing method further registers the to-be-provided condition selected as described above, with the fourth proposal data promoting the fourth agreement according to the provision condition when it is determined that the (E) provider has refused the third agreement
  • a process of transmitting to the terminal of the recipient may be included.
  • provision conditions may relate to the service or the set charge of the above-mentioned goods.
  • the provided condition may be related to a desired charge for the service or the product.
  • a program for causing a computer to perform the processing according to the above method can be created, and the program is, for example, a computer readable storage medium such as a flexible disk, a CD-ROM, an It may be stored in a storage device.
  • the intermediate processing results are generally temporarily stored in a storage device such as a main memory.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Engineering & Computer Science (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一態様に係る本実施の形態に係る情報処理方法は、（Ａ）サービス又は商品の被提供者の端末から被提供条件を受信した場合に、サービス又は商品の提供条件を複数記憶する第１記憶部において上記被提供条件に適合する提供条件を探索し、（Ｂ）上記被提供条件に適合する提供条件がない場合に、上記被提供条件に基づいて、第１記憶部において選び出した提供条件による第１合意を促す第１提案データを、被提供者の端末へ送信し、（Ｃ）被提供者が第１合意を拒んだと判定した場合に、上記被提供条件による第２合意を促す第２提案データを、上記選び出した提供条件を登録した提供者の端末へ送信する処理を含む。

Description

情報処理方法、プログラム及び情報処理装置
　本発明は、サービス又は商品に関する提供者と被提供者とを仲介する技術に関する。
　例えば、Ｗｅｂサーバにおいて、ユーザ間における車両の貸し借りを支援することがある。ユーザ間における車両の貸し借りは、カーシェアリングの１形態であるという捉え方がある。このように、ユーザ間における資産の貸し借りを支援する活動を、シェアリング・エコノミーという。シェアリング・エコノミーでは、動産の他に、土地や建物などの不動産を貸借の対象とすることもある。
　シェアリング・エコノミーの場合には、誰でも貸し手になることができるので、料金の設定も自由であることが多い。従って、同種の物を借りる場合でも、登録されている貸出条件によって設定されている料金は異なる。
　しかし、貸出条件も借入条件も多様であるので、シェアリングの合意が成立し難い場合もある。尚、シェアリングのような貸借はサービスの一例であって、他のサービスや商品の提供においても同様の事情を有することがある。
特開２００６－１２７２８５号公報
　本発明の目的は、一側面では、被提供者又は提供者の妥協による合意を取り付けやすくする。
　一態様に係る本実施の形態に係る情報処理方法は、（Ａ）サービス又は商品の被提供者の端末から被提供条件を受信した場合に、サービス又は商品の提供条件を複数記憶する第１記憶部において上記被提供条件に適合する提供条件を探索し、（Ｂ）上記被提供条件に適合する提供条件がない場合に、上記被提供条件に基づいて、第１記憶部において選び出した提供条件による第１合意を促す第１提案データを、被提供者の端末へ送信し、（Ｃ）被提供者が第１合意を拒んだと判定した場合に、上記被提供条件による第２合意を促す第２提案データを、上記選び出した提供条件を登録した提供者の端末へ送信する処理を含む。
　一側面としては、被提供者又は提供者の妥協による合意を取り付けやすくなる。
図１は、ネットワーク構成例を示す図である。 図２は、シーケンスの例を示す図である。 図３は、貸出画面の例を示す図である。 図４は、借入画面の例を示す図である。 図５は、申込画面の例を示す図である。 図６は、更新画面の例を示す図である。 図７は、シーケンスの例を示す図である。 図８は、仲介サーバのモジュール構成例を示す図である。 図９は、貸し手テーブルの例を示す図である。 図１０は、借り手テーブルの例を示す図である。 図１１は、貸出条件テーブルの例を示す図である。 図１２は、借入条件テーブルの例を示す図である。 図１３は、取引テーブルの例を示す図である。 図１４は、貸し手処理フローを示す図である。 図１５は、貸し手処理フローを示す図である。 図１６は、貸し手処理フローを示す図である。 図１７は、第１探索処理フローを示す図である。 図１８は、貸し手処理フローを示す図である。 図１９は、第２探索処理フローを示す図である。 図２０は、約定処理フローを示す図である。 図２１は、貸し手処理フローを示す図である。 図２２は、借り手処理フローを示す図である。 図２３は、借り手処理フローを示す図である。 図２４は、第３探索処理フローを示す図である。 図２５は、借り手処理フローを示す図である。 図２６は、第４探索処理フローを示す図である。 図２７は、借り手処理フローを示す図である。 図２８は、更新画面処理フローを示す図である。 図２９は、申込画面処理フローを示す図である。 図３０は、コンピュータの機能ブロック図である。
［実施の形態１］
　図１に、ネットワーク構成例を示す。本実施の形態は、車両の貸借を仲介するサービスに関する。貸し手端末１０１ａ乃至ｃは、インターネットを介して仲介サーバ１０５と接続する。貸し手端末１０１ａ乃至ｃは、車両を貸し出すユーザ（以下、貸し手という）が使用する端末である。貸し手端末１０１ａ乃至ｃは、例えばスマートフォン或いはパーソナルコンピュータである。貸し手端末１０１ａ乃至ｃは、後述する各種画面のデータに基づいて、画面を表示するブラウザを有している。
　借り手端末１０３ｐ乃至ｒは、インターネットを介して仲介サーバ１０５と接続する。借り手端末１０３ｐ乃至ｒは、車両を借り入れるユーザ（以下、借り手という）が使用する端末である。借り手端末１０３ｐ乃至ｒは、例えばスマートフォン或いはパーソナルコンピュータである。借り手端末１０３ｐ乃至ｒは、後述する各種画面のデータに基づいて、画面を表示するブラウザを有している。
　仲介サーバ１０５は、貸し手端末１０１から貸出条件を受け付けた場合に、貸出条件に適合する借入条件を探索する。そして、仲介サーバ１０５は、貸し手に借入条件に応じた取引を勧める。
　また、仲介サーバ１０５は、借り手端末１０３から借入条件を受け付けた場合に、借入条件に適合する貸出条件を探索する。そして、仲介サーバ１０５は、借り手に貸出条件に応じた取引を勧める。以下、本実施の形態におけるシーケンスの例を示す。
　図２に、シーケンスの例を示す。貸し手端末１０１ａは、仲介サーバ１０５へ貸出条件を登録する（Ｓ２０１）。具体的には、貸し手が、貸し手端末１０１ａに表示された貸出画面に貸出条件を入力して登録の操作を行うことによって、貸出条件が仲介サーバ１０５へ送信される。
　図３に、貸し手端末１０１ａにおいて表示される貸出画面の例を示す。貸出画面には、貸し手に貸出条件の入力を促す文が表示される。この例における貸出条件は、貸出車種、貸出場所、貸出対象期間及び設定金額に関する。
　貸出画面は、貸出車種を入力するためのエリアを有している。貸出車種は、貸し出される車両の種類である。この例では、貸し手が予め登録しておいた貸出車種が初期値として表示される。但し、貸し手が貸出車種を変更してもよい。
　貸出画面は、貸出場所を入力するためのエリアを有している。貸出場所は、貸し出す車両が存在する場所である。この例では、貸し手が予め登録しておいた貸出場所が初期値として表示される。但し、貸し手が貸出場所を変更してもよい。
　貸出画面は、貸出対象期間を入力するためのエリアを有している。貸出対象期間は、貸し手が車両の貸し出しに応じる期間である。貸出対象期間は、開始日時と終了日時とによって特定される。
　貸出画面は、設定金額を入力するためのエリアを有している。設定金額は、貸し手が設定した賃料の金額である。つまり、貸し手が、当該設定金額で車両を貸し出す意思を有することを意味する。この例における賃料は、１時間単位で設定されるものとする。図３に示した例で、設定金額は７００円である。
　そして、登録ボタンが選択されると、貸出画面に表示されている貸出車種、貸出場所、貸出対象期間及び設定金額が、仲介サーバ１０５へ送信される。仲介サーバ１０５は、受信した貸出条件を記憶する。
　図２の説明に戻る。仲介サーバ１０５は、受信した貸出条件に適合する借入条件を探索する。この例では、仲介サーバ１０５は、適合する借入条件がないと判定する（Ｓ２０３）。
　その後、借り手端末１０３ｐは、仲介サーバ１０５へ借入条件を登録する（Ｓ２０５）。具体的には、借り手が、借り手端末１０３ｐに表示された借入画面に借入条件を入力して登録の操作を行うことによって、借入条件が仲介サーバ１０５へ送信される。
　図４に、借り手端末１０３ｐにおいて表示される借入画面の例を示す。借入画面には、借り手に借入条件の入力を促す文が表示される。この例における借入条件は、借入車種、借入場所、借入期間及び希望金額に関する。
　借入画面は、借入車種を入力するためのエリアを有している。借入車種は、借り手が借り入れたい車両の種類である。
　借入画面は、借入場所を入力するためのエリアを有している。借入場所は、車両を借り入れる場所である。この例では、借り手が予め登録しておいた借入場所が初期値として表示される。但し、借り手が借入場所を変更してもよい。
　借入画面は、借入期間を入力するためのエリアを有している。借入期間は、借り手が車両を借り入れたい期間である。借入期間は、開始日時と終了日時とによって特定される。
　借入画面は、希望金額を入力するためのエリアを有している。希望金額は、借り手が希望する賃料の金額である。つまり、借り手が、当該希望金額以下で車両を借り入れる意思を有することを意味する。図４に示した例で、希望金額は６５０円である。
　そして、登録ボタンが選択されると、借入画面に表示されている借入条件（借入車種、借入場所、借入期間及び希望金額）が、仲介サーバ１０５へ送信される。
　図２の説明に戻る。仲介サーバ１０５は、受信した借入条件に適合する貸出条件を探索する。この例では、Ｓ２０１で登録された貸出条件の場合、貸出車種、貸出場所及び貸出対象期間が適合するが、設定金額が適合しない。従って、仲介サーバ１０５は、適合する貸出条件がないと判定する（Ｓ２０７）。
　このとき、仲介サーバ１０５は、借り手に対して妥協を促す提案を行う（Ｓ２０９）。この例のように、設定金額以外で適合した貸出条件がある場合には、希望金額に関して妥協して当該貸出条件に基づく取引に応じることを、借り手に検討してもらうようにする。
　図５に、Ｓ２０９の提案に応じて借り手端末１０３ｐに表示される申込画面の例を示す。申込画面には、借り手に妥協を促す文が表示される。Ｓ２０１で登録された貸出条件は、借入車種、借入場所及び借入期間に関する条件を満足している。従って、申込画面に表示される借入車種、借入場所及び借入期間は、借り手が登録した通りである。そして、借り手が登録した希望金額と、提案する貸出条件における設定金額とが表示される。このようにすれば、借り手は、金額に関する妥協の程度を捉えやすい。
　申込ボタンが選択されると、申込の応答が仲介サーバ１０５へ送信される。申込の応答は、当該設定金額での取引に合意したことを意味する。
　一方、拒否ボタンが選択されると、拒否の応答が仲介サーバ１０５へ送信される。拒否の応答は、当該設定金額での取引に合意しなかったことを意味する。
　図２の説明に戻る。この例では、借り手端末１０３ｐから拒否の応答が、仲介サーバ１０５へ送信されたものとする（Ｓ２１１）。
　借り手端末１０３ｐから拒否の応答を受信した場合に、仲介サーバ１０５は、貸し手に対して妥協を促す提案を行う（Ｓ２１３）。この例のように、設定金額以外で適合した借入条件がある場合には、設定金額に関して妥協して当該借入条件に基づく取引に応じることを、貸し手に検討してもらうようにする。つまり、設定金額の更新を促す。
　図６に、Ｓ２１３の提案に応じて貸し手端末１０１ａに表示される更新画面の例を示す。更新画面には、貸し手に妥協を促す文が表示される。Ｓ２０５で登録された借入条件は、貸出車種、貸出場所及び貸出対象期間に関する条件を満足している。従って、更新画面に表示される貸出車種及び貸出場所は、貸し手が登録した通りである。また、貸出期間は、貸し手が登録した貸出対象期間に含まれ、借入期間と同じである。そして、貸し手が登録した設定金額と、提案する借入条件における希望金額とが表示される。このようにすれば、貸し手は、金額に関する妥協の程度を捉えやすい。
　更新ボタンが選択されると、更新の応答が仲介サーバ１０５へ送信される。更新の応答は、設定金額を希望金額と同額に更新し、取引に合意したことを意味する。
　一方、拒否ボタンが選択されると、拒否の応答が仲介サーバ１０５へ送信される。拒否の応答は、設定金額を更新せず、取引に合意しなかったことを意味する。
　図２の説明に戻る。この例では、貸し手端末１０１ａから更新の応答が、仲介サーバ１０５へ送信されたものとする（Ｓ２１５）。
　そして、仲介サーバ１０５では、設定金額を７００円から６５０円に更新し、貸し手と借り手との取引を成立させる。
　図７に、別のシーケンス例を示す。この例では、先に借入条件が登録される。借り手端末１０３ｐは、仲介サーバ１０５へ借入条件を登録する（Ｓ７０１）。上述した通り、借り手が、借り手端末１０３ｐに表示された借入画面に借入条件を入力して登録の操作を行うことによって、借入条件が仲介サーバ１０５へ送信される。
　仲介サーバ１０５は、受信した借入条件に適合する貸出条件を探索する。この例では、仲介サーバ１０５は、適合する貸出条件がないと判定する（Ｓ７０３）。
　その後、貸し手端末１０１ａは、仲介サーバ１０５へ貸出条件を登録する（Ｓ７０５）。上述した通り、貸し手が、貸し手端末１０１ａに表示された貸出画面に貸出条件を入力して登録の操作を行うことによって、貸出条件が仲介サーバ１０５へ送信される。
　仲介サーバ１０５は、受信した貸出条件に適合する借入条件を探索する。この例では、Ｓ７０１で登録された借入条件の場合、借入車種、借入場所及び借入期間が適合するが、希望金額が適合しない。従って、仲介サーバ１０５は、適合する借入条件がないと判定する（Ｓ７０７）。
　このとき、仲介サーバ１０５は、貸し手に対して妥協を促す提案を行う（Ｓ７０９）。この例のように、希望金額以外で適合した借入条件がある場合には、設定金額に関して妥協して当該借入条件に基づく取引に応じることを、貸し手に検討してもらうようにする。図６に示した更新画面のデータが貸し手端末１０１ａへ送られる。
　そして、この例では、貸し手端末１０１ａから拒否の応答が、仲介サーバ１０５へ送信されたものとする（Ｓ７１１）。
　貸し手端末１０１ａから拒否の応答を受信した場合に、仲介サーバ１０５は、借り手に対して妥協を促す提案を行う（Ｓ７１３）。この例のように、希望金額以外で適合した貸出条件がある場合には、希望金額に関して妥協して当該貸出条件に基づく取引に応じることを、借り手に検討してもらうようにする。図５に示した申込画面のデータが借り手端末１０３ｐへ送られる。
　この例では、借り手端末１０３ｐから申込の応答が、仲介サーバ１０５へ送信されたものとする（Ｓ７１５）。
　そして、仲介サーバ１０５では、設定金額の７００円で、貸し手と借り手との取引を成立させる。
　上述のように、本実施の形態では、貸し手及び借り手に、金額面での妥協の機会を提供する。このようにすれば、取引が成立し易くなる。以上で、本実施の形態における概要の説明を終える。
　以下、仲介サーバ１０５の動作について説明する。図８に、仲介サーバ１０５のモジュール構成例を示す。仲介サーバ１０５は、受信部８０１、送信部８０３、アクセス受付部８０５、認証部８０７、制御部８０９、第１条件受付部８１１、第２条件受付部８１３、提案部８１５、探索部８１７及び約定部８１９を有する。
　受信部８０１は、各種データを受信する。送信部８０３は、各種データを送信する。アクセス受付部８０５は、所定ＵＲＬ（Uniform Resource Locator）へのアクセスを受け付ける。認証部８０７は、ユーザ認証を行う。制御部８０９は、仲介サーバ１０５における処理を制御する。第１条件受付部８１１は、貸出条件を受け付ける。第２条件受付部８１３は、借入条件を受け付ける。提案部８１５は、借り手及び貸し手に対する提案を行う。探索部８１７は、借入条件の探索及び貸出条件の探索を行う。約定部８１９は、借入条件と貸出条件とに基づく約定の処理を行う。
　仲介サーバ１０５は、更に貸し手テーブル記憶部８３１、借り手テーブル記憶部８３３、第１条件テーブル記憶部８３５、第２条件テーブル記憶部８３７、取引テーブル記憶部８３９及び内部パラメータ記憶部８４１を有する。
　貸し手テーブル記憶部８３１は、貸し手テーブルを記憶する。貸し手テーブルについては、図９を用いて後述する。借り手テーブル記憶部８３３は、借り手テーブルを記憶する。借り手テーブルについては、図１０を用いて後述する。第１条件テーブル記憶部８３５は、貸出条件テーブルを記憶する。貸出条件テーブルについては、図１１を用いて後述する。第２条件テーブル記憶部８３７は、借入条件テーブルを記憶する。借入条件テーブルについては、図１２を用いて後述する。取引テーブル記憶部８３９は、取引テーブルを記憶する。取引テーブルについては、図１３を用いて後述する。内部パラメータ記憶部８４１は、後述する第１探索処理の過程及び第２探索処理の過程において借入条件テーブルから抽出された借入条件を記憶する。また、内部パラメータ記憶部８４１は、後述する第３探索処理の過程及び第４探索処理の過程において貸出条件テーブルから抽出された貸出条件を記憶する。
　上述した受信部８０１、送信部８０３、アクセス受付部８０５、認証部８０７、制御部８０９、第１条件受付部８１１、第２条件受付部８１３、提案部８１５、探索部８１７及び約定部８１９は、ハードウエア資源（例えば、図３０）と、以下で述べる処理をＣＰＵ（Central Processing Unit）２５０３に実行させるプログラムとを用いて実現される。
　上述した貸し手テーブル記憶部８３１、借り手テーブル記憶部８３３、第１条件テーブル記憶部８３５、第２条件テーブル記憶部８３７、取引テーブル記憶部８３９及び内部パラメータ記憶部８４１は、ハードウエア資源（例えば、図３０）を用いて実現される。
　貸し手テーブルについて説明する。図９に、貸し手テーブルの例を示す。この例における貸し手テーブルは、貸し手に対応するレコードを有している。貸し手テーブルのレコードは、貸し手ＩＤが格納されるフィールドと、アカウント名が格納されるフィールドと、パスワードが格納されるフィールドと、名前が格納されるフィールドと、メールアドレスが格納されるフィールドと、貸出車種が格納されるフィールドと、貸出場所が格納されるフィールドとを有している。
　貸し手ＩＤは、貸し手を識別する。アカウント名とパスワードとは、貸し手のユーザ認証に用いられる。名前は、貸し手の名前である。メールアドレスは、貸し手のメールアドレスである。貸出車種及び貸出場所は、上述した通りである。尚、貸し手がユーザ登録を行った時点で、当該貸し手のレコードが設けられる。
　借り手テーブルについて説明する。図１０に、借り手テーブルの例を示す。この例における借り手テーブルは、借り手に対応するレコードを有している。借り手テーブルのレコードは、借り手ＩＤが格納されるフィールドと、アカウント名が格納されるフィールドと、パスワードが格納されるフィールドと、名前が格納されるフィールドと、メールアドレスが格納されるフィールドと、借入場所が格納されるフィールドとを有している。
　借り手ＩＤは、借り手を識別する。アカウント名とパスワードとは、借り手のユーザ認証に用いられる。名前は、借り手の名前である。メールアドレスは、借り手のメールアドレスである。借入場所は、上述した通りである。
　貸出条件テーブルについて説明する。図１１に、貸出条件テーブルの例を示す。この例における貸出条件テーブルは、貸出条件に対応するレコードを有している。貸出条件テーブルのレコードは、貸出条件ＩＤが格納されるフィールドと、貸し手ＩＤが格納されるフィールドと、貸出車種が格納されるフィールドと、貸出場所が格納されるフィールドと、貸出対象期間のフィールドと、設定金額が格納されるフィールドとを有している。
　貸出条件ＩＤは、貸出条件を識別する。貸し手ＩＤは、当該貸出条件を登録した貸し手を特定する。貸出車種、貸出場所及び貸出対象期間は、上述した通りである。貸出対象期間のフィールドは、開始日時が格納されるフィールドと、終了日時が格納されるフィールドとを有する。設定金額は、上述した通りである。
　借入条件テーブルについて説明する。図１２に、借入条件テーブルの例を示す。この例における借入条件テーブルは、借入条件に対応するレコードを有している。借入条件テーブルのレコードは、借入条件ＩＤが格納されるフィールドと、借り手ＩＤが格納されるフィールドと、借入車種が格納されるフィールドと、借入場所が格納されるフィールドと、借入期間のフィールドと、希望金額が格納されるフィールドとを有している。
　借入条件ＩＤは、借入条件を識別する。借り手ＩＤは、当該借入条件を登録した借り手を特定する。借入車種、借入場所及び借入期間は、上述した通りである。借入期間のフィールドは、開始日時が格納されるフィールドと、終了日時が格納されるフィールドとを有する。希望金額は、上述した通りである。
　取引テーブルについて説明する。図１３に、取引テーブルの例を示す。この例における取引テーブルは、賃借に係る取引に対応するレコードを有している。取引テーブルのレコードは、取引ＩＤが格納されるフィールドと、貸し手ＩＤが格納されるフィールドと、借り手ＩＤが格納されるフィールドと、貸出車種が格納されるフィールドと、貸出場所が格納されるフィールドと、貸出期間のフィールドと、確定金額が格納されるフィールドとを有している。
　取引ＩＤは、賃借に係る取引を識別する。貸し手ＩＤは、当該取引における貸し手を特定する。借り手ＩＤは、当該取引における借り手を特定する。貸出車種は、当該取引によって貸し出される車両の種類である。貸出場所は、当該取引によって車両が貸し出される場所である。貸出期間は、当該取引によって車両が貸し出される期間である。貸出期間のフィールドは、開始日時が格納されるフィールドと、終了日時が格納されるフィールドとを有する。確定金額は、当該取引における貸借の賃料を特定する。
　続いて、仲介サーバ１０５における処理について説明する。まず、貸し手に対する処理について説明する。図１４に、貸し手処理フローを示す。
　アクセス受付部８０５は、受信部８０１を介して、貸し手専用のＵＲＬへのアクセスを受け付ける（Ｓ１４０１）。ここでは、貸し手端末１０１が、当該ＵＲＬへアクセスするものとする。
　認証部８０７は、送信部８０３を介して、貸し手端末１０１宛てにログイン画面のデータを送信する（Ｓ１４０３）。ログイン画面は、アカウント名及びパスワードの入力を受け付ける。
　受信部８０１は、貸し手端末１０１からアカウント名及びパスワードを受信し（Ｓ１４０５）、認証部８０７は、当該アカウント名及びパスワードを得る。
　認証部８０７は、当該アカウント名及びパスワードに基づいて、ユーザ認証処理を実行する（Ｓ１４０７）。認証部８０７は、貸し手テーブルに基づいて、当該アカウント名及びパスワードが正当であるか否かを判定する。また、当該アカウント名及びパスワードが正当である場合には、認証部８０７は、当該アカウント名及びパスワードに対応する貸し手ＩＤを特定する。
　制御部８０９は、ユーザ認証が成功したか否かを判定する（Ｓ１４０９）。ユーザ認証が成功していないと判定した場合には、制御部８０９は、送信部８０３を介して、貸し手端末１０１宛てにユーザ認証失敗の画面のデータを送信する（Ｓ１４１１）。そして、Ｓ１４０１に示した処理に戻って、上述した処理を繰り返す。
　一方、ユーザ認証が成功したと判定した場合には、制御部８０９は、送信部８０３を介して、貸し手端末１０１宛てにメニュー画面のデータを送信する（Ｓ１４１３）。メニュー画面は、「貸出条件の登録」の指示及び終了指示を受け付ける。ここでは、メニュー画面における他の指示についての説明を省略する。
　受信部８０１は、貸し手端末１０１からメニュー画面における指示を受信し（Ｓ１４１５）、制御部８０９は、当該指示を得る。制御部８０９は、「貸出条件の登録」の指示を得たか否かを判定する（Ｓ１４１７）。
　「貸出条件の登録」の指示を得ていないと判定した場合には、制御部８０９は、終了指示を得たか否かを判定する（Ｓ１４１９）。終了指示を得たと判定した場合には、貸し手処理を終える。
　終了指示を得ていないと判定した場合には、Ｓ１４１５に示した処理に戻って、上述した処理を繰り返す。
　Ｓ１４１７において、「貸出条件の登録」の指示を得たと判定した場合には、端子Ａを介して、図１５に示したＳ１５０１の処理に移る。
　図１５の説明に移る。第１条件受付部８１１は、貸し手テーブルから、ユーザ認証で特定された貸し手ＩＤに対応する貸出車種を取得し、当該貸出車種を貸出画面のデータにおける初期値に設定する（Ｓ１５０１）。
　第１条件受付部８１１は、貸し手テーブルから、同じく貸し手ＩＤに対応する貸出場所を取得し、当該貸出場所を貸出画面のデータにおける初期値に設定する（Ｓ１５０３）。
　そして、第１条件受付部８１１は、送信部８０３を介して、貸出画面のデータを貸し手端末１０１へ送信する（Ｓ１５０５）。
　その後、受信部８０１は、貸し手端末１０１から貸出条件（貸出車種、貸出場所、貸出対象期間及び設定金額）を受信し（Ｓ１５０７）、第１条件受付部８１１は、当該貸出条件を得る。第１条件受付部８１１は、貸出条件テーブルに新しいレコードを設けて、受信した貸出条件を設定する（Ｓ１５０９）。このとき、第１条件受付部８１１は、当該新しいレコードに貸出条件ＩＤを割り当てる。また、第１条件受付部８１１は、ユーザ認証で特定された貸し手ＩＤを当該新しいレコードに格納する。
　端子Ｂを介して、図１６に示したＳ１６０１の処理に移る。探索部８１７は、第１探索処理を実行する（Ｓ１６０１）。探索部８１７は、第１探索処理において、図１５のＳ１５０７で受信した貸出条件に適合する借入条件を探索する。
　図１７に、第１探索処理フローを示す。探索部８１７は、借入条件テーブルにおいて借入条件を１つ特定する（Ｓ１７０１）。具体的には、探索部８１７は、借入条件テーブルにおけるレコードを１つ特定する。
　探索部８１７は、特定した借入条件の借入車種が、図１５のＳ１５０７で受信した貸出条件の貸出車種と一致するか否かを判定する（Ｓ１７０３）。当該借入車種が当該貸出車種と一致しないと判定した場合には、Ｓ１７１３の処理に移る。
　一方、当該借入車種が当該貸出車種と一致すると判定した場合には、探索部８１７は、特定した借入条件の借入場所が、上記貸出条件の貸出場所と一致するか否かを判定する（Ｓ１７０５）。当該借入場所が当該貸出場所と一致しないと判定した場合には、Ｓ１７１３の処理に移る。
　一方、当該借入場所が当該貸出場所と一致すると判定した場合には、探索部８１７は、特定した借入条件の借入期間が、上記貸出条件の貸出対象期間に含まれるか否かを判定する（Ｓ１７０７）。当該借入期間が当該貸出対象期間に含まれないと判定した場合には、Ｓ１７１３の処理に移る。
　一方、当該借入期間が当該貸出対象期間に含まれると判定した場合には、探索部８１７は、特定した借入条件の希望金額が、上記貸出条件の設定金額以上であるか否かを判定する（Ｓ１７０９）。当該希望金額が当該設定金額未満であると判定した場合には、Ｓ１７１３の処理に移る。
　一方、当該希望金額が当該設定金額以上であると判定した場合には、探索部８１７は、特定した借入条件を内部パラメータ記憶部８４１に記憶する（Ｓ１７１１）。
　探索部８１７は、Ｓ１７０１において未特定の借入条件があるか否かを判定する（Ｓ１７１３）。未特定の借入条件があると判定した場合には、Ｓ１７０１に示した処理に戻って、上述した処理を繰り返す。
　一方、未特定の借入条件がないと判定した場合には、第１探索処理を終え、呼び出し元の貸し手処理に復帰する。
　図１６の説明に戻る。提案部８１５は、第１探索処理の結果、適合する借入条件があったか否かを判定する（Ｓ１６０３）。具体的には、提案部８１５は、第１探索処理において内部パラメータ記憶部８４１に借入条件を記憶したか否かを判定する。
　適合する借入条件があったと判定した場合には、提案部８１５は、適合する借入条件を１つ特定する（Ｓ１６０５）。具体的には、提案部８１５は、第１探索処理において内部パラメータ記憶部８４１に記憶された借入条件を１つ特定する。
　提案部８１５は、特定した借入条件に基づいて、申込画面のデータを生成する（Ｓ１６０７）。このとき生成される申込画面は、登録されている借入条件を表示し、ユーザ操作による申込を受け付ける。このとき提案部８１５は、申込画面処理を起動する。申込画面処理については、図２９を用いて後述する。
　更に、提案部８１５は、当該申込画面へのリンクが貼られた提案メールを生成する（Ｓ１６０９）。つまり、提案メールには、当該申込画面のＵＲＬが記述されている。提案メールには、借入条件を満たす貸出条件が登録された旨が記述される。
　提案部８１５は、送信部８０３を介して、当該借入条件に対応する借り手端末１０３宛ての提案メールを送信する（Ｓ１６１１）。具体的には、宛先に借り手のメールアドレスが設定されたメールが、メールサーバへ送られる。
　提案部８１５は、Ｓ１６０５において未特定の借入条件があるか否かを判定する（Ｓ１６１３）。未特定の借入条件があると判定した場合には、Ｓ１６０５に示した処理に戻って、上述した処理を繰り返す。
　一方、未特定の借入条件がないと判定した場合には、端子Ｃを介して、図１４のＳ１４１３に示した処理に戻って上述した処理を繰り返す。
　また、Ｓ１６０３において、適合する借入条件がなかったと判定した場合には、端子Ｄを介して、図１８に示したＳ１８０１の処理に移る。
　探索部８１７は、第２探索処理を実行する（Ｓ１８０１）。探索部８１７は、第２探索処理において、希望金額以外の条件について満足する借入条件を探索する。
　図１９に、第２探索処理フローを示す。探索部８１７は、借入条件テーブルにおいて借入条件を１つ特定する（Ｓ１９０１）。具体的には、探索部８１７は、借入条件テーブルにおけるレコードを１つ特定する。
　探索部８１７は、特定した借入条件の借入車種が、図１５のＳ１５０７で受信した貸出条件の貸出車種と一致するか否かを判定する（Ｓ１９０３）。当該借入車種が当該貸出車種と一致しないと判定した場合には、Ｓ１９１１の処理に移る。
　一方、当該借入車種が当該貸出車種と一致すると判定した場合には、探索部８１７は、特定した借入条件の借入場所が、上記貸出条件の貸出場所と一致するか否かを判定する（Ｓ１９０５）。当該借入場所が当該貸出場所と一致しないと判定した場合には、Ｓ１９１１の処理に移る。
　一方、当該借入場所が当該貸出場所と一致すると判定した場合には、探索部８１７は、特定した借入条件の借入期間が、上記貸出条件の貸出対象期間に含まれるか否かを判定する（Ｓ１９０７）。当該借入期間が当該貸出対象期間に含まれないと判定した場合には、Ｓ１９１１の処理に移る。
　一方、当該借入期間が当該貸出対象期間に含まれると判定した場合には、探索部８１７は、特定した借入条件を内部パラメータ記憶部８４１に記憶する（Ｓ１９０９）。
　探索部８１７は、Ｓ１９０１において未特定の借入条件があるか否かを判定する（Ｓ１９１１）。未特定の借入条件があると判定した場合には、Ｓ１９０１に示した処理に戻って、上述した処理を繰り返す。
　一方、未特定の借入条件がないと判定した場合には、探索部８１７は、内部パラメータ記憶部８４１に借入条件を記憶したか否かを判定する（Ｓ１９１３）。
　内部パラメータ記憶部８４１に借入条件を記憶したと判定した場合には、探索部８１７は、記憶した借入条件のうち、希望金額が最も高い借入条件を特定する（Ｓ１９１５）。そして、第２探索処理を終えて、貸し手処理に復帰する。
　一方、内部パラメータ記憶部８４１に借入条件を記憶していないと判定した場合には、探索部８１７は、該当する借入条件がないと判定する（Ｓ１９１７）。そして、第２探索処理を終えて、貸し手処理に復帰する。
　図１８の説明に移る。提案部８１５は、第２探索処理の結果、該当する借入条件があったか否かを判定する（Ｓ１８０３）。
　該当する借入条件がなかったと判定した場合には、そのまま貸し手処理を終える。一方、該当する借入条件があったと判定した場合には、提案部８１５は、更新画面のデータを生成する（Ｓ１８０５）。例えば、図６に示した更新画面のデータが生成される。
　提案部８１５は、送信部８０３を介して、貸し手端末１０１宛てに更新画面のデータを送信する（Ｓ１８０７）。その後、提案部８１５は、受信部８０１が貸し手端末１０１から更新の応答を受信したか否かを判定する（Ｓ１８０９）。
　貸し手端末１０１から更新の応答を受信したと判定した場合には、約定部８１９は、約定処理を実行する（Ｓ１８１１）。約定部８１９は、約定処理において、上記該当する借入条件に基づいて、取引を成立させる。
　図２０に、約定処理フローを示す。約定部８１９は、取引テーブルの新しいレコードを生成する（Ｓ２００１）。このとき、約定部８１９は、取引ＩＤを割り当てる。また、貸し手ＩＤのフィールドには、ユーザ認証で特定された貸し手ＩＤが格納される。借り手ＩＤのフィールドには、上記該当する借入条件に対応する借り手ＩＤが格納される。貸出車種のフィールドには、借入条件の借入車種が格納される。貸出場所のフィールドには、借入条件の借入場所が格納される。貸出期間の開始日時のフィールドには、借入期間の開始日時が格納される。貸出期間の終了日時のフィールドには、借入期間の終了日時が格納される。確定金額のフィールドには、借入条件の希望金額が格納される。
　約定部８１９は、送信部８０３を介して、貸し手ＩＤに対応するメールアドレス宛の通知メールを送信する（Ｓ２００３）。通知メールには、更新した設定金額で取引が成立した旨が記述される。
　約定部８１９は、図１５のＳ１５０９において貸出条件テーブルに設けた貸出条件のレコードを削除する（Ｓ２００５）。但し、約定部８１９は、レコードを削除せずに、上記該当する貸出条件における貸出対象期間を修正するようにしてもよい。
　約定部８１９は、送信部８０３を介して、借り手ＩＤに対応するメールアドレス宛の通知メールを送信する（Ｓ２００７）。通知メールには、登録された借入条件に基づく取引が成立した旨が記述される。約定処理を終えると、呼び出し元の貸し手処理に復帰する。
　図１８の説明に戻る。約定部８１９は、借入条件テーブルにおいて、上記該当する借入条件のレコードを削除する（Ｓ１８１３）。そして、貸し手処理を終える。
　Ｓ１８０９において、貸し手端末１０１から更新の応答を受信していないと判定した場合、つまり拒否の応答を受信した場合には、端子Ｅを介して、図２１に示したＳ２１０１の処理に移る。
　提案部８１５は、図１８のＳ１８０３において該当すると判定した借入条件に基づいて、図５に示した申込画面のデータを生成する（Ｓ２１０１）。このとき提案部８１５は、申込画面処理を起動する。申込画面処理については、図２９を用いて後述する。
　更に、提案部８１５は、当該申込画面へのリンクが貼られた提案メールを生成する（Ｓ２１０３）。つまり、提案メールには、当該申込画面のＵＲＬが記述されている。提案メールには、希望金額以外の借入条件を満たす貸出条件が登録された旨が記述される。
　提案部８１５は、送信部８０３を介して、当該借入条件に対応する借り手端末１０３宛ての提案メールを送信する（Ｓ２１０５）。具体的には、宛先に借り手のメールアドレスが設定されたメールが、メールサーバへ送られる。そして、貸し手処理を終える。
　続いて、借り手に対する処理について説明する。図２２に、借り手処理フローを示す。
　アクセス受付部８０５は、受信部８０１を介して、借り手専用のＵＲＬへのアクセスを受け付ける（Ｓ２２０１）。ここでは、借り手端末１０３が、当該ＵＲＬへアクセスするものとする。
　認証部８０７は、送信部８０３を介して、貸し手端末１０１宛てにログイン画面のデータを送信する（Ｓ２２０３）。ログイン画面は、アカウント名及びパスワードの入力を受け付ける。
　受信部８０１は、貸し手端末１０１からアカウント名及びパスワードを受信し（Ｓ２２０５）、認証部８０７は、当該アカウント名及びパスワードを得る。
　認証部８０７は、当該アカウント名及びパスワードに基づいて、ユーザ認証処理を実行する（Ｓ２２０７）。認証部８０７は、借り手テーブルに基づいて、当該アカウント名及びパスワードが正当であるか否かを判定する。また、当該アカウント名及びパスワードが正当である場合には、認証部８０７は、借り手ＩＤを特定する。
　制御部８０９は、ユーザ認証が成功したか否かを判定する（Ｓ２２０９）。ユーザ認証が成功していないと判定した場合には、制御部８０９は、送信部８０３を介して、借り手端末１０３宛てにユーザ認証失敗の画面のデータを送信する（Ｓ２２１１）。そして、Ｓ２２０１に示した処理に戻って、上述した処理を繰り返す。
　一方、ユーザ認証が成功したと判定した場合には、制御部８０９は、送信部８０３を介して、借り手端末１０３宛てにメニュー画面のデータを送信する（Ｓ２２１３）。メニュー画面は、「借入条件の登録」の指示及び終了指示を受け付ける。ここでは、メニュー画面における他の指示についての説明を省略する。
　受信部８０１は、借り手端末１０３からメニュー画面における指示を受信し（Ｓ２２１５）、制御部８０９は、当該指示を得る。制御部８０９は、「借入条件の登録」の指示を得たか否かを判定する（Ｓ２２１７）。
　「借入条件の登録」の指示を得ていないと判定した場合には、制御部８０９は、終了指示を得たか否かを判定する（Ｓ２２１９）。終了指示を得たと判定した場合には、借り手処理を終える。
　終了指示を得ていないと判定した場合には、Ｓ２２１５に示した処理に戻って、上述した処理を繰り返す。
　Ｓ２２１７において、「借入条件の登録」の指示を得たと判定した場合には、端子Ｆを介して、図２３に示したＳ２３０１の処理に移る。
　図２３の説明に移る。第２条件受付部８１３は、借り手テーブルから、ユーザ認証で特定された借り手ＩＤに対応する借入場所を取得し、当該貸出車種を借入画面のデータにおける初期値に設定する（Ｓ２３０１）。
　第２条件受付部８１３は、送信部８０３を介して、借入画面のデータを借り手端末１０３へ送信する（Ｓ２３０３）。
　受信部８０１は、借入条件（借入車種、借入場所、借入期間及び希望金額）を受信し（Ｓ２３０５）、第２条件受付部８１３は、当該借入条件を得る。
　探索部８１７は、第３探索処理を実行する（Ｓ２３０７）。探索部８１７は、第３探索処理において、図２３のＳ２３０５で受信した借入条件に適合する貸出条件を探索する。
　図２４に、第３探索処理フローを示す。探索部８１７は、貸出条件テーブルにおいて貸出条件を１つ特定する（Ｓ２４０１）。具体的には、探索部８１７は、貸出条件テーブルにおけるレコードを１つ特定する。
　探索部８１７は、特定した貸出条件の貸出車種が、図２３のＳ２３０５で受信した借入条件の借入車種と一致するか否かを判定する（Ｓ２４０３）。当該貸出車種が当該借入車種と一致しないと判定した場合には、Ｓ２４１３の処理に移る。
　一方、当該貸出車種が当該借入車種と一致すると判定した場合には、探索部８１７は、特定した貸出条件の貸出場所が、上記借入条件の借入場所と一致するか否かを判定する（Ｓ２４０５）。当該貸出場所が当該借入場所と一致しないと判定した場合には、Ｓ２４１３の処理に移る。
　一方、当該貸出場所が当該借入場所と一致すると判定した場合には、探索部８１７は、特定した貸出条件の貸出対象期間が、上記借入条件の借入期間を含むか否かを判定する（Ｓ２４０７）。当該貸出対象期間が当該借入期間を含まないと判定した場合には、Ｓ２４１３の処理に移る。
　一方、当該貸出対象期間が当該借入期間を含むと判定した場合には、探索部８１７は、特定した貸出条件の設定金額が上記借入条件の希望金額以下であるか否かを判定する（Ｓ２４０９）。当該設定金額が当該希望金額を上回ると判定した場合には、Ｓ２４１３の処理に移る。
　一方、当該設定金額が当該希望金額以下であると判定した場合には、探索部８１７は、特定した貸出条件を内部パラメータ記憶部８４１に記憶する（Ｓ２４１１）。
　探索部８１７は、Ｓ２４０１において未特定の貸出条件があるか否かを判定する（Ｓ２４１３）。未特定の貸出条件があると判定した場合には、Ｓ２４０１に示した処理に戻って、上述した処理を繰り返す。一方、未特定の貸出条件がないと判定した場合には、第３探索処理を終え、呼び出し元の借り手処理に復帰する。
　図２３の説明に戻る。提案部８１５は、第３探索処理の結果、適合する貸出条件があったか否かを判定する（Ｓ２３０９）。具体的には、提案部８１５は、第３探索処理において内部パラメータ記憶部８４１に貸出条件を記憶したか否かを判定する。
　適合する貸出条件があったと判定した場合には、提案部８１５は、適合する貸出条件に係る申込画面のデータを生成する（Ｓ２３１１）。図５に示した申込画面のデータが生成される。尚、適合する貸出条件が複数ある場合に、提案部８１５は、１つの貸出条件を選択し、当該１つの貸出条件に係る申込画面のデータを生成する。１つの貸出条件を選択する方法は、任意である。提案部８１５は、例えば設定金額が最も低い貸出条件を選択するようにしてもよい。
　提案部８１５は、送信部８０３を介して、借り手端末１０３宛てに申込画面のデータを送信する（Ｓ２３１３）。
　提案部８１５は、一定時間内に、受信部８０１が借り手端末１０３から申込の応答を受信したか否かを判定する（Ｓ２３１５）。受信部８０１が借り手端末１０３から申込の応答を受信したと判定した場合には、約定部８１９は、約定処理を実行する（Ｓ２３１７）。約定部８１９は、約定処理において、図２３のＳ２３０５で受信した借入条件と上記適合する貸出条件とに基づいて、取引を成立させる。
　図２０に示したように、約定部８１９は、取引テーブルの新しいレコードを生成する（Ｓ２００１）。このとき、約定部８１９は、取引ＩＤを割り当てる。また、貸し手ＩＤのフィールドには、上記適合する貸出条件に対応する貸し手ＩＤが格納される。借り手ＩＤのフィールドには、ユーザ認証で特定された借り手ＩＤが格納される。貸出車種のフィールドには、借入条件の借入車種が格納される。貸出場所のフィールドには、借入条件の借入場所が格納される。貸出期間の開始日時のフィールドには、借入期間の開始日時が格納される。貸出期間の終了日時のフィールドには、借入期間の終了日時が格納される。確定金額のフィールドには、上記適合する貸出条件の設定金額が格納される。
　約定部８１９は、送信部８０３を介して、貸し手ＩＤに対応するメールアドレス宛の通知メールを送信する（Ｓ２００３）。通知メールには、上記適合する貸出条件の設定金額で取引が成立した旨が記述される。
　約定部８１９は、貸出条件テーブルにおける上記貸出条件のレコードを削除する（Ｓ２００５）。但し、約定部８１９は、レコードを削除せずに、上記該当する貸出条件における貸出対象期間を修正するようにしてもよい。
　約定部８１９は、送信部８０３を介して、借り手ＩＤに対応するメールアドレス宛の通知メールを送信する（Ｓ２００７）。通知メールには、受け付けた借入条件に基づく取引が成立した旨が記述される。約定処理を終えると、呼び出し元の借り手処理に復帰する。
　図２３の説明に戻る。約定処理から復帰すると、借り手処理を終える。
　Ｓ２３１５において、受信部８０１が借り手端末１０３から申込の応答を受信していないと判定した場合、つまり拒否の応答を受信した場合には、端子Ｇを介して、図２２に示したＳ２２１３の処理に戻る。
　また、Ｓ２３０９において、適合する貸出条件がなかったと判定した場合には、端子Ｈを介して、図２５に示したＳ２５０１の処理に移る。
　図２５の説明に移る。提案部８１５は、送信部８０３を介して、借り手端末１０３宛てに該当なし画面のデータを送信する（Ｓ２５０１）。該当なし画面には、借入条件に適合する貸出条件が登録されていない旨が表示される。また、該当なし画面は、提案要の指示及び提案不要の指示を受け付ける。
　受信部８０１は、借り手端末１０３から該当なし画面における指示を受信し（Ｓ２５０３）、提案部８１５は、受信した指示を得る。提案部８１５は、提案要の指示を得たか否かを判定する（Ｓ２５０５）。提案要の指示を得ていないと判定した場合、つまり提案不要の指示を得た場合には、端子Ｇを介して、図２２に示したＳ２２１３の処理に戻る。
　一方、提案要の指示を得たと判定した場合には、探索部８１７は、第４探索処理を実行する（Ｓ２５０７）。探索部８１７は、第４探索処理において、設定金額以外の条件について満足する貸出条件を探索する。尚、Ｓ２５０１乃至Ｓ２５０５の処理を省いて、端子ＨからＳ２５０７の処理に移るようにしてもよい。
　図２６に、第４探索処理フローを示す。探索部８１７は、貸出条件テーブルにおいて貸出条件を１つ特定する（Ｓ２６０１）。具体的には、探索部８１７は、貸出条件テーブルにおけるレコードを１つ特定する。
　探索部８１７は、特定した貸出条件の貸出車種が、図２３のＳ２３０５で受信した借入条件の借入車種と一致するか否かを判定する（Ｓ２６０３）。当該貸出車種が当該借入車種と一致しないと判定した場合には、Ｓ２６１１の処理に移る。
　一方、当該貸出車種が当該借入車種と一致すると判定した場合には、探索部８１７は、特定した貸出条件の貸出場所が、上記借入条件の借入場所と一致するか否かを判定する（Ｓ２６０５）。当該貸出場所が当該借入場所と一致しないと判定した場合には、Ｓ２６１１の処理に移る。
　一方、当該貸出場所が当該借入場所と一致すると判定した場合には、探索部８１７は、特定した貸出条件の貸出対象期間が、上記借入条件の借入期間を含むか否かを判定する（Ｓ２６０７）。当該貸出対象期間が当該借入期間を含まないと判定した場合には、Ｓ２６１１の処理に移る。
　一方、当該貸出対象期間が当該借入期間を含むと判定した場合には、探索部８１７は、特定した貸出条件を内部パラメータ記憶部８４１に記憶する（Ｓ２６０９）。
　探索部８１７は、Ｓ２６０１において未特定の貸出条件があるか否かを判定する（Ｓ２６１１）。未特定の貸出条件があると判定した場合には、Ｓ２６０１に示した処理に戻って、上述した処理を繰り返す。
　一方、未特定の貸出条件がないと判定した場合には、探索部８１７は、内部パラメータ記憶部８４１に貸出条件を記憶したか否かを判定する（Ｓ２６１３）。
　内部パラメータ記憶部８４１に貸出条件を記憶したと判定した場合には、探索部８１７は、記憶した貸出条件のうち、設定金額が最も低い貸出条件を特定する（Ｓ２６１５）。そして、第４探索処理を終えて、借り手処理に復帰する。
　一方、内部パラメータ記憶部８４１に貸出条件を記憶していないと判定した場合には、探索部８１７は、該当する貸出条件がないと判定する（Ｓ２６１７）。そして、第４探索処理を終えて、借り手処理に復帰する。
　図２５の説明に戻る。提案部８１５は、第４探索処理の結果、該当する貸出条件があったか否かを判定する（Ｓ２５０９）。
　該当する貸出条件がなかったと判定した場合には、提案部８１５は、送信部８０３を介して、借り手端末１０３宛てに該当なし画面のデータを送信する（Ｓ２５１１）。該当なし画面には、提案する貸出条件がない旨が表示される。また、該当なし画面は、確認のユーザ操作を受け付ける。
　提案部８１５は、受信部８０１による確認の応答の受信を待って（Ｓ２５１３）、借入条件テーブルに新しいレコードを設けて、図２３のＳ２３０５で受信した借入条件を設定する（Ｓ２５１５）。このとき、提案部８１５は、当該新しいレコードに借入条件ＩＤを割り当てる。また、提案部８１５は、ユーザ認証で特定された借り手ＩＤを当該新しいレコードに格納する。端子Ｇを介して、図２２に示したＳ２２１３の処理に戻る。
　Ｓ２５０９の説明に戻る。該当する貸出条件があったと判定した場合には、端子Ｉを介して、図２７に示したＳ２７０１の処理に移る。
　図２７の説明に移る。提案部８１５は、申込画面のデータを生成する（Ｓ２７０１）。図５に示した申込画面のデータが生成される。
　提案部８１５は、送信部８０３を介して、借り手端末１０３宛てに申込画面のデータを送信する（Ｓ２７０３）。提案部８１５は、受信部８０１が借り手端末１０３から申込の応答を受信したか否かを判定する（Ｓ２７０５）。
　受信部８０１が借り手端末１０３から申込の応答を受信したと判定した場合には、約定部８１９は、約定処理を実行する（Ｓ２７０７）。約定処理から借り手処理へ復帰すると、借り手処理を終える。
　Ｓ２７０５において、受信部８０１が借り手端末１０３から申込の応答を受信していないと判定した場合には、提案部８１５は、受信部８０１が借り手端末１０３から拒否の応答を受信したか否かを判定する（Ｓ２７０９）。受信部８０１が借り手端末１０３から拒否の応答を受信していないと判定した場合には、Ｓ２７０５に示した処理に戻って、上述した処理を繰り返す。
　一方、受信部８０１が借り手端末１０３から拒否の応答を受信したと判定した場合には提案部８１５は、借入条件テーブルに新しいレコードを設けて、図２３のＳ２３０５で受信した借入条件を設定する（Ｓ２７１１）。このとき、提案部８１５は、当該新しいレコードに借入条件ＩＤを割り当てる。また、提案部８１５は、ユーザ認証で特定された借り手ＩＤを当該新しいレコードに格納する。
　提案部８１５は、更新画面のデータを生成する（Ｓ２７１３）。図６に示した更新画面のデータが生成される。このとき提案部８１５は、更新画面処理を起動する。更新画面処理については、図２８を用いて後述する。
　更に、提案部８１５は、当該更新画面へのリンクが貼られた提案メールを生成する（Ｓ２７１５）。つまり、提案メールには、当該更新画面のＵＲＬが記述されている。提案メールには、設定金額を希望金額と同額に更新すれば取引が成立する旨が記述される。
　提案部８１５は、送信部８０３を介して、第４探索処理で該当すると判定された貸出条件に対応する貸し手端末１０１宛ての提案メールを送信する（Ｓ２７１７）。具体的には、宛先に貸し手のメールアドレスが設定されたメールが、メールサーバへ送られる。そして、端子Ｇを介して、図２２のＳ２２１３に示した処理に戻って上述した処理を繰り返す。
　次に、図２７のＳ２７１７で送信した提案メールのリンクに対する貸し手の操作によって、貸し手端末１０１から更新画面のＵＲＬへアクセスされた場合の処理について説明する。図２８に、更新画面処理フローを示す。
　アクセス受付部８０５は、受信部８０１を介して、更新画面のＵＲＬへのアクセスを受け付ける（Ｓ２８０１）。ここでは、貸し手端末１０１が、当該ＵＲＬへアクセスするものとする。具体的には、Ｓ２７１３で生成した更新画面のＵＲＬへのアクセスを受け付ける。このとき、アクセス受付部８０５は、例えば当該ＵＲＬに付加されているパラメータによって、借入条件ＩＤ及び貸出条件ＩＤを特定する。そして、借入条件ＩＤによって借入条件が特定され、貸出条件ＩＤによって貸出条件が特定される。
　提案部８１５は、送信部８０３を介して、貸し手端末１０１宛てに更新画面のデータを送信する（Ｓ２８０３）。
　提案部８１５は、受信部８０１が貸し手端末１０１から更新の応答を受信したか否かを判定する（Ｓ２８０５）。
　受信部８０１が貸し手端末１０１から更新の応答を受信したと判定した場合には、約定部８１９は、約定処理を実行する（Ｓ２８０７）。また、約定部８１９は、借入条件テーブルにおいて当該借入条件ＩＤに対応するレコードを削除する（Ｓ２８０９）。そして、更新画面処理を終える。
　Ｓ２８０５において、受信部８０１が貸し手端末１０１から更新の応答を受信していないと判定した場合には、提案部８１５は、受信部８０１が貸し手端末１０１から拒否の応答を受信したか否かを判定する（Ｓ２８１１）。
　受信部８０１が貸し手端末１０１から拒否の応答を受信していないと判定した場合には、Ｓ２８０５に示した処理に戻って、上述した処理を繰り返す。
　一方、受信部８０１が貸し手端末１０１から拒否の応答を受信したと判定した場合には、そのまま、更新画面処理を終える。
　最後に、図１６のＳ１６１１又は図２１のＳ２１０５で送信した提案メールのリンクに対する借り手の操作によって、借り手端末１０３から申込画面のＵＲＬへアクセスされた場合の処理について説明する。図２９に、申込画面処理フローを示す。
　アクセス受付部８０５は、受信部８０１を介して、申込画面のＵＲＬへのアクセスを受け付ける（Ｓ２９０１）。ここでは、借り手端末１０３が、当該ＵＲＬへアクセスするものとする。尚、図１６のＳ１６１１で送信した提案メールにおけるリンクの場合には、Ｓ１６０７で生成した申込画面のＵＲＬへのアクセスを受け付ける。一方、図２１のＳ２１０５で送信した提案メールにおけるリンクの場合には、Ｓ２１０１で生成した申込画面のＵＲＬへのアクセスを受け付ける。このとき、アクセス受付部８０５は、例えば当該ＵＲＬに付加されているパラメータによって、借入条件ＩＤ及び貸出条件ＩＤを特定する。そして、借入条件ＩＤによって借入条件が特定され、貸出条件ＩＤによって貸出条件が特定される。
　提案部８１５は、送信部８０３を介して、借り手端末１０３宛てに申込画面のデータを送信する（Ｓ２９０３）。
　提案部８１５は、受信部８０１が借り手端末１０３から申込の応答を受信したか否かを判定する（Ｓ２９０５）。
　受信部８０１が借り手端末１０３から申込の応答を受信したと判定した場合には、約定部８１９は、約定処理を実行する（Ｓ２９０７）。また、約定部８１９は、借入条件テーブルにおいて当該借入条件ＩＤに対応するレコードを削除する（Ｓ２９０９）。そして、申込画面処理を終える。
　Ｓ２９０５において、受信部８０１が借り手端末１０３から申込の応答を受信していないと判定した場合には、提案部８１５は、受信部８０１が借り手端末１０３から拒否の応答を受信したか否かを判定する（Ｓ２９１１）。
　受信部８０１が借り手端末１０３から拒否の応答を受信していないと判定した場合には、Ｓ２９０５に示した処理に戻って、上述した処理を繰り返す。
　一方、受信部８０１が借り手端末１０３から拒否の応答を受信したと判定した場合には、そのまま、申込画面処理を終える。
　本実施の形態によれば、借り手又は貸し手の妥協により取引を成立させ易い。尚、借り手は、サービスの被提供者の例である。また、借入の申し込みは、サービスの提供者との合意の例である。
　ここでは、サービスの対価に関する例を説明したが、商品を提供する場合に、商品の対価に関して本実施の形態を適用するようにしてもよい。
　以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上述の機能ブロック構成はプログラムモジュール構成に一致しない場合もある。
　また、上で説明した各記憶領域の構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ、処理の順番を入れ替えることや複数の処理を並列に実行させるようにしてもよい。
　なお、上で述べた仲介サーバ１０５は、コンピュータ装置であって、図３０に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
　以上述べた本発明の実施の形態をまとめると、以下のようになる。
　本実施の形態に係る情報処理方法は、（Ａ）サービス又は商品の被提供者の端末から被提供条件を受信した場合に、サービス又は商品の提供条件を複数記憶する第１記憶部において上記被提供条件に適合する提供条件を探索し、（Ｂ）上記被提供条件に適合する提供条件がない場合に、上記被提供条件に基づいて、第１記憶部において選び出した提供条件による第１合意を促す第１提案データを、被提供者の端末へ送信し、（Ｃ）被提供者が第１合意を拒んだと判定した場合に、上記被提供条件による第２合意を促す第２提案データを、上記選び出した提供条件を登録した提供者の端末へ送信する処理を含む。
　このようにすれば、被提供者又は提供者の妥協による合意を取り付けやすくなる。
　上記情報処理方法は、更に、（Ｄ）サービス又は商品の提供者の端末から提供条件を受信した場合に、サービス又は商品の被提供条件を複数記憶する第２記憶部において上記提供条件に適合する被提供条件を探索する処理を含むようにしてもよい。上記情報処理方法は、更に、（Ｅ）上記提供条件に適合する被提供条件がない場合に、上記提供条件に基づいて、第２記憶部において選び出した被提供条件による第３合意を促す第３提案データを、提供者の端末へ送信する処理を含むようにしてもよい。上記情報処理方法は、更に、（Ｅ）提供者が第３合意を拒んだと判定した場合に、上記提供条件による第４合意を促す第４提案データを、上記選び出した被提供条件を登録した被提供者の端末へ送信する処理を含むようにしてもよい。
　このようにすれば、被提供者又は提供者の妥協による合意を、更に取り付けやすくなる。
　更に、提供条件は、サービス又は上記商品の設定料金に関してもよい。また、被提供条件は、上記サービス又は上記商品の希望料金に関してもよい。
　このようにすれば、金銭面における被提供者又は提供者の妥協による合意を取り付けやすくなる。
　なお、上記方法による処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ－ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納されるようにしてもよい。尚、中間的な処理結果は、一般的にメインメモリ等の記憶装置に一時保管される。

Claims (5)

  1. 　サービス又は商品の被提供者の端末から被提供条件を受信した場合に、当該サービス又は当該商品の提供条件を複数記憶する第１記憶部において当該被提供条件に適合する提供条件を探索し、
    　前記被提供条件に適合する提供条件がない場合に、前記被提供条件に基づいて、前記第１記憶部において選び出した提供条件による第１合意を促す第１提案データを、前記被提供者の前記端末へ送信し、
    　前記被提供者が前記第１合意を拒んだと判定した場合に、前記被提供条件による第２合意を促す第２提案データを、前記選び出した提供条件を登録した提供者の端末へ送信する
    　処理を含み、コンピュータにより実行される情報処理方法。
  2. 　更に、
    　前記サービス又は前記商品の提供者の端末から提供条件を受信した場合に、前記サービス又は前記商品の被提供条件を複数記憶する第２記憶部において当該提供条件に適合する被提供条件を探索し、
    　前記提供条件に適合する被提供条件がない場合に、前記提供条件に基づいて、前記第２記憶部において選び出した被提供条件による第３合意を促す第３提案データを、前記提供者の前記端末へ送信し、
    　前記提供者が前記第３合意を拒んだと判定した場合に、前記提供条件による第４合意を促す第４提案データを、前記選び出した被提供条件を登録した被提供者の端末へ送信する
    　処理を含む請求項１記載の情報処理方法。
  3. 　前記提供条件は、前記サービス又は前記商品の設定料金に関し、
    　前記被提供条件は、前記サービス又は前記商品の希望料金に関する
    　請求項１又は２記載の情報処理方法。
  4. 　サービス又は商品の被提供者の端末から被提供条件を受信した場合に、当該サービス又は当該商品の提供条件を複数記憶する第１記憶部において当該被提供条件に適合する提供条件を探索し、
    　前記被提供条件に適合する提供条件がない場合に、前記被提供条件に基づいて、前記第１記憶部において選び出した提供条件による第１合意を促す第１提案データを、前記被提供者の前記端末へ送信し、
    　前記被提供者が前記第１合意を拒んだと判定した場合に、前記被提供条件による第２合意を促す第２提案データを、前記選び出した提供条件を登録した提供者の端末へ送信する
    　処理を、コンピュータに実行させるプログラム。
  5. 　サービス又は商品の被提供者の端末から被提供条件を受信した場合に、当該サービス又は当該商品の提供条件を複数記憶する第１記憶部において当該被提供条件に適合する提供条件を探索する探索部と、
    　前記被提供条件に適合する提供条件がない場合に、前記被提供条件に基づいて、前記第１記憶部において選び出した提供条件による第１合意を促す第１提案データを、前記被提供者の前記端末へ送信し、前記被提供者が前記第１合意を拒んだと判定した場合に、前記被提供条件による第２合意を促す第２提案データを、前記選び出した提供条件を登録した提供者の端末へ送信する送信部と
    　を有する情報処理装置。
PCT/JP2017/035158 2017-09-28 2017-09-28 情報処理方法、プログラム及び情報処理装置 WO2019064406A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2019545472A JP6943286B2 (ja) 2017-09-28 2017-09-28 情報処理方法、プログラム及び情報処理装置
PCT/JP2017/035158 WO2019064406A1 (ja) 2017-09-28 2017-09-28 情報処理方法、プログラム及び情報処理装置
EP17927212.5A EP3690786A1 (en) 2017-09-28 2017-09-28 Information processing method, program, and information processing device
US16/828,116 US20200226674A1 (en) 2017-09-28 2020-03-24 Information processing method, storage medium, and information processing apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/035158 WO2019064406A1 (ja) 2017-09-28 2017-09-28 情報処理方法、プログラム及び情報処理装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/828,116 Continuation US20200226674A1 (en) 2017-09-28 2020-03-24 Information processing method, storage medium, and information processing apparatus

Publications (1)

Publication Number Publication Date
WO2019064406A1 true WO2019064406A1 (ja) 2019-04-04

Family

ID=65901561

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/035158 WO2019064406A1 (ja) 2017-09-28 2017-09-28 情報処理方法、プログラム及び情報処理装置

Country Status (4)

Country Link
US (1) US20200226674A1 (ja)
EP (1) EP3690786A1 (ja)
JP (1) JP6943286B2 (ja)
WO (1) WO2019064406A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001325482A (ja) * 2000-05-18 2001-11-22 Takafumi Sato ネットワークを利用した売買仲介方法
JP2002297944A (ja) * 2001-03-30 2002-10-11 Fujitsu Ltd 価格情報仲介方法
JP2004070438A (ja) * 2002-08-01 2004-03-04 Nec Corp 検索システム及び検索方法
JP2006127285A (ja) 2004-10-29 2006-05-18 Tosen Ad:Kk 空き広告看板情報提供システム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE191805T1 (de) * 1994-08-17 2000-04-15 Reuters Ltd System und methode zum zusammenbringen potentieller handelspartner basierend auf verhandlungen
US20050119980A1 (en) * 2000-06-29 2005-06-02 Neat Group Corporation Electronic negotiation systems
US9083728B1 (en) * 2012-03-06 2015-07-14 Tal Lavian Systems and methods to support sharing and exchanging in a network
US20160379299A1 (en) * 2015-06-29 2016-12-29 Realster LLC Systems and Methods for Automatic Brokering of Properties

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001325482A (ja) * 2000-05-18 2001-11-22 Takafumi Sato ネットワークを利用した売買仲介方法
JP2002297944A (ja) * 2001-03-30 2002-10-11 Fujitsu Ltd 価格情報仲介方法
JP2004070438A (ja) * 2002-08-01 2004-03-04 Nec Corp 検索システム及び検索方法
JP2006127285A (ja) 2004-10-29 2006-05-18 Tosen Ad:Kk 空き広告看板情報提供システム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3690786A4 *

Also Published As

Publication number Publication date
EP3690786A4 (en) 2020-08-05
JP6943286B2 (ja) 2021-09-29
JPWO2019064406A1 (ja) 2020-10-15
US20200226674A1 (en) 2020-07-16
EP3690786A1 (en) 2020-08-05

Similar Documents

Publication Publication Date Title
US9251327B2 (en) Method and system for providing behavioral bi-directional authentication
CN110582769A (zh) 一种单账号多身份登录方法、装置、服务器及存储介质
US20030214775A1 (en) Portal site server system, portal site method and computer-readable storage medium
US11200604B2 (en) Methods and systems for dynamic matching and communication between service providers and service requesters
Oktian et al. Hierarchical multi-blockchain architecture for scalable internet of things environment
KR20230072462A (ko) 블록체인 기반 증명서 관리 서버 및 방법 그리고 컴퓨터 프로그램
JP7013711B2 (ja) デジタルコミュニティシステム
CN104753772A (zh) 一种信息交互的方法和装置
US20190273807A1 (en) Methods and systems for dynamic matching and communication between service providers and service requesters
KR20200102110A (ko) 인력정보 및 장비 매칭 서비스 시스템 및 그 제공방법
US20210120002A1 (en) Authorization apparatus, data server and communication system
US20240152983A1 (en) Adaptive control of domain name registrations via dynamically variable registration requirements
KR20150133055A (ko) 인터넷 공유기를 이용한 출결 관리 방법
JPWO2016143027A1 (ja) 情報処理装置、機器連携認証プログラム及び機器連携認証方法
WO2019064406A1 (ja) 情報処理方法、プログラム及び情報処理装置
KR20160086679A (ko) 위치 기반 데이팅 서비스 방법
KR102094867B1 (ko) 허위매물 근절 및 신속한 거래를 위한 폐쇄형 부동산 중개 서비스 제공 방법
CA3060381A1 (en) Method for providing accommodation sharing service based on web platform and web server therefor
Lämmel et al. Enhancing cloud based data platforms for smart cities with authentication and authorization features
CN104052605A (zh) 用于跨越不同第三方平台的实体认证的单系统
US20130152182A1 (en) System and method for enabling, verification of one or more credentials of entities and sharing result of verification
JP2018169741A (ja) 情報処理装置、情報処理方法および情報処理プログラム
CN114641767A (zh) 在经管理的多租户服务中管理用户身份
Chung et al. Pragmatic approach using OAuth mechanism for IoT device authorization in cloud
US20210382981A1 (en) Service providing system, application usage method, and information processing system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17927212

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019545472

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017927212

Country of ref document: EP

Effective date: 20200428