WO2020090202A1 - 取引管理装置、取引管理方法及び取引管理プログラム - Google Patents

取引管理装置、取引管理方法及び取引管理プログラム Download PDF

Info

Publication number
WO2020090202A1
WO2020090202A1 PCT/JP2019/033194 JP2019033194W WO2020090202A1 WO 2020090202 A1 WO2020090202 A1 WO 2020090202A1 JP 2019033194 W JP2019033194 W JP 2019033194W WO 2020090202 A1 WO2020090202 A1 WO 2020090202A1
Authority
WO
WIPO (PCT)
Prior art keywords
billing
data
total
user
payment
Prior art date
Application number
PCT/JP2019/033194
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 マネーツリー株式会社
Publication of WO2020090202A1 publication Critical patent/WO2020090202A1/ja

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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems

Definitions

  • the present invention relates to a transaction management device, a transaction management system, a transaction management method, and a transaction management program that realize simplification of billing and payment work.
  • the bills notified in this way have different notification timings and arrive at the billing destinations separately, so payment may be forgotten or payment may be delayed. If payment is delayed, the billing party needs to notify the billing party again. Also, in order to remember to pay for a plurality of different bills, the billing party must make a payment each time a bill occurs by the method specified in the notice of the bill. As described above, in the conventional method, both the billing source and the billing destination may be troublesome.
  • Patent Document 1 discloses a technique of collectively making payment for a plurality of billing cases.
  • Patent Document 1 the technology in the case of treating a plurality of requests from the same invoicing source as one request is considered. Therefore, in Patent Document 1, requests from a plurality of invoicing sources are treated as different requests. Therefore, it is not possible for the billing party to reduce all the trouble.
  • the present invention realizes simplification of the work required for billing and payment.
  • the transaction management device has an input unit for inputting billing data including a billing destination ID for identifying a billing destination user and a billing amount, and the same input unit for inputting to the input unit.
  • the billing amount included in a plurality of billing data for each billing ID is added to obtain the total billing amount, and the total billing ID that identifies the total billing and the obtained total billing amount are included.
  • the bill generation unit that generates one piece of total bill data for notifying the payment request, and the transmission unit that transmits the total bill data generated by the bill generation unit to the billing destination.
  • a transaction management device which realizes simplification of the work required for a transaction related to billing and payment by billing the billing party with a total bill that combines a plurality of billing for the same billing party,
  • a transaction management method and transaction management program can be provided.
  • (A) is a conceptual diagram explaining a general transaction
  • (b) is a conceptual diagram explaining the transaction management system which concerns on this embodiment. It is a block diagram explaining the transaction management system which concerns on 1st Embodiment.
  • (A) is a data configuration diagram showing an example of a billing data list of user data used in the transaction management system according to the first embodiment
  • (b) is a data showing an example of a total billing data list of user data.
  • FIG. It is a data block diagram which shows an example of the household account book data utilized with the transaction management system which concerns on 1st Embodiment.
  • (A) is a block diagram showing an example of point data used in the transaction management system according to the first embodiment
  • (b) is a block diagram showing an example of score data used in the transaction management system. is there.
  • (A) and (b) are examples of the screen displayed on a user terminal by the data which the transaction management apparatus which concerns on 1st Embodiment transmits. It is a sequence diagram explaining an example of a process in the transaction management system according to the first embodiment. It is a sequence figure explaining an example of processing in a transaction management system concerning a modification of a 1st embodiment. It is a block diagram explaining the transaction management system which concerns on 2nd Embodiment.
  • FIG. 1 is a conceptual diagram for explaining transactions related to general money payment and money payment using the transaction management system according to the present invention.
  • a billing user is billed in various ways.
  • a bill A may arrive by mail and be paid at a convenience store or bank.
  • the generated charge B may be paid by a credit card by electronic transaction.
  • a request C by electronic data such as SNS arrives and is handed to an acquaintance or a friend. In this way, the user pays for multiple claims in different ways.
  • a plurality of invoices A to C are collectively set as a total invoice, and the user can pay the total invoice. .. Accordingly, the user can complete the tasks related to the plurality of bills A to C by one payment action without having to perform the plurality of payment actions.
  • the transaction management system 1 according to the first embodiment will be described with reference to FIG.
  • the transaction management apparatus 10 collects a plurality of claims from the claimant apparatuses 20A to 20C of users of a plurality of billing sources to the user who is the holder of the user terminal 20 as one total claim.
  • the total billing data is transmitted to the user terminal 20 owned by the billing user.
  • the billing user can process a plurality of bills as one bill, so that the user does not have to perform the procedure for the payment a plurality of times, and the billing procedure can be simplified.
  • the claimant apparatuses 20A to 20C are apparatuses used by the user of the billing source, generate billing data, and send the billing data to the transaction management apparatus 10.
  • the claimant apparatuses 20A to 20C are information processing apparatuses such as personal computers and mobile terminals.
  • FIG. 2 for convenience of description, the number of claimant devices connected to the network 30 in the transaction management system 1 is three, but the number is not limited to this.
  • the user terminal 20 is a device used by the user of the billing destination, and the user terminal 20 receives the billing data transmitted from the transaction management device 10.
  • the user terminal 20 is an information processing device such as a personal computer or a mobile terminal.
  • the number of user terminals connected to the network 30 in the transaction management system 1 is one, but the number is not limited to this.
  • the network 30 may be wired or wireless. Further, the network 30 is not limited in its communication protocol as long as it can execute data transmission / reception among the transaction management device 10, the claimant devices 20A to 20C, and the user terminal 20.
  • the transaction management device 10 includes a billing ID assigned to a bill relating to payment of money, a billing source ID for identifying a user of a billing source of the bill, and a billing destination for identifying a user of the billing destination.
  • the input unit 111 into which the billing data including the ID and the billing amount is input, and the billing amounts included in the plurality of billing data for the same billing destination ID are added to obtain the total billing amount and the total billing is identified.
  • Generated by the bill generation unit 112 which generates one total bill data including the total billing ID and the obtained total billing amount to notify the billing party of a request for payment of money.
  • a transmission unit 113 for transmitting the total billing data to the billing destination.
  • the transaction management apparatus 10 may include a request reception unit 114, a code generation unit 115, an update unit 116, a point storage processing unit 117, a score calculation unit 118, a remind transmission unit 119, and a prepaid calculation unit 120.
  • the transaction management device 10 is, for example, an information processing device such as a server including a control unit 11, a storage unit 12, and a communication unit 13.
  • the management unit P1 stored in the storage unit 12 is executed, so that the control unit 11 causes the input unit 111, the bill generation unit 112, the transmission unit 113, the request reception unit 114, the code generation unit 115, The update unit 116, the point storage processing unit 117, the score calculation unit 118, the remind transmission unit 119, and the advance payment calculation unit 120 are executed.
  • the control unit 11 is a central processing unit (CPU).
  • the storage unit 12 is a storage device that stores data such as RAM and ROM.
  • the communication unit 13 is a communication interface used for data communication with an external device via the network 30. Further, the transaction management device 10 may include an input unit 14 used for inputting data such as operation buttons and a keyboard, and an output unit 15 used for outputting data such as a display and a speaker.
  • the storage unit 12 stores user data D1, household account book data D2, point data D3, and score data D4 in addition to the management program P1.
  • the transaction management device 10 is illustrated as one device, but is not limited to this, and may be composed of a plurality of devices. For example, some of the processes may be executed by different devices, and some of the data stored in the storage unit 12 may be stored in an external storage device.
  • the user data D1 is data including, for example, a “billing data list” shown in FIG. 3 (a) and a “total billing data list” shown in FIG. 3 (b).
  • a “user ID” that identifies a user
  • a “billing ID” that identifies a bill
  • a “billing date” that is a date when a bill occurs
  • a billing source It is data including a record having a “billing source ID” for identification, a “billing item” for specifying the content of billing, and a “billing amount” which is the billing amount.
  • FIG. 3A for example, in the billing data list, a “user ID” that identifies a user, a “billing ID” that identifies a bill, a “billing date” that is a date when a bill occurs, and a billing source
  • It is data including a record having a “billing source ID” for identification, a “billing item” for specifying the content of billing, and
  • a “user ID” that identifies a user
  • a “total billing ID” that identifies a bill
  • a “billing date” that is the date when the total billing occurred
  • a total billing "Billing ID” that identifies each of the multiple invoices that are the source of the
  • “Total billing amount” that is the total billing amount
  • Payment tag that indicates whether or not the total billing has been completed
  • the data includes a record having a "payment date", which is the date when the payment was made.
  • the bills of the “billing IDs” X001, X003, and X005 for the user A are totaled to generate the total bill of the “total billing ID” Y001. Recognize.
  • the household account book data D2 includes a user ID, data relating to the user's balance, and data relating to the user's savings.
  • the ID data of the user includes data regarding the date and amount of income of the user, the date and amount of expenditure of the user, and information regarding the amount of savings of the user.
  • the household account book data D2 is, for example, as shown in FIG. 4, "day”, which is the date when the money fluctuates, "item” that specifies the cause of the money fluctuation, and "income” that is the amount of money.
  • the data includes a record having “expendation”, which is the amount of expenditure, and “total”, which is the total savings amount after fluctuation.
  • this household account book data D2 is associated with the user ID. Note that in the example shown in FIG. 2, the household account book data D2 is independent of the user data D1, but may be included in the user data.
  • the point data D3 is data in which the billing ID of the billing user and the point value are associated with each other. As shown in FIG. 5A, the point data D3 is data in which a “user ID” identifying a user and a “point value” given to this user are associated with each other. The "point value” specifies the value of the "point” that can be used for payment of money or exchanged for a product, for example. In addition, in the example shown in FIG. 2, the point data D3 is independent of the user data D1, but may be included in the user data D1.
  • the score data D4 is data in which the billing-destination ID of the billing-destination user is associated with the score value for evaluating the prompt response of the billing-destination user. As shown in FIG. 5B, the score data D4 is data in which a “user ID” identifying a user and a “score value” given to this user are associated with each other. This "score value" evaluates the user's bill payment. For example, the score value can be used to evaluate whether the user pays immediately after billing or the user is prone to delay payment. Specifically, when the period from the occurrence of the bill to the payment is short, the score can be set to be higher than that of the long period from the occurrence of the bill to the payment. Although the score data D4 is independent of the user data D1 in the example shown in FIG. 2, it may be included in the user data D1.
  • the input unit 111 includes a billing ID given to a bill for payment of money, a billing source ID for identifying a user of a billing source of the bill, a billing destination ID for identifying a user of the billing destination, and a billing amount.
  • Billing data is entered.
  • the billing data is data transmitted from the biller apparatuses 20A to 20C.
  • the input unit 111 also adds the input billing data to the billing data list of the user data D1.
  • the bill generation unit 112 adds the billing amounts included in a plurality of billing data for the same billing destination ID to obtain the total billing amount, and includes the total billing ID identifying the total billing and the obtained total billing amount. , Generates one total billing data for notifying the billing party of a request for payment of money. That is, when the bill for the user who uses the user terminal 20 is received from each of the biller devices 20A to 20C, the bill generation unit 112 sums up the plurality of bills to obtain the total billed amount, and includes the total billed amount. Generate total billing data. The bill generation unit 112 also adds the generated total bill data to the total bill data list of the user data D1.
  • the bill generation unit 112 generates total bill data at a predetermined timing.
  • the predetermined timing is, for example, a regular timing or a timing when a predetermined number of billing data is accumulated for users who are the same billing destination.
  • the bill generation unit 112 may generate the total bill data at regular timings such as monthly, semi-monthly, weekly.
  • the bill generation unit 112 may generate total bill data for each user at the timing when a predetermined number of bill data are accumulated.
  • the bill generation unit 112 may generate total bill data at a timing when both of them are combined. That is, the bill generation unit 112 generates total bill data at a predetermined regular timing, but if a predetermined number of bill data is accumulated before that timing, the total bill data is generated at that timing. May be.
  • the bill generation unit 112 can calculate the value of points to be given to the user at the billing destination as a reward for payment of the bill, and can generate total bill data including the calculated point value.
  • the bill generation unit 112 can obtain the point value such that the point value varies depending on the payment timing. For example, the bill generation unit 112 is determined so that the short payment period becomes higher than the long payment period depending on the payment required period from the time when the total billing data is transmitted to the time when the user of the billing destination pays. Find the point value. Specifically, the bill generation unit 112 gives points of the highest value when the payment is made within 3 days from the transmission of the total bill data, and when the payment is made within 10 days, the value of 1 ⁇ 2 of the points is given. The point value can be calculated such that points are awarded and points are not awarded thereafter. When obtaining the point value, the bill generation unit 112 adds the total bill data including the obtained point value to the total bill data list of the user data D1.
  • the transmitting unit 113 transmits the total billing data generated by the billing generating unit 112 to the billing destination.
  • the total billing data is data that, when transmitted by the transmission unit 113 and received by the user terminal 20, displays a screen W1 as shown in FIG. 6A on the display of the user terminal 20.
  • the transmission method by the transmission unit 113 is not limited. For example, an email, a short message service, a social networking service, or any other method capable of sending a message may be used. Further, for example, the total billing data transmitted by the transmitting unit 113 may not include the total billing amount, but may include the URL for accessing the data for displaying the total billing amount.
  • the request receiving unit 114 includes a code generation requesting generation of a code for the user to make a payment, including information on a desired payment method from the user terminal 20 of the billing user to which the transmission unit 113 has transmitted the total billing data. Receive the request. This code is used by the billing user to pay the total bill. In this way, the user of the billing party can select the desired payment method, and thus the payment of the billing party can be promoted.
  • the code generation unit 115 generates a code used in the payment method included in the code generation request received by the request reception unit 114.
  • This code is information that can specify the total billing ID and the billing amount, and is, for example, a barcode or a two-dimensional barcode.
  • the transmission unit 113 transmits the code generated by the code generation unit 115 via the communication unit 13 to the user terminal 20 of the billing user. For example, when the transmission unit 113 transmits the code and the user terminal 20 receives the code, the code is displayed on the display of the user terminal 20 as shown in FIG. 6B.
  • the updating unit 116 updates the household account book data D2 by adding information regarding payment of the total billing data generated by the billing generation unit 112.
  • this household account book data D2 may be presented as a graph or the like as information regarding statistics of the user's income and expenditure.
  • the point storage processing unit 117 can store the bill data of the user of the billing destination and the point value in the storage unit 12 as the point data D3. it can. In addition, when a new point value is obtained, the point storage processing unit 117 can update the point data D3 stored in the storage unit 12 accordingly.
  • the score calculation unit 118 determines the billing destination user set for each payment required period from the transmission of the total billing data to the payment by the billing destination user. According to the calculation method of the score value to be evaluated, the score value of the billing destination user for the required payment period is calculated, and the score data stored in the storage unit 12 is updated with the calculated score value.
  • the score calculation unit 118 evaluates the user of the billing destination set according to the unpaid period when the unpaid period of the bill has passed a predetermined period or more since the total billing data was confirmed by the user of the billing destination.
  • the score value of the user of the billing destination for the unpaid period can be obtained according to the calculation method of, and the score data can be updated with the obtained score value.
  • the reminding sending unit 119 After sending the total billing data, the reminding sending unit 119 sends the payment reminding data to the billing destination user when the unpaid period in which the billing destination user is not paid has exceeded a predetermined period.
  • the reminding transmission unit 119 sends the reminding data of payment to the billing user when the unpaid period in which the billing user is not paid has passed a predetermined period since the confirmation of the total billing data by the billing user. You may send it. This can prompt payment if the user forgets to pay. Further, at the billing source, it is possible to reduce unpaid bills.
  • the prepaid computing unit 120 When the prepaid computing unit 120 receives from the user of the billing destination a prepaid request that includes a specific billing ID and a prepaid period and desires prepaid for the bill specified by the billing ID, the prepaid computing unit 120 relates to the billing ID in the prepaid period. Calculate the total prepaid amount to pay. For example, there are those that continue to pay a fixed amount of times, such as communication charges for internet connection, rent, and loan payments. For such items, billing data of the same billing amount is periodically notified from the same billing source. Therefore, when the user voluntarily proposes advance payment and receives the advance payment request from the user terminal 20, the advance payment calculation unit 120 calculates the total advance payment amount.
  • the bill generation unit 112 also generates prepaid bill data including the total prepaid amount calculated by the prepaid calculation unit 120.
  • the prepaid billing data generated here is also transmitted to the user terminal 20 by the transmission unit 113.
  • the billing source does not need to transmit the billing data a plurality of times, so that the cost of billing processing can be reduced, and the payment by the billing destination will not be delayed, so that unpaid bills can be prevented.
  • the bill generation unit 112 may set the calculation method so that the point value becomes higher when the prepayment is performed than when the regular periodic payment is made. Further, also in the score calculation unit 118, when the score value is obtained, the calculation method may be set so that the score value becomes higher than that of the regular periodic payment when the payment is made in advance. ..
  • the transaction management device 10 may also have a payment unit (not shown) that distributes the total bill amount paid to each billing party when the payment from the billing source is completed.
  • the payment unit extracts, for example, a record with a payment tag of “completed” from the total billing data list of the user data D1. Next, the payment unit extracts all “billing IDs” from the extracted records. In addition, the payment unit extracts the record of “billing ID” extracted from the billing data list of the user data D1. In addition, the payment unit executes a process of paying the monetary amount of the bill to the billing source specified by the billing source ID of the extracted record.
  • the billing data transmitted from the plurality of biller apparatuses 20A to 20C is input to the transaction management apparatus 10 (S101). Then, the transaction management device 10 calculates the total billing amount from the billing data for the same billing destination among the plurality of billing data (S102). Further, the transaction management device 10 generates total billing data including the calculated total billing amount (S103). The transaction management device 10 transmits the generated total billing data to the user terminal 20 (S104).
  • the user terminal 20 displays the received total billing data and prompts the user to confirm it (S105). At this time, the opening confirmation data may be transmitted from the user terminal 20.
  • the user terminal 20 transmits a request for generation of a code for paying the total bill notified by the total bill data by the operation of the user (S106).
  • the code generation request may be executed, for example, by tapping the screen W1 as described above with reference to FIG.
  • a code generation request button may be provided on the screen W1 and the selection may be executed by selecting this code generation request button.
  • the transaction management device 10 generates a code in response to the request (S107).
  • the transaction management device 10 also transmits the generated code to the user terminal 20 (S108). If the payment is not made after the code is sent, the transaction management device 10 sends the payment reminding data to the user terminal 20 (S109).
  • the transaction management device 10 acquires the payment completion data regarding the completion of the payment (S111). For example, this payment completion data is used for payment. After acquisition of the payment completion data, the transaction management device 10 adds payment information and updates the household account book data D2 stored in the storage unit 12 (S112). ..
  • the transaction management device 10 adds the point value given to the user by this payment, and updates the point data D3 stored in the storage unit 12 (S113).
  • the transaction management device 10 calculates the score value of the user by this payment (S114), and updates the score data D4 stored in the storage unit 12 with the calculated score value.
  • the order of the processes of steps S112 to S115 is not limited to this, and they may be executed simultaneously.
  • the processing is executed in this manner, the payment processing of a plurality of users can be facilitated, and the work required for billing and payment can be simplified. Therefore, at the billing destination, it is not necessary to centralize the payment processing and perform the payment procedure a plurality of times, and it is possible to prevent non-payment due to forgetting the bill. Since the invoicing source collects his / her own invoice together with other invoices and notifies the invoice addressee in a lump, it is possible to prevent unpaid payment. ⁇ Modification>
  • the billing generation unit 112 outputs the billing data.
  • the second total billing amount is calculated by adding the billing amounts included in the new billing data, and the calculated total second billing amount transmitted by the transmitting unit 113 is added to the third total billing amount. Then, a new total billing data including the third total billing amount is generated. Further, the transmitting unit 113 transmits the new total billing data to the billing destination.
  • first total billing data the total billing data initially generated in the processing of steps S101 to S105 (first billing) is referred to as first total billing data.
  • the transaction management device. 10 calculates the second total billing amount (T102).
  • the transaction management device 10 calculates the third total billed amount by combining the unpaid first total billed amount calculated in step S102 and the unpaid second total billed amount calculated in step T102. (T103). After that, the transaction management device 10 generates total billing data including the third total billing amount (T104) and transmits it to the user terminal 20 (T105). The user terminal 20 confirms the total billing data (T106), and sends a request to generate a code to the transaction management device 10 (S106).
  • the transaction management device 10 generates a code according to the request (S107), and transmits the generated code to the user terminal 20. At this time, the transaction management device 10 generates a code used for payment of the third total invoiced amount calculated in step T103. Note that the transaction management system according to this modification also executes the processing of steps S109 to S115 described above with reference to FIG.
  • the unpaid billing data (first billing data) of a plurality of users is totaled with the new billing data (second billing data).
  • the billing party it becomes possible for the billing party to make the billing procedure as a whole and facilitate it, and prevent nonpayment due to forgetting the existence of the bill.
  • a transaction management system 1A according to the second embodiment will be described with reference to FIG. Also in the transaction management system 1A according to the second embodiment, the transaction management apparatus 10A, the claimant apparatuses 20A to 20C, and the user terminal 20 are connected via a network 30.
  • the transaction management device 1 of the transaction management system 1 according to the first embodiment generates a code in response to a user request, whereas the transaction management device 10A of the transaction management system 1A according to the second embodiment, When generating the total billing data, a code is generated and the total billing data including the code is generated.
  • the transaction management device 10A of the transaction management system 1A includes a request reception unit 114 and a code generation unit 115, as compared with the transaction management device 10 described above with reference to FIG. The difference is that the code generator 115a is not provided, but the code generator 115a is provided. Further, the transaction management device 10A is different from the transaction management device 10 in that the payment method data D5 is stored in the storage unit 12 and the management program P2 is stored instead of the management program P1.
  • the management program P2 stored in the storage unit 12 is executed, whereby the control unit 11 causes the input unit 111, the bill generation unit 112, the transmission unit 113, the code generation unit 115a, and the update unit 116. , The point storage processing unit 117, the score calculation unit 118, the reminding transmission unit 119, and the advance payment calculation unit 120 are executed.
  • the payment method data D5 is data associating a billing ID with a payment method of money desired by the user identified by the billing ID in advance.
  • the payment method data D5 includes a "user ID” for identifying the user of the billing destination and a "payment method” which is the payment method desired by the user, as in the example shown in FIG.
  • the payment method data D5 includes a “number” such as a credit card number when the payment method desired by the user is “credit card payment” or an account number when the payment method is “debit payment”. 'To the payment method.
  • the code generation unit 115a generates a code used in the payment method associated with the billing party ID. Specifically, the code generation unit 115a extracts the payment method associated with the billing ID of the user from the payment method data D5. Then, the code generation unit 115a generates a code used when paying for the extracted payment method.
  • the code generation unit 115a generates a code used for payment by a credit card when the user wants to pay by a credit card.
  • the code generation unit 115a generates a code to be used for direct debit when the user desires direct debit.
  • the code generator 115a uses a code used for convenience store payment when the user wants to pay at the convenience store.
  • the bill generation unit 112 generates total bill data including the code generated by the code generation unit 115a.
  • the billing data transmitted from the plurality of biller apparatuses 20A to 20C is input to the transaction management apparatus 10A (S101). Then, the transaction management device 10A calculates the total billed amount from the plurality of billing data (S102).
  • the transaction management apparatus 10A extracts the payment method desired by the billing user from the payment method data D5 (S201). Further, the transaction management device 10A generates a code used for payment by the method extracted in step S201 (S202).
  • the transaction management apparatus 10A generates total billing data including the total billing amount calculated in step S102 and the code generated in step S202 (S203).
  • the transaction management device 10A transmits the generated total billing data to the user terminal 20 (S104).
  • the user confirms the received total billing data (S105).
  • the processes of steps S106 to S108 described above with reference to FIG. 7 are not executed.
  • the processing of steps S109 to S115 is the same as the processing described above.
  • the processing is executed in this manner, the payment processing of a plurality of users can be facilitated, and the work required for billing and payment can be simplified. Therefore, at the billing destination, it is not necessary to centralize the payment processing and perform the payment procedure a plurality of times, and it is possible to prevent non-payment due to forgetting the bill. Since the invoicing source collects his / her own invoice together with other invoices and notifies the invoice addressee in a lump sum, it is possible to prevent unpaid payment.
  • the billing generation unit 112 outputs the billing data.
  • the second total billing amount is calculated by adding the billing amounts included in the new billing data, and the calculated total second billing amount transmitted by the transmitting unit 113 is added to the third total billing amount. Then, a new total billing data including the third total billing amount is generated. Further, the transmitting unit 113 transmits the new total billing data to the billing destination.
  • first total billing data the total billing data initially generated in the processing of steps S101 to S105 (first billing) is referred to as first total billing data.
  • the transaction management device 10A calculates the second total billing amount (T202).
  • the transaction management device 10A calculates the third total billed amount by combining the unpaid first total billed amount calculated in step S102 and the unpaid second total billed amount calculated in step T202. (T203). Further, the transaction management device 10A extracts the payment method desired by the user from the payment method data D5 (T204). After that, the transaction management device 10A generates a code used for payment of the third billed amount by the payment method extracted in step T204 (T205).
  • the transaction management device 10A generates total billing data including the third total billing amount calculated in step T202 and the code generated in step T205 (T206), and transmits it to the user terminal 20 (T207).
  • the total billing data is confirmed at the user terminal 20 (T208). Since the subsequent processing is the processing of steps S109 to S115 described above with reference to FIG. 11, these illustrations are omitted in FIG. 12, and description thereof is also omitted.
  • the unpaid billing data (first billing data) of a plurality of users is totaled with the new billing data (second billing data).
  • the billing party it becomes possible for the billing party to make the billing procedure as a whole and facilitate it, and prevent nonpayment due to forgetting the existence of the bill.
  • a transaction management system 1B according to the third embodiment will be described with reference to FIG. Also in the transaction management system 1A according to the second embodiment, the transaction management apparatus 10A, the claimant apparatuses 20A to 20C, and the user terminal 20 are connected via a network 30.
  • the transaction management device 1 of the transaction management system 1 according to the first embodiment generates a code used for payment in response to a user request, whereas the transaction management system 1B according to the third embodiment manages the transaction.
  • the device 10B executes payment by electronic transaction at the user's request.
  • the transaction management device 10B of the transaction management system 1B includes a request reception unit 114 and a code generation unit 115, as compared with the transaction management device 10 described above with reference to FIG. The difference is that it is not provided, but is provided with a reception unit 121 and an execution unit 122. Further, transaction management device 10B is different from transaction management device 10 in that financial data D6 is stored in storage unit 12 and management program P3 is stored instead of management program P1.
  • control unit 11 causes the input unit 111, the bill generation unit 112, the transmission unit 113, the update unit 116, and the point storage processing unit to execute the management program P3 stored in the storage unit 12.
  • the processing of 117, the score calculation unit 118, the reminding transmission unit 119, the advance payment calculation unit 120, the reception unit 121, and the execution unit 122 is executed.
  • the financial data D6 is data that associates the user ID with the financial information used to pay the user's money.
  • This "financial information" is the credit card number of the credit card of the user or the bank account number of the bank account.
  • the payment method may be such that a certain charge is totaled. Specifically, a method of totaling and paying other charges to the telephone charge or a method of totaling and paying other charges to the communication charge may be used. Thereby, the payment can be made efficient.
  • the reception unit 121 receives a payment instruction from the user for the total bill data generated by the bill generation unit 112.
  • the execution unit 122 extracts financial information associated with the user ID of the user from the financial data D6 stored in the storage unit 12, and executes payment in response to the payment instruction accepted by the acceptance unit 121.
  • the execution unit 122 may execute payment after transmitting and receiving security data such as a personal identification number with the user terminal 20 or a terminal of a financial institution such as a credit card company or a bank.
  • the billing data transmitted from the plurality of biller devices 20A to 20C is input to the transaction management device 10B (S101).
  • the transaction management device 10B calculates the total billing amount from a plurality of billing data (S102).
  • the transaction management device 10B generates total billing data including the total billing amount calculated in step S102 (S103).
  • the transaction management device 10B transmits the generated total billing data to the user terminal 20 (S104).
  • the user confirms the received total billing data (S105). Thereafter, the payment instruction data is transmitted from the user terminal 20 to the transaction management device 10B (S301).
  • the transaction management device 10B executes payment according to the payment instruction data transmitted from the user terminal 20 in step S301 (S302). Further, the processing of steps S110 to S115 executed after step S302 is the same as the processing described above.
  • the processing is executed in this manner, the payment processing of a plurality of users can be facilitated, and the work required for billing and payment can be simplified. Therefore, at the billing destination, it is not necessary to centralize the payment processing and perform the payment procedure a plurality of times, and it is possible to prevent non-payment due to forgetting the bill. Since the invoicing source collects his / her own invoice together with other invoices and notifies the invoice addressee in a lump sum, it is possible to prevent unpaid payment.
  • the billing generation unit 112 outputs the billing data.
  • the second total billing amount is calculated by adding the billing amounts included in the new billing data, and the calculated total second billing amount transmitted by the transmitting unit 113 is added to the third total billing amount. Then, a new total billing data including the third total billing amount is generated. Further, the transmitting unit 113 transmits the new total billing data to the billing destination.
  • first total billing data the total billing data initially generated in the processing of steps S101 to S105 (first billing) is referred to as first total billing data.
  • the transaction management device 10B calculates the second total billing amount (T302).
  • the transaction management device 10B calculates the third total billed amount by combining the unpaid first total billed amount calculated in step S102 and the unpaid second total billed amount calculated in step T302. (T303).
  • the transaction management device 10B generates total billing data including the third total billing amount calculated in step T302 (T304) and transmits it to the user terminal 20 (T305).
  • the user terminal 20 confirms the total billing data (T306). Further, the payment instruction data is transmitted from the user terminal 20 to the transaction management device 10B (S301).
  • the transaction management device 10B executes payment (S302). Since the subsequent processing is the processing of steps S109 to S115 described above with reference to FIG. 11, these illustrations are omitted in FIG. 15, and description thereof is also omitted.
  • the previously billed billing data (first billing data) of a plurality of users is totaled with the new billing data (second billing data).

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

取引管理装置は、請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される入力部と、入力部に入力された同一の請求先IDに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する請求生成部と、請求生成部によって生成された合計請求データを請求先に送信する送信部とを備える。

Description

取引管理装置、取引管理方法及び取引管理プログラム
　この発明は、請求及び支払いの作業の簡易化を実現する取引管理装置、取引管理システム、取引管理方法及び取引管理プログラムに関する。
　一般的な日常生活において、公共料金の支払い、ローンの返済、家賃の支払い、クレジットカードの代金の支払い等の複数の請求が発生し、それぞれに対して支払いを実行する現状がある。この場合、各請求は異なるタイミングで発生するため、請求元から請求先には、これらの請求が異なるタイミングで到着する。また、各請求に関する通知方法も統一されていない。例えば、ある請求に対しては請求書が郵送されるが、別の請求については電子データ等で送信されることもある。
　このように通知される請求は、通知のタイミングが異なり、請求先には別々に届くため、支払いを忘れたり、支払い遅れることがある。支払いが滞ると、請求元では請求先に再度通知をする必要が生じる。また、請求先は、複数の異なる請求について、忘れずに支払いをするためには、各請求が発生する度にその請求の通知に規定される方法で支払いをする必要がある。このように、従来の方法では、請求元にとっても、請求先にとっても手間を要する可能性がある。
　これに対し、例えば、特許文献１では、複数の請求案件について一括して支払いをする技術が開示される。
特開２００２－８３１２５号公報
　しかしながら、特許文献１によると、同一の請求元からの複数の請求に関して一の請求として扱う場合の技術について考慮されたものである。したがって、特許文献１では、複数の請求元からの請求については別の請求として扱われる。このため、請求先ではすべての手間を軽減することができるものではない。
　そこで、本発明は、請求及び支払いに要する作業の簡易化を実現する。
　上記課題を解決するため、本発明に係る取引管理装置は、請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される入力部と、入力部に入力された同一の請求先IDに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する請求生成部と、請求生成部によって生成された合計請求データを請求先に送信する送信部とを備える。
　本発明によれば、同一の請求先に対する複数の請求をまとめた合計請求により請求先に請求することで、請求及び支払いに関する取引に要する作業の簡易化を実現する取引管理装置、取引管理システム、取引管理方法及び取引管理プログラムを提供することができる。
（ａ）は一般的な取引を説明する概念図であって、（ｂ）は本実施形態に係る取引管理システムを説明する概念図である。 第１実施形態に係る取引管理システムを説明するブロック図である。 （ａ）は第１実施形態に係る取引管理システムで利用されるユーザデータの請求データリストの一例を示すデータ構成図であって、（ｂ）はユーザデータの合計請求データリストの一例を示すデータ構成図ある。 第１実施形態に係る取引管理システムで利用される家計簿データの一例を示すデータ構成図である。 （ａ）は第１実施形態に係る取引管理システムで利用されるポイントデータの一例を示す構成図であって、（ｂ）は同取引管理システムで使用されるスコアデータの一例を示す構成図である。 （ａ）及び（ｂ）は第１実施形態に係る取引管理装置が送信するデータによりユーザ端末で表示される画面の一例である。 第１実施形態に係る取引管理システムにおける処理の一例を説明するシーケンス図である。 第１実施形態の変形例に係る取引管理システムにおける処理の一例を説明するシーケンス図である。 第２実施形態に係る取引管理システムを説明するブロック図である。 第２実施形態に係る取引管理システムで利用される支払い方法データの一例を示すデータ構成図である。 第２実施形態に係る取引管理システムにおける処理の一例を説明するシーケンス図である。 第２実施形態の変形例に係る取引管理システムにおける処理の一例を説明するシーケンス図である。 第３実施形態に係る取引管理システムを説明するブロック図である。 第３実施形態に係る取引管理システムにおける処理の一例を説明するシーケンス図である。 第３実施形態の変形例に係る取引管理システムにおける処理の一例を説明するシーケンス図である。
　以下に、図面を用いて本発明に係る取引管理システム、取引管理装置、取引管理方法及び管理プログラムの実施の形態を説明する。なお、この実施の形態により本発明が限定されるものではない。
　図１は、一般的な金銭の支払い及び本発明に係る取引管理システムを利用する金銭の支払いに関する取引を説明する概念図である。図１（ａ）に示すように、請求先のユーザには、様々な方法で請求が発生する。例えば、公共料金等については、郵便で請求書による請求Ａが届き、コンビニや銀行等で支払う場合がある。また、インターネットショッピング等では、発生する請求Ｂを、電子取引によるクレジットカードで支払う場合がある。さらに、ＳＮＳ等の電子データによる請求Ｃが届き、知人や友人に手渡しする場合もある。このように、ユーザは、複数の請求に対してそれぞれ異なる方法によって支払いを行う。
　これに対し、本発明に係る取引管理システムでは、図１（ｂ）に示すように、複数の請求Ａ～Ｃをまとめて合計請求とし、その合計請求に対してユーザが支払いをすることができる。これにより、ユーザは、複数の支払い行為を行う必要なく、１回の支払い行為により複数の請求Ａ～Ｃに関するタスクを終了させることができる。
　以下に、本発明の各実施形態に係る取引管理システム及び変形例について、図面を参照して説明する。以下の説明において、同一の構成又は同一の処理については同一の符号を用いて重複する説明を省略する。
〈第１実施形態〉
　図２を用いて、第１実施形態に係る取引管理システム１について説明する。図２に示すように、第１実施形態に係る取引管理システム１では、取引管理装置１０と、請求者装置２０Ａ～２０Ｃと、ユーザ端末２０とがネットワーク３０を介して接続される。この取引管理システム１では、複数の請求元のユーザの請求者装置２０Ａ～２０Ｃからユーザ端末２０の保有者であるユーザへの複数の請求を取引管理装置１０において一つの合計請求としてまとめる。また、この合計請求のデータを請求先のユーザが保有するユーザ端末２０に送信する。これにより、請求先のユーザは、複数の請求を一つの請求として処理することができるため、ユーザの支払いに関する手続き複数回する必要がなくなり、支払い手続きを簡略化させることができる。
　ここで、請求者装置２０Ａ～２０Ｃは、請求元のユーザが使用する装置であって、請求データを生成し、取引管理装置１０に送信する。例えば、請求者装置２０Ａ～２０Ｃは、パーソナルコンピューターや携帯端末等の情報処理装置である。なお、図２において、説明の便宜上、取引管理システム１でネットワーク３０に接続される請求者装置の数は３台であるが、これに限定されない。
　また、ユーザ端末２０は、請求先のユーザが使用する装置であって、ユーザ端末２０は、取引管理装置１０から送信された請求データを受信する。例えば、パーソナルコンピューターや携帯端末等の情報処理装置である。なお、図２において、説明の便宜上、取引管理システム１でネットワーク３０に接続されるユーザ端末の数は１台であるが、これに限定されない。
　ネットワーク３０は、有線でも無線でもよい。また、ネットワーク３０は、取引管理装置１０、請求者装置２０A～２０C及びユーザ端末２０間でデータの送受信を実行することが可能であれば、その通信プロトコルは限定されない。
《取引管理装置》
　図２に示すように、取引管理装置１０は、金銭の支払いに関する請求に付与された請求ＩＤと、当該請求の請求元のユーザを識別する請求元ＩＤと、請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される入力部１１１と、同一の請求先IDに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、前記請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する請求生成部１１２と、請求生成部１１２によって生成された合計請求データを請求先に送信する送信部１１３とを有する。
　また、取引管理装置１０は、リクエスト受信部１１４、コード生成部１１５、更新部１１６、ポイント記憶処理部１１７、スコア演算部１１８、リマインド送信部１１９及び先払い演算部１２０を備えてもよい。
　この取引管理装置１０は、例えば、制御部１１、記憶部１２及び通信部１３を備えるサーバ等の情報処理装置である。取引管理装置１０は、記憶部１２に記憶される管理プログラムP１が実行されることで、制御部１１が入力部１１１、請求生成部１１２、送信部１１３、リクエスト受信部１１４、コード生成部１１５、更新部１１６、ポイント記憶処理部１１７、スコア演算部１１８、リマインド送信部１１９及び先払い演算部１２０としての処理を実行する。制御部１１は、中央処理装置（ＣＰＵ）である。記憶部１２は、ＲＡＭやＲＯＭ等のデータを記憶する記憶装置である。通信部１３は、ネットワーク３０を介して外部の装置とのデータの通信に利用される通信インターフェースである。また、取引管理装置１０は、操作ボタンやキーボード等のデータの入力に利用される入力部１４及びディスプレイやスピーカ等のデータの出力に利用される出力部１５を備えてもよい。
　記憶部１２は、管理プログラムP１の他、ユーザデータＤ１、家計簿データＤ２、ポイントデータＤ３及びスコアデータＤ４を記憶する。図２において、取引管理装置１０は、１台の装置として図示されるが、これに限定されず、複数の装置で構成されてもよい。例えば、一部の処理が異なる装置で実行される構成であってもよいし、記憶部１２で記憶されるデータのうち一部が外部の記憶装置に記憶されてもよい。
　ユーザデータＤ１は、例えば、図３（ａ）に示す『請求データリスト』と、図３（ｂ）に示す『合計請求データリスト』とを含むデータである。図３（ａ）に示すように、例えば、請求データリストでは、ユーザを識別する「ユーザＩＤ」、請求を識別する「請求ＩＤ」、請求の発生した日付である「請求日」、請求元を識別する「請求元ＩＤ」、請求に内容を特定する「請求項目」、請求の金額である「請求金額」を有するレコードを含むデータである。図３（ｂ）に示すように、合計請求データリストでは、ユーザを識別する「ユーザＩＤ」、請求を識別する「合計請求ＩＤ」、合計請求の発生した日付である「請求日」、合計請求の元となる複数の各請求を識別する「請求ＩＤ」、合計の請求金額である「合計請求金額」、この合計請求について支払い済であるか否かの「支払いタグ」、支払い済である場合に支払いがされた日付である「支払日」とを有するレコードを含むデータである。
　図３（ａ）及び図３（ｂ）に示す例では、ユーザＡに対する「請求ＩＤ」Ｘ００１，Ｘ００３，Ｘ００５の請求を合計して、「合計請求ＩＤ」Ｙ００１の合計請求が生成されたことがわかる。
　家計簿データＤ２は、ユーザのIDと、ユーザの収支に関するデータと、ユーザの貯蓄に関するデータとを含むである。具体的には、ユーザのＩＤに、ユーザに収入が発生した日付及びその金額と、ユーザの支出が発生した日付及びその金額と、ユーザの貯蓄額に関する情報を含むデータである。
　家計簿データＤ２は、例えば、図４に示すように、金銭の変動が生じた日付である「日」、金銭の変動の原因の内容を特定する「項目」、収入の金額である「収入」、支出の金額である「支出」、変動後の合計の貯蓄金額である「合計」とを有するレコードを含むデータである。なお、図４において、図示されていないが、この家計簿データＤ２は、ユーザＩＤと関連付けられる。なお、図２に示す例では、家計簿データＤ２は、ユーザデータＤ１から独立しているが、ユーザデータに含まれてもよい。
　ポイントデータＤ３は、請求先のユーザの請求先IDと、ポイント値とが関連付けられるデータである。ポイントデータＤ３は、図５（ａ）に示すように、ユーザを識別する「ユーザＩＤ」と、このユーザに付与された「ポイント値」とが関連づけられるデータである。この「ポイント値」は、例えば、金銭の支払い等に使用したり、商品との交換が可能な「ポイント」の値を特定するものである。なお、図２に示す例では、ポイントデータＤ３は、ユーザデータＤ１から独立しているが、ユーザデータＤ１に含まれてもよい。
　スコアデータＤ４は、請求先のユーザの請求先IDと、請求先のユーザの支払いの即答性を評価するスコア値とが関連付けられるデータである。スコアデータＤ４は、図５（ｂ）に示すように、ユーザを識別する「ユーザＩＤ」と、このユーザに付与された「スコア値」とが関連づけられるデータである。この「スコア値」は、ユーザの請求に対する支払いを評価するものである。例えば、スコア値によって、請求後に直ちに支払いをするユーザであるのか、支払いの滞りが生じやすいユーザであるのかを評価することができる。具体的には、請求の発生から支払いまでの期間が短いと、請求の発生から支払いまでの期間が長いよりも高スコアとなるように設定することができる。なお、図２に示す例では、スコアデータＤ４は、ユーザデータＤ１から独立しているが、ユーザデータＤ１に含まれてもよい。
　入力部１１１は、金銭の支払いに関する請求に付与された請求ＩＤと、当該請求の請求元のユーザを識別する請求元ＩＤと、請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される。この請求データは、請求者装置２０Ａ～２０Ｃから送信されるデータである。また、入力部１１１は、入力された請求データを、ユーザデータD１の請求データリストに追加する。
　請求生成部１１２は、同一の請求先IDに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する。すなわち各請求者装置２０Ａ～２０Ｃから、ユーザ端末２０を利用するユーザに対する請求を受信したとき、請求生成部１１２は、これら複数の請求を合計して合計請求金額を求め、この合計請求金額を含む合計請求データを生成する。また、請求生成部１１２は、生成した合計請求データを、ユーザデータＤ１の合計請求データリストに追加する。
　ここで、複数の請求データをまとめることで、例えば、通常は手渡しでしか支払いをしないような少額の請求についても合計請求データに含めてコンビニ払い等の特別な支払いを利用することができる。また、まとめて請求することで、金銭の支払いに要する手数料も低減することができる。
　ここで請求生成部１１２は、所定のタイミングで、合計請求データを生成する。所定のタイミングは、例えば、定期的なタイミングであったり、同一の請求先であるユーザに対して所定数の請求データが溜まったタイミングである。具体的には、請求生成部１１２は、月毎、半月毎、週毎等の定期的なタイミングで合計請求データを生成してもよい。または、請求生成部１１２は、各ユーザについて、所定数の請求データが溜まったタイミングで合計請求データを生成してもよい。さらに、請求生成部１１２は、これら両方を組み合わせたタイミングで合計請求データを生成してもよい。すなわち、請求生成部１１２は、予め定められる定期的なタイミングで合計請求データを生成するが、そのタイミングの前に所定数の請求データが溜まった場合には、そのタイミングで合計請求データを生成してもよい。
　請求生成部１１２は、請求に対する支払いに対して請求先のユーザに報酬として付与されるポイントの値を求めるとともに、求めたポイント値を含む合計請求データを生成することができる。ここで、請求生成部１１２は、支払いの時期によって、異なるポイント値になるようにポイント値を求めることができる。例えば、請求生成部１１２は、合計請求データの送信時から請求先のユーザによる支払い時までの支払い所要期間に応じ、支払い所要期間が短い場合には長い場合と比較して高くなるように定められたポイント値を求める。具体的には、請求生成部１１２は、合計請求データの送信から３日以内に支払いした場合に最も高い値のポイントが付与され、１０日以内に支払いした場合にはその１／２の値のポイントが付与され、それ以降はポイントが付与されないようにポイント値を求めることができる。請求生成部１１２は、ポイント値を求めた場合、求めたポイント値を含む合計請求データを、ユーザデータＤ１の合計請求データリストに追加する。
　送信部１１３は、請求生成部１１２によって生成された合計請求データを請求先に送信する。例えば、合計請求データは、送信部１１３が送信し、ユーザ端末２０に受信されると、ユーザ端末２０のディスプレイにおいて、図６（ａ）に示すような画面Ｗ１を表示するデータである。この送信部１１３による送信方法は、限定されない。例えば、電子メール、ショートメッセージサービス、ソーシャルネットワーキングサービス等、メッセージを送信することができる方法であればよい。また、例えば、送信部１１３が送信する合計請求データに、合計請求金額が含まれておらず、合計請求金額を表示するためのデータにアクセスするためのＵＲＬが含まれるものであってもよい。
　リクエスト受信部１１４は、送信部１１３が合計請求データを送信した請求先のユーザのユーザ端末２０から、希望の支払い方法の情報を含み、ユーザが支払いをするためのコードの生成を要求するコード生成リクエストを受信する。このコードは、請求先のユーザが、合計請求金額の支払いに使用するものである。このように、請求先のユーザは希望の支払い方法を選択することが可能であるため、請求先の支払いを促進させることが可能となる。
　コード生成部１１５は、リクエスト受信部１１４が受信したコード生成リクエストが含む支払い方法で用いるコードを生成する。このコードは、合計請求ＩＤと請求金額を特定することが可能な情報であって、例えば、バーコードや二次元バーコードである。
　送信部１１３は、通信部１３を介してこのコード生成部１１５が生成したコードを請求先のユーザのユーザ端末２０に送信する。例えば、コードは、送信部１１３が送信し、ユーザ端末２０に受信されると、ユーザ端末２０のディスプレイにおいて、図６（ｂ）に示すように表示される。
　更新部１１６は、請求生成部１１２で生成された合計請求データの支払いに関する情報を、追加して家計簿データＤ２を更新する。なお、この家計簿データＤ２をユーザの収支の統計に関する情報としてグラフ等により提示可能であってもよい。図示を用いた説明を省略するが、取引管理装置１０は、支払いを受けると、支払いに利用される機関の端末等から支払い完了データを取得することができる。取引管理装置１０では、これにより、取引の完了を把握することができる。
　ポイント記憶処理部１１７は、合計請求データで通知された請求に対して支払いが完了すると、請求先のユーザの請求先IDと、ポイント値を関連付けてポイントデータＤ３として記憶部１２に記憶させることができる。また、ポイント記憶処理部１１７は、新たなポイント値が求められると、これにより記憶部１２で記憶されるポイントデータＤ３を更新することができる。
　スコア演算部１１８は、合計請求で通知された請求に対して支払いが完了すると、合計請求データの送信時から請求先のユーザによる支払い時までの支払い所要期間毎に設定される請求先のユーザを評価するスコア値の演算方法に応じて、当該支払い所要期間に対する請求先のユーザのスコア値を求め、求めたスコア値により、記憶部１２で記憶されるスコアデータを更新する。
　また、スコア演算部１１８は、請求先のユーザによる合計請求データの確認時から、請求について未払い期間が所定期間以上経過すると、当該未払い期間に応じて設定される請求先のユーザを評価するスコア値の演算方法に応じて、当該未払い期間に対する請求先のユーザのスコア値を求め、求めたスコア値により、スコアデータを更新することができる。
　リマインド送信部１１９は、合計請求データの送信後、請求先のユーザによる支払いがされない未払い期間が所定期間以上経過したとき、請求先のユーザに対し、支払いのリマインドデータを送信する。
　また、リマインド送信部１１９は、請求先のユーザによる合計請求データの確認時から、請求先のユーザによる支払いがされない未払い期間が所定期間以上経過すると、請求先のユーザに対し、支払いのリマインドデータを送信してもよい。これにより、ユーザが支払いを忘れていた場合に支払いを促すことができる。また、請求元では、請求の未払いを低減することが可能となる。
　先払い演算部１２０は、請求先のユーザから、特定の請求IDと、先払い期間とを含み、当該請求IDで特定される請求に関する先払いを希望する先払いリクエストを受信すると、当該先払い期間における請求IDに関して支払う合計先払い金額を演算する。例えば、インターネット接続の通信費、家賃、ローンの支払い等、一定額を複数回支払い続けるものがある。このようなものについては、同一の請求元から、同一の請求額の請求データが定期的に通知される。このため、ユーザが自主的に先払いを提案してユーザ端末２０から先払いリクエストが受信されると、先払い演算部１２０が合計先払い金額を演算する。
　また、請求生成部１１２は、先払い演算部１２０で演算された合計先払い金額を含む先払い請求データを生成する。また、ここで生成された先払い請求データも、送信部１１３によってユーザ端末２０に送信する。これにより、請求元では、請求データを複数回送信する必要は不要となるため請求処理のコストを削減し、また、請求先による支払いが滞ることもないため未払いを防止することができる。さらに、請求先でも、未来に生じる請求を予め支払うことが可能となるため、支払いの手間を低減することができる。
　なお、請求生成部１１２では、ポイント値を求める際、先払いをした場合には通常の定期的な支払いをするよりも高いポイント値になるように演算方法が定められていてもよい。また、スコア演算部１１８においても、スコア値を求める際、先払いをした場合には通常の定期的な支払いをするよりも高いスコア値になるように演算方法が定められていてもよい。　
　また、取引管理装置１０は、請求元からの支払いが終了すると、各請求先に支払われた合計請求金額の金銭を振り分ける支払い部を有してもよい（図示を省略）。この支払い部は、例えば、ユーザデータＤ１の合計請求データリストから支払いタグが「済」のレコードを抽出する。次に、支払い部は、抽出したレコードから、すべての「請求ＩＤ」を抽出する。また、支払い部は、ユーザデータＤ１の請求データリストから抽出した「請求ＩＤ」のレコードを抽出する。また、支払い部は、抽出したレコードの請求元ＩＤで特定される請求元に、請求金額の金銭の支払いの処理を実行する。
《取引管理処理》
　図７に示すシーケンス図を用いて、第１実施形態に係る取引管理システム１における処理を説明する。
　まず、取引管理装置１０に、複数の請求者装置２０A～２０Cから送信された請求データが入力される（Ｓ１０１）。
　その後、取引管理装置１０は、複数の請求データのうち同じ請求先に対する請求データから合計請求金額を算出する（Ｓ１０２）。
　また、取引管理装置１０は、算出した合計請求金額を含む合計請求データを生成する（Ｓ１０３）。
　取引管理装置１０は、生成した合計請求データをユーザ端末２０に送信する（Ｓ１０４）。
　ユーザ端末２０では、受信した合計請求データを表示し、ユーザに確認させる（Ｓ１０５）。このとき、ユーザ端末２０から開封確認データが送信されてもよい。
　ユーザ端末２０は、ユーザの操作により、合計請求データで通知された合計請求の支払いをするためのコードの生成を要求するリクエストを送信する（Ｓ１０６）。ここで、コードの生成の要求は、例えば、図６（ａ）を用いて上述したような画面Ｗ１をタップすることで実行されてもよい。また例えば、画面Ｗ１にコード生成要求ボタンを設け、このコード生成要求ボタンの選択により、実行されてもよい。
　取引管理装置１０は、リクエストに応じて、コードを生成する（Ｓ１０７）。
　また、取引管理装置１０は、生成したコードをユーザ端末２０に送信する（Ｓ１０８）。
　仮に、コードの送信後に支払いがされないとき、取引管理装置１０は、支払いのリマインドデータをユーザ端末２０に送信する（Ｓ１０９）。
　ユーザによってユーザ端末２０で受信したコードを利用して支払いがされると（Ｓ１１０）、取引管理装置１０は、その支払いの完了に関する支払い完了データを取得する（Ｓ１１１）。例えば、この支払い完了データは、支払いに利用される
　支払い完了データの取得後、取引管理装置１０は、支払いの情報を追加して記憶部１２に記憶される家計簿データＤ２を更新する（Ｓ１１２）。
　また、取引管理装置１０は、この支払いによってユーザに付与されるポイント値を加算して、記憶部１２に記憶されるポイントデータＤ３を更新する（Ｓ１１３）。
　さらに、取引管理装置１０は、この支払いによってユーザのスコア値が算出され（Ｓ１１４）、算出されたスコア値によって、記憶部１２に記憶されるスコアデータＤ４を更新する。なお、ステップＳ１１２～Ｓ１１５の処理の順序はこれに限定されず、また、同時に実行されてもよい。
　取引管理システム１では、このように処理が実行され、複数のユーザの支払いの処理を容易にし、請求及び支払いに要する作業の簡易化を実現することができる。したがって、請求先では、支払いの処理を一括化して支払いの手続きを複数回行う必要がなく、また、請求を忘れることによる不払いを防止することが可能となる。請求元では自身の請求が他の請求とまとめられ一括して請求先に通知されるため、未払いを防止することが可能となる。
《変形例》
　図８に示すシーケンス図を用いて、第１実施形態の変形例に係る取引管理システムにおける処理を説明する。第１実施形態の変形例に係る取引管理システムでは、ユーザに始めに合計請求（第１の請求）をし、ユーザからまだ支払いがされない場合に、新たに発生した別の合計請求をするとき、これも合計に含めて第２の請求とする。
　ここで、請求生成部１１２は、送信部１１３が合計請求データを送信後に請求先による支払いがされる前に、入力部１１１に請求先に対する複数の新たな請求データが入力されると、当該複数の新たな請求データに含まれる請求金額を加算して第２の合計請求金額を求めるとともに、送信部１１３が送信した合計請求金額と、求めた第２の合計請求金額とを加算して第３の合計請求金額を求め、第３の合計請求金額を含む新たな合計請求データを生成する。また、送信部１１３は、新たな合計請求データを請求先に送信する。
　なお、図８に示す例で、図７で用いた符号と同一の処理については、同一の符号を付す。また、図８に示すシーケンス図において追加された処理については、太枠又は太字により強調する。ここで、図８に示すように、ステップＳ１０１～Ｓ１０５の処理（第１の請求）で始めに生成する合計請求データを第１の合計請求データとする。
　ここで、ステップＳ１０４で取引管理装置１０からユーザ端末２０に送信された第１の合計請求データによる請求に対し、未払いであるときに、請求データが複数入力されると（Ｔ１０１）、取引管理装置１０は、第２の合計請求金額を算出する（Ｔ１０２）。
　また、取引管理装置１０は、ステップＳ１０２で算出した未払いの第１の合計請求金額と、ステップＴ１０２で算出した未払いの第２の合計請求金額とを合わせて、第３の合計請求金額を算出する（Ｔ１０３）。
　その後、取引管理装置１０は、第３の合計請求金額を含む合計請求データを生成し（Ｔ１０４）、ユーザ端末２０に送信する（Ｔ１０５）。
　ユーザ端末２０では、この合計請求データが確認され（Ｔ１０６）、コードを生成するリクエストを取引管理装置１０に送信する（Ｓ１０６）。
　取引管理装置１０は、リクエストに応じてコードを生成し（Ｓ１０７）、生成したコードをユーザ端末２０に送信する。このとき、取引管理装置１０は、ステップＴ１０３で算出した第３の合計請求金額の支払いに使用するコードを生成する。
　なお、この変更例に係る取引管理システムでも、図７を用いて上述したステップＳ１０９～Ｓ１１５の処理を実行する。
　これにより、変形例に係る取引管理システムでは、複数のユーザの未払いである先にされた請求データ（第１の請求のデータ）を新たな請求データ（第２の請求のデータ）と合計して再請求することができる。したがって、請求元では自身の請求が他の請求とまとめられ一括して請求先に通知されるため、未払いを防止することが可能となる。また、請求先では請求の手続きを一括化して容易にするとともに、請求の存在を忘れることによる不払いを防止することが可能となる。
〈第２実施形態〉
　図９を用いて、第２実施形態に係る取引管理システム１Ａについて説明する。第２実施形態に係る取引管理システム１Ａも取引管理装置１０Ａと、請求者装置２０Ａ～２０Ｃと、ユーザ端末２０とが、ネットワーク３０を介して接続される。第１実施形態に係る取引管理システム１の取引管理装置１は、ユーザのリクエストに応じてコードを生成していたのに対し、第２実施形態に係る取引管理システム１Ａの取引管理装置１０Ａは、合計請求データ生成の際に、コードを生成し、コードを含む合計請求データを生成する。
《取引管理装置》
　図９に示すように、第２実施形態に係る取引管理システム１Ａの取引管理装置１０Ａは、図２を用いて上述した取引管理装置１０と比較して、リクエスト受信部１１４及びコード生成部１１５を備えず、コード生成部１１５ａを備える点で異なる。また、取引管理装置１０Aは、取引管理装置１０と比較して、記憶部１２に支払い方法データＤ５を記憶し、管理プログラムＰ１に代えて管理プログラムＰ２を記憶する点で異なる。
　この取引管理装置１０Ａは、記憶部１２に記憶される管理プログラムＰ２が実行されることで、制御部１１が、入力部１１１、請求生成部１１２、送信部１１３、コード生成部１１５ａ、更新部１１６、ポイント記憶処理部１１７、スコア演算部１１８、リマインド送信部１１９及び先払い演算部１２０の処理を実行する。
　支払い方法データＤ５は、請求先ＩＤと、当該請求先ＩＤで識別されるユーザが予め希望する金銭の支払い方法とを関連づけるデータである。例えば、支払い方法データＤ５は、図１０に示す一例のように、請求先のユーザを識別する「ユーザＩＤ」と、このユーザが希望する支払いの方法である「支払い方法」とを含む。また、図１０に示すように、支払い方法データＤ５は、ユーザの希望する支払い方法が『クレジットカード払い』である場合のクレジットカード番号や『口座引き落とし払い』である場合の口座番号等の「番号」を支払い方法に関連付ける。
　コード生成部１１５ａは、請求先ＩＤと関連づけられる支払い方法で用いるコードを生成する。具体的には、コード生成部１１５ａは、支払い方法データＤ５からユーザの請求先ＩＤと関連付けられる支払い方法を抽出する。そして、コード生成部１１５ａは、抽出した支払い方法で用いる支払う場合に使用するコードを生成する。ここで、例えば、コード生成部１１５ａは、ユーザがクレジットカード払いを希望するときには、クレジットカードによる支払いで使用するコードを生成する。また、コード生成部１１５ａは、ユーザが口座引き落としを希望するとときには、口座引き落としで使用するコードを生成する。さらに、コード生成部１１５ａは、ユーザが銀行振り込みを希望するときには、銀行振り込みで使用するコードを生成する。また、コード生成部１１５ａは、ユーザがコンビニ払いを希望するときには、コンビニ払いで使用するコードを利用する。
　なお、請求生成部１１２は、コード生成部１１５ａが生成したコードを含む合計請求データを生成する。
《取引管理処理》
　図１１に示すシーケンス図を用いて、第２実施形態に係る取引管理システム１Ａにおける処理を説明する。なお、図１１に示すシーケンス図において、図７を用いて上述した処理と異なる処理については、太枠又は太字により強調し、同一の処理については、一部の説明を省略する。
　まず、取引管理装置１０Ａに、複数の請求者装置２０A～２０Cから送信された請求データが入力される（Ｓ１０１）。
　その後、取引管理装置１０Ａは、複数の請求データから合計請求金額を算出する（Ｓ１０２）。
　ここで、取引管理装置１０Ａは、支払い方法データＤ５から請求先のユーザが希望する支払い方法を抽出する（Ｓ２０１）。
　また、取引管理装置１０Ａは、ステップＳ２０１で抽出した方法による支払で使用するコードを生成する（Ｓ２０２）。
　続いて、取引管理装置１０Ａは、ステップＳ１０２で算出した合計請求金額、ステップＳ２０２で生成したコードを含む合計請求データを生成する（Ｓ２０３）。
　取引管理装置１０Ａは、生成した合計請求データをユーザ端末２０に送信する（Ｓ１０４）。
　ユーザ端末２０では、ユーザが、受信した合計請求データを確認する（Ｓ１０５）。第２実施形態に係る取引管理システム１Ａでは、既にコードの生成がされているため、図７で上述したステップＳ１０６～Ｓ１０８の処理については実行されない。また、ステップＳ１０９～Ｓ１１５の処理については、上述した処理と同一である。
　取引管理システム１Ａでは、このように処理が実行され、複数のユーザの支払いの処理を容易にし、請求及び支払いに要する作業の簡易化を実現することができる。したがって、請求先では、支払いの処理を一括化して支払いの手続きを複数回行う必要がなく、また、請求を忘れることによる不払いを防止することが可能となる。請求元では自身の請求が他の請求とまとめられ一括して請求先に通知されるため、未払いを防止することが可能となる。
《変形例》
　図１２に示すシーケンス図を用いて、第２実施形態の変形例に係る取引管理システムにおける処理を説明する。第２実施形態の変形例に係る取引管理システムでは、ユーザに始めに合計請求（第１の請求）をし、ユーザからまだ支払いがされない場合に、次の合計請求をするとき、これも合計に含めて第２の請求とする。
　ここで、請求生成部１１２は、送信部１１３が合計請求データを送信後に請求先による支払いがされる前に、入力部１１１に請求先に対する複数の新たな請求データが入力されると、当該複数の新たな請求データに含まれる請求金額を加算して第２の合計請求金額を求めるとともに、送信部１１３が送信した合計請求金額と、求めた第２の合計請求金額とを加算して第３の合計請求金額を求め、第３の合計請求金額を含む新たな合計請求データを生成する。また、送信部１１３は、新たな合計請求データを請求先に送信する。
　なお、図１２に示す例で、図１１で用いた符号と同一の処理については、同一の符号を付す。また、図１２に示すシーケンス図において追加された処理については、太枠又は太字により強調する。ここで、図１２に示すように、ステップＳ１０１～Ｓ１０５の処理（第１の請求）で始めに生成する合計請求データを第１の合計請求データとする。
　ここで、ステップＳ１０４で取引管理装置１０Ａからユーザ端末２０に送信された第１の合計請求データによる請求に対し、未払いであるときに、請求データが複数入力されると（Ｔ２０１）、取引管理装置１０Ａは、第２の合計請求金額を算出する（Ｔ２０２）。
　その後、取引管理装置１０Ａは、ステップＳ１０２で算出した未払いの第１の合計請求金額と、ステップＴ２０２で算出した未払いの第２の合計請求金額とを合わせて、第３の合計請求金額を算出する（Ｔ２０３）。
　また、取引管理装置１０Ａは、支払い方法データＤ５から、ユーザが希望する支払い方法を抽出する（Ｔ２０４）。
　その後、取引管理装置１０Ａは、ステップＴ２０４で抽出した支払い方法で第３の請求金額の支払いに使用するコードを生成する（Ｔ２０５）
　続いて、取引管理装置１０Ａは、ステップＴ２０２で算出した第３の合計請求金額と、ステップＴ２０５で生成したコードを含む合計請求データを生成し（Ｔ２０６）、ユーザ端末２０に送信する（Ｔ２０７）。
　ユーザ端末２０では、この合計請求データが確認される（Ｔ２０８）。その後の処理は、図１１を用いて上述したステップＳ１０９～Ｓ１１５の処理であるため、図１２ではこれらの図示を省略し、説明も省略する。
　これにより、変形例に係る取引管理システムでは、複数のユーザの未払いである先にされた請求データ（第１の請求のデータ）を新たな請求データ（第２の請求のデータ）と合計して再請求することができる。したがって、請求元では自身の請求が他の請求とまとめられ一括して請求先に通知されるため、未払いを防止することが可能となる。また、請求先では請求の手続きを一括化して容易にするとともに、請求の存在を忘れることによる不払いを防止することが可能となる。
〈第３実施形態〉
　図１３を用いて、第３実施形態に係る取引管理システム１Ｂについて説明する。第２実施形態に係る取引管理システム１Ａも取引管理装置１０Ａと、請求者装置２０Ａ～２０Ｃと、ユーザ端末２０とが、ネットワーク３０を介して接続される。第１実施形態に係る取引管理システム１の取引管理装置１は、ユーザのリクエストに応じて支払いに使用するコードを生成していたのに対し、第３実施形態に係る取引管理システム１Ｂの取引管理装置１０Ｂは、ユーザの請求により、電子取引により支払いを実行する。
《取引管理装置》
　図１３に示すように、第３実施形態に係る取引管理システム１Ｂの取引管理装置１０Ｂは、図２を用いて上述した取引管理装置１０と比較して、リクエスト受信部１１４及びコード生成部１１５を備えず、受付部１２１及び実行部１２２を備える点で異なる。また、取引管理装置１０Ｂは、取引管理装置１０と比較して、記憶部１２に金融データＤ６を記憶し、管理プログラムＰ１に代えて管理プログラムＰ３を記憶する点で異なる。
　この取引管理装置１０Ｂは、記憶部１２に記憶される管理プログラムＰ３が実行されることで、制御部１１が、入力部１１１、請求生成部１１２、送信部１１３、更新部１１６、ポイント記憶処理部１１７、スコア演算部１１８、リマインド送信部１１９、先払い演算部１２０、受付部１２１及び実行部１２２の処理を実行する。
　金融データＤ６は、ユーザのIDと、当該ユーザの金銭の支払いに使用される金融情報とを関連付けるデータである。この『金融情報』は、ユーザの有するクレジットカードのクレジットカード番号や銀行口座の銀行口座番号である。その他、ある請求に合計させるような支払い方法であってもよい。具体的には、電話料金に他の請求を合計して支払う方法や、通信費に他の請求を合計して支払う方法であってもよい。これにより、支払いを効率化することができる。
　受付部１２１は、請求生成部１１２が生成した合計請求データに対してユーザからの支払い指示を受け付ける。
　実行部１２２は、記憶部１２に記憶される金融データＤ６からユーザのユーザIDと関連付けられる金融情報を抽出し、受付部１２１が受け付けた支払い指示に対して、支払いを実行する。ここで、実行部１２２は、ユーザ端末２０又はクレジットカード会社や銀行等の金融機関の端末との間で、暗証番号等のセキュリティデータを送受信した後に、支払いを実行するものであってもよい。
《取引管理処理》
　図１４に示すシーケンス図を用いて、第３実施形態に係る取引管理システム１Ｂにおける処理を説明する。なお、図１４に示すシーケンス図において、図７を用いて上述した処理と異なる処理については、太枠又は太字により強調し、同一の処理については、一部の説明を省略する。
　まず、取引管理装置１０Ｂに、複数の請求者装置２０A～２０Cから送信された請求データが入力される（Ｓ１０１）。
　その後、取引管理装置１０Ｂは、複数の請求データから合計請求金額を算出する（Ｓ１０２）。
　続いて、取引管理装置１０Ｂは、ステップＳ１０２で算出した合計請求金額を含む合計請求データを生成する（Ｓ１０３）。
　取引管理装置１０Ｂは、生成した合計請求データをユーザ端末２０に送信する（Ｓ１０４）。
　ユーザ端末２０では、ユーザが、受信した合計請求データを確認する（Ｓ１０５）。
　その後、ユーザ端末２０から取引管理装置１０Ｂに支払い指示データが送信される（Ｓ３０１）。
　また、取引管理装置１０Ｂは、ステップＳ３０１でユーザ端末２０から送信された支払い指示データにしたがって、支払いを実行する（Ｓ３０２）。
　また、ステップＳ３０２に続いて実行されるステップＳ１１０～Ｓ１１５の処理については、上述した処理と同一である。
　取引管理システム１Ｂでは、このように処理が実行され、複数のユーザの支払いの処理を容易にし、請求及び支払いに要する作業の簡易化を実現することができる。したがって、請求先では、支払いの処理を一括化して支払いの手続きを複数回行う必要がなく、また、請求を忘れることによる不払いを防止することが可能となる。請求元では自身の請求が他の請求とまとめられ一括して請求先に通知されるため、未払いを防止することが可能となる。
《変形例》
　図１５に示すシーケンス図を用いて、第２実施形態の変形例に係る取引管理システムにおける処理を説明する。第２実施形態の変形例に係る取引管理システムでは、ユーザに始めに合計請求（第１の請求）をし、ユーザからまだ支払いがされない場合に、次の合計請求をするとき、これも合計に含めて第２の請求とする。
　ここで、請求生成部１１２は、送信部１１３が合計請求データを送信後に請求先による支払いがされる前に、入力部１１１に請求先に対する複数の新たな請求データが入力されると、当該複数の新たな請求データに含まれる請求金額を加算して第２の合計請求金額を求めるとともに、送信部１１３が送信した合計請求金額と、求めた第２の合計請求金額とを加算して第３の合計請求金額を求め、第３の合計請求金額を含む新たな合計請求データを生成する。また、送信部１１３は、新たな合計請求データを請求先に送信する。
　なお、図１５に示す例で、図１４で用いた符号と同一の処理については、同一の符号を付す。また、図１５に示すシーケンス図において追加された処理については、太枠又は太字により強調する。ここで、図１５に示すように、ステップＳ１０１～Ｓ１０５の処理（第１の請求）で始めに生成する合計請求データを第１の合計請求データとする。
　ここで、ステップＳ１０４で取引管理装置１０Ｂからユーザ端末２０に送信された第１の合計請求データによる請求に対し、未払いであるときに、請求データが複数入力されると（Ｔ３０１）、取引管理装置１０Ｂは、第２の合計請求金額を算出する（Ｔ３０２）。
　その後、取引管理装置１０Ｂは、ステップＳ１０２で算出した未払いの第１の合計請求金額と、ステップＴ３０２で算出した未払いの第２の合計請求金額とを合わせて、第３の合計請求金額を算出する（Ｔ３０３）。
　続いて、取引管理装置１０Ｂは、ステップＴ３０２で算出した第３の合計請求金額を含む合計請求データを生成し（Ｔ３０４）、ユーザ端末２０に送信する（Ｔ３０５）。
　ユーザ端末２０では、この合計請求データが確認される（Ｔ３０６）。
　また、ユーザ端末２０から取引管理装置１０Ｂに支払い指示データが送信される（Ｓ３０１）。
　これにより、取引管理装置１０Ｂは、支払いを実行する（Ｓ３０２）。その後の処理は、図１１を用いて上述したステップＳ１０９～Ｓ１１５の処理であるため、図１５ではこれらの図示を省略し、説明も省略する。
　これにより、変形例に係る取引管理システムでは、複数のユーザの未払いである先にされた請求データ（第１の請求のデータ）を新たな請求データ（第２の請求のデータ）と合計して再請求することができる。したがって、請求元では自身の請求が他の請求とまとめられ一括して請求先に通知されるため、未払いを防止することが可能となる。また、請求先では請求の手続きを一括化して容易にするとともに、請求の存在を忘れることによる不払いを防止することが可能となる。
　１、１Ａ、１Ｂ　取引管理システム
　１０、１０Ａ、１０Ｂ　取引管理装置
　１１　制御部
　１１１　入力部
　１１２　請求生成部
　１１３　送信部
　１１４　リクエスト受信部
　１１５　コード生成部
　１１６　更新部
　１１７　ポイント記憶処理部
　１１８　スコア演算部
　１１９　リマインド送信部
　１２０　先払い演算部
　１２　記憶部
　Ｄ１　ユーザデータ
　Ｄ２　家計簿データ
　Ｄ３　ポイントデータ
　Ｄ４　スコアデータ
　Ｐ１、Ｐ２、Ｐ３　管理プログラム
　２０Ａ～２０Ｃ　請求者装置
　２０　ユーザ端末

Claims (15)

  1. 　請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される入力部と、
    　前記入力部に入力された同一の請求先IDに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、前記請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する請求生成部と、
    　前記請求生成部によって生成された合計請求データを前記請求先に送信する送信部と、
    　を備える取引管理装置。
  2. 　前記送信部が前記合計請求データを送信した前記請求先のユーザから、希望の支払い方法の情報を含み、前記ユーザが支払いをするためのコードの生成を要求するコード生成リクエストを受信するリクエスト受信部と、
    　前記リクエスト受信部が受信したコード生成リクエストが含む支払い方法で用いるコードを生成するコード生成部と、
    　をさらに備え、
    　前記送信部は、前記コード生成部が生成したコードを前記請求先のユーザに送信する
    　請求項１に記載の取引管理装置。
  3. 　請求先ＩＤと、当該請求先ＩＤで識別されるユーザが予め希望する金銭の支払い方法とを関連づける支払い方法データを記憶する支払い方法データ記憶部と、
    　前記支払い方法データにおいて前記請求先ＩＤと関連づけられる支払い方法で用いるコードを生成するコード生成部とをさらに備え、
    　前記請求生成部は、前記コード生成部が生成したコードを含む合計請求データを生成する
    　請求項１に記載の取引管理装置。
  4. 　ユーザのIDと、当該ユーザの金銭の支払いに使用される金融情報とを関連付ける金融データを記憶する金融データ記憶部と、
    　前記請求生成部が生成した合計請求データに対して前記ユーザからの支払い指示を受け付ける受付部と、
    　前記金融データ記憶部から前記ユーザのユーザIDと関連付けられる金融情報を抽出し、前記受付部が受け付けた支払い指示に対して、支払いを実行する実行部と、
    　をさらに備える請求項１に記載の取引管理装置。
  5. 　ユーザのIDと、当該ユーザの収支に関するデータと、当該ユーザの貯蓄に関するデータとを含む家計簿データを記憶する家計簿データ記憶部と、
    　前記請求生成部で生成された前記合計請求データの支払いに関する情報を、追加して前記家計簿データを更新する更新部と、
    　をさらに備える請求項１乃至４に記載の取引管理装置。
  6. 　前記請求生成部は、前記送信部が前記合計請求データを送信後に請求先による支払いがされる前に、前記入力部に前記請求先に対する複数の新たな請求データが入力されると、当該複数の新たな請求データに含まれる請求金額を加算して第２の合計請求金額を求めるとともに、前記送信部が送信した前記合計請求金額と、求めた前記第２の合計請求金額とを加算して第３の合計請求金額を求め、前記第３の合計請求金額を含む新たな合計請求データを生成し、
    　前記送信部は、前記新たな合計請求データを前記請求先に送信する
    　請求項２乃至５のいずれか１に記載の取引管理装置。
  7. 　前記請求生成部は、請求に対する支払いに対して前記請求先のユーザに報酬として付与されるポイントの値を求めるとともに、求めたポイント値を含む合計請求データを生成し、
    　前記合計請求データで通知された請求に対して支払いが完了すると、前記請求先のユーザの請求先IDと、前記ポイント値を関連付けてポイントデータとしてポイントデータ記憶部に記憶させるポイント記憶処理部を
    　さらに備える請求項１乃至６のいずれか１に記載の取引管理装置。
  8. 　前記請求生成部は、前記合計請求データの送信時から前記請求先のユーザによる支払い時までの支払い所要期間に応じ、前記支払い所要期間が短い場合には長い場合と比較して高くなるように定められたポイント値を求め、
    　前記ポイント記憶処理部は、前記請求先IDと、前記支払い所要期間に対して求められたポイント値とを関連付けてポイントデータ記憶部に記憶させる
    　請求項７に記載の取引管理装置。
  9. 　請求先のユーザの請求先IDと、前記請求先のユーザの支払いの即答性を評価するスコア値とが関連付けられるスコアデータを記憶するスコアデータ記憶部と、
    　前記合計請求で通知された請求に対して支払いが完了すると、前記合計請求データの送信時から前記請求先のユーザによる支払い時までの支払い所要期間毎に設定される前記請求先のユーザを評価するスコア値の演算方法に応じて、当該支払い所要期間に対する前記請求先のユーザのスコア値を求め、求めた前記スコア値により、前記スコアデータを更新するスコア演算部と、
    　をさらに備える請求項１乃至８のいずれか１に記載の取引管理装置。
  10. 　前記スコア演算部は、前記請求先のユーザによる前記合計請求データの確認時から、前記請求について未払い期間が所定期間以上経過すると、当該未払い期間に応じて設定される前記請求先のユーザを評価するスコア値の演算方法に応じて、当該未払い期間に対する前記請求先のユーザのスコア値を求め、求めた前記スコア値により、前記スコアデータを更新する
    　請求項９に記載の取引管理装置。
  11. 　前記合計請求データの送信後、前記請求先のユーザによる支払いがされない未払い期間が所定期間以上経過したとき、前記請求先のユーザに対し、支払いのリマインドデータを送信するリマインド送信部
    　をさらに備える請求項１乃至１０のいずれか１に記載の取引管理装置。
  12. 　前記リマインド送信部は、前記請求先のユーザによる前記合計請求データの確認時から、前記請求先のユーザによる支払いがされない未払い期間が所定期間以上経過すると、前記請求先のユーザに対し、支払いのリマインドデータを送信する
    　請求項１１に記載の取引管理装置。
  13. 　前記入力部に入力される請求データは、金銭の支払いに関する請求に付与された請求IDをさらに含み、
    　前記請求先のユーザから、特定の請求IDと、先払い期間とを含み、当該請求IDで特定される請求に関する先払いを希望する先払いリクエストを受信すると、当該先払い期間における前記請求IDに関して支払う合計先払い金額を演算する先払い演算部をさらに備え、
    　前記請求生成部は、前記先払い演算部で演算された合計先払い金額を含む先払い請求データを生成する
    　請求項１乃至１２のいずれか１に記載の取引管理装置。
  14. 　請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される入力ステップと、
    　前記入力ステップで入力された同一の請求先IDに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、前記請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する請求生成ステップと、
    　前記請求生成ステップにおいて生成された合計請求データを前記請求先に送信する送信ステップと、
    　を有する取引管理方法。
  15. 　コンピュータに、
    　請求先のユーザを識別する請求先ＩＤと、請求金額とを含む請求データが入力される入力機能と、
    　前記入力機能に入力された同一の請求先IDに対する複数の請求データに含まれる請求金額を加算して合計請求金額を求めるとともに、合計の請求を識別する合計請求ＩＤと求めた合計請求金額とを含み、前記請求先に対して金銭の支払いの要求を通知する一つの合計請求データを生成する請求生成機能と、
    　前記請求生成機能によって生成された合計請求データを前記請求先に送信する送信機能と、
    　を実現させる取引管理プログラム。
PCT/JP2019/033194 2018-11-01 2019-08-23 取引管理装置、取引管理方法及び取引管理プログラム WO2020090202A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018-206922 2018-11-01
JP2018206922A JP2020071787A (ja) 2018-11-01 2018-11-01 取引管理装置、取引管理方法及び取引管理プログラム

Publications (1)

Publication Number Publication Date
WO2020090202A1 true WO2020090202A1 (ja) 2020-05-07

Family

ID=70464450

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/033194 WO2020090202A1 (ja) 2018-11-01 2019-08-23 取引管理装置、取引管理方法及び取引管理プログラム

Country Status (2)

Country Link
JP (1) JP2020071787A (ja)
WO (1) WO2020090202A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002259900A (ja) * 2000-12-28 2002-09-13 Confidential Accounting Service:Kk 電子請求書管理システム
JP2003281454A (ja) * 2002-03-22 2003-10-03 Ntt Comware Corp 統合請求システム、統合請求方法、統合請求システム用プログラム、統合請求システム用記録媒体
JP2004259196A (ja) * 2003-02-27 2004-09-16 Com'app:Kk 通信ネットワークを利用して電子請求書の処理を行うための方法及びシステム
JP2015114774A (ja) * 2013-12-10 2015-06-22 株式会社Ｍｒｓホールディングズ コードシステム、端末装置、及びコード読取装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002259900A (ja) * 2000-12-28 2002-09-13 Confidential Accounting Service:Kk 電子請求書管理システム
JP2003281454A (ja) * 2002-03-22 2003-10-03 Ntt Comware Corp 統合請求システム、統合請求方法、統合請求システム用プログラム、統合請求システム用記録媒体
JP2004259196A (ja) * 2003-02-27 2004-09-16 Com'app:Kk 通信ネットワークを利用して電子請求書の処理を行うための方法及びシステム
JP2015114774A (ja) * 2013-12-10 2015-06-22 株式会社Ｍｒｓホールディングズ コードシステム、端末装置、及びコード読取装置

Also Published As

Publication number Publication date
JP2020071787A (ja) 2020-05-07

Similar Documents

Publication Publication Date Title
US8527413B2 (en) Method and system for mobile bill presentment and payment messaging and marketing
US8326770B1 (en) Monetary transfer in a social network
JP6672377B2 (ja) 給与前払いシステム、給与前払い方法、及びそのプログラム
JP6065475B2 (ja) 決済装置、及び決済方法
JP5680518B2 (ja) 督促決済システム
JP6349450B1 (ja) 給与受取システム、給与受取方法、及びプログラム
JP6437155B1 (ja) 支払管理サーバ、支払管理システム、支払管理方法及び支払管理プログラム
JP2004326727A (ja) 決済処理サーバ、決済処理方法、決済処理プログラム、決済処理端末装置、決済処理端末方法、及び決済処理端末プログラム
US10262361B2 (en) Electronic money server, electronic money processing method, electronic money processing program product, and storage medium on which electronic money processing program product is stored
JP2007213399A (ja) 電子マネー決済システム、加入者端末、加入者端末の決済方法及びプログラム
WO2009050825A1 (ja) 決済システムとの連携機能を有するアフィリエイトシステム
WO2020090202A1 (ja) 取引管理装置、取引管理方法及び取引管理プログラム
WO2012127478A1 (en) System and method for rule-based presentment and payment of bills or invoices
JP6730019B2 (ja) 電子決済システムおよび電子決済方法
JP2006040249A (ja) プリペイドカードサービス運用システム及び方法
JP5244505B2 (ja) リアルタイム・アフィリエイト報酬支払いシステム
KR20110126872A (ko) 인터넷 기반의 장례 서비스 사전 제시형 후불식 장례 서비스 시스템
JP2007233480A (ja) 有料メール配信システムとそれに用いるメール処理サーバ
JP2020098494A (ja) 処理システム、処理装置、処理方法及びプログラム
JP4421924B2 (ja) 振込サービスシステム
JP2002312582A (ja) 電子書面交付システム、電子書面交付システムにおける特典付与方法およびプログラム
TW574663B (en) Method for calendar applied to commercial transaction services
KR102401317B1 (ko) 공정하고 투명한 기부 서비스 시스템 및 방법
WO2021141083A1 (ja) 給与前払管理装置、給与前払管理方法およびプログラム
KR101987066B1 (ko) 모바일 장치를 이용한 청구 및 결제 서비스 시스템 및 방법과, 이를 위한 컴퓨터 프로그램

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: 19878405

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19878405

Country of ref document: EP

Kind code of ref document: A1