JP2001243403A - System and method for payment - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a system and a method for payment which can shorten a total processing time, save the labor and cost, and improve convenience to not only companies and account settling financial institutions, but also customers. SOLUTION: A member 2 previously registers a financial institution to be used and a member company as an asking agency by using a member terminal 21, etc. A member company system 40 generates transfer demand data. An interface server 30 for member companies converts the transfer demand data to a common format and also converts the customer code specific to the member company into a common account settlement member code. An account settlement data center system 10 records the contents of the transfer demand data and distributes them by financial periods. A financial institution interface server 50 determines a transfer account according to the account settlement member code. The financial institution server 50 divides and sends data on transfer success and failure back to the account settlement data center system 10.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a settlement system and a settlement method for transferring funds between accounts for various services such as utility charges and various commodities. In particular, it relates to a payment system and a payment method for centrally exchanging payment data via a network.

[0002]

2. Description of the Related Art Transfer processing between accounts at financial institutions such as banks is widely used for settlement of various charges such as electricity, gas, water and communication. Conventionally, in such transfer processing, data exchange between a company that charges a fee and a financial institution that performs account transfer processing has been performed using a magnetic tape. FIG. 18 is a reference diagram showing a method of exchanging fee transfer data in the related art. In FIG. 18, reference numeral 940 denotes a company system of a company that charges a fee, and 960 denotes a financial institution system that performs account processing in the financial institution.

[0003] The company system 940 calculates the amount charged to the customer, and records the transfer data on a magnetic tape (MT, Magnetic Tape) 901 in its own data format. The data recorded on the magnetic tape 901 includes customer numbers, addresses, names, financial institution codes,
Includes deposit type, account number, and the like. These magnetic tapes are created for each financial institution, transported to each financial institution, and read by the financial institution system 960. The financial institution system 960 executes a fee transfer process based on the data read from the magnetic tape 901. Then, the processing result data is stored in the financial institution system 960.
Is recorded on a magnetic tape, transported in the opposite direction to the above flow, and read by the enterprise system 940. The processing result data includes, for each billing party,
Information indicating whether the transfer process was successful or failed due to a shortage of account balance or the like is included.

[0004] In the case of data exchange using a magnetic tape as described above, it generally takes several days from when the billing process is performed on the company system 940 side to when the fee is actually deducted on the financial institution system 960 side. Also, it usually takes several days (about 2 to 10 days) from when the debit processing is performed on the financial institution system 960 side to when the processing result data reaches the enterprise system 940 side. Corporate system 940
Performs a billing amount elimination process for a customer who has been successfully debited based on the processing result data, and performs a reclaim process for a customer who has failed to be debited.

Further, in the enterprise system 940, since the magnetic tape 901 is created several days ahead of the actual transfer processing date, in the above-described normal processing flow, a request generated during the several days is generated. Inability to respond to changes in content. In such a case, the following special measures are taken. FIG. 19 is a sequence diagram showing the flow of processing for changing the content of a claim according to the conventional technique. In FIG. 19, the company system 940 generates transfer data and records it on the magnetic tape 901 (), and the magnetic tape 901 is delivered to the financial institution system 960 (). Thereafter, if it is necessary to change the billing amount for some reason, for example, the person in charge updates the data of the corporate system 940 by inputting from the system terminal 941 provided in the business office (), and the billing is updated. A telephone call is made to the branch of the financial institution handling the pre-customer, and a contact is made (), and the person in charge of the financial institution branch which has been notified inputs the data from the system terminal 961 to update the data of the financial institution system 960 (). .

[0006] In addition, when a general customer applies for account transfer of various fees, the customer must fill out a paper application document, submit the document to the company that billed the fee, and then submit the document from the company to the handling financial institution. Circulation is taking place. Alternatively, application documents are submitted from a general customer to a financial institution, and the financial institution circulates the documents to a requesting company.

[0007]

In many cases, the processing of account transfer of one company's fee is handled by more than 100 financial institutions, and almost every business day for the purpose of leveling the processing volume on the company system side. Is being processed. There are various problems with such a conventional settlement method. The first problem is that it takes too much time for both the data for the financial institution system and the data for the enterprise system to reach the other party and be processed by the physical transport of the magnetic tape. Second
The problem is that mounting or unmounting an enormous number of magnetic tapes on an apparatus, sorting by delivery destination, and delivering too much labor are too laborious.

There are also various problems derived from these problems. For example, there is a problem in that the processing result data can be acquired on the corporate system side slowly, so that it is not immediately known whether or not the charge has been successfully deducted. In particular, if the withdrawal fails, it is necessary to wait until the processing result data arrives, although it is desired to take an action for collection immediately. Another problem is that if the contents of the bill are changed after the transfer data is output on the company system side, as described with reference to FIG. 19, it is necessary to take a very laborious procedure. In addition, since the data format exchanged by the magnetic tape is unique to each company, there is another problem that a financial institution system must be constructed so as to correspond to all of these individual formats. Due to these problems, the conventional payment processing
It is very costly and time consuming. Also,
Although it is conceivable to transmit data through a communication network, if the conventional data exchange using a magnetic tape is simply replaced with a network, the following new problem occurs. First, conventional transfer request data includes information such as customer name information, address information, account number, and the like. Since the data amount is enormous, for example, let's transmit data over a network using a dedicated line or the like. Then, there is a problem that the network cost is very high. Second, it is conceivable to use a relatively inexpensive network such as the Internet, for example. When transmitting the above-mentioned name information, address information, account number information, etc. over the Internet, the personal information of these personal information may be used. There is a risk of leakage, and there is a serious problem from the viewpoint of information security.

The present invention has been made in view of such circumstances, and it is possible to reduce the cost by shortening the end-to-end processing time and reducing the manpower required for the processing. Considering data security related to personal information, improving the convenience not only for companies and settlement financial institutions but also for customers, and providing a flexible settlement system and settlement method applicable to various forms of business. With the goal.

[0010]

In order to solve the above-mentioned problems, the invention according to claim 1 is a method for settingtle a billed amount from a member company to a member, and setting the member's account in a financial institution to the member company. A center system for executing data processing to be performed by transfer processing to and from an account of a first transfer request data receiving unit that receives transfer request data created by a member company system of a plurality of said member companies A transfer request data distribution unit that distributes the transfer request data to a plurality of destination financial institutions;
A gist of a center system comprising: a first transfer request data transmission unit that transmits the transfer request data distributed by the transfer request data distribution unit to a destination financial institution.

In the invention according to claim 2, the processing result data output as a result of the transfer processing performed by the financial institution system of the financial institution based on the transfer request data transmitted by the first transfer request data transmitting unit. A first processing result data receiving unit, a processing result data distributing unit for distributing the processing result data to a plurality of invoicing member companies, and a processing result data distributed by the processing result data distributing unit. A first processing result data transmitting unit that transmits the processing result data to the requesting member company.

According to a third aspect of the present invention, there is provided transaction data for retaining information based on the transfer request data for each of the member companies, for each of the members, and for each designated transfer date.

[0013] In the invention described in claim 4, the transaction data includes information based on the processing result data for each of the member companies, for each of the members, for each of the designated transfer dates, and for the transfer request data. It is characterized in that it is stored in association with the base information.

In the invention according to claim 5, the transaction data is updated based on the correction data sent from the member company for the purpose of correcting the transfer request data, and the corrected data is transmitted to the financial institution. And a first correction data receiving unit for sending the first correction data.

According to the invention described in claim 6, electronic statement data is created for each of the members based on the transaction data and transmitted to a terminal device.

Further, in the invention according to claim 7, the first transfer request data receiving section receives the transfer request data in a state where the information is compressed, and the transfer request data distributing section receives the transfer request data of the transfer request data. The transfer request data is sorted at least partially while the information is compressed.

In the invention described in claim 8, the transfer request data data transmitted by the first transfer request data transmitting section does not include account number information of the member.

In the ninth aspect of the present invention, the first processing result data transmitting section includes a “transfer success” or a “transfer failure” in the processing result data received by the first processing result data receiving section. Based on the transfer result indicating either of the above, only the data of “transfer failure” is selectively transmitted.

According to a tenth aspect of the present invention, there is provided a data processing for performing settlement of a billed amount from a member company to a member by a transfer process between the account of the member and the account of the member company in a financial institution. An interface system for member companies that mediates between the center system and the member company system that generates transfer request data for
A transfer request data input unit for inputting the transfer request data generated by the member company system; a first transfer request data format conversion unit for converting the transfer request data from a member company system format to a common format; A gist of an interface system for a member company, comprising: a second transfer request data transmitting unit that transmits the transfer request data converted by the first transfer request data format conversion unit to the center system.

Here, the "common format" means
This is a data format for processing by the center system, and is a common format commonly used in data exchange with all member companies and all financial institutions.

In the invention according to claim 11, there is provided a first conversion table which holds a relationship between an individual customer code used uniquely for each of the member companies and a settlement member code commonly used in the center system. The first
The transfer request data format conversion unit converts the individual customer code in the transfer request data into the payment member code based on the first conversion table, for a member company according to claim 10, wherein Interface system.

In the invention according to claim 12,
The transfer request data transmitted by the second transfer request data transmitting unit does not include account number information of the member.

According to a thirteenth aspect of the present invention, there is provided a data processing for performing settlement of a billed amount from a member company to a member by transfer processing between the account of the member and the account of the member company in a financial institution. A financial institution interface system that mediates between a center system and a financial institution system that performs a transfer process for receiving transfer request data sent from the center system.
A transfer request data receiving unit, a second transfer request data format conversion unit for converting the transfer request data from a common format commonly used in the center system to a format for a financial institution system, and the second transfer request data format conversion And a third transfer request data transmitting unit for transmitting the transfer request data converted by the unit to the financial institution system.

Further, in the invention according to claim 14,
A second conversion table for holding a relationship between a settlement member code commonly used in the center system for member identification and member account identification information for identifying the account of the member, wherein the second transfer request data format conversion unit Is characterized by adding the member account identification information to the transfer request data based on the settlement member code in the second conversion table and the transfer request data.

Here, the "member account identification information" is information for identifying the account of the member from which the funds are to be withdrawn at the time of settlement. Specifically, the deposit type, account number,
The name of the depositor, or a combination of a plurality of these. Further, other information (for example, a financial institution code, a branch code, etc.) may be combined to form “member account identification information”. The “deposit type” is, for example,
This is data indicating the distinction between ordinary deposits, checking deposits, savings deposits, notice deposits, and the like.

In the invention according to claim 15,
A processing result data input unit for acquiring processing result data output as a result of the transfer processing performed by the financial institution system based on the transfer request data transmitted by the third transfer request data transmitting unit; A first processing result data format converter for converting the format for the institutional system into a common format commonly used in the center system, and directing the processing result data converted by the first processing result data format converter to the center system. And a second processing result data transmitting unit for transmitting the data.

[0027] In the sixteenth aspect of the present invention,
The first processing result data format conversion unit, based on the transfer result indicating either "transfer success" or "transfer failure" in the processing result data, data of "transfer success" and "transfer failure" It is characterized by sorting data.

Further, in the invention according to claim 17,
The second processing result data transmission unit is characterized in that data of “transfer success” and data of “transfer failure” are distinguished and transmitted.

Further, in the invention according to claim 18,
The second processing result data transmission unit transmits data of “transfer failure” with priority over data of “transfer success”.

[0030] In the invention according to claim 19,
The second processing result data transmitting unit transmits only the data of “transfer failure” among the data of “transfer success” and the data of “transfer failure”.

Further, in the invention according to claim 20,
A second correction data receiving unit for receiving correction data sent from a member company for the purpose of correcting the transfer request data, wherein the transfer request data is received based on the correction data received by the second correction data receiving unit; It is characterized by being modified.

According to a twenty-first aspect of the present invention, there is provided a data processing for performing settlement of a billed amount from a member company to a member by a transfer process between the account of the member and the account of the member company in a financial institution. A transfer request data output from a member company system of the member company, and the transfer request data is converted into a plurality of files in a common format commonly used by all the member companies. The interface system for member companies that outputs the member data of the member as one unit, and the transfer request data output from the plurality of interface systems for member companies are input, and while the transfer request data is held inside, Of payment data to be assigned to the destination of each financial institution and output to the destination financial institution. And a financial institution interface system for inputting transfer request data output from the settlement data center system, adding member account identification information for identifying each of the member accounts to the transfer request data, and outputting the data. The gist of the present invention is a settlement system comprising:

[0033] In the invention described in claim 22, the transfer request data is transmitted between the member company interface system and the settlement data center system or between the settlement data center system and the financial institution interface system. And / or wherein the transfer request data in the common format does not have the member account identification information.

In the invention according to claim 23, the interface system for a financial institution converts the data of “transfer failure” to “transfer failure” with respect to the processing result data output as a result of the processing at the financial institution based on the transfer request data. The processing is performed prior to the data of "successful transfer".

In the invention according to claim 24, the interface system for a financial institution, with regard to the processing result data output as a result of the processing at the financial institution based on the transfer request data, only the data of “transfer failure”. It is characterized in that it is transmitted to the member company and the data of “successful transfer” is not transmitted to the member company.

According to a twenty-fifth aspect of the present invention, there is provided a settlement method for performing settlement of a billed amount from a member company to a member by using a computer network, wherein a plurality of member companies make bills to the members. A first step of receiving the included transfer request data, a second step of distributing the received transfer request data to the financial institution for settlement of the member, and the member based on the allocated transfer request data. And a third step of synchronously withdrawing funds from an account of the member company and depositing funds into an account of the member company.

According to a twenty-sixth aspect of the present invention, in the third step, a process of directly depositing funds withdrawn from the member's account into the member company's account is performed.

[0038] In the invention according to claim 27, in the third step, a process of depositing the fund withdrawn from the account of the member into the account of the member company via the account of the third party is performed. It is characterized by performing.

In the invention described in claim 28, the transfer request data in the first step is created based on shopping performed by the member using a recording medium on which the identification information of the member is recorded. It is characterized by the following.

In the invention described in claim 29, the transfer request data in the first step is created based on shopping performed by the member via a network using the identification information of the member. Features.

According to a thirtieth aspect of the present invention, there is provided a data processing for performing settlement of a billed amount from a member company to a member by transfer processing between the account of the member and the account of the member company in a financial institution. Receiving a transfer request data created by a member company system of the plurality of member companies, allocating the transfer request data to a plurality of destination financial institutions, and Transmitting the transfer request data to the destination financial institution, respectively.

According to a thirty-first aspect of the present invention, there is provided a data processing for performing settlement of a billed amount from a member company to a member by transfer processing between the account of the member and the account of the member company in a financial institution. Inputting transfer request data generated by a member company system of the member company, converting the transfer request data from a member company system format to a common format, and converting the transfer request data to the common format. Transmitting the transferred transfer request data to a center system that performs data exchange processing.

According to a thirty-second aspect of the present invention, there is provided a data processing for performing settlement of a billing amount from a member company to a member by transfer processing between the account of the member and the account of the member company in a financial institution. Method for receiving transfer request data sent from a center system that performs data exchange processing, and converting the transfer request data from a common format commonly used in the center system to a format for a financial institution system And transmitting the transfer request data converted to the financial institution system format to the financial institution system.

According to a thirty-third aspect of the present invention, there is provided a data processing for performing settlement of a billing amount from a member company to a member by a transfer process between the account of the member and the account of the member company in a financial institution. Inputting transfer request data output from a member company system of the member company, and transferring the transfer request data to a plurality of the members in a common format commonly used by all the member companies. A first step of outputting data as one unit, inputting the transfer request data output in the first step, holding the transfer request data, and distributing the transfer request data to a plurality of financial institutions; A second step of outputting to the financial institution, and inputting the transfer request data output in the second step , The data processing method characterized by having a third step of outputting by adding the membership account identification information identifying each of the member's account in the transfer billing data and subject matter.

[0045]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is a configuration diagram showing a configuration of a settlement system according to the embodiment. In this figure, reference numeral 0 denotes the Internet, 1 denotes a payment data center, 2 denotes a member who pays a fee through the payment system, 3 denotes a member company that charges the member 2, 5
Is a financial institution that manages the deposit account of the member 2.

The settlement data center 1 operates a settlement data center system 10 (center system). The settlement data center system 10 includes transaction data 11, a member master 12, a member company-specific history data 13,
Processing is performed using the member history data 14 or the like. The member company 3 has its own member company system 4 for each member company.
0 and a member company interface server 30 (member company interface system) that performs data conversion processing between the member company system 40 and the settlement data center system 10 and the like. In addition, the financial institution 5 has its own financial institution system 60 for each financial institution,
Financial Institution System 60 and Payment Data Center System 1
A financial institution interface server 50 (a financial institution interface system) that performs data conversion processing between 0 and the like is operated.

The settlement data center system 10 is connected to the member company interface server 30 and the financial institution interface server 50 through the Internet 0. Further, the member 2 has a member terminal 21 and accesses the settlement data center system 10 from the member terminal 21 through the Internet 0 to perform various operations in addition to data reference. The settlement data center system 10 is connected to a plurality of member companies 3 and a plurality of financial institutions 5, and performs intensive data exchange between the member companies and the financial institutions.

Next, an outline of the processing flow among the member 2, the member company 3, the financial institution 5, and the settlement data center system 10 will be described. FIG. 2 is a reference diagram illustrating an outline of a process related to the settlement data center system 10.
As shown in this figure, the member 2 has previously registered “account registration” and “transfer application” with the settlement data center system 10.
I do. By “account registration”, a deposit account held by the member 2 at the financial institution 5 is registered. In addition, by the “transfer application”, registration for transfer settlement of the billing amount from the member company 3 to the member 2 and setting of a deposit account thereof are performed. This “transfer application” information is also transmitted to the member companies 3 and the financial institution 5.

Assuming that the “account registration” and “transfer application” have already been made, the settlement data center system 10 sends the designated financial institution 5 based on the “transfer request” sent from the member company 3. Send “Transfer request” to As a result of the processing at the financial institution 5, a “transfer result error list” regarding the customer whose transfer has not been completed normally is sent to the settlement data center system 10, further sorted, and sent to the member company 3. The member company 3 can know the member whose settlement has not been completed based on the transfer result error list. Also, every fixed period (for example, every month)
In addition to the periodic billing, the member 2 sends a "transfer request" to the settlement data center 10, and based on this, the settlement data center system 10 sends a "transaction instruction" to the financial institution 5. Can also be. Also in this case, the “transaction result” is returned from the financial institution 5 to the settlement data center system 10. The contents of the above-mentioned registration and transfer processing are described in the member master 12 and the member company history data 1.
3 and the member history data 14.

Next, a flow of a series of settlement processing based on a request from a member company will be described. FIG. 3 is a sequence diagram showing the flow of the transfer request data in the member company interface server 30. FIG. 4 is a sequence diagram showing the flow of transfer request data in the settlement data center system 10. FIG. 6 is a sequence diagram showing the flow of the transfer request data in the financial institution interface server 50. FIG. 7 is a sequence diagram showing the flow of the processing result data in the financial institution interface server 50. FIG. 8 is a sequence diagram showing a flow of processing result data in the settlement data center system 10. FIG. 9 is a sequence diagram showing the flow of the processing result data in the member company interface server 30.

In FIG. 3, a file is input (process 30).
1. Transfer request data input unit) reads the transfer request data created by the enterprise system (of FIG. 3) and writes it into the data queue 310. Then, according to an instruction from the queue monitor (process 351), code conversion (process 30) is performed.
2) takes out data from the data queue 310 and converts the character code. Next, common format conversion (process 30)
3. The first transfer request data format conversion unit) converts the individual customer code unique to the member company in the data into a payment member code commonly used in the payment data center, and a data format commonly used in the payment data center. Convert to Then, the data relating to each billing party is put together in a unit called a package. Here, the package is a unit of data sent from the member company to the same financial institution. Also,
The package is composed of a header section in which information necessary for sorting processing for exchange and transmission control is stored, and a body section in which billing content data for each individual member is stored. In the body part, data for a plurality of members is usually stored collectively. The data size of each of these packages is compressed by package compression (processing 304), and the settlement data center system 10 is transmitted by package transmission (processing 305, the second transfer request data transmission unit).
(FIG. 3). At this time, transmission / reception synchronization (process 352) performs synchronization control with the settlement data center system (A in FIG. 3). The conversion from the individual customer code to the settlement member code will be described later in detail.

Next, in FIG. 4, the package reception (processing 101, first transfer request data receiving unit) receives the package sent from the member company interface server 30 (FIG. 4) and decompresses the package (processing 102). Only the header part is decompressed and written to the data queue 110. The package extracted from the data queue 110 by the package distribution (process 103, the transfer request data distribution unit) is distributed to the destination financial institution while the body part is kept compressed, and is stored in the queue 15 for each financial institution. Written. Package extraction (Process 10
The package extracted from the financial institution queue 15 by 4) is transmitted to the destination financial institution interface server 50 by the package transmission (process 105, first transfer request data transmission unit) (FIG. 4). Here, “decompression” refers to a process of returning (decompressing) the compressed information to the state before compression.

In the package written in the data queue 110, the body part is also decompressed by the package decompression (processing 106), and the transaction information is updated (processing 107,
The transaction data update unit) uses this data to make the transaction data 1
1 is written. The transaction data 11 is an accumulation of individual statement data, and holds the contents of the transfer request from the member company by writing by this transaction information update (process 107). Note that transmission / reception synchronization (processing 152 and 15
3) is a member company interface server 30
And synchronous control with the financial institution interface server 50 (A and B in FIG. 4, respectively).

Next, in FIG. 6, the package reception (process 501, second transfer request data receiving unit) receives the package sent from the settlement data center system 10 (FIG. 4), and the package decompression (process 502) Decompress both the header and the body of the package. Then, the financial transaction message format conversion (process 503, second transfer request data format conversion unit) performs a deposit type and an account number for which the amount to be charged should be withdrawn based on the settlement member code and the member company code in the data. The name of the depositor (these three are collectively referred to as “member account identification information”) is determined by referring to the conversion table, and is converted into a data format for a financial institution system. Further, in the code conversion (process 504), after the character code is converted, writing to the data queue 510 is performed. The method for the financial transaction message format conversion to determine the deposit type, account number, and depositor name based on the settlement member code and the member company code will be described later in detail.

There are two ways of transferring data from the financial institution interface server 50 to the financial institution system 60. The first method is file output. In this case, the file output (process 505, third transfer request data transmission unit) outputs the data extracted from the data queue 510 as a file (FIG. 6). The output file is read in batches by the financial institution system and passed to the account transfer process. The second method is transaction execution. In this case, the transaction execution (process 506, third transfer request data transmission unit) divides the data extracted from the data queue 510 into appropriate units, and performs the account transfer processing as a real-time transaction. (FIG. 6). In both the case of the batch processing and the case of the real transaction, the result of the transfer processing is returned from the financial institution system 60 to the financial institution interface server 50.

In the financial institution system 60, transfer processing is performed based on the received transfer request data. Several types of patterns can be considered as the transfer processing method. The first pattern is to transfer funds directly from the member's account to the member company's account. The second pattern is a method of transferring funds from a member's account to a member company's account via a third party's account. Here, the “third party” is, for example, a company that operates a settlement data center. In either case, the withdrawal of funds from the member account and the deposit of funds into the member company account are performed synchronously. Here, "synchronous" does not necessarily mean "simultaneously" or "immediately", but means that a considerable amount is paid to the member company account after the payment from the member account is confirmed. By adopting such a method, unlike a conventional settlement system using a credit card or the like, the financial institution or the "third party" referred to here does not need to take the risk of irrecoverable funds. In addition, when transferring funds through a third party account, it is preferable for a member company to shorten the period in which funds are retained in the third party account, and transfer funds from a member's account to a third party's account. More preferably, the transfer of funds from the third party's account to the member company's account is on the same business day.

In the case of batch processing, the received transfer request data is collectively processed in the financial institution system 60. In addition, in the case of batch processing and in the case where data is passed as a real-time transaction from the financial institution interface server 50 to the financial institution system 60, a plurality of members (bill destinations) are provided between the member company system 40 and the financial institution interface server 50. Are transmitted and processed together as a file or a package. By taking such a method,
Unlike a conventional payment system using a credit card or a debit card, processing throughput can be improved.

Next, in FIG. 7, in the case of a real-time transaction, the transaction is executed (process 50).
6, the processing result data input unit) receives the result of the transfer processing (FIG. 7), and writes the data to the data queue 530. In the case of batch processing, file input (processing 521, processing result data input unit) is performed by the financial institution system 6.
Input the processing result data returned from 0 (FIG. 7),
Write to the data queue 530. In each of these cases, the processing result data includes the success /
The information includes the type of failure and data indicating the reason for failure. Here, the reasons for failure include, for example, "insufficient balance", "name mismatch", "account canceled", and the like.

Next, after character code conversion in code conversion (processing 522), message division and common format conversion (processing 52)
3. The first processing in the first processing result data format conversion unit) is to distribute the data of the successful transfer and the data of the failed transfer to different packages while referring to the processing result of each billing party. The second process is a conversion from a data format for a financial institution system to a common data format for a payment data center. The package created in this way is compressed in package compression (processing 524), and then transmitted to the settlement data center system by package transmission (processing 525, the second processing result data transmitting unit) (FIG. 7). Note that synchronization control is performed by transmission / reception synchronization (process 551) (B in FIG. 7).

As described above, the processing result data is
In the financial institution interface server, the transfer is divided into a package for a successful transfer and a package for a failed transfer.
Therefore, transmission and processing of these packages can be performed separately. For example, the package for the transfer failure is relatively small, and it is desired to return the package to the member company system as soon as possible, so that the package for the transfer failure can be preferentially processed. In this case, it is preferable to lower the processing priority of the package corresponding to the successful transfer, or to schedule the package to be processed when there is sufficient computer or network resources.

Next, in FIG. 8, the package reception (processing 121, first processing result data receiving unit) receives the package from the financial institution interface server (FIG. 8) and decompresses the package (processing 122) to the header section. Only the data is decompressed and written to the data queue 130.
The package extracted from the data queue 130 by the package distribution (processing 123, processing result data distribution unit) is distributed to each member company while the body part is kept compressed, and written to the member company-specific queue 16. The package extracted from the member company queue 16 by the package extraction (process 124) is
It is transmitted to the member company interface server 30 by package transmission (processing 125, first processing result data transmission unit) (FIG. 8).

The package written in the data queue 130 has its body also decompressed by package decompression (process 126), and the transaction result update (process 127, transaction data update unit) uses this data to transfer the transaction data 11 to the transaction data 11. Is written. The transaction data 11 has already been written based on the transfer request data at the stage of the transaction information update (step 107) in FIG. 4, and accordingly, this time, the discrimination between success / failure and the reason for failure have been performed. Record the data.

Next, in FIG. 9, package reception (step 321) receives the package from the settlement data center system (FIG. 9), and decompresses the package (step 32).
2) decompress it. In the public institution message format conversion (process 323), the settlement member code in the data is re-converted into the individual customer code unique to the member company, and is also converted into the data format unique to the member company. The details of the conversion from the settlement member code to the individual customer code will be described later. Then, this data is converted into a character code by the code conversion (processing 324),
Written to 0. Thereafter, based on the instruction from the output instruction (processing 353), the file output (processing 325) retrieves the processing result data from the data queue 330 and outputs it (FIG. 9). The file output here is read by the member company system 40 and used for the transfer request clearing process.

It is necessary to notify the member company system of the processing result data for the transfer failure including the reason for the failure. Therefore, the financial institution system—the interface server for the financial institution—the settlement data center system—the data for the member company It is essential to send the data from the interface server to the member company system, but the processing result data for the successful transfer is not necessarily required. For example, do not output the processing result data of the successful transfer at any stage of the financial institution system, the financial institution interface server, the settlement data center system, or the member company interface server, and do not send it to the next stage. You may do it. In such a case, in the processing on the side receiving the processing result data, the transfer processing is normally completed for the customer of the settlement member code (or individual customer code) not included in the transfer failure. Treated as

Next, data items transmitted in the above-described series of processing will be described. First, the transfer request data passed from the member company system is composed of data of the following items. That is, the header portion of the transfer request data includes the items of the designated transfer date (D0001), the member company code (D0002), the financial institution code (D0003), and the body portion includes the individual customer code (D1011), the charged amount (D0012). ) Is repeated for each customer.

The common format conversion shown in FIG. 3 (process 303)
When the data is converted into the common data format for the settlement data center system, the designated transfer date (D0001), member company code (D0002), and financial institution code (D0003) in the header portion are carried over as is, and the body portion is settled. The data including the member code (D0021) billing amount (D0012) is repeated for the number of members.

Here, the conversion from the individual customer code (D1011) to the settlement member code (D0021) will be described. FIG. 10 is a data relationship diagram showing a relationship between member company system side data and settlement data center system side data. As shown in FIG. 10, the member company interface server is provided with an individual customer code / settlement member code conversion table (first conversion table). The conversion table includes a member company code (D8002) and a customer individual code ( D8011), settlement member code (D8021)
And is realized as, for example, a table of a relational database. Here, an entity having a set of a member company code and an individual customer code as a key has a one-to-one correspondence with an entity having a set of a member company code and a settlement member code as a key.
It is possible to perform bidirectional conversion using the above conversion table.

The transfer request data in this common data format is converted into the financial transaction message format shown in FIG.
When the data format is further converted to the data format for the financial institution system by 3), the header portion is inherited again as it is, and the body portion is the type of deposit (D2013) Account number (D2014) Name of depositor (D2015) Payment member code (D0021) The data including the item of (D0012) is repeated for the number of members. The deposit type is, for example, data indicating a distinction between an ordinary deposit, a checking account, a savings deposit, a notice deposit, and the like.

Here, a method of adding a deposit type (D2013), an account number (D2014), and a name of a depositor (D2015) will be described. FIG. 11 is a data relationship diagram showing the relationship between the settlement data center system-side data and the financial institution system-side data. As shown in FIG. 11, the financial institution interface server is provided with a settlement member code / account information conversion table (second conversion table), and this conversion table includes a settlement member code (D802).
1), a member company code (D8002), a financial institution code (D8003), a deposit type (D8013), an account number (D8014), and a depositor name (D8015). I have. By referring to this table, it is possible to determine the deposit type, account number, and name of the depositor from the settlement member code and the member company code.

The processing result data output from the financial institution system is, like the transfer request data, the transfer specified date (D0
001), the member company code (D0002), and the financial institution code (D0003) in the header section, and the body section contains the settlement member code (D0021) The amount charged (D0012) The transfer result (D2113) The reason why transfer is not possible (D2114) Is repeated for the number of members. Of these, the settlement member code (D0021) is shown in FIG.
Is converted back to the individual customer code (D1011) using the individual customer code / settlement member code conversion table shown in FIG. It should be noted that the transfer result (D2113) is data representing the distinction between “transfer success” and “transfer failure”, and the transfer impossible reason (D2114) is data representing the reason in the case of “transfer failure”.

Since the billing amount (D0012) is known on the member company system side and the settlement data center system, it may be omitted on the transmission data. In addition, since the data for the successful transfer and the data for the failed transfer are managed in separate packages, the transfer result (D2113) and the reason why the transfer is impossible (D2114) are omitted for the data for the successful transfer. No problem.

In addition, new registration / change / withdrawal of a member, registration / change / deletion of a financial institution account for settlement for each member, registration / change / deletion of a member company of a payee for each member, new registration of a financial institution, etc. Registration / change / deletion, new registration / change /
At the time of deletion, etc., various master data such as member master, member company master, financial institution master, account master, etc. on the settlement data center system are updated, and accordingly, the interface server for member companies and financial institution The conversion table and various master data used in the interface server are also updated.
In order to realize such a synchronous update of the master data and the conversion table, an application program that updates all related data as necessary may be used, or a database management system (DBMS,
The replication function and the trigger function of the Database Management System) may be used. here,
The replication function is used between multiple databases.
This function automatically reflects operations (insertion, deletion, update, etc.) on data in one database in another database. Further, the trigger function is a function of detecting when a data operation is performed in a certain database and executing a procedure defined in advance in the database or another database.

Also, various master data and conversion tables on the member company interface server have only data relating to the customers (members) of the member company, and do not have data for other member companies. good. Similarly, the various master data and the conversion table on the financial institution interface server may have only data relating to members who have accounts at the financial institution, and may not have data for other financial institutions. As a result, the storage capacity on each interface server can be saved, and the transmission amount for updating data can be saved,
Also, information leakage between member companies or between financial institutions can be prevented.

Next, confirmation of the state of the package being processed will be described. FIG. 5 is a block diagram showing a functional configuration for checking a package state. As shown in FIG. 5, the settlement data center system 10 has a status monitoring file 17 and a package status confirmation process 171. The status monitoring file 17 holds the progress status of the process for each package as a value, and the status value is updated each time the process of a predetermined unit is completed. Here, the processing monitored by the status monitoring file 17 is not limited to the processing in the settlement data center system 10. For example, the processing status of the member company and financial institution interface servers may be updated by receiving communication from each server. Further, the status may be updated by receiving a communication from a member company system or a financial institution system.

The package processing confirmation processing 171 has a function of referring to the state monitoring file 17 in response to an inquiry from the outside and replying to the state of the package. In the example shown in FIG. 5, the system terminal 41 installed in the member company office 8 can inquire and confirm the package state to the package state confirmation processing 171 through the member company system 40. In addition, an inquiry to the package status confirmation processing 171 may be made not only from the member company office but also from another location. For example, the package status can be confirmed from a terminal in a settlement data center or a financial institution. You may do it. As described above, the status monitoring file 17 is provided to automatically update the status of the package. Therefore, compared with the case where data is exchanged by magnetic tape using the conventional technology, the status is quickly and without human intervention. It becomes possible to grasp the processing state.

Next, the flow of the correction processing of the transfer request data will be described. FIG. 12 is a block diagram illustrating a functional configuration for a transfer request data correction process. As shown in FIG. 12, the member company system 40 performs the fund transfer correction request processing 481, the settlement data center system 10 performs the correction data reception processing 181 (first correction data reception unit), and the financial institution interface server 50 stores the correction data. It has a receiving process 581 (second correction data receiving unit). When the transfer contents need to be corrected after the transfer request data has been transmitted from the member company system 40 to the member company interface server 30, the person in charge at the member company office 8 performs, for example, the aforementioned package state confirmation processing. After confirming the state of the package by the
Input the correction data to the fund transfer correction request processing 481. The correction data is transmitted from the fund transfer correction request processing 481 to the correction data reception processing 181, and the correction data reception processing 181 updates the transaction data based on the correction data.

The correction data is further transmitted from the correction data reception processing 181 to the correction data reception processing 581. The correction data reception processing 581 writes the correction data in the data queue 580 on the financial institution interface server 50. Conversion of financial transaction message format (Process 50
3) examines the contents of the data queue 580 when processing the transfer request data sent by the normal route based on the instruction from the transaction start instruction (processing 552) on a package basis, and corrects the data related to the package. Is determined, and if so, the data is corrected using the corrected data, and then data in a financial institution system format is created. Therefore, on the financial institution system 60 side, the account transfer process can be performed based on the data reflecting the correction.

By providing such a mechanism for correcting the billing transfer data, the correction can be performed quickly and without human intervention as compared with the conventional method described with reference to FIG.

The transfer process for settlement has been described above. The following describes the member registration process and the change process which are the premise of such transfer process. FIG.
FIG. 5 is a reference diagram showing a flow of a contract application for using a settlement data processing service, registration of a customer code for each member company and account information of a financial institution, and notification of various changes.

As shown in FIG. 13, a member who has become a member
First, the account from which the fee is to be transferred is registered. The settlement data center system 10 acquires information such as a financial institution code, a deposit type, and an account number as information necessary for account registration, stores the information in the system, and registers the account with the financial institution. And a request to verify the account data. In response, the financial institution 5 checks the account data and returns the result to the settlement data center system 10. The member also registers the requesting member company. The settlement data center system 10 acquires information such as a member company code and an individual customer code as information necessary for registration of a billing member member company, and together with such information, a member's financial institution account of the member is already registered. Register one as a transfer account with this member company. Then, the settlement data center system 10 and the member company 3 collate the individual customer code (customer code) and the like. A similar process is performed when a member changes or adds a financial institution account or a billing member company.

In FIG. 13, the exchange of information between the member 2 and the settlement data center system 10 may be performed by data communication via a data network such as the Internet, by mailing documents, or the like. Alternatively, the call may be made by telephone. Similarly, the exchange between the settlement data center system 10 and the member company 3 or the financial institution 5 may use data communication by a computer,
Documents may be used.

Member 2 and settlement data center system 10
Next, an example of a case in which information is exchanged with the data communication is described. FIG. 14 is a diagram showing an example of a screen on the member terminal for registering the member's account for financial institution for settlement. It is assumed that the authentication process using the settlement member code has been completed before the screen transitions to the screen of FIG. The member inputs or selects data in the fields 801 to 804 of this screen, and then presses a button 805 displayed as “register” to register an account. FIG. 15 is a diagram showing an example of a screen on a member terminal for registering a member company as a billing source. Similarly to the above, it is assumed that the authentication processing has been completed before the screen of FIG. 15 is displayed. The member can use the fields 81 on this screen.
By entering or selecting data on the member company in 1 and 812, selecting from among the registered financial institution accounts in the field 813, and pressing the button 815 labeled "register" by pressing the button 815 of the member company. Register.

Since the transaction data 11 of the settlement data center system 10 even stores the data of the detail level for each member, an electronic statement is created using this data and displayed on the member terminal. You may do it. FIG.
FIG. 4 is a diagram showing an example of a screen of such an electronic statement on a member terminal. As shown in FIG. 16, in the electronic specification according to the present embodiment, the transfer date and the billing amount for each of the “next” and “previous” are displayed in a table format for each member company of the billing source. Further, by pressing a button labeled "Details", a transition is made to another screen (not shown), and detailed data relating to the billed amount is displayed. Also,
The status of the “last time” bill is also displayed, and the transfer result (D211) of the processing result data described above is displayed.
For example, information such as “completed” (transfer succeeded) or “insufficient balance” (transfer failed) is displayed based on 3) and the transfer impossible reason (D2114).

Incidentally, regarding this electronic specification, FIG.
Not only the example shown in FIG. As an example, past billing amounts over a longer period may be displayed in chronological order. Further, as another example, the increase / decrease tendency of the billing amount, the unique value, and the like may be graphically displayed using a graph, a symbol, or an icon.

The electronic statement function as described above is provided by EB
Although the system is a part of the PP (Electronic Bill Presentment and Payment) technology, the system of the present invention has the following features as compared with the configuration which is already known regarding the EBPP. The first feature is to realize a network that does not need to collect data for preparing a statement separately from data exchange using a magnetic tape, which is conventionally performed, and does not require data exchange using a magnetic tape.
The point is that data is accumulated in the course of data flow on the network and is used for preparing a specification. Such a method makes it possible to reduce the overall system cost. The second feature is that, instead of performing settlement (transfer processing) triggered by individual transaction instructions by members (general customers), automatic (for example, monthly) transfer processing is performed automatically in accordance with the contents registered by the member in advance. The point is to do it. With this method, the trouble of the member can be saved, and the payment delay due to the forgetting of the transaction instruction can be prevented.

Next, a second embodiment according to the application of the present invention will be described. FIG. 17 is a configuration diagram showing a system configuration for online shopping and card shopping according to the same embodiment. In the case of online shopping, in FIG. 17, the member 2 accesses the online shopping system 44 from the member terminal 21 to make a shopping, and inputs a settlement member code (identification information) for settlement. Then, the information of the amount and the settlement member code is transferred from the online shopping system to the member company system 40 in the member company 3. In the case of card shopping, the member goes to the retail store 7 with the card (recording medium) on which the settlement member code (identification information) is recorded and makes a purchase. The settlement member code is read and passed to the member company system 40 in the member company 3 together with the amount information. The member company system 40 creates transfer request data based on these pieces of information. Since the subsequent processing flow is basically as described above, a detailed description is omitted here.

The cards used for card shopping include, for example, magnetic cards and IC cards, but are not limited thereto. These cards may be replaced by a recording medium in which the payment member code is recorded in a computer-readable form, or a device incorporating such a recording medium.

Note that utility bills such as electric power, gas, and telephone are billed at regular intervals (for example, every month), whereas the transactions of online shopping and card shopping described here occur irregularly. Therefore, as shown in FIG. 17, the settlement data center system 10 may request the member to confirm withdrawal.

Although the embodiments of the settlement system and the settlement method have been described above, the implementation method of the present invention is not limited to the above embodiments. For example, for the purpose of improving data transmission efficiency, etc., information compression is performed between the settlement data center system and the interface servers for member companies and financial institutions, but this is not essential, and compression is not performed. May be. Further, for example, of the header and the body constituting the package, only the body may be compressed and the header may be transmitted without being compressed. For the purpose of improving security, data transmitted between the settlement data center system and the interface servers for member companies and financial institutions may be subjected to encryption processing.

In the above embodiment, the settlement data center and the member company interface server, the financial institution interface server, and the member terminal are connected via the Internet. However, the present invention is not limited to the Internet. Other networks may be used. The other network is, for example, a LAN (Local Area Network).
rk), a dedicated line, a fixed or mobile public telephone network, a local telephone subscriber line, a wireless network, a network using a cable for CATV, or a composite thereof.

Note that the above-described settlement data center system, member terminal, member company interface server, member company system, financial institution interface server, financial institution system, online shopping system, and the like are realized by a computer system. Then, the process of each process described above is stored in a computer-readable recording medium in the form of a program,
The above processing is performed by the computer reading and executing this program. Here, the computer-readable recording medium includes, for example, a floppy (registered trademark) disk, a magneto-optical disk, a CD-ROM, a magnetic tape, a magnetic hard disk, a semiconductor memory, and the like, but is not limited thereto.

Further, the above-described settlement data center system, member terminal, member company interface server, member company system, financial institution interface server, financial institution system, online shopping system, etc. may be constituted by a single computer. Alternatively, the functions may be distributed among a plurality of computers. Conversely, all or some of these systems may be integrated into another system and implemented on a computer.

[0093]

As described above, according to the present invention, since the transfer request data and the processing result data are exchanged via the settlement data center via the network, quick processing is possible, and the processing until the completion of the settlement is possible. The time can be shortened, and a handling process including sorting of magnetic tapes by destination in the member company and the financial institution becomes unnecessary, and a low-cost settlement system and settlement method can be realized.

Further, according to the present invention, the settlement member code commonly used in the center system is used for identification of the member, and the settlement member code and the customer code unique to the member company or the financial system are converted by the conversion process using the conversion table. Institution account identification information (deposit type, account number, name of depositor)
Therefore, the data transmitted between the center system and the interface system for the member company or between the center system and the interface system for the financial institution via the network can not include the customer code and the account identification information. . In addition, thereby, the processing speed can be improved by reducing the amount of data transmission on the network, and at the same time, the risk of the customer code and the account identification information leaking in the network can be avoided.

Further, according to the present invention, since the processing result data returned from the financial institution as a result of the transfer processing is separately processed into a transfer success part and a transfer failure part, it is required early for the member companies and the like. Processing result data for transfer failure can be preferentially handled. In addition, by performing such separate processing, the processing result data having a relatively large data amount but having a low priority is not returned to the member company, and the processing result data can be relatively stored in the network or the computer. It is also possible to adopt a processing mode in which processing is performed in a time zone where there is enough time.

Further, according to the present invention, since the interface system for the member company and the financial institution is provided, the settlement system is realized by minimizing the modification of the member company system and the financial institution system according to the prior art. be able to.

Further, according to the present invention, since information based on the transfer request data is stored in the center system at a detailed level as transaction data, members can refer to this information via a network or the like. it can. In addition, it becomes possible to provide an electronic statement to a member or the like based on the transaction data.

According to the present invention, since the transaction data is updated based on the processing result data returned from the financial institution as a result of the transfer processing, when the information is provided by an electronic statement or other means, It is also possible to provide information such as a distinction between success / failure of the transfer and a reason for the transfer failure in the case of the transfer failure.

According to the present invention, the correction data sent from the member company is accepted by the center system and the interface system for financial institutions, and is reflected in the transaction data and the transfer request data before being sent to the financial institution system. Therefore, even after the transmission and exchange processing of the created normal transfer request data is started, the data can be corrected without much trouble.

Further, according to the present invention, in the center system, the first transfer request data receiving section receives the transfer request data in a state where the information is compressed, and the transfer request data distribution section determines at least one of the transfer request data. The unit distributes the transfer request data in a state where the information is compressed, so that the process of expanding and recompressing the information can be reduced, and resources such as memory and storage devices required during the transfer process are reduced. It is possible to save money.

Further, according to the present invention, the transfer request data created by the member companies and distributed to each financial institution and used in the transfer process is a unit of bills to a plurality of members, and Since processing is performed in units, processing throughput can be increased as compared with the case where processing is performed as a transaction for each member. This effect is particularly large when processing a large amount of data.

Further, according to the present invention, since the withdrawal of funds from the account of the member and the deposit of money into the account of the member company at the financial institution are performed synchronously, unlike a conventional settlement system using a credit card, There is no need for institutions or third parties to risk irretrievable funds from members.

Further, according to the present invention, the member creates transfer request data based on shopping performed by using the recording medium on which the identification information of the member is recorded, or the member uses the identification information of the member. Transfer data is created based on shopping performed via a network, and payment using such transfer request data can be performed. Therefore, the payment system and the payment method according to the present invention can be used for card shopping and online shopping. Can also be applied.

According to the present invention, the status monitoring file is provided so that the status of the package is automatically updated. Therefore, compared with the case where data is exchanged by magnetic tape using the conventional technique, Thus, the processing state can be quickly grasped without human intervention.

[Brief description of the drawings]

FIG. 1 is a configuration diagram showing a configuration of a payment system according to an embodiment of the present invention.

FIG. 2 is a reference diagram showing an outline of processing relating to a settlement data center system according to the embodiment.

FIG. 3 is a sequence diagram showing a flow of transfer request data in the member company interface server according to the embodiment.

FIG. 4 is a sequence diagram showing a flow of transfer request data in the settlement data center system according to the embodiment.

FIG. 5 is a block diagram showing a configuration for a package state confirmation function according to the embodiment;

FIG. 6 is a sequence diagram showing a flow of transfer request data in the financial institution interface server according to the embodiment.

FIG. 7 is a sequence diagram showing a flow of processing result data in the financial institution interface server according to the embodiment;

FIG. 8 is a sequence diagram showing a flow of processing result data in the settlement data center system according to the embodiment.

FIG. 9 is a sequence diagram showing a flow of processing result data in the member company interface server according to the embodiment.

FIG. 10 is a data relationship diagram showing a relationship between member company system side data and settlement data center system side data according to the embodiment.

FIG. 11 is a data relationship diagram showing a relationship between settlement data center system-side data and financial institution system-side data according to the embodiment.

FIG. 12 is a block diagram showing a configuration for a transfer request data correction function according to the embodiment;

FIG. 13 is a reference diagram showing a flow of registration and the like of member-specific information in the settlement system according to the embodiment.

FIG. 14 is a diagram showing an example of a screen on a member terminal for registering a financial institution account for settlement according to the embodiment.

FIG. 15 is a diagram showing an example of a screen on a member terminal for registering a billing source member company according to the embodiment.

FIG. 16 is a diagram showing an example of a screen on the member terminal of the electronic statement according to the embodiment.

FIG. 17 is a configuration diagram showing an additional configuration for online shopping and card shopping according to another embodiment of the present invention.

FIG. 18 is a reference diagram showing a method of exchanging fee transfer data using a magnetic tape according to the related art.

And FIG. 19 is a sequence diagram showing a flow of processing for changing the contents of a claim according to the conventional technique.

[Explanation of symbols]

 0 Internet 1 Payment data center 2 Member 3 Member company 5 Financial institution 7 Retail store 8 Member company office 9 Financial institution branch 10 Payment data center system 11 Transaction data 12 Member master 13 Member company history data 14 Member history data 15 Financial institution Separate queue 16 Member company queue 17 Status monitoring file 21 Member terminal 30 Member company interface server 40 Member company system 41 System terminal 44 Online shopping system 50 Financial institution interface server 60 Financial institution system

 ────────────────────────────────────────────────── ─── Continuing on the front page (72) Inventor Masahiro Toyoshima 4-1 Kioicho, Chiyoda-ku, Tokyo New Otani Garden Court Inside Oracle Japan Co., Ltd. (72) Inventor Yoshiyuki Goto 4-1 Kioicho, Chiyoda-ku, Tokyo -Otani Garden Court Japan Oracle Corporation (72) Inventor Masatoshi Tomina 4-1 Kioicho, Chiyoda-ku, Tokyo New Otani Garden Court Japan Oracle Corporation F-term (reference) 5B055 BB16 CB09 EE12 EE21 EE27

Claims (33)

[Claims] 1. A center system for executing data processing for performing settlement of a billing amount from a member company to a member by transfer processing between a member account and a member company account in a financial institution. A first transfer request data receiving unit that receives transfer request data created by the member company systems of the plurality of member companies; and a transfer request data distribution unit that distributes the transfer request data to a plurality of destination financial institutions. And a first transfer request data transmission unit for transmitting the transfer request data distributed by the transfer request data distribution unit to a destination financial institution. 2. A first process result data receiving unit that receives process result data output as a result of a transfer process performed by a financial institution system of the financial institution based on the transfer request data transmitted by the first transfer request data transmitting unit. A processing result data distribution unit that distributes the processing result data to a plurality of billing source member companies; and the processing result data distributed by the processing result data distribution unit is transmitted to the requesting member company. The center system according to claim 1, further comprising: a first processing result data transmitting unit that performs the processing. 3. The system according to claim 1, further comprising transaction data for holding information based on the transfer request data for each of the member companies, for each of the members, and for each of the designated transfer dates.
The center system described in 1. 4. The transaction data holds information based on the processing result data for each of the member companies, for each of the members, for each of the designated transfer dates, and in association with the information based on the transfer request data. The center system according to claim 3, wherein: 5. A first correction data receiving unit that updates the transaction data based on correction data sent from a member company for the purpose of correcting the transfer request data and sends the correction data to a financial institution. The center system according to claim 3, wherein the center system is provided. 6. The center system according to claim 3, wherein electronic statement data is created for each of said members based on said transaction data and transmitted to a terminal device. . 7. The transfer request data receiving unit receives the transfer request data in a state where the information is compressed, and the transfer request data distribution unit determines that at least a part of the transfer request data is compressed. The center system according to any one of claims 1 to 6, wherein the transfer request data is sorted in the state of (1). 8. The center according to claim 1, wherein the transfer request data data transmitted by the first transfer request data transmitting unit does not include account number information of the member. system. 9. The first processing result data transmitting unit transmits a transfer result indicating either “transfer success” or “transfer failure” in the processing result data received by the first processing result data receiving unit. 9. The center system according to claim 2, wherein only the data of "transfer failure" is selectively transmitted. 10. A data transfer system for transferring data between a member company and a member company account at a financial institution to settle a billed amount from a member company to a member. An interface system for a member company that mediates between the member company system that generates billing data, a transfer request data input unit that inputs the transfer request data generated by the member company system, and the transfer request data. A first transfer request data format conversion unit for converting a format for a member company system into a common format, and a second transfer request data for converting the transfer request data converted by the first transfer request data format conversion unit to the center system. And a transfer request data transmitting unit. . 11. The first transfer request data format conversion, comprising: a first conversion table for holding a relationship between an individual customer code uniquely used by each of the member companies and a settlement member code commonly used in the center system. 11. The member company interface system according to claim 10, wherein the unit converts the individual customer code in the transfer request data into the settlement member code based on the first conversion table. 12. The member company interface according to claim 10, wherein the transfer request data transmitted by the second transfer request data transmitting section does not include account number information of the member. system. 13. A data transfer system for transferring data between a member company and a member company account at a financial institution for settlement of a billing amount from a member company to a member. An interface system for a financial institution that mediates with a financial institution system that performs processing, a second transfer request data receiving unit that receives transfer request data sent from the center system, A second transfer request data format converter for converting a common format commonly used in the system into a format for a financial institution system; and transferring the transfer request data converted by the second transfer request data format converter to the financial institution system. And a third transfer request data transmitting unit for transmitting to the third party Institutional interface system. 14. A second conversion table for holding a relationship between a settlement member code commonly used in the center system for member identification and member account identification information for identifying an account of the member, wherein the second transfer is performed. 14. The claim data format conversion unit according to claim 13, wherein the member account identification information is added to the transfer request data based on the settlement member code in the second conversion table and the transfer request data. Interface system for financial institutions. 15. A processing result data input unit for acquiring processing result data output as a result of a transfer process performed by the financial institution system based on the transfer request data transmitted by the third transfer request data transmitting unit; A first processing result data format conversion unit for converting the result data from a format for a financial institution system to a common format commonly used in a center system; and a processing result data converted by the first processing result data format conversion unit. 15. The financial institution interface system according to claim 13, further comprising a second processing result data transmitting unit that transmits the data to the center system. 16. The first processing result data format conversion unit performs “transfer success” based on a transfer result indicating “transfer success” or “transfer failure” in the processing result data.
The interface system for a financial institution according to claim 15, wherein the data of "transfer failure" and the data of "transfer failure" are sorted. 17. The second processing result data transmitting unit,
17. The interface system for a financial institution according to claim 16, wherein data of "transfer success" and data of "transfer failure" are transmitted separately. 18. The second processing result data transmitting unit,
18. The financial institution interface system according to claim 16, wherein data of "transfer failure" is transmitted with priority over data of "transfer success". 19. The second processing result data transmitting section,
Of the "Transfer success" data and "Transfer failure" data,
18. The financial institution interface system according to claim 16, wherein only data of "transfer failure" is transmitted. 20. A second correction data receiving unit for receiving correction data sent from a member company for the purpose of correcting the transfer request data, and based on the correction data received by the second correction data receiving unit. 20. The financial institution interface system according to claim 13, wherein the transfer request data is corrected. 21. A settlement system for executing data processing for performing settlement of a billing amount from a member company to a member by transfer processing between the account of the member and the account of the member company in a financial institution. Transfer request data output from the member company system of the member company is input, and the transfer request data is converted into one common member data in a common format used by all the member companies. An interface system for member companies that is output as a unit, and transfer request data that is output from a plurality of the interface systems for member companies are input, and the transfer request data is retained internally and distributed to a plurality of financial institutions. A settlement data center system for outputting to the destination financial institution; A financial institution interface system for inputting transfer request data output from the data center system, adding member account identification information for identifying each of the member accounts to the transfer request data, and outputting the data. Payment system. 22. The transfer request data is transmitted to a network in at least one of the interface system for member companies and the settlement data center system or between the settlement data center system and the interface system for financial institutions. 22. The settlement system according to claim 21, wherein the transfer request data in the common format does not include the member account identification information. 23. The financial institution interface system, with regard to the processing result data output as a result of the processing at the financial institution based on the transfer request data, gives priority to data of “transfer failure” over data of “transfer success”. 23. The settlement system according to claim 21, wherein the payment is processed. 24. The interface system for a financial institution transmits only “transfer failure” data to a member company with respect to the processing result data output as a result of the processing at the financial institution based on the transfer request data, The settlement system according to any one of claims 21 to 23, wherein the data of "successful transfer" is not transmitted to the member company. 25. A settlement method for performing settlement of a billing amount from a member company to a member by using a computer network, comprising receiving transfer request data including a plurality of bills for the member from a plurality of member companies. A first step, a second step of distributing the received transfer request data according to the financial institution for settlement of the member, and a method of withdrawing funds from the account of the member based on the allocated transfer request data. A third step of synchronously depositing funds into an account of a member company. 26. The method according to claim 25, wherein in the third step, a process of directly depositing funds withdrawn from the member's account into the member company's account is performed.
Payment method described in. 27. The method according to claim 27, wherein in the third step, a process of depositing funds withdrawn from the member's account into the member company's account via a third party's account is performed. 25. The settlement method according to 25. 28. The transfer request data in the first step is created based on shopping performed by the member using a recording medium on which the identification information of the member is recorded. 28. The settlement method according to any one of claims to 27. 29. The transfer request data in the first step is created based on shopping performed by the member via a network using the identification information of the member. Settlement method according to any of the above. 30. A data processing method for performing settlement of a billed amount from a member company to a member by transfer processing between the account of the member and the account of the member company in a financial institution, wherein: A step of receiving transfer request data created by the member company system of the member company; a step of distributing the transfer request data to a plurality of destination financial institutions; and a step of distributing the allocated transfer request data to the destination. Transmitting to a financial institution; and a data processing method. 31. A data processing method for performing settlement of a billing amount from a member company to a member by a transfer process between the account of the member and the account of the member company in a financial institution, the method comprising: Inputting the transfer request data generated by the member company system, converting the transfer request data from the member company system format to a common format, and converting the transfer request data converted into the common format into data. Transmitting the data to a center system that performs an exchange process. 32. A data processing method for performing settlement of a billing amount from a member company to a member by a transfer process between the account of the member and the account of the member company in a financial institution, comprising: a data exchange process. Receiving the transfer request data sent from the center system that performs the transfer, and converting the transfer request data from a common format commonly used in the center system to a format for a financial institution system. Transmitting the transfer request data converted to the financial institution system to the financial institution system. 33. A data processing method for performing settlement of a billing amount from a member company to a member by a transfer process between a member account and a member company account at a financial institution, wherein the member company Transfer request data output from the member company system is output, and the transfer request data is output as one unit in the form of a common format commonly used by all the member companies. A first step, inputting the transfer request data output in the first step, holding the transfer request data, distributing the transfer request data to each of a plurality of financial institutions, and outputting the data to the destination financial institution; Inputting the transfer request data output in the second step, and inputting the transfer request data A third step of adding and outputting member account identification information for identifying each of the member accounts, and outputting the same.