JP5261734B2 - Scheduling processing method and apparatus, and settlement processing method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To improve a payer's convenience, respond the payer's payment intention, and prevent using by unspecified payers or recipients. <P>SOLUTION: A first contract is made between a payer and a bank, and one or a plurality of debit numbers are issued corresponding to the payer's account for settlement. A second contract is made between the payer and the bank, and one or a plurality of debit numbers are issued corresponding to the payer's account for settlement. When the payer purchases goods or the like from a recipient, the recipient is notified of the debit number used in the current deal. The recipient notifies to the bank a transfer request containing the debit number notified by the payer, the transfer number used by the deal, and the information on the deal. The payer goes to the bank and confirms the content of the transfer request regarding his or her debit number. If there is no problem, he or she directs recognition. Accordingly, remittance is made from the payer's account for settlement to the recipient's account for settlement. <P>COPYRIGHT: (C)2009,JPO&amp;INPIT

Description

  The present invention relates to a technique related to a new settlement method.

  For example, Japanese Patent Application Laid-Open No. 2002-299717 discloses a technique for giving a prior notice to a user before the scheduled date of account withdrawal, and enabling payment of the price before the scheduled date of account withdrawal. Specifically, a step of receiving an automatic withdrawal scheduled statement in which one or more account transfer requests are collected from a server of a storage company, a step of storing the account transfer request for each user in the first storage unit, Creating a prior notice from the information relating to the account transfer of the direct debit request read from the first storage unit and the terminal number of the user read from the second storage unit storing the user attribute information; Sending an account withdrawal advance notice summarizing the user's advance notice to a server of an information distribution company. As a result, it becomes possible to respond to a request from a user who wishes to transfer money while there is a balance in the account. However, it is limited to payment for a bill from a company that has previously made an automatic withdrawal contract.

Japanese Laid-Open Patent Publication No. 2006-259854 discloses a technique for protecting personal information of a payer and a claimant and preventing an artificial deficiency in payment. Specifically, the server device includes account information storage means for storing at least payer's account information among a biller and a payer, payer's account information stored in the account information storage means, and A payment information storage means for storing information relating to payment between the payer and the claimant in association with each other, and predetermined for each payment to be executed transmitted from the communication terminal of the claimant having a payment function, The payment information transmitted from the communication terminal of the requester after authenticating that the authentication information for payment common to the payer and the payer is stored in the payment information storage means in association with the payer's account information. Means for storing the information on the amount charged to the person and the information on the deposit account for the amount charged in association with the authentication information for payment, the authentication information for payment, and the association with this Et The notification means for notifying the payer's communication terminal of the information on the charged amount and the approval of the payment for the charged amount associated with the authentication information for payment indicated by the information notified by the notifying means. When it is obtained from a terminal, a payment unit that is associated with the payment authentication information and a payment unit that performs a payment process of the billing amount that is associated with the payment authentication information between the payment account and the payment account. . Although account information can be concealed, it is not configured to enable various payments. In addition, the payer's communication terminal is used and cannot be used for issuing a ticket.
JP 2002-297717 A JP 2006-259854 A

  For example, there are a method of using a credit card, cash on delivery, bank transfer, etc. as a settlement method when purchasing a product or the like in a virtual shop on the Internet or a normal mail order. Credit cards are not always usable, and COD is expensive. Bank transfer is relatively inexpensive, but when using it for the first time, it is necessary to specify the payee's bank, account number, account name, etc., and the account number, account name, etc. are incorrect. May cause problems such as designation. There is also a settlement service called automatic debit, but as mentioned above, a contract procedure is necessary between the payee and the payer in advance, and it is difficult to use for settlement for unspecified customers. As for automatic withdrawals, once a contract is made, it will be withdrawn mechanically regardless of the payer's intention, resulting in an insufficient balance due to an unscheduled withdrawal, or an error after the contract between the payer and the payee ends. Even if a claim is made, a situation occurs in which the withdrawal is made. As described above, the conventional settlement methods have problems in terms of payer convenience and confirmation of payment intention.

  In addition to paying for goods and services in a lump sum, the same problem occurs when paying in installments, or when paying taxes and public charges (payment in installments) (referred to collectively as installments in this application). was there. Furthermore, when paying in installments, the payer has a certain merit, but there is also a problem that the collecting side takes a lot of time for collecting.

  Accordingly, an object of the present invention is to provide a technique relating to a new settlement method that improves the convenience of the payer, respects the payer's intention to pay, and can be used by unspecified payers and payees. It is.

  Furthermore, another object of the present invention is to provide a technique for making it possible to easily implement payment of various charges.

  In the present invention, a first contract is made between a payer and a bank (including other financial institutions), and one or a plurality of withdrawal numbers are issued corresponding to the payer's settlement account. Further, a second contract is made between the payee and the bank, and one or more transfer numbers are issued corresponding to the payee's settlement account. Then, when the payer purchases goods or the like from the payee, the payee is notified of the withdrawal number used in the current transaction. The payee notifies the bank of a transfer request including the withdrawal number notified from the payer, the transfer number used in the current transaction, and information relating to the current transaction. The payer goes to the bank and confirms the details of the transfer request for his / her withdrawal number. In response to this, remittance is performed from the payer's settlement account to the payee's settlement account. In this way, there is no need to specify the payee's account number or account name, so the convenience of the payer is improved, and payment is made with the approval of the payer. Even if there is no contractual relationship in advance, the bank can use a settlement service similar to withdrawal. Furthermore, by applying the scheme as described above, it is possible to handle various payments including taxes and utilities.

  Specifically, in the settlement processing method according to the first aspect of the present invention, (A) the processing unit corresponds to the account number of the settlement account of the first user according to the usage request from the first user. A step of issuing one or a plurality of transfer numbers and registering them in the payee table, and (B) the account of the settlement account of the second user according to the usage request from the second user by the processing unit A step of issuing one or a plurality of withdrawal numbers corresponding to the numbers and registering them in the payer table; and (C) the processing unit, the name of the second user and the second user The specific withdrawal number notified from the second user to the first user by performing the purchase application for the purchase target, the specific transfer number of the first user, the amount, and the data related to the purchase target Depending on the transfer request, issue a request number A specific transfer number and amount corresponding to the withdrawal number and request number are registered in the withdrawal table, and the name of the second user, a specific withdrawal number, amount and purchase object corresponding to the specified transfer number and request number And (D) when the account number and withdrawal number of the settlement account are specified by the second user, or the account number of the settlement account is specified by the second user. When a withdrawal number that is specified and corresponds to the account number of the settlement account is specified from the payer table, the processing unit is responsible for data relating to an unapproved transfer request that corresponds to the specified or specified withdrawal number from the withdrawal table. The step of generating and outputting an approval confirmation list for the transfer request and (E) the processing unit identifies the transfer request selected from the approval confirmation list In response to the detailed display request from the second user, the transfer number related to the selected transfer request, the amount corresponding to the selected transfer request request number, and the data related to the purchase target are extracted from the transfer table. A step of generating and outputting approval confirmation data for presentation to the second user using the extracted data, and (F) an approval instruction from the second user for the approval confirmation data by the processing unit. In response, register the approval result in the transfer table corresponding to the request number related to the approval confirmation data and the transfer number related to the request number, and correspond to the request number related to the approval confirmation data and the specified or specified withdrawal number Register the approval result in the withdrawal table and store the settlement data including the request number related to the approval confirmation data and the specified or specified withdrawal number in the withdrawal approval table (G) The transfer number and amount corresponding to the request number and withdrawal number included in the settlement data are identified from the withdrawal table for the unsettled settlement data registered in the withdrawal approval table by the processing unit. Identify the account number of the settlement account corresponding to the withdrawal number from the payer table, identify the account number of the settlement account corresponding to the transfer number from the payee table, and correspond to the withdrawal number for the specified amount A remittance step for performing processing for remittance from the settlement account to the settlement account corresponding to the transfer number.

  Thus, the above-described problems can be solved by performing the specific processing described above in cooperation with various tables by the processing unit. Further, by using the withdrawal number, the withdrawal number can be used separately for management, for example, without presenting the account number to the first user. Transfer numbers can also be used for management purposes. Further, by managing the transfer request with the transfer table and the withdrawal table, it becomes possible to easily manage the approval result and the like from the respective standpoints. Furthermore, the withdrawal approval table is also effective for performing the remittance step flexibly.

  In addition, in the payer table described above, there may be further registered withdrawal conditions such as whether or not withdrawal approval is required, corresponding to the withdrawal number. In that case, if a withdrawal condition that does not require withdrawal approval is registered in the payer table in accordance with the withdrawal number, an approval step may be performed upon completion of the transfer request registration step. For example, for the first user who can be trusted, the remittance is performed without the second user's approval again. Therefore, the convenience of the second user is improved.

  Further, the computer system described above may be connected to an automatic teller machine operated by a second user. Then, after the approval step, the processing unit further includes a step of causing the automatic teller machine operated by the second user to print out at least a part of the data related to the purchase target related to the approval confirmation data on the receipt. You may make it. For example, when the purchase target is a concert ticket or the like, by printing the ticket data on the receipt, it is possible to reduce the trouble of mailing the ticket separately. Also, tickets can be sold using ATMs effectively.

  In addition, if the transfer request registration step described above indicates that the transfer number included in the transfer request is the transfer account transfer number in the other bank of the partner, the processing unit will transfer to another bank. The account number of the settlement account of the other bank that is registered in the recipient table of the other computer system and that corresponds to the transfer number is obtained from the computer system of the other bank and corresponds to the request number and withdrawal number Then, a step of registering in the withdrawal table may be included. In addition, the remittance step reads out the data corresponding to the request number and the withdrawal number included in the settlement data from the withdrawal table for the unsettled settlement data registered in the withdrawal approval table by the processing unit; When the transfer number included in the above-mentioned data is the transfer number of a settlement account in another bank, the processing unit specifies the account number of the settlement account corresponding to the withdrawal number from the payer table, Processing for remittance from the settlement account corresponding to the withdrawal number for the amount included in the read data to the account related to the account number of the settlement account of another bank included in the read data May be included. Withdrawal is usually carried out within the same bank, but if the bank has partnered to implement this method, it will be possible for other banks to send money as well.

  Further, in the payer table, a withdrawal condition for the number of days from the approval date to the withdrawal date may be further registered corresponding to the withdrawal number. In such a case, the approval step described above includes a step of extracting a withdrawal condition corresponding to the designated or specified withdrawal number from the payer table by the processing unit, and an approval date and withdrawal by the processing unit. The step of specifying the settlement date from the number of days included in the condition and the processing unit store the settlement data including the request number related to the approval confirmation data and the designated or specified withdrawal number corresponding to the settlement date in the withdrawal approval table. Step may be included. In this manner, the second user can set the withdrawal condition according to his / her own fund schedule and set the settlement date appropriately.

  Furthermore, in the first aspect of the present invention, the processing unit transfers the request number related to the approval confirmation data and the transfer related to the request number in response to the rejection instruction or the no purchase instruction from the second user for the approval confirmation data. Data indicating rejection or no purchase is registered in the transfer table corresponding to the number, and data indicating rejection or no purchase is registered in the withdrawal table corresponding to the request number related to the approval confirmation data and the specified or specified withdrawal number And the step of storing the approval rejection data including the request number related to the approval confirmation data and the specified or specified withdrawal number in the withdrawal approval rejection table, and the processing unit relates to each transfer number or a specific user in the transfer table. Counting the number of transfer requests for which data indicating no purchase is registered for each transfer number group to be processed, and processing Accordingly, in the draw down table, for each withdrawal number group associated with withdrawal numbers every or some other user, may further include the steps of counting the number of transfer requests data representing the rejection is registered. In this way, it becomes possible to identify a problem user who has not made a purchase but has issued a transfer request, or a problem user who has applied for purchase but refused payment.

  In the settlement processing method according to the second aspect of the present invention, (A) the processing unit accepts the receiving condition corresponding to the account number of the settlement account of the first user according to the usage request from the first user. A step of issuing a transfer number every time and registering it in the payee table, and (B) processing unit corresponding to the account number of the settlement account of the second user according to the usage request from the second user. Issuing one or a plurality of withdrawal numbers and registering them in the payer table, and (C) the processing unit, the name of the second user and the second user A transfer request including a specific withdrawal number notified from the second user to the first user by performing a purchase application, a specific transfer number of the first user, an amount, and data related to the purchase target. In response, a request number is issued, a specific withdrawal number and A specific transfer number and amount corresponding to the request number are registered in the withdrawal table, and the second user's name, specific withdrawal number, amount, and data related to the purchase object corresponding to the specific transfer number and request number, A transfer request registration step for registering the payment account in the transfer table, and (D) when the account number and withdrawal number of the settlement account are designated by the second user, or the account number of the settlement account is designated by the second user, and When the withdrawal number corresponding to the account number of the settlement account is identified from the payer table, the processing unit is data relating to an unapproved transfer request corresponding to the designated or identified withdrawal number from the withdrawal table. , Extract the data satisfying the receipt condition registered in the recipient table corresponding to the transfer number included in the data, and generate the approval confirmation list for the transfer request And (E) the transfer unit selected from the approval confirmation list by the processing unit, and in response to the detailed display request from the second user, the transfer request is transferred from the transfer table to the selected transfer request. Extracting the transfer number and the amount corresponding to the selected transfer request request number and the data related to the purchase object, and generating approval confirmation data to be presented to the second user using the extracted data And (F) a transfer table corresponding to the request number related to the approval confirmation data and the transfer number related to the request number in accordance with the approval instruction from the second user for the approval confirmation data by the processing unit (F) The approval result is registered in the registration table, and the approval result is registered in the withdrawal table corresponding to the request number related to the approval confirmation data and the specified or specified withdrawal number. An approval step for storing settlement data including a request number related to data and a specified or specified withdrawal number in the withdrawal approval table, and (G) processing unit for unsettled settlement data registered in the withdrawal approval table, Specify the transfer number and amount corresponding to the request number and withdrawal number included in the settlement data from the withdrawal table, identify the account number of the settlement account corresponding to the withdrawal number from the payer table, and change the transfer number from the payee table A remittance step for identifying the account number of the corresponding settlement account and performing a process for transferring the specified amount from the settlement account corresponding to the withdrawal number to the settlement account corresponding to the transfer number .

  Thus, by setting the transfer number for each receiving condition, flexible settlement can be performed.

  The scheduling process method according to the third aspect of the present invention includes: (A) the processing unit 1 or 2 corresponding to the account number of the settlement account of the first user according to the usage request from the first user. A step of issuing a plurality of transfer numbers and registering them in the payee table, and (B) processing unit corresponding to the account number of the settlement account of the second user according to the usage request from the second user. Issuing one or a plurality of withdrawal numbers and registering them in the payer table, (C) the specific withdrawal number notified from the second user to the first user by the processing unit, and the first user A request number is issued in response to a partial collection request including a specific transfer number, a single charge amount, a total charge amount, and data related to the billing object, and corresponds to a specific withdrawal number and request number. A specific transfer number, the invoice amount and the total invoice amount The first withdrawal request content data including the registration data is registered in the withdrawal table, and includes a specific withdrawal number, a charge amount for one time, a total charge amount, and data relating to a billing object corresponding to the specific transfer number and the request number. A partial collection request registration step of registering the transfer request content data in the transfer table, and (D) when the account number and withdrawal number of the settlement account are designated by the second user, or the settlement account of the settlement account is designated by the second user When an account number is specified and a withdrawal number corresponding to the account number of the settlement account is specified from the payer table, the processing unit issues an unapproved withdrawal request corresponding to the specified or specified withdrawal number from the withdrawal table. Extracting the content data, generating and outputting an approval confirmation list for the withdrawal request content data, and (E) selecting from the approval confirmation list by the processing unit In response to a detailed display request from the second user that identifies the withdrawal request content data, a transfer number related to the selected withdrawal request content data and a request for the selected withdrawal request content data from the transfer table Extracting the billing amount for one time corresponding to the number and data relating to the billing object, and generating and outputting approval confirmation data including the extracted data for presentation to the second user; (F) The processing unit registers the approval result in the transfer table corresponding to the request number related to the approval check data and the transfer number related to the request number in accordance with the approval instruction from the second user for the approval check data. Register the approval result in the withdrawal table corresponding to the request number related to the confirmation data and the specified or specified withdrawal number, and include the request number related to the approval confirmation data. The approval step for storing the data for remittance in the approval table, and (G) the processing unit associates the approval confirmation data with the request number related to the approval confirmation data according to the approval instruction from the second user. The second request number issued is issued, and the total charge amount in the first withdrawal request content data corresponding to the request number related to the approval confirmation data is replaced with the difference between the total charge amount and the approved amount Is registered in the withdrawal table corresponding to the withdrawal number and the second request number related to the approval confirmation data, and the total charge in the first transfer request content data corresponding to the request number related to the authorization confirmation data The second transfer request content data in which the amount is replaced with the difference between the total billed amount and the approved amount is assigned to the transfer number and the second request number related to the approval confirmation data. And a automatic data generation step of registering in the table.

  By carrying out such processing, the data necessary for the next payment is automatically generated for each payment, so that the first user does not need to make many requests, and the labor saving of the first user is achieved. This will enable the use of this service.

  Further, in the third aspect of the present invention, when the approval instruction from the second user includes an amount different from the one billed amount as the amount approved by the second user, it is registered in the transfer table. The approved amount is included in the approved result, the approved amount is included in the approved result registered in the withdrawal table, and the approved amount may be included in the data for remittance. If the second user designates the amount that can be paid this time, the amount is registered according to that and the remaining amount to be paid from the next time is also set.

  Furthermore, in the third aspect of the present invention, the first withdrawal request content data and the first transfer request content data may include data for determining a billing period. In this case, the processing unit searches the unapproved first transfer request content data or the first withdrawal request content data even after the billing period has elapsed in the transfer table or the withdrawal table, and the unapproved first transfer request content. If the data or the first withdrawal request content data exists, issue the third request number associated with the first transfer request content data or the request number related to the first withdrawal request content data, The third withdrawal request content data obtained by changing the data for determining the billing period in the first withdrawal request content data to the data for determining the next billing period is the withdrawal number related to the first withdrawal request content data. In order to register the next billing period with the data for defining the billing period in the first transfer request content data, registered in the withdrawal table corresponding to the third request number A second automatic data generation step of registering the third transfer request content data changed to data in the transfer table corresponding to the transfer number and the third request number related to the first transfer request content data; Also good. In this way, even if there is no payment within each time limit, data for the next billing period can be automatically generated, and the payment status can be managed appropriately. In this way, it becomes possible to calculate an arrears fee to be described later based on the request contents data and the approval result.

  Furthermore, in the third aspect of the present invention, the rating of the first user may be registered in the recipient table in correspondence with the account number of the first user's settlement account. In this case, the processor approves the transaction from the second user settlement account specified in the payer table from the withdrawal number corresponding to the request number included in the data for remittance registered in the approval table. And the processing unit identifies the rating of the first user specified in the payee table from the transfer number corresponding to the request number included in the data for remittance registered in the approval table. The payment grace period corresponding to the first user's rating is specified from the grace period table that holds the correspondence between the rating and the grace period, and the transfer number corresponding to the request number included in the data for remittance or The account number of the first user's settlement account identified in the payee table from the transfer number corresponding to the request number included in the data for remittance; The step of registering the deposit / remittance schedule data including the scheduled deposit date obtained from the specified deposit grace period and the approval date in the deposit / remittance schedule table, and the processing unit deposit the current date from the deposit / remove schedule table. The method may further include a step of extracting data that is a scheduled date and depositing or transferring money to the first user's settlement account according to the data. In this way, substantial remittance will be made after the number of grace days depending on the rating, and an incentive to raise the rating will work in order to increase fund efficiency. If any problem (for example, bankruptcy) occurs, the damage can be reduced by stopping the deposit / remittance process.

  Furthermore, in the third aspect of the present invention, the processing unit gives the payer the account number of the transfer number or settlement account related to the user registered in the transaction suspension list for storing information identifying the user who has suspended the transaction. A step of extracting from the table; and a step of moving the deposit / remittance schedule data including the extracted transfer number or the account number of the settlement account by the processing unit from the deposit / remittance schedule table to the transaction stop data storage unit; The processing unit may further include a step of moving unapproved withdrawal request content data including the extracted transfer number from the withdrawal table to the transaction stop data storage unit. In this way, it becomes possible to prevent deposits and remittances to problematic recipients.

  A program for causing a computer to execute this method can be created, and this program is stored in a storage medium or storage device such as a flexible disk, a CD-ROM, a magneto-optical disk, a semiconductor memory, or a hard disk. . Moreover, it may be distributed as a digital signal via a network or the like. The intermediate processing result is temporarily stored in a storage device such as a main memory.

  According to the present invention, it becomes possible to introduce a new settlement method that improves the convenience of the payer, respects the payer's intention to pay, and can be used by unspecified payers and payees. .

  Further, according to another aspect of the present invention, it is possible to easily carry out various payments.

[Embodiment 1]
First, an outline of the settlement service according to the first embodiment of the present invention will be described. In this settlement service, it is not necessary for the dealer 100 that sells products and the user 200 who purchases products from the dealer 100 to make a contract for settlement in advance. However, as shown in FIG. 1, the store 100 makes an application for use of the payment service including the data of the account for payment to the bank 300 (step (1)). One or a plurality of transfer numbers are issued to the settlement account according to the information and notified to the store 100 (step (2)).

  As shown in FIG. 2, the user 200 makes an application for the use of the settlement service including the settlement account data to the bank 300 asynchronously with the procedure of FIG. 1 (step (3)). The bank 300 issues one or a plurality of withdrawal numbers to the settlement account related to the use application and notifies the user 200 (step (4)).

  Thereafter, as shown in FIG. 3, when the user 200 purchases a product or the like from the store 100, if the user 200 uses this payment service as a payment method, the user 200 notifies the store 100 of his / her withdrawal number. (Step (5)). Then, the store 100 receives the withdrawal number received from the user 200, the transfer number of the store 100 used this time, data related to sales (including data of the user 200, data on products, etc., and print data on the receipt), and the like. The transfer request including this is notified to the bank 300 (step (6)). The notification of the transfer request itself may be performed online or by means such as FAX or e-mail. The bank 300 accumulates the transfer request in the system and waits for the approval by the user 200 when the approval of the user 200 is necessary.

  The user 200, for example, goes to an automated teller machine (ATM) of the bank 300, authenticates, confirms the content of a specific transfer request, and gives a transfer approval for the specific transfer request ( Step (7)). At this stage, it is also possible to reject a specific transfer request. In addition, if there is an erroneous transfer request from the store 100 in some cases, “no purchase” can be registered. When the bank 300 receives the transfer approval from the user 200, the bank 300 prints and outputs the print data included in the transfer request on the receipt (step (8)). For example, if the product is a ticket, it is possible to save the trouble of mailing the ticket itself by printing the ticket data (seat data, etc.) on the receipt. Further, the bank 300 executes the withdrawal process for the transfer request having received the transfer approval if the settlement account of the store 100 and the settlement account of the user 200 belong to the bank 300, and the settlement of the store 100 is performed. When the account for use is that of a partner bank different from that of the bank 300, a transfer process is performed and remittance is performed (step (9)). Furthermore, the bank 300 notifies the store 100 of the result of the transfer request that received the transfer approval or the like (including instructions such as transfer refusal or no purchase) (step (10)).

  By performing such processing, it is not necessary to make a contract for withdrawal in advance between the store 100 and the user 200, and settlement can be made between unspecified users (including cases between individuals occurring in an auction or the like). Will be able to do. Further, the transfer request is notified to the bank 300 in advance, and the user 200 does not need to input the account number or account name of the store 100, but only has to select approval or rejection. Is getting smaller. Furthermore, since the user 200 can determine approval or rejection after determining the contents of each transfer request, it is possible to avoid erroneous withdrawals.

  Next, FIG. 4 shows an example of a computer system used in the settlement service described with reference to FIGS. For example, in the network 1 such as the Internet, one or a plurality of user terminals 5 that are, for example, personal computers operated by the user 200, and one or a plurality of sales that are managed and operated by the store 100 and that sell products and the like. The store server 3 is connected to one or a plurality of bank systems 7 of banks that provide the settlement service. A plurality of ATMs 9 (9a to 9c in FIG. 4) are connected to the bank system 7 and perform processing in cooperation. The ATM 9 has a normal ATM function and can perform processing as described below.

  Instead of placing an order online using the user terminal 5 as in a normal mail order, an order may be made to the store 100 by telephone. Similarly, the dealer server 3 accepts an order, does not send a transfer request to the bank system 7, accepts an order by telephone or FAX, or notifies the bank system 7 of a transfer request by FAX or e-mail. You may do it. Furthermore, although the example which implements transfer approval etc. using ATM9 below is demonstrated, you may make it implement transfer approval etc. using the user terminal 5. FIG.

  FIG. 5 shows a functional block diagram of the bank system 7. The bank system 7 includes a store registration unit 72 that performs a process of registering data on a use application from the store 100, a recipient table 76 that stores data registered by the store registration unit 72, and a user 200. Refer to the user registration unit 73 that performs the process of registering data about the application for use from the payer table, the payer table 77 that stores the data registered by the user registration unit 73, the payee table 76, and the payer table 77. The transfer request receiving unit 71 that receives a transfer request from the store 100 and generates the data for the payee and the data for the payer, and the transfer table that stores the data for the payee generated by the transfer request receiving unit 71 74, a withdrawal table 75 for storing payer data generated by the transfer request receiving unit 71, a transfer table 74, Refer to the drop table 75, the payee table 76, and the payer table 77, and an approval processing unit 78 that performs an approval confirmation process in cooperation with the ATM 9, and a process of the approval processing unit 78 when approval is obtained from the user 200 A withdrawal approval table 79 for storing the results, a withdrawal approval refusal table 80 for storing the processing result of the approval processing unit 78 when the approval is not obtained from the user 200, a payee table 76, a payer table 77, a withdrawal table. From the settlement processing unit 83 that performs processing for settlement with reference to 75 and the withdrawal approval table 79, the withdrawal processing unit 84 that performs withdrawal processing according to an instruction from the settlement processing unit 83, and the settlement processing unit 83 A transfer processing unit 85 that performs a transfer process in response to the instruction of the transfer, and a process of aggregating approval results registered in the transfer table 74 and the withdrawal table 75 Having a Hodokosuru aggregating part 81, and aggregate data storage unit 82 for storing the processing results of the aggregation processing unit 81.

  Next, processing contents of the system shown in FIGS. 4 and 5 will be described with reference to FIGS. First, the processing at the time of application for use from the user 200 to the bank 300 will be described with reference to FIGS. The user registration unit 73 includes a name, contact information (address, telephone number, e-mail address, etc.), account data including an account number for settlement, withdrawal conditions (presence / absence of withdrawal notice (before / after and unnecessary), withdrawal notice) Contact information (e-mail address, address, FAX number, etc.), withdrawal permission information (unconditional withdrawal permission (withdrawal with or without withdrawal approval), unconditional withdrawal prohibited (withdrawal with or without withdrawal approval) Set if you want to change the withdrawal number after use.), Withdrawal approval required (withdrawal only at the time of approval), withdrawal date (withdrawal after n (an integer greater than or equal to 0) days from the date of approval) )) Is received and stored in a storage device such as a main memory (step S1). Note that the user registration unit 73 recognizes data sent by FAX, extracts data from e-mail data, obtains data input to a web page for input by the user 200, or applies an application form. In the case of application, the data input by the operator is acquired or received in various forms. Also, a plurality of withdrawal numbers can be issued for one account number. When issuing a plurality of withdrawal numbers, the number of withdrawal numbers is required for withdrawal conditions.

  Then, the user registration unit 73 issues withdrawal numbers as many as requested in the usage application, and stores them in a storage device such as a main memory (step S3). The withdrawal number includes the bank code so that the bank can be specified. Thereafter, payer data including name, contact information, account data, withdrawal conditions (in addition to the above-mentioned data, expiration date (use date of this settlement service)) and withdrawal number are registered in the payer table 77 (step S5).

  FIG. 7 shows an outline of the data structure of the payer table 77. As shown in FIG. 7, as a contractor, data is stored for each user (users 1 to 3 in the example of FIG. 7). FIG. 8 shows the detailed structure of data for each user. FIG. 8 shows a specific example of the data structure of the user 3, and the account number (two in this case) of the account for settlement is registered corresponding to the name and contact data for identifying the user 3. Further, one or a plurality of withdrawal numbers and withdrawal conditions (two sets in FIG. 8) are registered corresponding to the account number of each settlement account. With regard to withdrawal conditions, as described above, the expiration date (as it is by default or the deadline if specified in particular), whether or not withdrawal notices are made and before / after, contact information for withdrawal notices, withdrawal availability information, Conditions such as settlement date are registered. Thus, since the withdrawal condition can be set for each withdrawal number, the user 200 can use the withdrawal number properly according to the opponent. The withdrawal conditions can be changed later by applying for a change. In particular, when it is set not to withdraw due to a trouble with the store 100 afterwards, unconditional withdrawal prohibition may be set in the withdrawal allowance information. Further, when the store 100 can be trusted, if the withdrawal number set for unconditional withdrawal permission is notified in the withdrawal permission / inhibition information, remittance can be made without executing the approval procedure.

  Finally, the user registration unit 73 outputs a registration completion notification including the withdrawal number (step S7). In the case of a use application from FAX, e-mail, or an input Web page, a registration completion notice is output by FAX, e-mail, or output Web page. In the case of a paper use application, for example, it is printed and sent to the user 200 by mail.

  In this way, the initial registration of the user 200 is completed.

  Next, with reference to FIG. 9 to FIG. 11, a process at the time of application for use from the store 100 to the bank 300 will be described. The store registration unit 72 stores the name, contact information (address, telephone number, e-mail address, etc.), account data including the account number for settlement, withdrawal conditions (receipt period (waiting for payment from the user 200), fee Usage application including payment conditions (payee pay / pay pay) is received and stored in a storage device such as a main memory (step S11). Note that the store registration unit 72 recognizes data sent by FAX, extracts data from e-mail data, acquires data input to the Web page for input by the store 100, for example, When the application form is applied, the data input by the operator is acquired and received in various forms. In addition, a plurality of transfer numbers can be issued for one account number. When a plurality of transfer numbers are issued, the number of transfer numbers required for receiving conditions is required.

  And the store registration part 72 issues the number of transfer numbers requested | required by use application, for example, stores it in memory | storage devices, such as main memory (step S13). The transfer number includes, for example, a bank code so that the bank can be specified. Thereafter, recipient data including name, contact information, account data, receipt conditions (in addition to the above data, expiration date (use date of this settlement service)), and transfer number are registered in the recipient table 76 (step S15).

  FIG. 10 shows an outline of the data structure of the recipient table 76. As shown in FIG. 10, each corporate user (corporations 1 and 2 and store A in the example of FIG. 10 is not limited to a corporation but may be an individual user) as a contractor. It is designed to store data. FIG. 11 shows the detailed structure of data for each corporate user. FIG. 11 shows a specific example of the data structure of the store A, and the account number (two in this case) of the settlement account is registered corresponding to the name specifying the store A and the data of the contact information. Furthermore, one or a plurality of transfer numbers and receiving conditions (two sets in FIG. 11) are registered corresponding to the account number of each settlement account. As described above, the expiry date (the default or the deadline if specified), the receipt period (the receipt start date and receipt end date), and the commission (sales shop or user) are registered for the receipt conditions. Is done. As described above, since the receiving condition can be set for each transfer number, the store 100 can use the transfer number according to the other party. The receiving conditions can be changed later by applying for a change.

  Finally, the store registration unit 72 outputs a registration completion notification including the transfer number (step S17). In the case of a use application from FAX, e-mail, or an input Web page, a registration completion notice is output by FAX, e-mail, or output Web page. In the case of a paper use application, for example, it is printed and sent to the store 100 by mail.

  In this way, the initial registration of the store 100 is completed.

  Next, with reference to FIG. 12, when the user 200 operates the user terminal 5 to make a purchase process and a transfer request to the store server 3 of the store 100 that sells products and the like. The process will be described. In addition, although the example of online shopping is shown here, the payment service in this Embodiment can be used also for mail order which is not online.

  For example, the store server 3 generates product list page data in response to a search instruction from the user terminal 5 and transmits it to the user terminal 5. The user terminal 5 receives the product list page data from the store server 3, and displays the product list page on the display device. On the other hand, the user selects any product and inputs an instruction to put it in the shopping cart. The user terminal 5 receives an instruction from the user, and transmits an instruction to insert the selected product into the shopping cart to the store server 3. The store server 3 receives an instruction to put the selected product into the shopping cart from the user terminal 5, and registers the data of the selected product in the data area of the shopping cart. Then, page data including a list of products input to the shopping cart is generated and transmitted to the user terminal 5. The user terminal 5 receives the page data including the product list input to the shopping cart from the store server 3, and displays the page including the product list input to the shopping cart on the display device.

  At this stage, although shopping may be continued or purchase may be stopped, it is assumed here that the user 200 has input a settlement instruction. The user terminal 5 receives the payment instruction from the user 200 and transmits the payment instruction to the store server 3 (step S31). The store server 3 receives a payment instruction from the user terminal 5 (step S33), generates payment data input page data, and transmits it to the user terminal 5 (step S35). For example, page data including the data of a product put in a shopping cart and including a data input field described below is generated and transmitted.

  The user terminal 5 receives the payment data input page data from the store server 3, and displays the payment data input page on the display device (step S37). The user operates the user terminal 5 to input settlement data including a name, a contact information, a withdrawal number, and the like. The user terminal 5 accepts input of settlement data including the name, contact information, withdrawal number and the like from the user, and transmits it to the store server 3 (step S39). The dealer server 3 receives payment data including the name, contact information, withdrawal number, etc. from the user terminal 5 and registers it in a database (not shown) (step S41). Then, a reception completion notification is generated and transmitted to the user terminal 5 (step S43).

  The user terminal 5 receives the acceptance completion notification from the store server 3 and displays it on the display device (step S44). This completes the first stage of the procedure performed by the user 200.

  On the other hand, the store server 3 transfers the transfer number, withdrawal number, name and contact information of the user 200, receipt print data (including purchased product data), summary wording data to be printed on the passbook, etc. Data is generated and stored in a storage device such as a main memory (step S45). And the transfer request containing the said transfer data is transmitted to the bank system 7 of the bank specified from the withdrawal number (step S47). Step S47 is not directly transmitted to the bank system 7 via the network 1, but is output by another method, for example, FAX, transmitted in the form of an e-mail, or printed for mailing. You may make it do.

  Next, processing executed by the bank system 7 after FIG. 12 will be described with reference to FIGS. The transfer request reception part 71 of the bank system 7 receives the transfer request including the transfer data from the store server 3 (step S51). For example, when data is transmitted in the form of FAX or e-mail, necessary data is extracted from them. Further, when a transfer request is sent to the bank in the form of paper, a transfer request including transfer data input by an operator or the like is acquired.

  And the transfer request reception part 71 collates the data contained in transfer data with the payer table 77 (step S53). Specifically, for example, the payer table is searched with the withdrawal number used in the current settlement included in the transfer data, and the name and contact information of the corresponding user 200, and the name and contact information of the user 200 included in the transfer data. Is matched. If they do not match, the subsequent processing is not performed. An error may be notified to the sender of the transfer request. Further, when the transfer number used in the current settlement included in the transfer data is a transfer number of another affiliated bank, for example, a settlement account is connected to the bank system of another affiliated bank connected via the network 1, for example. After sending a data request such as an account number, and confirming the transfer number with the bank system of another affiliated bank, the store name, contact information, account number of the settlement account, etc. are obtained.

  Next, the transfer request receiving unit 71 generates a request number for this transfer request (step S54). If there are multiple transfer requests with the same combination of transfer number and withdrawal number, the transfer request cannot be easily identified, so a request number is introduced. Then, a record is registered in the transfer table 74 using the transfer data included in the transfer request (step S55). In the transfer table 74, for example, data is managed in a data structure as shown in FIG. That is, the request content is registered for each transfer number. When the user 200 approves the request, the result is registered corresponding to the request content. FIG. 15 shows a detailed data structure example of request contents and results. The request content specified by the request number is associated with the name and contact information of the purchaser user 200, the withdrawal number, the amount, the date of receipt of the transfer request, the receipt print data, and the summary text for filling in the passbook. Furthermore, the request content specified by the request number is also associated with result data, and the result is associated with the approval date and the approval content (approval, rejection, no purchase).

  Further, the transfer request accepting unit 71 registers a record in the withdrawal table 75 using the corresponding data in the payee table 76 (store name, contact information, etc. corresponding to the transfer number) and the transfer data included in the transfer request (step) S57). In the withdrawal table 75, for example, data is managed in a data structure as shown in FIG. That is, the request content is registered for each withdrawal number. When the user 200 approves the request, the result is registered corresponding to the request content. FIG. 17 shows a detailed data structure example of request contents and results. The details of the request identified by the request number include the dealer name, dealer contact information, transfer number, amount, transfer request receipt date, and, in the case of another partner bank transfer number, the account number of the settlement account of the dealer. Are associated. Furthermore, the request content specified by the request number is also associated with result data, and the result is associated with the approval date and the approval content (approval, rejection, no purchase).

  Thus, the process before the user 200 approves the transfer request is completed.

  Next, a process when the user 200 registers approval, rejection, or no purchase for the transfer request will be described with reference to FIGS. Here, it is assumed that the user 200 goes to the ATM 9 connected to the bank system 7 and operates the ATM 9.

  First, the user 200 selects withdrawal approval from a main menu (for example, FIG. 19) displayed on the display device of the ATM 9. The ATM 9 accepts a selection input for withdrawal approval from the user 200 (step S61), prompts the insertion of a cash card or a passbook, and then performs a well-known authentication process (step S63). In this case, an authentication server (not shown) may be accessed. It is assumed that authentication succeeded without any problem.

  Thereafter, the ATM 9 generates an approval search request including the account number read from the cash card or the like, and transmits it to the bank system 7 (step S65). Prior to step S65, the user 200 may be requested to input a withdrawal number to be approved, and the withdrawal number may be transmitted together with the account number.

  The approval processing unit 78 of the bank system 7 receives the approval search request including the account number from the ATM 9, and stores the account number in a storage device such as a main memory (step S67). Then, the payer table 77 is searched with the account number, and the withdrawal number issued to the user 200 is specified (step S68). If the withdrawal number is included in the approval search request, step S68 is skipped. Then, from the withdrawal table 75, the data of the transfer request corresponding to the withdrawal number specified in step S68 and for which the result is not registered is extracted, and the recipient is received with the transfer number included in the extracted transfer request. By identifying a transfer request corresponding to the receiving period included in the receiving condition obtained by searching the table 76, an unapproved transfer request within the receiving period is extracted (step S69).

  The approval processing unit 78 generates an unapproved list including the store of the corresponding transfer request and the amount (data from the withdrawal table 75) from the extracted transfer request, and transmits it to the ATM 9 (step S71). The ATM 9 receives the unapproved list from the bank system 7 and displays it on the display device (step S73). For example, a display screen as shown in FIG. 20 is displayed. That is, for the extracted transfer request, a store and an amount are listed, and a content inquiry button is also displayed. The user 200 presses a content inquiry button corresponding to a transfer request to be registered for approval, rejection, and no purchase.

  The ATM 9 receives the selection of the approval target from the user 200 and transmits data (request number or identifier for specifying the request number) specifying the transfer request that is the approval target to the bank system 7 (step S75). The approval processing unit 78 of the bank system 7 receives the data specifying the transfer request to be approved from the ATM 9 (step S77), specifies the request number of the transfer request to be approved, and the request number from the transfer table 74. The detailed data (purchased product (data included in the receipt print data), purchase date (transfer request date), amount, etc.) is extracted (step S79). Then, detailed data of the transfer request to be approved including the store name from the withdrawal table 75 is transmitted to the ATM 9 (step S81). The ATM 9 receives the detailed data of the transfer request to be approved from the bank system 7 and displays it on the display device (step S83). Then, the processing shifts to the processing in FIG. 22 through terminals A and B.

  In step S83, for example, a screen as shown in FIG. 21 is displayed. In the screen example of FIG. 21, the payee (store name), the purchased item (data included in the receipt print data), the purchase date (transfer request date), and the amount are displayed. The reject button and the no purchase button can be selected. The user 200 confirms the display content and selects one of approval, rejection, and no purchase.

  Moving to the explanation of the processing in FIG. 22, the ATM 9 accepts an instruction input of approval, rejection, or no purchase, and transmits it to the bank system 7 (step S85). The approval processing unit 78 of the bank system 7 receives any one of approval, refusal, and no purchase instructions from the ATM 9 (step S87), and determines whether approval is instructed (step S89). If the approval is instructed, the transfer request data to be approved is registered in the withdrawal approval table 79 (step S91). In step S91, the payer table 77 is searched for the withdrawal number related to the transfer request to be approved, the settlement date data included in the withdrawal condition is extracted, the settlement date is specified, and the transfer is performed in accordance with the settlement date. Request data (for example, withdrawal number) is registered in the withdrawal approval table 79.

  The withdrawal approval table 79 has a data structure as shown in FIG. Specifically, a withdrawal number is associated with each settlement date (settlement execution date), and a transaction history (request number) is associated with the withdrawal number. The transaction history includes an approval date and time, an approval content (approval), and a withdrawal result (registered at the time of withdrawal).

  On the other hand, if approval is not instructed, transfer request data (for example, withdrawal number) is registered in the withdrawal approval rejection table 80 corresponding to the operation date (step S93). The withdrawal approval rejection table 80 has a data structure as shown in FIG. 24, for example. Specifically, a withdrawal number is associated with each operation day, and further, a transaction history (request number) is associated with the withdrawal number, and the transaction history includes operation details (rejection or no purchase). .

  After step S91 or S93, the approval processing unit 78 registers the result in the withdrawal table 75 and the transfer table 74 (step S95). That is, the result (approval date and approval content) corresponding to the withdrawal number and the request number is registered in the withdrawal table 75, and the result (approval date and approval content) is transferred to the transfer number and the request number. Register in the table 74.

  Thereafter, the approval processing unit 78 transmits an acceptance completion notification to the ATM 9 (step S97). The ATM 9 receives the acceptance completion notification from the bank system 7 and displays it on the display device (step S99). That is, a message indicating that the approval process has been completed is displayed.

  If the approval is instructed by the user 200, the approval processing unit 78 of the bank system 7 receives the transfer number related to the transfer request and the receipt print data registered in the transfer table 74 corresponding to the request number and Summary wording data (if there is a bankbook) is extracted and transmitted to ATM 9 (step S101). The ATM 9 receives the receipt print data and summary text data from the bank system 7, prints the receipt print data on the receipt, outputs the summary text, writes the summary text on the passbook, and outputs the passbook (step S103).

  Further, the approval processing unit 78 searches the recipient table 76 with the transfer number of the corresponding transfer request, acquires contact data (e.g., e-mail, etc.), and notifies the approval result using the contact data. (Step S105). For example, an electronic mail or a paper on which the result is printed is mailed or transmitted by FAX. Further, the payer table 77 is searched with the withdrawal number of the corresponding transfer request, and it is determined whether or not it is necessary to contact before withdrawal of the withdrawal notice of the withdrawal condition. Notify the date of settlement.

  By performing such processing, the user 200 can determine whether or not to approve the withdrawal for each transfer request notified to the bank 300. In other words, it is possible to instruct whether or not to withdraw funds from its own settlement account. Furthermore, there is no need for the trouble of making a normal transfer.

  Further, by using the receipt print data as ticket data (seat information or the like), the receipt can be used as a ticket as it is. Further, it can be used as a voucher for a reserved sale, a coupon, or the like.

  Next, processing when making a settlement will be described with reference to FIGS. The settlement processing unit 83 of the bank system 7 acquires one unprocessed record whose settlement execution date is the processing date in the withdrawal approval table 79 (step S111), and the withdrawal table with the withdrawal number and request number included in the obtained record. 75 is searched and the corresponding transfer number, amount, and account number data for a settlement account (in the case of another bank) are specified. As described above, since the transfer number includes a code identifying the bank such as a bank code, the settlement processing unit 83 determines whether the remittance destination is another bank from the transfer number (step S113). If the remittance destination is another bank, the bank code, the account number for settlement of the remittance destination read from the withdrawal table 75, and the account number of the payer settlement account specified by the withdrawal number from the payer table 77 are entered. Then, the transfer processing unit 85 is notified to perform a known transfer process (step S117). In the well-known transfer process, as schematically shown in FIG. 26, an amount specified from the withdrawal table 75 is withdrawn from the settlement account of the user 200, and the settlement account of the recipient (another bank) is exchanged. ).

  On the other hand, in the case of remittance within the bank, the settlement processing unit 83 searches the payee table 76 with the transfer number read from the withdrawal table 75 to identify the account number of the settlement account and obtains an acquisition record. The payer table 77 is searched with the withdrawal number included in the transaction number, the account number of the account for settlement is specified, the account number is notified to the withdrawal processing unit 84, and a known withdrawal process is performed (step S115). In the known withdrawal process, as schematically shown in FIG. 27, the amount specified from the withdrawal table 75 is withdrawn from the settlement account of the user 200 and deposited into the settlement account of the recipient.

  After step S115 or S117, the settlement processing unit 83 receives the processing result from the withdrawal processing unit 84 or the transfer processing unit 85, and registers the processing result for the processing target record in the withdrawal approval table 79 (step S118). In addition, the payer table 77 is searched with the withdrawal number included in the acquired record to determine whether the withdrawal result notification of the withdrawal notification included in the withdrawal condition is necessary. ) Is notified of the withdrawal execution result (step S119).

  Thereafter, it is determined whether there is an unprocessed record whose settlement execution date is the processing date (step S120). If there is an unprocessed record, the process returns to step S111, and there is no unprocessed record. The process is terminated.

  By performing the processing as described above, the remittance processing is appropriately performed on the settlement date.

  As described above, “unconditional withdrawal permission” may be registered in the allowance condition allowance information registered corresponding to the withdrawal number in the payer table 77. Therefore, for example, before executing the processing of FIG. 25 on each business day, specify a withdrawal number for which unconditional withdrawal permission is set as a withdrawal condition, and identify a transfer request in which the withdrawal number is registered. Auto-approval processing.

  Specifically, first, the approval processing unit 78 of the bank system 7 specifies a withdrawal number in which the unconditional withdrawal permission is registered as the withdrawal condition in the payer table 77, and corresponds to the unconditional withdrawal permission from the withdrawal number. The transfer request to be extracted is extracted from the withdrawal table 75 (FIG. 28: Step S121). Then, an automatic approval process is performed on the extracted transfer request (step S123). Specifically, steps S91, S95, and S105 of FIG. 22 are performed. The settlement execution date is the date when the processing of FIG. 28 is performed.

  If the processing of FIG. 28 is performed in this way, money can be appropriately transferred even in the case of automatic approval.

  Note that the approval processing unit 78 of the bank system 7 searches the withdrawal table 75 to identify a transfer request for which the result is not registered, identifies a transfer number related to the transfer request, and receives the payee table 76 from the transfer number. To identify the applicable receipt period. Then, it is determined whether the receipt period has elapsed from the processing date and the transfer request date. If it has elapsed, it is determined as “rejection”, and steps S93, S95, and S105 of FIG. 22 are performed as automatic rejection processing. To do. This makes it possible to process a transfer request that has been left unapproved.

  Next, a process for evaluating the user 200 and the store 100 will be described with reference to FIG. The totalization processing unit 81 counts the total number of transfer requests (the number of transfer requests for which results are registered) and the number of refusals for each withdrawal number in the withdrawal table 75 and stores them in the aggregated data storage unit 82 (step S131). . Further, the withdrawal number of the same payer is specified from the payer table 77, and the total number of transfer requests and the number of rejections are totaled for the same payer and stored in the total data storage unit 82 (step S133). Then, a refusal ratio (= number of refusals / total number of transfer requests) for each withdrawal number and each payer is calculated and stored in the total data storage unit 82 (step S135). Further, in the transfer table 74, the total number of transfer requests (the number of transfer requests for which results are registered) and the number of purchases are counted for each transfer number and stored in the total data storage unit 82 (step S137). Then, the transfer number of the same payee is specified from the payee table 76, and the total number of transfer requests and the number of no purchases are counted for the same payee and stored in the total data storage unit 82 (step S139). Thereafter, the ratio of no purchase (= the number of purchases / the total number of transfer requests) is calculated for each transfer number and recipient, and stored in the total data storage unit 82 (step S141). Then, in response to a request from an administrator or the like, the data stored in the total data storage unit 82 is output (step S143).

  For example, based on the data stored in the aggregate data storage unit 82, the administrator can select a user 200 whose rejection number or rejection ratio is equal to or higher than a predetermined threshold, or a store where the number of purchases or no purchase ratio is equal to or higher than a predetermined threshold. 100 is identified and a warning is issued or the contract is canceled.

  This encourages improper users and dealers to make improvements and eliminates them so that remittance can be carried out properly. Note that the user 200 and the store 100 may be rated according to the number and ratio.

[Embodiment 2]
Even in the first embodiment described above, it is possible to make a collective payment of public charges (for example, water charges, school lunch expenses, public hospital medical expenses, etc.) and taxes. However, in the first embodiment, in order to perform payment, the local government that is the recipient must generate a transfer request for the number of payments and send it to the financial institution. In addition, it takes time for the local government, which is the recipient, to collect more late fees. In particular, in recent years, the number of non-payers and delinquents has increased greatly, and it is desired to improve the efficiency of collection work from such non-payers and delinquents. The same applies to installment payments for services and goods.

  Further, in the first embodiment, it is impossible to automatically stop the transaction or stop the payment / remittance even for a recipient who is fraudulent or has a problem (such as a store).

  In order to solve the above-mentioned problems, a system capable of dealing with partial payments (including not only partial payment of utility charges and taxes but also other installments) is provided.

  First, an outline of the scheduling process according to the second embodiment of the present invention will be described with reference to FIGS. However, it is assumed that the procedures in FIGS. 1 and 2 in the first embodiment are completed. 1 and 2 corresponds to the local government 600 in the second embodiment, and the user 200 in FIGS. 1 and 2 corresponds to the payer 700 in the second embodiment. Note that the contract between the local government 600 and the bank 300 includes the interest rate of late charges to be applied (or fees for installment payments, which may be 0%), payment intervals (for example, every month), and the like.

  First, the local government 600 and the payer 700 agree to divide taxes, utilities, etc., and the payer 700 notifies the local government 700 of the withdrawal number used for settlement (step (1)). The agreement includes an agreement such as the amount of payment or the number of payments, the interest rate of late charges, and the like. Then, the local government 600, instead of the transfer request, the payer 700 data (name, etc.) and the withdrawal number, the local government transfer number, the payment details data (for example, “automobile tax”, etc.), the total amount paid, and the amount paid once The bank 300 is notified of a partial collection request including the payment start date only once (step (2)). In response to the payment request, the bank 300 fills the transfer table with the data of the payer 700, the withdrawal number, and the initial data (billing start date (payment start date), billing end date (the date after the payment interval in the contract). ), Billing amount (payment amount for one time), remaining amount (total amount paid), receipt date of request, printed contents of receipt (for example, "Car tax? Yen received"? Is the actual approved amount). Register a summary word (for example, automobile tax payment), and in the withdrawal table, local government 600 data, transfer number, initial data, (billing start date (payment date), billing end date (day after contract payment interval) The previous day), billing amount (payment amount for one time), remaining amount (total amount paid), and date of receipt of request (step (3)).

  Thereafter, the payer 700 goes to the ATM of the bank 300 and performs authentication, and then gives a payment approval for a specific partial collection request among the relevant transfer request and partial collection request (step (4)). As will be described below, in the case of partial payment, the payment amount can be changed once. When the bank 300 receives the payment approval from the payer 700, the bank 300 prints and outputs a receipt print content (for example, “has received 30000 yen automobile tax”) on the transfer table (step (5)). Further, the bank 300 registers the result of payment approval in the transfer table and the withdrawal table (step (6)). Then, the bank 300 performs a withdrawal process as described below (step (7)). The payment / remittance processing to the local government 600 is performed after a predetermined grace date from the approval date as described later. Further, the bank 300 notifies the local government 600 of the collection result (step (8)). The collection result is performed every time payment is approved and when it is confirmed that payment has not been performed within the payment interval. Further, the bank 300 automatically generates request content data for the next time until payment is completed (until payment is made with the remaining amount being “0”), and registers it in the transfer table and the withdrawal table (step (9 )).

  By performing such a process, even in the case of partial payment, the local government 600 can cause the bank 300 to appropriately execute the partial payment process by sending the partial collection request to the bank 300 only once. In this embodiment, one-time payment other than payment is also possible, which will be described in detail below.

  The outline of the computer system used in the settlement service according to this embodiment is the same as that of the computer system (FIG. 4) in the first embodiment. However, in the case of the local government 600, a local government server is used instead of the store server 3.

  FIG. 32 shows a functional block diagram of the bank system 7 according to the present embodiment, which is included in this computer system. The bank system 7 includes a store registration unit 572 that performs a process of registering data regarding a use application from the store 100 or the local government 600, and a recipient table 576 that stores data registered by the store registration unit 572. , A user registration unit 573 that performs a process of registering data on a use application from the user 200 or the payer 700, a payer table 577 that stores data registered by the user registration unit 573, a payee table 576, and With reference to the payer table 577, a transfer request or a partial collection request is received from the store 100 or the local government 600, and a transfer request receiving unit 571 for generating payee data and payer data, and a transfer request receiving unit 571 A transfer table 574 for storing the recipient data generated by, and a transfer request reception unit 71, a withdrawal table 575 for storing payer data generated by 71, a deposit / remittance grace day table 590 in which the number of payment grace days is registered for each rating, a transfer table 574, a withdrawal table 575, and a payee table 576. , With reference to the payer table 577 and the payment / remittance grace period table 590, an approval processing unit 578 for executing an approval confirmation process in cooperation with the ATM 9, and an approval process when approval is obtained from the user 200 or the payer 700. An approval table 579 for storing the processing result of the unit 578, an approval rejection table 580 for storing the processing result of the approval processing unit 578 when approval is not obtained from the user 200 or the payer 700, a payee table 576, payment Person table 577, withdrawal table 575, approval table 579, and number of days for payment and remittance A withdrawal processing unit 583 that performs processing for withdrawal with reference to the table 590, and a deposit / reception unit that stores data for depositing and transferring money corresponding to the withdrawal performed by the withdrawal processing unit 583. Remittance schedule table 584, deposit / remittance processing unit 585 for performing deposit / remittance processing according to data of deposit / remittance schedule table 584, rating processing data storage unit 582 for storing data for rating processing, and transfer table 574, a rating processing data storage unit 582, and an approval rejection table 580 with reference to a rating processing unit 581 that performs a process for rating a recipient (store 100 and local government 600) and a rating processing unit 581 or Transaction stop list 588 for storing data on recipients determined to be stopped by the administrator, request contents data related to stop of transaction, and payment / The transaction stop table 587 for registering remittance schedule data and the data registered in the withdrawal table 575 and the deposit / remittance schedule table 584 for the recipients registered in the transaction stop list 588 using the data in the payee table 576. The transaction stop processing unit 586 to be moved to the transaction stop table 587 and the payment table 574 and the withdrawal table are generated by identifying the non-payment within the payment period of the partial payment using the data of the payee table 576 and generating necessary request contents data. And a scheduling monitor processing unit 589 registered in 575.

  The recipient ratings determined by the rating processing unit 581 are registered in the recipient table 576.

  Next, processing contents of the system shown in FIGS. 4 and 32 will be described with reference to FIGS. 33 to 73. In addition, about the process in the case of the use application from the user 200 or the payer 700 to the bank 300, it is as having shown in FIG. The overall data structure of data registered in the payer table 577 is as shown in FIG. FIG. 33 shows the detailed structure of data for each user / payer. FIG. 33 shows a specific example of the data structure of the user 3, and the account number (two here) of the settlement account is registered corresponding to the name and contact data for identifying the user 3. Further, one or a plurality of withdrawal numbers and withdrawal conditions (two sets in FIG. 33) are registered corresponding to the account number of each settlement account. As for withdrawal conditions, conditions such as an expiration date (as it is default or when there is a specific designation), presence / absence of withdrawal notice and before / after, contact information of withdrawal notice, withdrawal possibility information are registered. As described above, since the withdrawal condition can be set for each withdrawal number, the user 200 / payer 700 can use the withdrawal number properly according to the other party. The withdrawal conditions can be changed later by applying for a change. In particular, when it is set not to withdraw due to a trouble with the store 100 afterwards, unconditional withdrawal prohibition may be set in the withdrawal allowance information. Further, when the store 100 can be trusted, if the withdrawal number set for unconditional withdrawal permission is notified in the withdrawal permission / inhibition information, remittance can be made without executing the approval procedure.

  Further, the processing at the time of application for use from the store 100 or the municipality 600 to the bank 300 is as shown in FIG. The overall data structure of data registered in the recipient table 576 is as shown in FIG. In the present embodiment, the local government 600 is registered in the same manner as a corporation or a store. FIG. 34 shows the detailed structure of data for each corporate user or local government. FIG. 34 shows a specific example of the data structure of the store A. The account number of the settlement account (in this case, 2) corresponding to the name identifying the store A, the contact data, and the rating described below. In addition, one or more sets of transfer numbers and receiving conditions (two sets in FIG. 34) are registered corresponding to the account number of each settlement account. As for the receiving conditions, as described above, an expiration date (the default or the expiration date if specified) and a fee (a store or a user) are registered. As described above, since the receiving condition can be set for each transfer number, the store 100 can use the transfer number according to the other party. The receiving conditions can be changed later by applying for a change. The receiving conditions can be set in other ways, and may include, for example, interest rates and payment intervals at the time of payment. Therefore, when generating the request content data related to the payment described below, the receiving condition may be read and processed.

  The settlement account is set, for example, for each actual store or for each shopping site on the Internet. In addition, multiple transfer numbers can be set for each settlement account. For example, for items that can be stored easily (for example, clothing, furniture, etc.), a transfer number with a longer expiry date is used to store products such as fresh food. For those that are difficult, it is possible to prepare a transfer number with a short expiration date and use it separately.

  After such pre-processing, transmission of actual sales and transfer requests to the bank system 7 is performed online as described with reference to FIG. Similarly to the first embodiment, a transfer request or a partial collection request may be transmitted to the bank system 7 in the form of FAX or e-mail, or may be transmitted to the bank in the form of paper. Also good. The municipality 600 may also be sent to the bank, for example, a copy of a payment contract (including payment terms) with the payer 700. Separately, the local government 600 may create and send data on a partial collection request.

  The transfer request includes the transfer number used in the current settlement, the withdrawal number acquired from the user 200 or the payer 700, the name and contact information of the user 200 or the payer 700, and data for specifying the billing period (billing start date And billing end date (however, it may be empty or may include only the billing start date), amount, receipt print content (including purchased product data, etc.), summary text to be printed on the passbook, etc.

  The partial collection request includes the transfer number used in the current settlement, the withdrawal number obtained from the user 200 or the payer 700, the name and contact information of the user 200 or the payer 700, and data for specifying the first billing period (1 Payment start date and payment end date of the first payment (however, only the payment start date may be used) First payment amount, total payment amount, receipt print contents (including purchased product data or payable public charges or taxes) , Including summary wordings printed on the passbook.

  Next, processing executed for a transfer request and a partial collection request will be described with reference to FIGS. The transfer request reception unit 571 of the bank system 7 receives a transfer request or a partial collection request from the store server 3 or the like (step S201). For example, when data is transmitted in the form of FAX or e-mail, necessary data is extracted from them. Further, when the transfer request or the partial collection request is sent to the bank in the form of paper, the transfer request or the partial collection request input by the operator or the like is acquired.

  Then, the transfer request receiving unit 571 collates the data included in the transfer request or the partial collection request with the payer table 577 (step S203). Specifically, for example, the payer table 577 is searched with the withdrawal number used in the current settlement included in the transfer request or the partial collection request, and the name and contact information of the corresponding user 200 and the like, the transfer request or the partial collection request The name and contact information of the included user 200 and the like are collated. If they do not match, the subsequent processing is not performed. An error may be notified to the sender of the transfer request or the partial collection request. Further, in the present embodiment, the recipient table 576 is searched with the transfer number, and it is confirmed whether the rating of the corresponding store 100 or the like is a rating corresponding to the suspension of transactions. In the case of a rating corresponding to a transaction suspension, the transaction suspension may be notified to the sender of the transfer request or the partial collection request.

  Further, when the transfer number used in the current settlement included in the transfer request or the partial collection request is the transfer number of another partner bank, for example, the bank system of another partner bank connected via the network 1 Send a request for data such as the account number of the settlement account to the bank, confirm the transfer number with the bank system of another affiliated bank, and obtain the store name, contact information, account number of the settlement account, etc. Like that.

  Next, the transfer request receiving unit 571 generates a request number for this transfer request or partial collection request (step S204). If there are multiple transfer requests with the same combination of transfer number and withdrawal number, the transfer request cannot be easily identified, so a request number is introduced. The request number is composed of a combination of a system serial number and a serial number for distinguishing each partial payment in the case of a partial collection request.

  Then, the transfer request reception unit 571 registers a record in the transfer table 574 using the transfer request or the partial collection request (step S205). In the transfer table 574, for example, data is managed in a data structure as shown in FIG. That is, the request content is registered for each transfer number. When the user 200 approves the request, the result is registered corresponding to the request content. As shown in FIG. 36, request content data for a request number without additional number (for example, “00001”) is generated in response to the transfer request, and request numbers with additional number (for example, “00001-1” and “00002”). -2 ") request content data is generated in response to a partial collection request.

  FIG. 37 shows a detailed data structure example of request contents and results. The request content data includes the request number, the name and contact information of the purchaser, such as the user 200, the withdrawal number, the billing start date and billing end date, the billing amount, the remaining amount, the transfer request receipt date, the receipt print data, and the passbook entry. Includes a brief wording. Further, the request content data is also associated with result data, and the result is associated with the approval date, the approval content (approval, rejection), and the approval amount.

  For example, FIG. 38 shows an example of request content data of the transfer table 574 generated in response to the transfer request. The purchaser's name and contact information, withdrawal number, billing end date and billing end date, billing amount, receipt print contents, and summary text for filling in the passbook remain the data included in the transfer request. The remaining amount is always set to “0” if it is not paid in installments. The transfer request reception date is the date when the transfer request is received or accepted.

  FIG. 39 shows an example of request content data in the transfer table 574 generated in response to the partial collection request. The purchaser's name and contact information, withdrawal number, receipt print contents, and summary text for filling in the passbook are the data included in the partial collection request. The billing start date and billing end date are the first billing start date and billing end date included in the partial collection request, the billing amount is the first payment amount, and the remaining amount is the total payment amount. The transfer request receipt date is the date on which the split collection request is received or accepted. This is used when calculating late fees.

  Further, the transfer request receiving unit 571 registers a record in the withdrawal table 575 using the corresponding data (the store name corresponding to the transfer number, contact information, etc.) and the transfer request or the partial collection request in the recipient table 576 (step S207). ). In the withdrawal table 575, data is managed with a data structure as shown in FIG. That is, request content data is registered for each withdrawal number. When the user 200 or the like approves the request content data, the result is registered corresponding to the request content data. The method of assigning the request number is as described above.

  FIG. 42 shows a detailed data structure example of request content data and results. The request contents data includes the request number dealer name, dealer contact information, transfer number, billing start date and billing end date, billing amount, remaining amount, transfer request receipt date, and the bank number for other affiliated banks. Are associated with the account number of the settlement account. Further, the request content data is also associated with the result data, and the result is associated with the approval date, the approval content (approval, rejection), and the approval amount.

  An example of request content data in the withdrawal table 575 corresponding to FIG. 39 is shown in FIG. Except for the store name, contact information, and settlement account information, data similar to the request content data shown in FIG. 39 is retained.

  The process before the user 200 or the like approves the transfer request or the division collection request is completed.

  Next, with reference to FIG. 43 to FIG. 59, processing when the user 200 or the like approves a transfer request or a partial collection request will be described. Here, it is assumed that the user 200 or the like goes to the ATM 9 connected to the bank system 7 and operates the ATM 9.

  First, the user 200 or the like selects the withdrawal approval from the main menu (for example, FIG. 19) displayed on the ATM 9 display device. The ATM 9 accepts a selection input for withdrawal approval from the user 200 or the like (step S211), prompts the insertion of a cash card or a passbook, and then performs a well-known authentication process (step S213). In this case, an authentication server (not shown) may be accessed. It is assumed that authentication succeeded without any problem.

  Thereafter, the ATM 9 generates an approval search request including the account number read from the cash card or the like, and transmits it to the bank system 7 (step S215). Prior to step S215, the user 200 or the like may be requested to input a withdrawal number to be approved, and the withdrawal number may be transmitted together with the account number.

  The approval processing unit 578 of the bank system 7 receives the approval search request including the account number from the ATM 9, and stores the account number in a storage device such as a main memory (step S217). Then, the payer table 577 is searched with the account number, and the withdrawal number issued to the user 200 or the like is specified (step S218). If the withdrawal number is included in the approval search request, step S218 is skipped. Then, request content data corresponding to the withdrawal number specified in step S218 and having no result registered is extracted from the withdrawal table 575, and the current date is included in the extracted request content data. By identifying the request content data within the billing period defined by the billing start date to the billing end date, the request content data that is not approved and within the billing period is extracted (step S219).

  The approval processing unit 578 determines, from the extracted request content data, for each case of the corresponding request content data, the dealer, the billing amount (billing amount for one time), and the delivery deadline (billing end date or billing end date-current date). An unapproved list including the number of remaining days calculated in (1) is generated and transmitted to ATM 9 (step S221). The ATM 9 receives the unapproved list from the bank system 7 and displays it on the display device (step S223). For example, a display screen as shown in FIG. 44 is displayed. That is, for the cases of the extracted request content data, the store, the amount, and the delivery deadline (the number of remaining days in this case) are listed, and a content inquiry button is also displayed. Displaying the delivery deadline in this way produces a dunning effect. Note that the user 200 or the like presses a content inquiry button corresponding to request content data to be registered for approval or the like.

  The ATM 9 receives the selection of the approval target from the user 200 or the like, and transmits data (request number or identifier for specifying the request number) specifying the request content data that is the approval target to the bank system 7 (step S225). . The approval processing unit 578 of the bank system 7 receives the data specifying the request content data to be approved from the ATM 9 (step S227), specifies the request number of the request content data to be approved, and transfers the data from the transfer table 574. Detailed data (purchased product (data included in receipt print data), purchase date (transfer request date), amount, etc.) corresponding to the request number is extracted (step S229). Then, the detailed data of the request content data to be approved including the store name and the like is transmitted to the ATM 9 (step S231). The ATM 9 receives the detailed data of the request content data to be approved from the bank system 7 and displays it on the display device (step S233). Then, the processing shifts to the processing in FIG. 46 through terminals C and D.

  In step S233, for example, a screen as shown in FIG. 45 is displayed. In the screen example of FIG. 45, the payee (store name or local government name), purchased item (data included in the receipt print data), purchase date (transfer request date), and amount (billed amount) are displayed. The payment button and the return button can be selected. In the example of FIG. 45, request content data relating to a partial collection request is displayed. In the case of a partial collection request, only payment or return can be selected. In the case of a transfer request, an approval button, a rejection button, and a return button can be selected, and any one can be selected.

  46, the ATM 9 receives an instruction input from the user 200 and transmits it to the bank system 7 (step S235). In the present embodiment, the instruction input is one of approval, rejection, partial payment, and return. The approval processing unit 578 of the bank system 7 receives the instruction input from the ATM 9 (step S237), and determines whether or not the payment is instructed (step S239). If an instruction other than payment is instructed, the process proceeds to the process of FIG.

  On the other hand, when the payment is instructed, the approval processing unit 578 pays as prescribed from the charge amount included in the request content data to be approved and the receipt print content (purchased product, for example, “automobile tax”). In addition to generating data, data of the amount change range (from the predetermined minimum delivery amount to the remaining amount) is generated, and payment amount designation data including the payment data and the amount change range data is generated and transmitted to ATM 9 (step S241). ). The ATM 9 receives the payment amount designation data and displays it on the display device (step S243). For example, a screen as shown in FIG. 47 is displayed. Specifically, the upper row displays the purchased product (automobile tax), the prescribed charge amount, and an approval button for paying the charge amount as it is, and the lower row displays the amount within the above amount change range. An amount input field and an approval button for changing and approving payment are displayed. The user 200 or the like presses the upper approval button or inputs an amount in the lower amount input field and presses the approval button.

  The ATM 9 transmits an amount and an approval instruction to the bank system 7 in accordance with an instruction from the user 200 or the like (step S245). The bank system 7 receives the money amount and the approval instruction from the ATM 9 (step S247), and withdraws the money amount and the request contents data to be approved (corresponding data in the withdrawal table 575 and the transfer table 574) and the payee table 576. Then, data for depositing is generated and registered in the approval table 579 (step S249). An example of the data structure of the approval table 579 is shown in FIG. In the example of FIG. 48, for each approval date, the request number (transfer table 574 or withdrawal table 575), approval date and time, designated amount, recipient information (recipient table 576) corresponding to the withdrawal number (transfer table 574). , The payee account information corresponding to the transfer number and the payee name (withdrawal table 575)) are registered.

  Then, the approval processing unit 578 of the bank system 7 transmits an acceptance completion notification to the ATM 9 (step S251). The ATM 9 receives the acceptance completion notification from the bank system 7 and displays it on the display device (step S253). That is, the fact that the approval process is completed is displayed. Further, the approval processing unit 578 extracts the receipt number and summary text data (if there is a passbook) registered in the transfer table 574 corresponding to the transfer number and the request number related to the corresponding request content data, It transmits to ATM9 (step S255). The ATM 9 receives the receipt print content data and the summary text data from the bank system 7, prints the receipt print content data on the receipt, and outputs the summary text in the passbook and outputs the passbook (step S257). . Further, the processing shifts to the processing in FIG.

  Shifting to the description of the processing in FIG. 49, the approval processing unit 578 includes, in the transfer table 574 and the withdrawal table 575, a result including an approval date, an approval content (approval), and an amount corresponding to the request content data to be approved. Is registered (step S258). Further, the approval processing unit 578 automatically generates request content data for the next installment and registers it in the transfer table 574 and the withdrawal table 575 in response to the request content data to be approved if the current remaining amount is not 0. (Step S259).

  For example, if the user 200 or the like approves payment of 40000 yen according to the billing amount for the request content data of the transfer table 574 as shown in FIG. 39, the result data of FIG. 39 is registered in step S257. In the example of FIG. 39, “schedule approval” is registered as the approval content, and “40000 yen” is registered as the approval amount. Similar data is registered as result data for the withdrawal table 575 of FIG.

  In step S259, request content data of request number 00002-2 is generated by incrementing the serial number by one. Specifically, the billing start date and billing end date are shifted by a set payment interval (for example, January, which may be one of the receiving conditions corresponding to the transfer number). Furthermore, the new remaining amount = the old remaining amount−the approval amount is set. Specifically, as shown in FIG. 50A, the request number is “00002-2”, and the billing start date and billing end date are shifted by one month from the billing start date and billing end date in FIG. The remaining amount has been changed to 80000 yen (= 120,000-40000). Also for the withdrawal table 575, the request content data “00002-2” with the same change is registered. Also for the withdrawal table 575, as shown in FIG. 50B, the request content data “00002-2” with the same changes as described above is registered.

  Next, when the user 200 or the like approves the payment of 30000 yen instead of the charged amount for the request content data of the transfer table 574 as shown in FIG. 50A, the result data of FIG. 50A is registered in step S257. . In the example of FIG. 50A, “schedule approval” is registered as the approval content, and “30000 yen” is registered as the approval amount. Similar data is registered as result data for the withdrawal table 575 of FIG. 50B.

  In step S259, request content data of request number 00002-3, which is obtained by incrementing the serial number by 1, is generated. Specifically, the billing start date and the billing end date are shifted by a set payment interval (for example, January). Furthermore, the new remaining amount = the old remaining amount−the approval amount is set. Specifically, as shown in FIG. 51A, the request number is “00002-3”, and the billing start date and billing end date are shifted by one month from the billing start date and billing end date in FIG. 50A. The remaining amount is changed to 50,000 yen (= 80000-30000). Also for the withdrawal table 575, the request content data “00002-3” with the same change is registered. Also for the withdrawal table 575, as shown in FIG. 51B, the request content data “00002-3” with the same changes as described above is registered.

  Here, it is assumed that the user 200 or the like has not approved payment for the request content data of the transfer table 574 as shown in FIG. 51A. Then, steps S257 and S259 are not performed. The process by the scheduling monitor processing unit 589 described below is performed, and the request content data related to the scheduling for which the payment approval has not been performed from the billing start date to the billing end date is searched, and the result data as shown in FIG. 51A is obtained. Generate and register. That is, the approval date is “−”, the approval content is “unpaid”, and the approval amount is “0”. As for the withdrawal table 575, similar result data is registered as shown in FIG. 51B.

  Then, request content data of request number 00002-4, in which the serial number is incremented by 1, is generated. Specifically, the billing start date and the billing end date are shifted by a set payment interval (for example, January). Furthermore, the new remaining amount = the old remaining amount−the approval amount is set. However, since the approved amount is 0, the remaining amount = the old remaining amount. Specifically, as shown in FIG. 52A, the request number is “00002-4”, and the billing start date and billing end date are shifted by one month from the billing start date and billing end date in FIG. 51A. The remaining amount remains 50,000 yen. Also for the withdrawal table 575, the request content data “00002-4” with the same change is registered. Also for the withdrawal table 575, as shown in FIG. 52B, the request content data “00002-4” with the same changes as described above is registered.

  Thereafter, when the user 200 or the like approves payment of 40000 yen according to the billing amount for the request content data of the transfer table 574 as shown in FIG. 52A, the result data of FIG. 52A is registered in step S257. In the example of FIG. 52A, “schedule approval” is registered as the approval content, and “40000 yen” is registered as the approval amount. Similar data is registered as result data for the withdrawal table 575 of FIG. 52B.

  In step S259, request content data of request number 00002-5, which further increments the serial number by 1, is generated. Specifically, the billing start date and the billing end date are shifted by a set payment interval (for example, January). Furthermore, the new remaining amount = the old remaining amount−the approval amount is set. Specifically, as shown in FIG. 53A, the request number is “00002-5”, and the billing start date and billing end date are shifted by one month from the billing start date and billing end date in FIG. 52A. The remaining amount is changed to 10,000 yen (= 50000-40000). If the remaining amount is equal to or more than the charged amount per time, it is not necessary to change the charged amount, but the remaining amount of 10000 yen this time is less than the charged amount per time of 40000 yen. Therefore, it is necessary to change the billing amount to 10,000 yen. Also for the withdrawal table 575, the request content data “00002-5” with the same change is registered. Also for the withdrawal table 575, as shown in FIG. 53B, the request content data “00002-5” with the same changes as described above is registered.

  Thereafter, when the user 200 approves payment of 10000 yen according to the billing amount for the request content data of the transfer table 574 as shown in FIG. 53A, the result data of FIG. 53A is registered in step S257. In the example of FIG. 53A, “schedule approval” is registered as the approval content, and “10000 yen” is registered as the approval amount. Similar data is registered as result data for the withdrawal table 575 of FIG. 53B.

  In step S259, request content data of request number 00002-6, which further increments the serial number by 1, is generated. When the remaining amount = the old remaining amount−the approved amount = 0, the request content data is generated by making a change different from the change described above. Specifically, as shown in FIG. 54A, the billing start date is shifted by the set payment interval, but the billing end date is not set. The remaining amount is set to 0. Further, the billing amount is set by calculating the late fee. The late charge is calculated as amount x interest rate x (days overdue / 365), but it is actually calculated by changing the amount for each payment. From the data in FIG. 39, the number of days in arrears = approval date (2008/06/10) -billing start date (2008/05/25) = 16, and the amount is 120,000 yen in the balance. Further, from the data of FIG. 50A, the number of days in arrears = approval date (2008/07/07) −billing start date (2008/06/25) = 12, and the amount is a balance of 80000 yen therebetween. Further, from the data in FIG. 51A, since there is no approval date, the number of days in arrears is 31 days, and the amount is a balance of 50000 yen in the meantime. Further, from the data of FIG. 52A, the number of days in arrears = approval date (2008/08/26) −billing start date (2008/08/25) = 1, and the amount is a balance of 50,000 yen therebetween. Further, from the data in FIG. 53A, the number of days in arrears = approval date (2008/10/23) −billing start date (2008/09/25) = 28, and the amount is 10000 yen in the balance. Thus, the sum of the late charges calculated for all the serial numbers of the request numbers having the same serial number is the total late charge, and this is the last billed amount. Also for the withdrawal table 575, the request content data “00002-6” with the same change is registered. Also for the withdrawal table 575, as shown in FIG. 54B, the request content data “00002-6” with the same changes as described above is registered.

  In the present embodiment, even if the request content data is related to payment, if the balance is “0”, it is not handled as payment. This is to prevent payment of late charges by adjusting the amount of money, and in step S231 in FIG. 43, the request number includes a serial number, and detailed data is transmitted for request content data related to payment. Even in this case, in step S233, the “schedule” button cannot be selected, and only the “approval” button and the “return” button can be selected. If it does so, in step S239 of Drawing 46, processing after terminal E will be carried out by No route.

  Returning to the description of the processing in FIG. 49, the approval processing unit 578 notifies the recipient (for example, the local government 600) of the collection result (step S261). For example, data may be transmitted via a network, mail may be transmitted, or data may be printed and sent as a document. Note that the collection result includes the content of result data registered corresponding to the request content data, for example. However, for example, the date when the approved amount is deposited may be calculated and included in the collection result.

  In the present embodiment, the number of grace days for payment from the approval date is set according to the rating set for the recipient. This is for the purpose of avoiding problems caused by early payment / remittance to a problem store or the like, and in some cases, the remittance is stopped so that the user 200 and the like can collect it. For example, data as shown in FIG. 55 is held in the deposit / remittance grace period table 590. In the example of FIG. 55, the number of grace days set by the bank 300 or the like is registered for each rating. Accordingly, the rating of the payee (sales shop) corresponding to the transfer number related to the request content data to be approved is read from the payee table 576, and further, the number of grace days corresponding to the rating is read from the payment / transfer remittance days table 590. . Then, the payment / transfer date is calculated by the approval date + the number of grace days.

  By carrying out such processing, in this embodiment, it becomes possible to handle the payment by reducing the labor of the local government.

  Next, the processing when the partial payment is not selected in step S239 in FIG. 46 will be described with reference to FIG. Next, the approval processing unit 578 determines whether or not the instruction input received from the ATM 9 is a “return” instruction (step S271). If the instruction is “return”, the process returns to the step S221 in FIG. That is, an unapproved list of extraction request content data is presented.

  On the other hand, if it is not a “return” instruction, the approval processing unit 578 determines whether it is an “approval” instruction (step S273). If approval is instructed, data for withdrawal and payment is generated from the request content data to be approved (corresponding data in the withdrawal table 575 and transfer table 574) and the recipient table 576, and the approval table 579 is generated. (Step S275). The data structure of the approval table 579 is, for example, as shown in FIG. If not approved, the process proceeds to the process in FIG.

  In addition, the approval processing unit 578 registers the result including the approval date, the approval content (approval), and the amount corresponding to the request content data to be approved in the transfer table 574 and the withdrawal table 575 (step S277).

  Then, the approval processing unit 578 transmits an acceptance completion notification to the ATM 9 (Step S279). The ATM 9 receives the acceptance completion notification from the bank system 7 and displays it on the display device (step S281). That is, the fact that the approval process is completed is displayed. Further, the approval processing unit 578 extracts the receipt number and summary text data (if there is a passbook) registered in the transfer table 574 corresponding to the transfer number and the request number related to the corresponding request content data, It transmits to ATM9 (step S283). The ATM 9 receives the receipt print content data and summary text data from the bank system 7, prints the receipt print content data on a receipt, outputs the summary text, writes the summary text on the passbook, and outputs the passbook (step S285). .

  Further, the approval processing unit 578 notifies the recipient (for example, a store) of the collection result (step S287). For example, data may be transmitted via a network, mail may be transmitted, or data may be printed and sent as a document. For example, the recipient table 576 is searched with the transfer number of the corresponding request content data to obtain contact data (e-mail address, IP address, mailing address, etc.). Note that the collection result includes the content of result data registered corresponding to the request content data, for example. However, for example, the date when the approved amount is deposited may be calculated and included in the collection result. The method for calculating the deposit date is as described in step S261.

  Further, the approval processing unit 578 searches the payer table 577 with the withdrawal number of the corresponding request content data, determines whether it is necessary to contact before withdrawal of withdrawal notice of withdrawal conditions, and if necessary, Notify the contact date (email address, etc.) of the settlement date (approval date), etc.

  By performing such processing, the user 200 or the like can determine whether or not to approve the withdrawal for each transfer request notified to the bank 300. In other words, it is possible to instruct whether or not to withdraw funds from its own settlement account. Furthermore, there is no need for the trouble of making a normal transfer.

  Further, by using the receipt print data as ticket data (seat information or the like), the receipt can be used as a ticket as it is. Further, it can be used as a voucher for a reserved sale, a coupon, or the like.

  On the other hand, processing when it is determined that approval is not instructed and rejection is instructed will be described with reference to FIG. The approval processing unit 578 transmits rejection reason selection data (no purchase record, amount difference, purchase item difference, payment destination difference) to the ATM 9 (step S291). The ATM 9 receives the rejection reason selection data from the bank system 7 and displays it on the display device (step S293). For example, a screen as shown in FIG. 58 is displayed. In the screen example of FIG. 58, any of the reasons for refusal of “no purchase results”, “difference in amount”, “difference in purchased items”, and “difference in payee” can be selected. The user 200 clicks one of the rejection reason buttons.

  The ATM 9 receives a selection instruction from the user and transmits a corresponding selection rejection reason to the bank system 7 (step S295). The approval processing unit 578 of the bank system 7 receives the reason for selection refusal from the ATM 9 (step S297). Then, the approval processing unit 578 registers result data corresponding to the request content data to be approved (step S299). The result data includes a rejection instruction date as the approval date, a rejection in the approval content, and 0 in the approval amount.

  Further, the approval processing unit 578 registers the withdrawal number and the reason for selection refusal related to the request content data subject to approval rejection in the approval rejection table 580 corresponding to the operation date (step S301). The approval rejection table 580 has a data structure as shown in FIG. 59, for example. Specifically, a withdrawal number is associated with each operation date, and a request number and a rejection reason are associated with the withdrawal number.

  Thereafter, the approval processing unit 578 transmits an acceptance completion notification to the ATM 9 (step S303). The ATM 9 receives the acceptance completion notification from the bank system 7 and displays it on the display device (step S305). That is, a message indicating that the process has been completed is displayed.

  Also, the approval processing unit 578 sends a rejection notice to the recipient (for example, a store) (step S307). For example, data may be transmitted via a network, mail may be transmitted, or data may be printed and sent as a document. For example, the recipient table 576 is searched with the transfer number of the corresponding request content data to obtain contact data (e-mail address, IP address, mailing address, etc.). The rejection notification includes, for example, the content of result data registered corresponding to the request content data and the reason for selection rejection.

  In this way, the user 200 or the like can stop inappropriate withdrawals by pointing out the reason for refusal and refusing a problematic transfer request.

  Next, the process of the scheduling monitor processing unit 589 mentioned in the description of FIGS. 51A and 51B will be described with reference to FIG. The scheduling monitor processing unit 589 is, for example, periodically from the transfer table 574 or the withdrawal table 575, request content data related to the scheduling, in which result data including payment approval is not registered by the billing end date. Is extracted (step S311). Request content data as shown in FIG. 51A is extracted. Then, result data indicating that there is no payment approval (approval date “none”, approval content “unpaid” and approval amount “0”) is registered corresponding to the corresponding request content data in the transfer table 574 and the withdrawal table 575 ( Step S313). The state shown in FIGS. 51A and 51B is obtained.

  Further, the scheduling monitor processing unit 589 searches the recipient table 576 with the transfer number included in the request content data extracted in step S311 and contacts the contact data (for example, e-mail address, IP address, mail) of the corresponding recipient. And the like, and a collection result indicating no deposit is notified (step S315). Data may be transmitted via a network, mail may be transmitted, or data may be printed and sent as a document.

  In addition, the scheduling monitor processing unit 589 transfers the request content data having the same contents obtained by incrementing the serial number of the request number (however, as described above, the billing start date and the billing end date are shifted by the scheduling interval). It registers in the table 574 and the withdrawal table 575 (step S317).

  By carrying out such processing, it is possible to automatically generate request content data that is necessary even if non-payment occurs for partial payment, and prepare for the next payment.

  Next, processing for settlement will be described with reference to FIGS. In the present embodiment, as shown in FIG. 61, in the case of remittance within the bank, withdrawing from the user settlement account according to the approval table 579, but without immediately depositing into the store settlement account within the bank, It is registered in the deposit / remittance schedule table 584. Then, the payment is made to the store settlement account according to the deposit / remittance schedule table 584 on the payment date determined according to the rating of the store 100 or the like. On the other hand, as shown in FIG. 62, in the case of other bank remittance, withdrawal is made from the user settlement account in accordance with the approval table 579. Register in the remittance schedule table 584. Then, on the payment date determined according to the rating of the dealer 100 or the like, the money is transferred to the dealer settlement account of another bank according to the payment / remittance schedule table 584.

  First, processing at the time of withdrawal will be described with reference to FIGS. 63 may be performed periodically, for example, or may be performed each time data is added to the approval table 579. The withdrawal processing unit 583 extracts one unprocessed record (FIG. 48) from the approval table 579 (step S321). Then, the withdrawal process is executed from the payer's settlement account based on the extracted record and the withdrawal table 575, and the recipient table 576 is searched with the transfer number specified from the withdrawal table 575 by the request number of the extracted record. The grace period corresponding to the recipient's rating is extracted from the Deposit / Remittance Grace Days table 590, and the record including the extracted record and scheduled deposit date (approval date + grace period) is scheduled to be deposited / remitted. It is registered in the table 584 (step S323). In the withdrawal process (also called withdrawal process), the payer table 577 is searched for the withdrawal number included in the extracted record, the account number corresponding to the withdrawal number is extracted, and the amount included in the extracted record is calculated from the account number. Withdraw money.

  FIG. 64 shows an example of the data structure of the deposit / remittance schedule table 584. In the example of FIG. 64, for each transaction withdrawn, the expected payment date, recipient information (payee account information and recipient name), and amount are registered corresponding to the withdrawal data including the withdrawal number. It is like that.

  Then, the withdrawal processing unit 585 determines whether there is an unprocessed record (step S325). If there is an unprocessed record, the process returns to step S321, and if there is no unprocessed record, The process ends.

  By performing the processing as described above, the scheduling of deposit / remittance is completed. That is, a record in which a scheduled deposit date is set is generated in the scheduled deposit / remittance table 584 according to the rating on the recipient side.

  As described above, “unconditional withdrawal permission” may be registered in the allowance condition allowance information registered corresponding to the withdrawal number in the payer table 577. Therefore, for example, on each business day, a withdrawal number for which unconditional withdrawal permission is set as a withdrawal condition is specified, and request content data in which the withdrawal number is registered is specified, and automatic approval processing is performed.

  Specifically, first, the approval processing unit 578 of the bank system 7 specifies a withdrawal number in which the unconditional withdrawal permission is registered as the withdrawal condition in the payer table 577, and corresponds to the unconditional withdrawal permission from the withdrawal number. Request contents data to be extracted is extracted from the withdrawal table 575 (FIG. 65: step S331). Then, an automatic approval process is performed on the extracted request content data (step S333). Specifically, steps S275, S277, and S287 of FIG. 56 are performed.

  If such processing is performed, even in the case of automatic approval, it is properly registered in the approval table 579, and money can be transferred appropriately.

  Note that the approval processing unit 578 of the bank system 7 searches the withdrawal table 575, specifies the request content data that is not registered and results in non-payment, and passes the billing end date included in the request content data. Judgment is made. If it has elapsed, it is determined as “rejection”, and steps S299, S301, and S307 in FIG. 57 are performed as automatic rejection processing. This makes it possible to process an unapproved transfer request that has been neglected even after the billing period has passed without being neglected.

  Next, processing for deposit and remittance will be described with reference to FIG. The deposit / remittance processing unit 585 extracts a record in which the scheduled deposit date is the processing date (current date) from the scheduled deposit / remittance table 584 (step S341). Then, one unprocessed extracted record is specified (step S343). The recipient information included in the extracted record is checked against the transaction stop list 588 (step S345). In the transaction stop list 588, information of a recipient (that is, a store or the like) determined to stop the transaction in the processing shown below or by an administrator is registered, for example, data as shown in FIG. That is, the transaction stop payee name and the information on the settlement account number (which may include the transfer number) are registered correspondingly.

  As a result of the collation, it is determined whether information matching the recipient information of the extracted record is registered in the transaction stop list 588 (step S347). If the matched information is registered, the process proceeds to step S351. On the other hand, if information matching the recipient information of the extracted record is not registered in the transaction stop list 588, the deposit / remittance processing unit 85 performs a known deposit / remittance process according to the extracted record (step S349). . As schematically shown in FIGS. 61 and 62, the approved amount is deposited or transferred (exchange) to the account included in the recipient information.

  Then, the deposit / remittance processing unit 585 determines whether all the extracted records have been processed (step S351), and returns to step S343 if there is an unprocessed extracted record. On the other hand, if all extracted records have been processed, the process is terminated.

  Next, transaction stop processing related to the transaction stop list 588 will be described with reference to FIGS. This process is a process for preventing a problem in advance by stopping payment or remittance to a recipient whose transaction has been suspended.

  First, the transaction stop processing unit 586 specifies a new transaction stop recipient in the transaction stop list 588 (step S361). In the process of FIG. 35, when the transfer request or the partial collection request is received, it is confirmed whether the rating of the transmission source is not the transaction stop rating, so here, it is limited to a new stop transaction recipient. As to whether or not it is new, for example, by registering the date and time added to the transaction stop list 588 in addition to the data as shown in FIG. 67, it is possible to identify the recipient registered after the previous processing date and time.

  And transaction stop processing part 586 specifies all the transfer numbers of a new transaction stop payee from payee table 576 (Step S363). Then, all the request contents data including no specified transfer number are transferred from the withdrawal table 575 to the transaction stop table 587 (step S365).

  Further, the transaction stop processing unit 586 specifies all settlement accounts of new transaction stop payees from the payee table 576 (step S367). Then, all the data including the specified settlement account whose payment scheduled date is after the processing date (current date) is transferred to the transaction stop table 587 from the payment / remittance schedule table 584 (step S369).

  For example, data as shown in FIG. 69 is registered in the transaction stop table 587. That is, request content data that satisfies the above-described conditions is registered as data from the withdrawal table 575, and data that satisfies the above-described conditions is registered as data from the deposit / remittance schedule table 584.

  When the transaction is stopped in this manner, since it is not extracted in step S219, the user 200 or the like approves it, and since it is not extracted in step S341, the deposit / remittance processing unit 585 cannot perform deposit / remove. In other words, it is possible to prevent deposits / remittances that may cause problems. It should be noted that funds for data transferred from the deposit / remittance schedule table 584 in the transaction stop table 587 are returned to the user 200 or the like in a legal procedure.

  Next, the rating process of the recipient (seller, etc.) will be described with reference to FIGS. The rating is used to determine the number of grace days for deposits and remittances and the suspension of transactions.

  First, the rating processing unit 581 identifies one unprocessed recipient in the recipient table 576 (step S371). Further, all transfer numbers of the specified payees are specified in the payee table 576 (step S373). Then, from the transfer table 574, the request number that includes the specific transfer number and whose approval date in the result data is within a certain period (for example, the latest one month) is counted, and the approval result is “rejected” for the corresponding request number. The request number is extracted and stored in a storage device such as a main memory (step S375).

  Furthermore, the rating processing unit 581 identifies an unprocessed extraction request number (step S377). Then, the rejection reason included in the record corresponding to the specified extraction request number is specified from the approval rejection table 580, and the counter value for the corresponding rejection reason is incremented by 1 (step S379). In the example described above, the reason for refusal is “no purchase results”, “amount difference”, “purchased item difference”, or “payment destination difference”. Is incremented by one.

  Then, the rating processing unit 581 determines whether all extraction request numbers have been processed (step S381), and if there is an unprocessed extraction request number, the process returns to step S377. On the other hand, when processing has been performed for all extraction request numbers, the trouble index is calculated by adding the multiplication result of the reasons for each rejection reason and the count value and dividing by the total number of request numbers (step S383). . For example, data as shown in FIG. 71 is registered in the rating processing data storage unit 582, and the reason point is specified from this data. That is, a reason point is set for each refusal reason. Therefore, the number of “no purchase results” × r1 + the number of “difference in money” × r2 + “difference in purchase” × r3 + “difference in payment” × r4 is calculated and further divided by the total number D of request numbers. A trouble index is calculated. The trouble index is stored in a storage device such as a main memory, for example. The processing shifts to the processing in FIG.

  Then, the rating processing unit 581 identifies the rating corresponding to the trouble index from the table (FIG. 73) stored in the rating processing data storage unit 582 (step S385) and registers it in the recipient table 576 (step S385). S387). For example, a rating table as shown in FIG. 73 is used. In the example of FIG. 73, the range of the trouble index is defined from ratings A to Z. The range can be set for each financial institution. In this example, the rating Z is defined as a transaction suspension, but other ratings may be suspended.

  Then, the rating processing unit 581 determines whether the specified rating is a rating of transaction suspension (step S389), and if applicable, registers it in the transaction suspension list 588 (step S391). On the other hand, if not applicable, the process proceeds to step S393.

  Thereafter, the rating processing unit 581 determines whether or not all recipients have been processed (step S393). If there is an unprocessed recipient, the process returns to step S371 in FIG. On the other hand, if all recipients have been processed, the process ends.

  By carrying out the processing as described above, deposits are made quickly for high-quality dealers, and fund efficiency is improved. For dealers with problems, there is a grace period for deposits. Crime) can be prevented. If the rating is changed or the transaction is suspended, the recipient is notified.

  In this way, both the payment collection request and the transfer request can be handled, and the labor of the store 100, the local government 600, the user 200, and the payer 700 can be reduced.

  In the second embodiment, the billing start date and the billing end date are set in the transfer table 574 and the withdrawal table 575. For example, only the billing start date is set and the billing end date is set as follows. A period from the billing start date may be set, or a billing end date obtained from the default payment period may be set.

  Furthermore, in the second embodiment, an aspect has been shown in which the amount of payment can be changed in the case of partial payment, but it is also possible not to change it. In that case, FIG. 47 is unnecessary for the display screen.

  Although the embodiment of the present invention has been described above, the present invention is not limited to this. For example, regarding the processing flow, if the result does not change, the order of the processing may be changed or executed in parallel. The functional block diagrams of FIGS. 5 and 32 are merely examples, and may not necessarily correspond to the actual program module configuration.

  Further, although not described above, the bank system 7 is also provided with functions for correcting payer data and payee data later, and correcting transfer requests later.

  Further, although the term “store” is used, it may be an individual. In other words, it can also be used in personal auctions.

  Note that the user terminal 5, the dealer server 3, and the bank system 7 are computer devices. As shown in FIG. 74, the computer device includes a memory 2501 (storage unit), a CPU 2503 (processing unit), and a hard disk drive. (HDD) 2505, a display control unit 2507 connected to the display device 2509, a drive device 2513 for the removable disk 2511, an input device 2515, and a communication control unit 2517 for connecting to the network are connected by a bus 2519. . Application programs including an operating system (OS) and a Web browser are stored in the HDD 2505, and are read from the HDD 2505 to the memory 2501 when executed by the CPU 2503. If necessary, the CPU 2503 controls the display control unit 2507, the communication control unit 2517, and the drive device 2513 to perform necessary operations. Further, data in the middle of processing is stored in the memory 2501 and stored in the HDD 2505 if necessary. Such a computer realizes various functions as described above by organically cooperating hardware such as the CPU 2503 and the memory 2501 described above with the OS and necessary application programs.

It is a schematic diagram which shows the 1st step of the service which concerns on the 1st Embodiment of this invention. It is a schematic diagram which shows the 2nd step of the service which concerns on the 1st Embodiment of this invention. It is a schematic diagram which shows the 3rd step of the service which concerns on the 1st Embodiment of this invention. It is a figure which shows the system outline | summary in the 1st Embodiment of this invention. It is a figure which shows the functional block diagram of a bank system. It is a figure which shows the processing flow at the time of processing the utilization application from a user. It is a figure which shows the data structure of a payer table. It is a figure which shows the detailed data structure of a payer table. It is a figure which shows the processing flow at the time of processing the use application from a store. It is a figure which shows the data structure of a recipient table. It is a figure which shows the detailed data structure of a recipient table. It is a figure which shows the processing flow of a process when a user purchases goods etc. from a store. It is a figure which shows the processing flow of the process in the bank system at the time of receiving a transfer request. It is a figure which shows the data structure of a transfer table. It is a figure which shows the detailed data structure of a transfer table. It is a figure which shows the data structure of a withdrawal table. It is a figure which shows the detailed data structure of a withdrawal table. It is a figure which shows the processing flow (1st part) of withdrawal approval processing. It is a figure which shows the example of a display screen of ATM. It is a figure which shows the example of a display screen of ATM. It is a figure which shows the example of a display screen of ATM. It is a figure which shows the processing flow (2nd part) of withdrawal approval processing. It is a figure which shows the data structure of a withdrawal approval table. It is a figure which shows the data structure of a withdrawal approval rejection table. It is a figure which shows the processing flow of a payment process. It is a figure which shows the outline | summary of a transfer process. It is a figure which shows the outline | summary of a withdrawal process. It is a figure which shows a process in case unconditional withdrawal permission is set to the withdrawal condition. It is a figure which shows the processing flow of a total process. It is a schematic diagram which shows the 1st step of the service which concerns on the 2nd Embodiment of this invention. It is a schematic diagram which shows the 2nd step of the service which concerns on the 2nd Embodiment of this invention. It is a functional block diagram of the bank system in the 2nd embodiment of the present invention. It is a figure which shows the detailed data structure of the payer table in 2nd Embodiment. It is a figure which shows the detailed data structure of the recipient table in 2nd Embodiment. It is a figure which shows the processing flow of the process in a bank system at the time of receiving a transfer request or a partial collection request. It is a figure which shows the data structure of a transfer table. It is a figure which shows the detailed data structure of a transfer table. It is a figure which shows an example of the data registered into a transfer table, when a transfer request is received. It is a figure which shows the 1st example of the request content data which concern on the payment in a transfer table. It is a figure which shows the 1st example of the request content data which concern on the payment in a withdrawal table. It is a figure which shows the data structure of a withdrawal table. It is a figure which shows the detailed data structure of a withdrawal table. It is a figure which shows the processing flow (1st part) of an approval process. It is a figure which shows the example of a display screen of ATM. It is a figure which shows the example of a display screen of ATM. It is a figure which shows the processing flow (2nd part) of withdrawal approval processing. It is a figure which shows the example of a display screen of ATM. It is a figure which shows the data structure of an approval table. It is a figure which shows the processing flow (3rd part) of an approval process. It is a figure which shows the 2nd example of the request content data which concern on the payment in a transfer table. It is a figure which shows the 2nd example of the request content data concerning the payment in the withdrawal table. It is a figure which shows the 3rd example of the request content data which concern on the payment in a transfer table. It is a figure which shows the 3rd example of the request content data concerning the payment in the withdrawal table. It is a figure which shows the 4th example of the request content data which concern on the payment in a transfer table. It is a figure which shows the 4th example of the request content data concerning the payment in the withdrawal table. It is a figure which shows the 5th example of the request content data which concern on the payment in a transfer table. It is a figure which shows the 5th example of the request content data concerning the payment in the withdrawal table. It is a figure which shows the 6th example of the request content data which concern on the payment in a transfer table. It is a figure which shows the 6th example of the request content data concerning the payment in the withdrawal table. It is a figure which shows the example of data of a payment and remittance postponement days table. It is a figure which shows the processing flow (4th part) of an approval process. It is a figure which shows the processing flow (5th part) of an approval process. The figure which shows the example of the display screen of ATM It is a figure showing the data structure of an approval refusal table. It is. It is a figure which shows the processing flow of a scheduling monitoring process. It is a conceptual diagram of the own bank transfer process in 2nd Embodiment. It is a conceptual diagram of the other bank transfer process in 2nd Embodiment. It is a figure which shows the processing flow of a payment process. It is a figure which shows an example of the data structure of a payment / remittance schedule table. It is a figure which shows the processing flow of the process at the time of performing automatic approval. It is a figure which shows the processing flow of a money_receiving | payment / remittance process. It is a figure which shows the data structure of a transaction stop table. It is a figure which shows the processing flow of a transaction stop process. It is a figure which shows the data structure of a transaction stop table. It is a figure which shows the processing flow (1st part) of a rating process. It is a figure which shows an example of the table showing the relationship between a refusal reason and a reason point. It is a figure which shows the processing flow (2nd part) of a rating process. It is a figure which shows a rating table. It is a functional block diagram of a computer.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Network 3 Dealer server 5 User terminal 7 Bank system 9a, 9b, 9c ATM
71 Transfer Request Reception Unit 72 Dealer Registration Unit 73 User Registration Unit 74 Transfer Table 75 Withdrawal Table 76 Recipient Table 77 Payer Table 78 Approval Processing Unit 79 Withdrawal Approval Table 80 Withdrawal Approval Rejection Table 81 Aggregation Processing Unit 82 Total Data Storage Unit 83 Settlement Processing Unit 84 Debit Processing Unit 85 Transfer Processing Unit 571 Transfer Request Accepting Unit 572 Dealer Registration Unit 573 User Registration Unit 574 Transfer Table 575 Withdrawal Table 576 Recipient Table 577 Payer Table 578 Approval Processing Unit 579 Approval Table 580 Approval Rejection Table 581 Rating processing unit 582 Rating processing data storage unit 583 Withdrawal processing unit 584 Deposit / remittance schedule table 585 Deposit / remittance processing unit 586 Transaction stop processing unit 587 Transaction stop table 588 Transaction stop list processing unit 589 90 deposit, remittance grace dates of table

Claims (9)

A scheduling method executed by a computer system having a processing unit,
A step of issuing one or a plurality of transfer numbers corresponding to an account number of a settlement account of the first user in accordance with a usage request from the first user and registering it in a recipient table by the processing unit. When,
A step of issuing one or a plurality of withdrawal numbers corresponding to the account number of the settlement account of the second user and registering it in the payer table by the processing unit in response to a usage request from the second user. When,
The specific withdrawal number notified from the second user to the first user by the processing unit, the specific transfer number of the first user, the amount charged for one time, the total amount charged, A request number is issued in response to a partial collection request including data related to the billing object, and the specific transfer number, the one-time charge amount and the total bill amount corresponding to the specific withdrawal number and the request number Is registered in a withdrawal table, and the specific withdrawal number, the billed amount for one time, the total billed amount, and the bill corresponding to the specific transfer number and the request number are registered. A partial collection request registration step of registering the first transfer request content data including data relating to the object in the transfer table;
When the account number and withdrawal number of the settlement account are designated by the second user, or the account number of the settlement account is designated by the second user and the account of the settlement account is specified from the payer table When the withdrawal number corresponding to the number is specified, the processing unit extracts the unapproved withdrawal request content data corresponding to the designated or specified withdrawal number from the withdrawal table, and the withdrawal request content data Generating and outputting an approval confirmation list for
In response to a detailed display request from the second user that specifies the withdrawal request content data selected from the approval confirmation list by the processing unit, the processing unit relates to the selected withdrawal request content data from the transfer table. To extract the transfer amount and the charge amount corresponding to the request number of the selected withdrawal request content data and the data related to the billing object, and present them to the second user including the extracted data Generating and outputting approval confirmation data for
In response to the approval instruction from the second user for the approval confirmation data by the processing unit, in the transfer table corresponding to the request number related to the approval confirmation data and the transfer number related to the request number. Registering an approval result, registering an approval result in the withdrawal table corresponding to the request number related to the approval confirmation data and the specified or specified withdrawal number, and including the request number related to the approval confirmation data. An approval step for storing data for remittance in an approval table;
In response to an approval instruction from the second user for the approval confirmation data, the processing unit issues a second request number associated with the request number related to the approval confirmation data, and the approval confirmation data Second withdrawal request content data in which the total billed amount in the first withdrawal request content data corresponding to the request number related to the request number is replaced with the difference between the total billed amount and the approved amount, the approval confirmation data Corresponding to the withdrawal number and the second request number, and registering the total bill amount in the first transfer request content data corresponding to the request number related to the approval confirmation data. The second transfer request content data replaced with the difference between the total billed amount and the approved amount is the transfer number and the second request number related to the approval confirmation data. And automated data generation step of registering the transfer table in response,
Including the scheduling process. When the amount of money approved by the second user is included in the approval instruction from the second user, an amount different from the one-time charge amount,
The approved amount is included in the approval result registered in the transfer table,
The approved amount is included in the approval result registered in the withdrawal table,
The payment processing method according to claim 1, wherein the approved amount is included in the data for remittance. The first withdrawal request content data and the first transfer request content data include data for determining a billing period,
The processing unit searches the transfer table or the withdrawal table for the unapproved first transfer request content data or the first withdrawal request content data even after the billing period has elapsed, and the unapproved first If there is the transfer request content data or the first withdrawal request content data, the third transfer request content data or the third withdrawal request content data associated with the request number associated with the first withdrawal request content data. Issue the request number and change the data for defining the billing period in the first withdrawal request content data to the data for defining the next billing period, the third withdrawal request content data is the first withdrawal The billing period in the first transfer request content data is registered in the withdrawal table corresponding to the withdrawal number and the third request number related to the request content data. The third transfer request content data obtained by changing the data for determining to the data for determining the next billing period corresponds to the transfer number and the third request number related to the first transfer request content data. A second automatic data generation step registered in the transfer table,
The method of claim 1 further comprising: In the recipient table, the rating of the first user is registered corresponding to the account number of the first user's settlement account,
From the settlement account of the second user specified in the payer table from the withdrawal number corresponding to the request number included in the data for remittance registered in the approval table by the processing unit, Withdrawing the approved amount;
The processing unit specifies the rating of the first user specified in the payee table from the transfer number corresponding to the request number included in the data for remittance registered in the approval table, The transfer corresponding to the request number included in the data for the remittance is specified by specifying the payment grace days corresponding to the rating of the first user from the grace days table holding the correspondence between the ratings and the grace days of payment. The account number of the first user's settlement account specified in the payee table from the transfer number corresponding to the request number included in the number or the data for remittance, and the specified number of grace days for payment Registering payment / remittance schedule data including the expected payment date obtained from the approval date and the transfer / remittance schedule table,
Extracting data whose current date is the scheduled payment date from the deposit / remittance schedule table by the processing unit, and depositing or transferring money to the first user settlement account according to the data;
The method of claim 1 further comprising: Extracting from the payer table the transfer number or the account number of the settlement account related to the user registered in the transaction stop list storing information identifying the user who has stopped the transaction by the processing unit;
The step of moving the deposit / remittance schedule data including the extracted transfer number or the account number of the settlement account from the deposit / remittance schedule table to the transaction stop data storage unit by the processing unit;
Moving the unapproved withdrawal request content data including the extracted transfer number from the withdrawal table to the transaction stop data storage by the processing unit;
The method of claim 4, further comprising: A payment processing method executed by a computer system having a processing unit,
A step of issuing one or a plurality of transfer numbers corresponding to an account number of a settlement account of the first user in accordance with a usage request from the first user and registering it in a recipient table by the processing unit. When,
A step of issuing one or a plurality of withdrawal numbers corresponding to the account number of the settlement account of the second user and registering it in the payer table by the processing unit in response to a usage request from the second user. When,
From the second user to the first user by the processing unit, the second user making a purchase application for the purchase target to the first user by the name of the second user. In response to the transfer request including the specific withdrawal number to be notified, the specific transfer number of the first user, the amount, and the data related to the purchase target, the request number is issued, and the specific withdrawal number and wherein in response to request number register and the amount the previous SL specific transfer number to debit the table, the specific transfer number and name as the specific withdrawal number of the second user in response to the request number And a transfer request registration step of registering the amount and the data related to the purchase object in the transfer table;
When the account number and withdrawal number of the settlement account are designated by the second user, or the account number of the settlement account is designated by the second user and the account of the settlement account is specified from the payer table When a withdrawal number corresponding to a number is specified, the processing unit extracts data related to the unapproved transfer request corresponding to the specified or specified withdrawal number from the withdrawal table, and the transfer request Generating and outputting an authorization confirmation list for
The processing unit identifies the transfer request selected from the approval confirmation list, and in response to a detailed display request from the second user, from the transfer table, the transfer number related to the selected transfer request and the transfer request The amount corresponding to the request number of the selected transfer request and the data related to the purchase target are extracted, and approval confirmation data to be presented to the second user is generated and output using the extracted data. Steps,
In response to the approval instruction from the second user for the approval confirmation data by the processing unit, in the transfer table corresponding to the request number related to the approval confirmation data and the transfer number related to the request number. An approval result is registered, an approval result is registered in the withdrawal table corresponding to the request number related to the approval confirmation data and the specified or specified withdrawal number, and the request number related to the approval confirmation data and designated or An approval step of storing settlement data including the specified withdrawal number in a withdrawal approval table;
For the unsettled settlement data registered in the withdrawal approval table, the processing unit specifies the transfer number and the amount corresponding to the request number and the withdrawal number included in the settlement data from the withdrawal table. The account number of the settlement account corresponding to the withdrawal number is identified from the payer table, the account number of the settlement account corresponding to the transfer number is identified from the payee table, and the identified amount A remittance step of performing a process for remittance from a settlement account corresponding to the withdrawal number to a settlement account corresponding to the transfer number;
Payment processing method. A payment processing method executed by a computer system having a processing unit,
A step of issuing a transfer number for each receipt condition corresponding to the account number of the first user's settlement account and registering it in a recipient table by the processing unit in response to a usage request from the first user. When,
A step of issuing one or a plurality of withdrawal numbers corresponding to the account number of the settlement account of the second user and registering it in the payer table by the processing unit in response to a usage request from the second user. When,
From the second user to the first user by the processing unit, the second user making a purchase application for the purchase target to the first user by the name of the second user. In response to the transfer request including the specific withdrawal number to be notified, the specific transfer number of the first user, the amount, and the data related to the purchase target, the request number is issued, and the specific withdrawal number and The specific transfer number and the amount are registered in a withdrawal table corresponding to the request number, and the name of the second user and the specific withdrawal number are associated with the specific transfer number and the request number. A transfer request registration step of registering the amount and data relating to the purchase object in a transfer table;
When the account number and withdrawal number of the settlement account are designated by the second user, or the account number of the settlement account is designated by the second user and the account of the settlement account is specified from the payer table When the withdrawal number corresponding to the number is specified, the processing unit is data relating to the unapproved transfer request corresponding to the designated or specified withdrawal number from the withdrawal table, and is included in the data Extracting the data satisfying the receipt condition registered in the payee table corresponding to the transfer number, and generating and outputting an approval confirmation list for the transfer request;
The processing unit identifies the transfer request selected from the approval confirmation list, and in response to a detailed display request from the second user, from the transfer table, the transfer number related to the selected transfer request and the transfer request The amount corresponding to the request number of the selected transfer request and the data related to the purchase target are extracted, and approval confirmation data to be presented to the second user is generated and output using the extracted data. Steps,
In response to the approval instruction from the second user for the approval confirmation data by the processing unit, in the transfer table corresponding to the request number related to the approval confirmation data and the transfer number related to the request number. An approval result is registered, an approval result is registered in the withdrawal table corresponding to the request number related to the approval confirmation data and the specified or specified withdrawal number, and the request number related to the approval confirmation data and designated or An approval step of storing settlement data including the specified withdrawal number in a withdrawal approval table;
For the unsettled settlement data registered in the withdrawal approval table, the processing unit specifies the transfer number and the amount corresponding to the request number and the withdrawal number included in the settlement data from the withdrawal table. The account number of the settlement account corresponding to the withdrawal number is identified from the payer table, the account number of the settlement account corresponding to the transfer number is identified from the payee table, and the identified amount A remittance step of performing a process for remittance from a settlement account corresponding to the withdrawal number to a settlement account corresponding to the transfer number;
Payment processing method.   A program for causing a computer to execute the scheduling method according to any one of claims 1 to 5. Means for issuing one or more transfer numbers corresponding to the account number of the first user's settlement account in response to a usage request from the first user, and registering it in the payee table;
Means for issuing one or a plurality of withdrawal numbers corresponding to the account number of the settlement account of the second user in response to a usage request from the second user and registering it in the payer table;
A specific withdrawal number notified from the second user to the first user, a specific transfer number of the first user, a charge amount for one time, a total charge amount, and data relating to a charge target; In response to the collection request including the first, a request number is issued, and the specific transfer number, the one-time charge amount, and the total charge amount corresponding to the specific withdrawal number and the request number, Withdrawal request content data of is registered in the withdrawal table, and the specific withdrawal number, the charge amount for one time, the total billed amount, and the data related to the billing object corresponding to the specific transfer number and the request number A divisional collection request registration means for registering the first transfer request content data including the transfer data into the transfer table;
When the account number and withdrawal number of the settlement account are designated by the second user, or the account number of the settlement account is designated by the second user and the account of the settlement account is specified from the payer table When a withdrawal number corresponding to a number is specified, the unapproved withdrawal request content data corresponding to the designated or specified withdrawal number is extracted from the withdrawal table, and an approval confirmation list for the withdrawal request content data is extracted. Means for generating and outputting
In response to a detailed display request from the second user that identifies the withdrawal request content data selected from the approval confirmation list, the transfer number and the selection related to the selected withdrawal request content data from the transfer table Approval confirmation data for extracting to the second user the extracted billing amount corresponding to the request number of the withdrawal request content data and the data related to the billing object is extracted and the extracted data is included. Means for generating and outputting;
In response to an approval instruction from the second user for the approval confirmation data, an approval result is registered in the transfer table corresponding to the request number related to the approval confirmation data and the transfer number related to the request number. , Data for remittance including the request number related to the approval confirmation data, registering the approval result in the withdrawal table corresponding to the request number related to the approval confirmation data and the designated or specified withdrawal number An approval means for storing the information in the approval table;
In response to an approval instruction from the second user for the approval confirmation data, a second request number associated with the request number related to the approval confirmation data is issued, and the request number related to the approval confirmation data The second withdrawal request content data in which the total billed amount in the first withdrawal request content data corresponding to is replaced with the difference between the total billed amount and the approved amount is the withdrawal number related to the approval confirmation data. And the second request number corresponding to the request number in the first transfer request content data corresponding to the request number related to the approval confirmation data and the total request amount. The second transfer request content data replaced with the difference from the approved amount is transferred in correspondence with the transfer number and the second request number related to the approval confirmation data. And automated data generation means for registering the Buru,
A scheduling processing apparatus having

Images