JP6114656B2 - Non-payable information processing apparatus and non-payable information processing method - Google Patents

Description

  The present invention relates to a non-payable information processing apparatus and a non-payable information processing method.

Electronically recorded receivables that manage receivables electronically are used (see Patent Document 1). With electronically recorded receivables, there is no need to manage paper receivables such as bills, which can reduce the burden on administrators and reduce receivable management costs.
Here, there is a method of penalizing the debtor when the payment is not made as a method for ensuring the payment of the electronic record receivable. For example, in Densai Net's insolvency disposal system, if the electronically recorded receivables are not paid on the due date for reasons attributable to the debtor, a notice of inability to pay is notified to all participating financial institutions. Furthermore, when the second insolvency occurs, the use of electronically recorded receivables as borrowers and lending transactions at all participating financial institutions will be suspended.

JP 2012-14300 A

  With Densai Net's insolvency disposition system, all institutional financial institutions are notified of insolvency notifications. Will also receive. In particular, if the number of insolvency notifications referred to by the person in charge of the financial institution is large, the attention of the person in charge may be dispersed and the attention to the insolvency notice that is highly important for the financial institution may be insufficient. is there.

  The present invention has been made in consideration of such circumstances, and the purpose of the present invention is that a person who refers to insolvency information indicating that payment of an electronic financial receivable has not been made is important for the importance of the insolvency information. It is an object of the present invention to provide a non-payable information processing apparatus and a non-payable information processing method capable of more reliably grasping.

  The present invention has been made to solve the above-described problems, and the insolvent information processing apparatus according to one aspect of the present invention has become incapable of payment based on the insolvency notification transmitted by the recording institution of the electronic record receivable. A destination financial institution information acquisition unit that acquires information of a destination financial institution of the electronically recorded receivable; a financial institution determination unit that determines whether the destination financial institution is a predetermined financial institution based on the information of the destination financial institution; A debtor information acquisition unit that acquires information on a debtor of an electronically recorded claim that has become unpaid based on the insolvency notification, and based on the debtor information, the debtor An account presence / absence determination unit that determines whether or not the user has an account, and an output unit that outputs the determination result of the financial institution determination unit and the determination result of the account presence determination unit.

  An insolvent information processing apparatus according to an aspect of the present invention is the insolvent information processing apparatus described above, wherein the electronic record receivable that has become insolvent is in the business area of the destination financial institution and the business of the predetermined financial institution. An overlap condition evaluation unit that evaluates the overlap condition with the service area is provided, and the output unit displays an evaluation result of the overlap condition evaluation unit.

  An insolvent information processing apparatus according to an aspect of the present invention is the insolvent information processing apparatus described above, wherein the location of the debtor of the electronic record receivable that has become unpaid is a business area of the predetermined financial institution. Including an inclusion determination unit that determines whether or not it is included in the output, and the output unit displays a determination result of the inclusion determination unit.

  Further, the insolvent information processing apparatus according to one aspect of the present invention obtains information on a destination financial institution of an electronic record receivable that has become incapable of payment based on a notice of inability transmitted by the recording institution of the electronic record receivable. Based on the information of the institutional information acquisition unit, the destination financial institution, the financial institution determination unit for determining whether or not the destination financial institution is a predetermined financial institution, and the insolvency notification based on the insolvency notification An obligor information acquisition unit that acquires information on the debtor of the electronically recorded loan, and an account presence determination unit that determines whether the obligor has an account in the predetermined financial institution based on the information of the obligor And the determination result of the financial institution determination unit and the determination result of the account presence determination unit when the destination financial institution is the predetermined financial institution and the destination financial institution is a financial institution other than the predetermined financial institution. is there A display data generation unit for generating display data to be displayed in the same display mode for the mixture, characterized by comprising an output unit that outputs the display data.

  The non-payable information processing method according to one aspect of the present invention is an unpaid information processing method for an unpaid information processing apparatus, and becomes non-payable based on a non-payment notice transmitted by a recording organization of electronic record receivables. A destination financial institution information acquisition step for acquiring information on the destination financial institution of the electronic record receivable, and a financial institution determination step for determining whether the destination financial institution is a predetermined financial institution based on the information on the destination financial institution A debtor information acquisition step of acquiring information on the debtor of the electronically recorded claim that has become unpaid based on the insolvency notification, and based on the information on the debtor, the debtor An account presence / absence determination step for determining whether or not the institution has an account, an output step for outputting the determination result at the financial institution determination step and the determination result at the account presence determination step. Characterized in that it comprises Tsu and up, the.

  According to the present invention, a person who refers to insolvency information can more reliably grasp the importance of the insolvency information.

It is a schematic block diagram which shows the apparatus structure of the electronic record loan system in one Embodiment of this invention. It is a schematic block diagram which shows the function structure of the relay apparatus in the embodiment. It is explanatory drawing which shows the example of the data structure of the remittance settlement information between accounts memorize | stored in the remittance settlement database between accounts in the embodiment. It is explanatory drawing which shows the example of the data structure of the payment failure notification management information which the payment failure notification management database in the embodiment memorize | stores. It is explanatory drawing which shows the example of the data structure of the address management information which the address management database in the embodiment memorize | stores. It is explanatory drawing which shows the example of the data structure of the payment failure history information which the payment failure history database in the embodiment memorize | stores. It is explanatory drawing which shows the example of the data structure of the payment impossible log | history (own bank account) information which the payment failure log | history (own bank account) database memorize | stores in the embodiment. It is explanatory drawing which shows the example of the data structure of the payment failure history information management information which the payment failure history information management database in the embodiment memorize | stores. It is explanatory drawing which shows the example of the data structure of the payment failure management information which the payment failure management database in the embodiment memorize | stores. It is explanatory drawing which shows the example of the data structure of the contractor information which the contractor database in the embodiment memorize | stores. It is explanatory drawing which shows the example of the data structure of the account information which the account information database in the embodiment memorize | stores. It is explanatory drawing which shows the example of the data structure of the account information which the account information database in the embodiment memorize | stores. In the embodiment, it is explanatory drawing which shows the example of the search condition input area | region which a person in charge terminal device displays. In the same embodiment, it is explanatory drawing which shows the example of the list of the search result of the payment failure log | history which a person in charge terminal device displays. In the same embodiment, it is explanatory drawing which shows the example which displayed the insolvent case in the same display mode, without the person-in-charge terminal device performing highlighting. In the same embodiment, it is explanatory drawing which shows the example of the notification information which a person in charge terminal device displays. In the embodiment, it is explanatory drawing which shows the example of the nonpayable user information which a person in charge terminal device displays. In the embodiment, it is explanatory drawing which shows the example of the own line information which a person in charge terminal device displays. It is explanatory drawing which shows the example of the flow of the settlement process of an electronic record receivable and the non-payment registration process in the embodiment. It is explanatory drawing which shows the example of the process at the time of payment non-payment in the same embodiment, and the flow of non-payment history search processing. In the same embodiment, it is a flowchart which shows the example of the process sequence in which the log | history production | generation part produces | generates the additional information of payment failure log | history information. In the same embodiment, it is a flowchart which shows the example of the process sequence in which the log | history production | generation part produces | generates the additional information of an insolvency log | history (own bank account) information. In the same embodiment, it is a flowchart which shows the example of the procedure of the process which an online process part performs in the case of the search of a payment failure log | history.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 is a schematic configuration diagram showing an apparatus configuration of an electronic record bond system according to an embodiment of the present invention. In FIG. 1, the electronic record credit system 1 includes a relay device 10, a person-in-charge terminal device 21, an approval authority terminal device 22, and a server device 30.
The relay apparatus 10 includes a financial institution communication circuit 11, a recording institution communication circuit 12, a storage device 13, and a CPU (Central Processing Unit) 14.
The person-in-charge terminal device 21 and the approval authority terminal device 22 constitute a client device 20.

The electronic record receivable system 1 is a system for handling electronic record receivables (receivables whose requirements are the generation and transfer of electronic records in the record book).
The server device 30 is installed in a recording organization for electronic record receivables and manages a record book of electronic record receivables. In particular, the server device 30 updates the record book based on a record request from a company (may be an individual business operator) or a financial institution using the electronic record credit system 1. Hereinafter, a company that uses the electronic record credit system 1 is referred to as a “user”. A financial institution that uses the electronic record credit system 1 is referred to as a “participating financial institution”.

In addition, the server device 30 notifies various information such as a reception result notification such as a recording request and a notification of the occurrence of an electronic recording receivable to a company or a financial institution using the electronic recording receivable system 1. Various notifications from the server device 30 to a company or financial institution using the electronic record credit system 1 are made via the relay device 10 as shown in FIG. Similarly, various requests from the company or financial institution using the electronic record credit system 1 to the server device 30 are also made via the relay device 10.
In particular, when inability to pay occurs, the server device 30 notifies the inability of payment and the contents by sending a notification of inability to pay to each person in charge terminal device 21 or approval authority terminal device 22 of all participating financial institutions. . The inability to pay here means that the electronic record receivable is not paid on the due date.

Furthermore, if the same user cannot be paid twice within a predetermined period, the server device 30 will stop the use of the electronic record receivable as a debtor and the suspension of lending transactions for all participating financial institutions. Record and notify all participating financial institutions with inability to pay.
Further, when the due date of the electronically recorded receivable comes, the server device 30 transmits an inter-account remittance settlement request to the inter-account remittance processing device 90 of the participating financial institution to be settled. Here, the inter-account remittance settlement request is a remittance request for settlement of the electronically recorded receivable.
An example of the server device 30 is a densai net, but is not limited thereto.

The person-in-charge terminal device 21 is installed in a participating financial institution, and transmits a request for recording to the server apparatus 30 and a service provision request to the relay apparatus 10 in accordance with the operation of the person in charge of the electronic record receivable in the financial institution. The person-in-charge terminal device 21 displays various information provided from the server device 30 or the relay device 10. In particular, the person-in-charge terminal device 21 transmits a search request for an insolvent history to the relay device 10 and displays a search result returned by the relay device 10.
In the following, the person in charge of electronic record receivables at a financial institution is simply referred to as “person in charge”.

Approval-right person terminal device 22 is installed in a participating financial institution, and approves a recording request transmitted by person-in-charge terminal device 21 installed in the participating financial institution in accordance with the operation of the approval right person in the financial institution. Further, the authorization authority terminal device 22 can accept the same operation as that of the person-in-charge terminal device 21 or can perform the same display as that of the person-in-charge terminal device 21.
In addition, an inter-account remittance processing device 90 is also installed in the participating financial institutions. The inter-account remittance processing apparatus 90 performs inter-account remittance processing. In particular, the inter-account remittance processing device 90 performs remittance processing from the destination account to the destination account according to the inter-account remittance settlement request transmitted by the server device 30 on the due date of the electronically recorded receivable.
Here, the destination (or “destination”) indicates a side that performs remittance. Therefore, the destination account is an account for transferring money. In addition, the destination (or “to-be-targeted”) here refers to the side that receives the remittance. Therefore, the destination account is an account that receives remittance.

  The relay device 10 is installed in a relay center (a provider that provides a relay service), and relays communication between the client device 20 and the server device 30. In addition, the relay device 10 provides various services to the client device 20 such as aggregation of notifications transmitted by the server device 30 and provision of notification history information. In particular, the relay device 10 provides non-payment history information to the client device 20 based on the non-payment notification transmitted by the server device 30.

The financial institution communication circuit 11 communicates with the person-in-charge terminal device 21, the approval authority terminal device 22, and the inter-account remittance processing device 90.
The anti-recording institution communication circuit 12 communicates with the server device 30.
The storage device 13 stores various data.
A CPU (Central Processing Unit) 14 reads out and executes a program stored in the storage device 13 to control each unit of the relay device 10 and perform various processes.

  Note that the communication path W11 between the person-in-charge terminal device 21 and the relay apparatus 10, the communication path W12 between the authorization authority terminal apparatus 22 and the relay apparatus 10, and the communication path W13 between the inter-account remittance processing apparatus 90 and the relay apparatus 10. Alternatively, the communication path W21 between the server device 30 and the relay device 10 can have various configurations. For example, these communication paths may be configured by dedicated communication lines, or may be configured by general-purpose communication networks such as the Internet or telephone lines.

Further, the number of person-in-charge terminal devices 21, approval authority terminal devices 22, and inter-account remittance processing devices 90 connected to the relay device 10 is not limited to one and may be plural. Further, the person-in-charge terminal device 21, the approval authority terminal device 22, and the inter-account remittance processing device 90 of a plurality of participating financial institutions may be connected to the relay device 10.
In addition, a plurality of relay devices 10 may be connected to the server device 30.

  FIG. 2 is a schematic block diagram illustrating a functional configuration of the relay device 10. In FIG. 1, the relay device 10 includes a batch processing unit 110, a database function unit 120, and an online processing unit 140. The batch processing unit 110 includes a file reception unit 111, a file transmission unit 112, a notification reception unit 113, a history generation unit 114, and a notification transmission unit 115. The history generation unit 114 includes a destination financial institution information acquisition unit 201, a financial institution determination unit 202, a debtor information acquisition unit 203, an account presence / absence determination unit 204, and an overlap condition evaluation unit 205. The database function unit 120 includes an inter-account remittance settlement database 121, an inability to pay notification management database 122, an address management database 123, an inability to pay history database 124, an inability to pay history (own account) database 125, and an inability to pay history information. The management database 126, the insolvency management database 127, the contractor database 128, the account information database 129, and the account information database 130 are provided. The online processing unit 140 includes a billing reception unit 141, an approval reception unit 142, a billing transmission unit 143, a search request reception unit 144, a case extraction unit 145, a display data generation unit 146, and an output unit 147. To do.

The batch processing unit 110 stores the notification transmitted by the server device 30 and the inter-account remittance settlement request (request for settlement on the due date of the electronically recorded receivable) in the database function unit 120, and these notifications and inter-account remittance settlement The request is transmitted (transferred) to the person-in-charge terminal device 21, the approval authority terminal device 22, and the inter-account remittance processing device 90.
The file reception unit 111 receives the inter-account remittance settlement request transmitted by the server device 30, and outputs the received inter-account remittance settlement request to the file transmission unit 112 and the inter-account remittance settlement database 121. The file receiving unit 111 is configured by the CPU 14 (FIG. 1) controlling the anti-recording institution communication circuit 12.
The file transmission unit 112 transmits (transfers) the inter-account remittance settlement request received by the file receiving unit 111 to the inter-account remittance processing device 90. The file transmission unit 112 is configured by the CPU 14 controlling the financial institution communication circuit 11.

The notification receiving unit 113 receives the notification transmitted by the server device 30 and outputs the received notification to the history generation unit 114 and the non-payable notification management database 122. The notification receiving unit 113 is configured by the CPU 14 (FIG. 1) controlling the anti-recording engine communication circuit 12.
The history generation unit 114 generates a non-payable history based on the non-payable notification among the notifications received by the notification receiving unit 113. In addition, the history generation unit 114 outputs (transfers) the notification received by the notification reception unit 113 to the notification transmission unit 115. Each unit of the history generation unit 114 is realized by a CPU.

  The destination financial institution information acquisition unit 201 acquires information on the destination financial institution of the electronic record receivable that has become unpaid based on the insolvency notification transmitted by the server device 30 of the recording institution of the electronic record receivable. Specifically, the destination financial institution information acquisition unit 201 reads the code of the destination financial institution from the insolvency notification transmitted by the server device 30 and received by the notification reception unit 113. The code here is a character string or a number as identification information. The destination financial institution here is a financial institution that performs remittance. Hereinafter, the electronic record receivable that has become unpaid will be referred to as “unpaid debt”.

The financial institution determination unit 202 determines whether or not the destination financial institution is a predetermined financial institution based on the information of the destination financial institution. Specifically, the financial institution determination unit 202 determines whether or not the destination financial institution with non-payable debt is a financial institution to provide services based on the code of the destination financial institution acquired by the destination financial institution information acquisition unit 201. judge. The financial institution to be provided here is a financial institution for which the relay apparatus 10 provides the service. When there are a plurality of service providing target financial institutions, the financial institution determining unit 202 performs determination for each of the service providing target financial institutions.
The determination result of the financial institution determination unit 202 is included in the non-payable history generated by the history generation unit 114.

The debtor information acquisition unit 203 acquires information on the debtor of the electronically recorded receivable (unpaid debt) that has become unpaid based on the insolvency notification. Specifically, the debtor information acquisition unit 203 reads the debtor's user number of the insolvent debt from the insolvency notification transmitted by the server device 30 and received by the notification receiver 113.
The user number here is a number for identifying the user, and one user number is given to each user. Even when the user uses the electronic record credit system 1 with a plurality of accounts, one common user number is given to the plurality of accounts.
Hereinafter, a user who is a debtor of an insolvent debt is referred to as a “user who has become unable to pay”.

Based on the debtor information, the account presence / absence determination unit 204 determines whether the debtor has an account at a predetermined financial institution. Specifically, the account presence / absence determination unit 204 stores the user number of the debtor of the insolvent debt acquired by the debtor information acquisition unit 203, the contractor database 128, the account information database 129, and the account information database 130. Based on the information of the user, it is determined whether or not the debtor of the insolvent debt has an account at the financial institution to which the service is provided.
The determination result of the account presence / absence determination unit 204 is included in the non-payable history generated by the history generation unit 114.

The overlap state evaluation unit 205 evaluates the overlap state between the business area of the destination financial institution and the business area of a predetermined financial institution for the electronic record receivable (unpaid debt) that has become unpaid. Specifically, the overlap condition evaluation unit 205 reads out the location information of each branch of the destination financial institution from the address management database 123 based on the code of the destination financial institution acquired by the destination financial institution information acquisition unit 201. In addition, the overlap condition evaluation unit 205 reads the location of each branch of the financial institution targeted for service provision from the address management database 123. The overlap condition evaluation unit 205 determines whether the branch of the destination financial institution and the branch of the financial institution to which the service is provided exist in the same region. Is determined.
The determination result of the overlap condition evaluation unit 205 is included in the non-payable history generated by the history generation unit 114.
The notification transmission unit 115 transmits (transfers) the notification received by the notification reception unit 113 to the person-in-charge terminal device 21 or the approval authority terminal device 22.

The database function unit 120 is configured by the CPU 14 controlling the storage device 13 and stores and manages (searches) various data.
The inter-account remittance settlement database 121 stores and manages inter-account remittance settlement information.

FIG. 3 is an explanatory view showing an example of the data structure of the inter-account remittance settlement information stored in the inter-account remittance settlement database 121. The inter-account remittance settlement information stores the details of the inter-account remittance settlement request received by the file receiving unit 111.
In the figure, inter-account remittance settlement information is configured as tabular data, and one line corresponds to one settlement.

  Each line of inter-account remittance settlement information includes an ID (Identifier), a settlement information management number, a destination_financial institution code, a destination_branch code, a destination_user number, a destination_account type, Destination_Account Number, Destination_Account Name, Destination_Receivable Record Number, Destination_Receivable Amount, Destination_Payment Date, Destination_Financial Institution Code, Destination_Branch Code, Destination_Account Each information includes a type, a destination_account number, and a destination_account name.

The ID in the inter-account remittance settlement information identifies a row of inter-account remittance settlement information.
The payment information management number identifies the payment corresponding to the row in which the payment information management number is stored.
The destination_financial institution code is a code for identifying the destination financial institution.
The destination_branch code identifies the destination branch in the destination financial institution. A destination branch here is a branch which remits money. By combining the financial institution code and the branch code, it is possible to identify a branch from all branches of all participating financial institutions. For example, a destination branch can be identified from all branches of all participating financial institutions by a combination of a destination_financial institution code and a destination_branch code.

  The destination_user number identifies the user who performs the remittance. The user here is a company that uses the electronic record credit system 1. Therefore, the user who performs remittance identified by the destination_user number is the debtor in the electronic record receivable to be settled.

The destination_account type, destination_account number, and destination_account name are the destination account type, account number, and name, respectively. Examples of account types include types such as a savings account and a checking account.
The destination_receivable record number in the inter-account remittance settlement information identifies the electronic record receivable to be settled.
The destination_receivable amount and the destination_payment due date in the inter-account remittance settlement information are the amount of the electronic record receivable (settlement amount) to be settled and the due date of the electronic record receivable to be settled, respectively.

The destination_financial institution code is a code for identifying the destination financial institution. The financial institution here is a financial institution that receives remittance.
The destination_branch code identifies the destination branch within the destination financial institution. The destination branch here is a branch that receives remittance.
The destination_account type, the destination_account number, and the destination_account name are the type of the destination account, the account number of the destination account, and the name of the destination account, respectively.

The non-payment notification management database 122 stores and manages non-payment notification management information.
FIG. 4 is an explanatory diagram showing an example of the data structure of the non-payment notification management information stored in the non-payment notification management database 122. The non-payment notification management information stores the content of non-payment notification.
In the figure, the insolvency notification management information is configured as tabular data, and one line corresponds to one insolvency notification.

  Each line of non-payment notice management information includes ID, user number, attribute, corporation name / individual company name Kana, corporation name / individual company name, shop name Kana, shop name, and representative name Kana. And representative name, postal code, address, company classification, date of establishment, date of birth, industry classification, insolvency rule 1, insolvency rule 2, and insolvency rule cancellation, , Including information on the availability of debtors.

The ID in the non-payment notification management information identifies the row of non-payment notification management information.
The user number in the insolvency notification management information is the user number of the user who has become unable to pay.
The attribute in the insolvency notification management information is an attribute of the user who has become unable to pay. Here, as an example of the attributes of the user, there can be listed attributes such as a corporation (financial institution), a corporation (other than a financial institution), and an individual business operator.

The corporate name / individual business name kana in the insolvency notification management information is a pseudonym of the corporate name or the personal business name of the user who has become unable to pay.
The corporate name / individual business operator name in the insolvency notification management information is the corporate name or the personal business operator name of the user who has become unable to pay.
The store name Kana in the insolvency notification management information is a pseudonym of the store name of the user who has become unable to pay.
The name in the insolvency notification management information is the name of the user who has become unable to pay.

The representative name Kana in the insolvency notification management information is a pseudonym of the representative name of the user who has become unable to pay.
The representative name in the insolvency notification management information is the representative name of the user who has become unable to pay.
The postal code in the insolvency notification management information is the postal code of the address of the user who has become unable to pay. The address here includes the location of a company or the like.

The address in the insolvency notification management information is the address of the user who has become unable to pay.
The company classification in the non-payable notification management information is the company classification of the user who has become non-payable. Examples of company classifications include large companies, medium-sized companies, and SMEs.
The establishment date in the insolvency notification management information is the establishment date of the user who has become unable to pay.

The date of birth in the insolvency notification management information is the date of birth of the representative of the user who has become unable to pay.
The industry category in the insolvency notification management information is the industry category of the user who has become unable to pay. Examples of industry classifications include agriculture / forestry, fishery, mining / quarrying / gravel extraction, construction, manufacturing (food), and so on.

In the column of insolvency rule 1 is stored the operation start date of the rule (notification to all participating financial institutions) for the first insolvency. If the first payment failure is not occurring, the payment failure rule 1 column is blank.
The column of insolvency rule 2 stores the operation start date of the rule for the second insolvency (use of electronic record receivables as debtor and suspension of lending transaction). If there is no second insolvency, the insolvency rule 2 column is blank.

The date when the application of the non-payable rule is canceled is stored in the non-payable rule cancellation column. If the insolvency rule has not been canceled or if the insolvency rule has not been applied in the first place, the insolvency rule cancellation column is blank.
The debtor availability in the insolvency notification management information indicates whether or not the user who has become unable to pay is able to use the electronic record receivable as a debtor.

The address management database 123 stores and manages address management information.
FIG. 5 is an explanatory diagram showing an example of the data structure of the address management information stored in the address management database 123. The address management information stores the address of the branch of the participating financial institution. The address management information is used by the overlap condition evaluation unit 205 to evaluate the overlap between the business area of the financial institution of the electronic record receivable (unpaid debt) that has become unpaid and the business area of the predetermined financial institution. It is done.

In the figure, the address management information is configured as tabular data, and one line corresponds to one branch.
Each row of address management information includes address management, ID, financial institution code, branch code, postal code, address (prefecture), address (city), address (address), and address ( And other information.

The ID in the address management information identifies a row of address management information.
The financial institution code is a code for identifying a financial institution.
The branch code identifies the branch within the financial institution. As described above, a branch can be identified from all branches of all participating financial institutions by a combination of a financial institution code and a branch code. Hereinafter, a branch identified by a combination of a financial institution code and a branch code in one line of the address management information is referred to as “corresponding branch”.
The postal code in the address management information indicates the postal code of the corresponding branch.
In the address management information, an address (prefecture), an address (city), an address (address), and an address (other) indicate the prefecture, city, address, and others of the address of the branch.

The non-payable history database 124 stores and manages non-payable history information.
FIG. 6 is an explanatory diagram showing an example of the data structure of the insolvency history information stored in the insolvency history database 124. The non-payable history information is history information that the history generating unit 114 generates in advance by batch processing so that the case extracting unit 145 extracts a corresponding case in the non-payable history search.

In the figure, the insolvency history information is configured as tabular data, and one line corresponds to one inability to pay.
Each line of non-payment history information includes an ID, a financial institution code, a capture reference date, a notification interface (IF) management number, a reception date and time, a transfer type, a notification date, and a correction / cancellation notification Each information includes date, user number, use / non-use, branch code, branch name, and inability to pay.

The ID in the non-payable history information identifies the line of non-payable history information.
The financial institution code in the insolvency history information identifies the destination financial institution of the insolvent debt.
The capture reference date in the insolvency history information indicates the date on which the history information of the user who has become unable to pay is captured. The reference date for acquisition is used as one of the search keys in the search for the insolvency history.

The notification interface management number in the non-payment history information identifies the non-payment notification (hereinafter referred to as “corresponding non-payment notification”) that has notified the corresponding non-payment.
The interface here refers to the transaction type of the electronically recorded bond, and includes, for example, a billing interface, a billing result interface, and a notification interface.
The reception date and time in the insolvency history information indicates the date and time when the relay device 10 received the corresponding insolvency notification.

The change type in the insolvency history information indicates the change type (registration, correction or cancellation) notified by the corresponding insolvency notification.
The notification date in the non-payment history information indicates the date when the corresponding non-payment notification is notified.
The correction / cancellation target notification date in the insolvency history information indicates the date when the insolvency notification targeted for correction or cancellation is notified.

The user number in the insolvency history information identifies the user who has become unable to pay.
The presence / absence of own use in the insolvency history information indicates whether the user who has become unable to pay has an account in his / her own bank. The bank here refers to each financial institution to which the relay device 10 provides a service. The non-payable history database 124 stores non-payable history information for each financial institution subject to service provision, and the financial institution associated with the non-payable history information is the bank in the non-payable history information.

The branch code in the insolvency history information indicates a branch code when a user who has become unable to pay has an account in his / her bank. When a user who has become unable to pay has accounts at a plurality of branches of the bank, a plurality of branch codes are indicated.
The branch name in the insolvency history information indicates the branch name of the branch code shown in the branch code column.

  The non-payable status in the non-payable history information indicates whether or not the user who has become non-payable has an account in his / her bank and that the account is a destination account for non-payable debt. Specifically, if the destination account in the corresponding insolvency notification is an own bank account, the value of inability to pay is “Yes”, and in the case of other banks (non-owner financial institutions) Becomes "nothing". When a user who has become unable to pay has an account at a plurality of branches of the bank, whether or not payment is possible is indicated for each branch (for each branch code in the branch code column).

The non-payable history (own bank account) database 125 stores and manages non-payable history (own bank account) information.
FIG. 7 is an explanatory diagram showing an example of the data structure of insolvency history (own account) information stored in the insolvency history (own account) database 125. The non-payment history (own account) information is generated in advance by the history generation unit 114 in batch processing in order for the case extraction unit 145 to extract the corresponding case in the non-payment history search of a user who has an account in the own bank. It is history information.

In the figure, the insolvency history (own bank account) information is configured as tabular data, and one line corresponds to one inability to pay.
Each line of non-payment history (own bank account) information includes ID, financial institution code, capture reference date, notification interface management number, user number, account number, account type, account number, and account Includes each name and information.

The ID in the non-payable history (own bank account) information identifies the line of non-payable history (own bank account) information.
The financial institution code in the insolvency history (own bank account) information is used to identify a destination financial institution that is unable to pay debt, and is specifically the bank institution code of the bank.
The reference date of acquisition, the notification interface management number, and the user number in the insolvency history (own account) information are all the same as in the case of insolvency history information.

The account number in the insolvency history (own account) information identifies the account of the user who has become unable to pay. The account here is information relating to attributes such as the name and address of the user that the user registers when using the electronic record credit system 1. The user registers an account for each branch that uses the account in the electronic record receivable system 1. However, the user can register a plurality of accounts in one branch.
The account type, account number, and account name in the insolvency history (own account) information indicate the account type, account number, and account name of the user's account that is the destination account of the insolvent debt, respectively. .

The non-payable history information management database 126 stores and manages non-payable history information management information.
FIG. 8 is an explanatory diagram showing an example of the data structure of the non-payable history information management information stored in the non-payable history information management database 126. The non-payable history information management information indicates a correspondence relationship between the reference date for acquisition and the date / time for extraction. The extraction target date and time here indicates a target period of history information to be searched in the extraction of non-payable cases performed by the case extraction unit 145. The non-payment history information management information is used to display the target period when the person in charge designates the search range on the take-in reference date in the person-in-charge terminal device 21. The same applies to the search from the approval authority terminal device 22.

In the figure, the insolvency history information management information is configured as tabular data, and one line corresponds to one capture reference date.
Each line of the insolvency history information management information includes information on an ID, a financial institution code, an acquisition reference date, an extraction target date and time (from), and an extraction target date and time (to).

The ID in the non-payable history information management information identifies the row of non-payable history information management information.
The financial institution code in the insolvency history information management information corresponds to the financial institution requesting the retrieval of the insolvency history information.
The capture reference date indicates the date when the history information of the user who has become unable to pay is captured.
The extraction target date and time (from) and the extraction target date and time (to) in the insolvency history information management information indicate the search target period corresponding to the acquisition reference date.

The non-payable management database 127 stores non-payable management information.
FIG. 9 is an explanatory diagram showing an example of the data structure of insolvency management information stored in the insolvency management database 127. The insolvency management information stores information on the insolvency that has occurred. More specifically, the non-payable management information stores non-payable content registered by the client device 20.

In the figure, the insolvency management information is configured as tabular data, and one line corresponds to one insolvent debt.
Each line of insolvency management information includes an ID, a user number, a financial institution code, a branch code, a branch name, an account type, an account number, an account name, a claim record number, a claim amount, Includes information on due date.

The ID in the non-payable management information identifies the line of non-payable management information.
The user number in the insolvency management information identifies the user who has become unable to pay.
The financial institution code in the insolvency management information is a code for identifying the destination financial institution of the insolvent debt.
The branch code in the insolvency management information identifies the destination branch in the destination financial institution of the insolvent debt.

The branch name in the insolvency management information is the branch name of the destination branch of the insolvent debt.
The account type, account number, and account name in the insolvency management information are the name of the destination account of the insolvent debt, the account number of the destination account of the insolvent debt, and the name of the destination account of the insolvent debt, respectively.
The claim record number in the insolvency management information identifies the insolvent debt.
The amount of receivable and the due date in the insolvency management information are the amount of unpaid debt (the amount of receivable) and the due date of the unpaid debt, respectively.

FIG. 10 is an explanatory diagram showing an example of the data structure of the contractor information stored in the contractor database 128. The contractor information stores information related to users (including corporations and non-corporations such as individual businesses) who have an account at a financial institution to provide services and use the electronic record credit system 1. The contractor database 128 stores contractor information for each financial institution targeted for service provision.
In the following, a user who has an account at a financial institution to provide services and uses the electronic record credit system 1 is referred to as a “contractor”.

In the figure, the contractor information is configured as tabular data, and one line corresponds to one user.
Each line of the contractor information includes each information of the contractor ID, the financial institution code, the user number, the transaction start date, and the use / non-use of IB (Internet Banking).
The contractor ID is identification information given to each user, and identifies the user.
The financial institution code in the contractor information identifies the financial institution in which the user has an account.
The user number is a user number assigned to the user.
The transaction start date indicates the transaction start date between the user and the financial institution.
The presence / absence of use of IB indicates whether or not the user is using internet banking.

FIG. 11 is an explanatory diagram showing an example of the data structure of account information stored in the account information database 129. The account information stores information related to an account held by the user registered in the contractor information. The account information database 129 stores account information for each financial institution that provides services.
In the figure, account information is configured as tabular data, and one line corresponds to one account.

Each line of account information includes an account ID, a contractor ID, an account number, a financial institution code, a branch code, a FAX number, a corporate name / individual business name, and a corporate name / individual business name , A department name, etc., a department name, etc., an attribute code, a recorded postal code, a recorded prefecture code, and a recorded address.
The account ID is identification information attached to each account and identifies the account.

The contractor ID in the account information is the contractor ID of the contractor who has an account.
The account number in the account information is an account number assigned to the account.
The financial institution code in the account information identifies the financial institution corresponding to the account. As described above, the user registers an account for each branch that uses the account in the electronic record credit system 1.
The branch code in the account information identifies the branch corresponding to the account in the financial institution.

The FAX number in the account information is the FAX number of the user who has an account.
The corporate name / individual company name in the account information is the corporate name or individual company name of the user who has the account.
The corporate name / individual company name Kana in the account information is a pseudonym of the corporate name or individual company name of the user who has the account.

The department name or the like in the account information is the name of the department or the like that uses the account. Here, as an account usage method, it is assumed to have an account for each unit inside the user, such as for each department or each branch office.
“Kana” such as department name in the account information is a pseudonym of the name of the department or the like that uses the account.

The attribute code in the account information is an attribute code such as a department that uses the account.
The recorded zip code in the account information is the zip code of the location of the department or the like that uses the account.
The record prefecture code in the account information identifies the location of the department that uses the account by prefecture.
The recorded address in the account information is an address registered as the location of the department or the like that uses the account.

FIG. 12 is an explanatory diagram showing an example of a data structure of account information stored in the account information database 130. The account information stores information related to an account held by the user registered in the contractor information. The account information database 130 stores account information for each financial institution for which services are provided.
In the figure, account information is configured as tabular data, and one line corresponds to one account.

Each line of the account information includes information of an account ID, an account ID, a financial institution code, a branch code, an account type code, an account number, and an account name.
The account ID is identification information given to each account, and identifies the account.
The account ID in the account information identifies an account corresponding to the account. As described above, the user registers one or a plurality of accounts for each branch that uses the account in the electronic record credit system 1.

The financial institution code in the account information identifies the financial institution that manages the account.
The branch code in the account information identifies the branch that manages the account in the financial institution.
The account type code indicates the type of account. The account number and the account name are the account number assigned to the account and the name or name of the account holder, respectively.
Information relating to the user is stored as a normalized database by a combination of the contractor database 128, the account information database 129, and the account information database 130.

The online processing unit 140 transmits (transfers) a request such as a recording request transmitted by the client device 20 to the server device 30. At that time, the online processing unit 140 outputs the non-payable information registered by the client device 20 to the non-payable management database 127, and the non-payable management database 127 stores the information as described above.
In addition, the online processing unit 140 replies the search result to the non-payment history search request from the person-in-charge terminal device 21. The same applies to the search from the approval authority terminal device 22.

The claim accepting unit 141 accepts (receives) various bills from the person-in-charge terminal device 21 or the approval authority terminal device 22 to the server device 30. The claim accepting unit 141 outputs the received claim to the approval accepting unit 142, and outputs the non-payable registration request among the received claims to the non-payable management database 127.
The approval receiving unit 142 notifies the approval right person terminal device 22 that the request has been received for the request received by the charge receiving unit 141, and receives the approval that the approval right person operates by operating the approval right person terminal device 22. . The approval reception unit 142 outputs the approved request to the bill transmission unit 143.
The bill transmission unit 143 transmits (transfers) the approved bill to the server device 30.

The search request accepting unit 144 accepts (receives) a request for retrieval of non-payment history from the person-in-charge terminal device 21 and the approval authority terminal device 22. The search request receiving unit 144 outputs the received search request to the case extracting unit 145.
The case extraction unit 145 extracts a case from the database function unit 120 (particularly, the insolvency history database 124 and the insolvency history (own account) database 125) in accordance with the search request received by the search request reception unit 144, and as a search result. The data is output to the display data generation unit 146.
The display data generation unit 146 generates display data based on the search result extracted by the case extraction unit 145. The format of the display data generated by the display data generation unit 146 can be various. For example, the display data format may be an image data format such as JPEG or a hypertext format.

The output unit 147 outputs (transmits) the display data generated by the display data generation unit 146 to the person-in-charge terminal device 21 and the approval authority user terminal device 22. As a result, the output unit 147 outputs the determination result of the financial institution determination unit 202 included in the search result. Further, the output unit 147 outputs the determination result of the account presence / absence determination unit 204 by including it in the search result.
Note that the relay device 10, the server device 30, and the inter-account remittance processing device 90 may be configured by a plurality of devices. For example, the relay device 10 may be configured by a server device that configures the batch processing unit 110 and the online processing unit 140 and a database machine that configures the database function unit 120.

Next, with reference to FIGS. 13 to 18, the display of the person-in-charge terminal device 21 in the insolvency history search will be described. The same applies to the search from the approval authority terminal device 22.
FIG. 13 is an explanatory diagram illustrating an example of a search condition input area displayed by the person-in-charge terminal device 21. In the search condition input area of the figure, the person in charge inputs search conditions such as the reference date of search and the type of non-payment notification and presses the “Search” button (for example, with a mouse click). A search request based on the input search condition is transmitted to the relay apparatus 10.

FIG. 14 is an explanatory diagram illustrating an example of a list of search results of insolvency history displayed by the person-in-charge terminal device 21. The list of search results of insolvency history is generated by the case extraction unit 145 extracting information from insolvency history information and the like.
In the figure, the person-in-charge terminal device 21 shows a list of search results of insolvency history in a tabular form, and shows one piece of information on inability to pay per line.
Further, the “own branch of the bank” column indicates the branch of the bank where the user who has become unable to pay has an account. No. As shown in line 2, when there are a plurality of corresponding branches, a plurality of branches are shown.

The information shown in the “own branch office” column corresponds to an example of the determination result of the account existence determination unit 204. That is, by indicating the branch name in the same column, it is determined that the user who has become unable to pay has an account in his / her bank. In addition, “-” in the same column indicates a determination result that the user who has become unable to pay does not have an account in the bank.
Non-payable projects that have their own branch (the bank where the insolvent user has an account) are likely to have an impact on the bank and are considered to be highly important in this respect. . Therefore, the person-in-charge terminal device 21 displays the target branch of the bank, thereby indicating the importance of the non-payable item and prompting the person in charge. In other words, the person (here, the person in charge) referring to the insolvency information (here, the insolvency history) indicating that the payment of the electronic financial receivable has not been made more surely grasps the importance of the insolvency information. it can.

  In addition, the “presence / absence of insolvent debt” column indicates whether or not the branch account for each branch shown in the “subject branch” column is the destination account for the insolvent debt. More specifically, if the account that the insolvent user has in his / her bank is the destination account for the insolvent project (the insolvent project indicated in that bank), enter the “Unpaid debt” column. “Yes” is displayed, otherwise “No” is displayed. However, if the transfer type of the insolvency notification is other than registration, “-” is displayed in the “non-payable debt” column.

  The information shown in the “Presence / absence of unpaid debt” column corresponds to an example of a determination result of the financial institution determination unit 202. If the bank's account is the destination account for insolvent debt, it may directly affect the bank, and in this respect it is considered a highly insolvent project. Therefore, the person-in-charge terminal device 21 displays whether or not the bank account is the destination account for the insolvent debt, thereby indicating the importance of the insolvent case and prompting the person in charge. That is, a person who refers to insolvency information indicating that payment of an electronic financial receivable has not been made can more reliably grasp the importance of the insolvency information.

In addition, in the “Presence / absence of overlap of business areas” column, if the destination financial institution of the non-payable item is another bank (a financial institution other than its own bank), Indicates whether there is an overlap of business areas with the branch of the destination financial institution. For example, if there is a branch of the destination financial institution in the city where the branch of the bank is located, “Yes” is displayed in the “Presence / absence of overlapping business areas” column. On the other hand, if there is no branch of the destination financial institution in the city where the branch of the bank is located, “None” is displayed in the “Overlap of business areas” column.
If the destination financial institution of the insolvent item is the bank or the transfer type of the insolvency notification is other than registration, “-” is displayed in the “business overlap” column.

The information shown in the “presence / absence of overlapping business areas” column corresponds to an example of an evaluation result of the overlap condition evaluation unit 205. In other words, “Yes” is displayed in the same column to indicate that there is a relatively large overlap between the business area of the financial institution of the electronic record receivable that has become unpaid and the business area of the bank. On the other hand, “None” is displayed in the same column, indicating that the overlap between the business area of the financial institution of the electronic record receivable that has become unpaid and the business area of the bank is relatively small.
The greater the overlap of business areas, the more likely it is that users who are unable to pay will visit their bank for loan consultations, etc. . Therefore, the person-in-charge terminal device 21 displays the degree of overlap of the business areas, thereby indicating the importance of the non-payable item and prompting the person in charge. That is, a person who refers to insolvency information indicating that payment of an electronic financial receivable has not been made can more reliably grasp the importance of the insolvency information.

  In addition, the size of the area used as the evaluation standard for the overlap of business areas is not limited to the unit of municipality. For example, different evaluation criteria may be used depending on the type of financial institution, such as evaluating the degree of overlap for city banks in units of municipalities and evaluating the degree of overlap for local banks in units of prefectures. Or, if there is a branch of the destination financial institution in the same prefecture as the bank of your own bank, it overlaps and “Yes” is displayed, and if there is a branch of the destination financial institution in the same city as your bank, it overlaps The degree of overlap may be evaluated and displayed step by step, such as highlighting “large”.

  In addition, the person-in-charge terminal device 21 is No. As in line 1, the insolvent case where the user who has become unable to pay does not have a branch in his / her own bank is highlighted. In the case of insolvent projects where the insolvent user does not have a branch in his / her bank, attention will be required when the user visits the bank for loan consultations in the future. This is considered a high-value project. Therefore, the person-in-charge terminal device 21 can highlight the case, thereby indicating the importance of the non-payable case and prompting the person in charge. That is, a person who refers to insolvency information indicating that payment of an electronic financial receivable has not been made can more reliably grasp the importance of the insolvency information.

  Various modes can be used as the mode in which the person-in-charge terminal device 21 performs the highlight display. For example, the person-in-charge terminal device 21 may display a pattern such as hatching, or may highlight the character color or the background color using a color such as red. Alternatively, the person-in-charge terminal device 21 may highlight the character according to the size, thickness, font, blinking of the character, or luminance change. Alternatively, the person-in-charge terminal device 21 may perform highlighting in a combination of a plurality of modes.

In addition, the subject that the person-in-charge terminal device 21 performs highlighting is not limited to an insolvent case in which a user who has become unable to pay does not have a branch in the bank.
For example, the person-in-charge terminal device 21 may highlight an insolvent case in which a user who has become unable to pay has a branch in the bank. As described above, a non-payable case where a user who has become non-payable has a branch in his / her bank has a relatively high possibility of affecting his / her bank, and is considered to be a highly important case in this respect. Therefore, the person-in-charge terminal device 21 highlights the non-payable item, thereby indicating the importance of the non-payable item and prompting the person in charge.

Alternatively, the person-in-charge terminal device 21 may highlight other objects, such as highlighting insolvent matters that are overlapped with business areas and having “Yes”.
Furthermore, the person-in-charge terminal device 21 may highlight a plurality of objects. At that time, the person-in-charge terminal device 21 may perform highlighting in a different manner for each target. For example, in the example of FIG. 14, the person-in-charge terminal device 21 has a No. You may make it display each line of 1-3 by a red character.

The unit in which the person-in-charge terminal device 21 performs highlighting is not limited to the line unit. For example, the person-in-charge terminal device 21 may perform highlighting in units of columns, such as highlighting the “presence / absence of non-payable debt” column.
In the present embodiment, the display data generation unit 146 generates display data in which highlight display is added to the search result generated by the case extraction unit 145, but the person-in-charge terminal device 21 processes the highlight display on the search result. You may make it perform.

  Alternatively, the person-in-charge terminal device 21 may display each non-payable item in the same display mode without performing highlighting. In this case, the display data generation unit 146 shows the determination result of the financial institution determination unit 202 and the determination result of the account existence determination unit 204 when the destination financial institution is a predetermined financial institution (own account) and the destination financial institution Display data to be displayed in the same display mode as that in the case of a financial institution (other bank) other than a predetermined financial institution is generated. Then, the output unit 147 outputs the display data generated by the display data generation unit 146.

FIG. 15 is an explanatory diagram illustrating an example in which the person-in-charge terminal device 21 displays each non-payable item in the same display mode without performing highlighting. In the figure, the person-in-charge terminal device 21 displays the list of search results of the non-payable history having the same contents as the example of FIG. 14 without highlighting.
Thus, the person-in-charge terminal device 21 can clearly display the search result of the insolvency history by displaying each insolvent matter in the same display mode without performing highlighting.

14 and 15, when the person in charge depresses the “detail” button (for example, mouse click), the person-in-charge terminal device 21 makes the non-payable item in the corresponding line as in the examples shown in FIGS. Display detailed information for.
FIG. 16 is an explanatory diagram illustrating an example of notification information displayed by the person-in-charge terminal device 21. In the notification information shown in the figure, the person-in-charge terminal device 21 displays information related to the inability to pay notification, such as a notification management number for identifying the inability to pay notification and a notification date of the inability to pay notification. The notification information is generated by the case extraction unit 145 extracting information from the insolvency history information and the like.

  FIG. 17 is an explanatory diagram illustrating an example of non-payable user information displayed by the person-in-charge terminal device 21. In the non-payable user information shown in the figure, the person-in-charge terminal device 21 displays information about the non-payable user, such as the user identification number and attributes of the non-payable user. The non-payable user information is generated by the case extraction unit 145 extracting information from non-payment history information and the like.

  FIG. 18 is an explanatory diagram illustrating an example of own-run information displayed by the person-in-charge terminal device 21. In the bank information shown in the figure, the person-in-charge terminal device 21 displays information related to the bank, such as information on an account held by a user who has become unable to pay and information on a branch that manages the account. The case information is generated by the case extraction unit 145 by extracting information from the non-payment history information, the non-payment history (own account) information, and the like.

Next, with reference to FIGS. 19 to 20, the flow of processing in the electronic record bond system 1 will be described. In FIG. 19 and FIG. 20, the operation and display performed by the person-in-charge terminal device 21 can be performed by the approval authority terminal device 22.
FIG. 19 is an explanatory diagram showing an example of the flow of the settlement process for electronic record receivables and the insolvency registration process.
<Payment between accounts>
When the payment date of the electronically recorded receivable is between two days before and the due date, the server device 30 transmits an inter-account remittance settlement file (file indicating inter-account remittance settlement request) to the batch processing unit 110.
The batch processing unit 110 stores the contents of the inter-account remittance settlement file in the inter-account remittance settlement database 121.
Further, the batch processing unit 110 transmits (transfers) the inter-account remittance settlement file to the inter-account remittance processing apparatus 90.
The inter-account remittance processing device 90 performs remittance processing for settlement according to the inter-account remittance settlement file.

<Insolvency registration>
When remittance fails, such as when the remittance amount cannot be withdrawn due to a shortage of balance, the inter-account remittance processing device 90 outputs an error indicating a remittance failure.
The person in charge who has referred to the error starts a non-payable task, and performs a non-payable provisional registration operation on the person-in-charge terminal device 21. The person-in-charge terminal device 21 requests provisional registration from the relay apparatus 10 (online processing unit 140) based on the operation of the person in charge. The temporary registration of non-payment here is a process in which the relay device 10 temporarily stores a non-payable record request waiting for approval.

Receiving the provisional registration request, the online processing unit 140 transmits the provisional registration result (content of the provisionally registered insolvency) and the approval request notification to the approval authority terminal device 22. Approval-right person terminal device 22 displays the provisionally registered non-payable content and approval request.
When the approval right person who refers to the display of the approval right person terminal device 22 performs the approval operation for the non-payment registration in the approval right person terminal device 22, the approval right person terminal device 22 relays the approval information of the non-payment registration. Transmit to device 10.

In the relay device 10 that has received the approval information for the insolvency registration, the online processing unit 140 performs an approval process. Specifically, the online processing unit 140 transmits a non-payable record request to the server device 30.
The server device 30 that has received the non-payable request records the non-payable charge. When the recording is completed, the server device 30 notifies the charge terminal device 21 and the billing transmission unit 143 of the billing result via the online processing unit 140.

FIG. 20 is an explanatory diagram showing an example of a flow of processing when payment failure is confirmed and payment failure history search processing.
<Notice of insolvency>
On the next day after two business days of the payment due date, the server device 30 performs settlement information confirmation processing in a payment batch (batch processing for processing payment records). In the settlement information confirmation process, the server device 30 confirms the already recorded settlement information. In particular, when the record of inability to pay is confirmed, the server device 30 transmits a notification of inability to pay to all participating financial institutions.

  The batch processing unit 110 captures the notification interface transmitted by the server device 30 by batch processing. Then, the batch processing unit 110 notifies the corresponding financial institution of the captured notification interface. In particular, when a payment failure notification is included in the fetched notification interface, the batch processing unit 110 transmits a payment failure notification to all financial institutions to which services are provided. More specifically, the batch processing unit 110 notifies the non-payment to the person-in-charge terminal device 21 registered in advance as the terminal device of the person in charge having the reference authority among the person-in-charge terminal devices 21 to be provided with service. Send.

  In addition, when the payment notification is included in the captured notification interface, the batch processing unit 110 (history generation unit 114) updates the information stored in the database function unit 120 based on the payment failure notification. . More specifically, the history generation unit 114 displays the information included in the insolvency notification, the information generated by the financial institution determination unit 202, the account presence / absence determination unit 204, and the overlap condition evaluation unit 205, the insolvency history database 124. Or the payment failure history (own account) database 125, and the payment failure history database 124 or payment failure history (own account) database 125 stores the information.

<Insolvency history search>
When the person in charge performs an insolvency history search request operation (for example, an operation to input the display of FIG. 13 and press the “search” button) on the person-in-charge terminal device 21, the online processing unit 140 (case extraction) Unit 145) extracts a corresponding insolvent matter and generates a search result. The online processing unit 140 (output unit 147) transmits the search result as display data to the person-in-charge terminal device 21, and the person-in-charge terminal device 21 displays the search result as in the examples of FIGS. .

Next, the operation of the electronic record bond system 1 will be described with reference to FIGS.
FIG. 21 is a flowchart illustrating an example of a processing procedure in which the history generation unit 114 generates additional information of non-payment history information. When the history generation unit 114 acquires the insolvency notification transmitted by the server device 30, the history generation unit 114 performs the process illustrated in FIG.

  In the process of FIG. 9, the relay device 10 transcribes information from the payment failure notification to payment failure history information (step S101). Specifically, the history generation unit 114 reads information such as a notification interface management number and a transfer type from the inability to pay notification, and together with information on the take-in status of the non-payable notification by the relay device 10 such as the take-in reference date. Output to the impossible history database 124. The non-payable history database 124 provides a new line in the non-payable history information, and writes the information from the history generation unit 114 in the corresponding column of the newly provided line. For example, the non-payment history database 124 writes the ID using a serial number.

Next, the debtor information acquisition unit 203 reads the user number of the user who has become unable to pay from the inability to pay notification, thereby identifying the user who has become unable to pay (step S102).
Then, the account presence / absence determination unit 204 refers to the user information stored in the contractor database 128, the account information database 129, and the account information database 130 for the user specified by the debtor information acquisition unit 203 in step S102. Then, it is determined whether or not the user has an account in the bank (whether or not the bank is used) (step S103).

  If it is determined that the user has an account in the bank (step S103: YES), the relay device 10 acquires information on the branch used and writes it in the insolvency history information (step S111). Specifically, the account presence / absence determination unit 204 acquires a branch code and a branch name for an account held by the user who has become unable to pay, and outputs the acquired branch code and branch name to the non-payable history database 124. The non-payable history database 124 writes the information from the account presence / absence determining unit 204 in the corresponding column of the new line of non-payable history information.

Next, the destination financial institution information acquisition unit 201 reads the destination account information from the insolvency notification to identify the destination account (step S112).
Then, the financial institution determining unit 202 determines whether the destination account is a bank account (step S113).
When it is determined that the destination account is the bank account (step S113: YES), the relay device 10 writes “not payable” to the destination branch in the insolvency history information, and writes “not payable” to other branches (step S113). S121).

Specifically, the financial institution determination unit 202 identifies the branch that manages the account and outputs the branch code to the insolvency history database 124. The insolvency history database 124 writes information that there is inability to pay for the branch corresponding to the branch code from the financial institution determination unit 202 among the branches in which the information has been written in step S111, and the like. Write information about the inability to pay for the branch.
As for the presence or absence of overlapping business areas, the non-payable history database 124 writes no overlap (step S141).
Thereafter, the process of FIG.

On the other hand, when it is determined in step S113 that the destination account is an account of another bank (step S113: NO), the non-payment history database 124 stores the information about each branch in which information is written in step S111.
Write “No payment impossible” in the “Payment impossible” column of the payment failure history information.
Then, it progresses to step S141.

On the other hand, if it is determined in step S103 that the user who has become unable to pay does not have an account in the bank (step S103: NO), the non-payable history database 124 displays information indicating that there is no use branch history. The information is written in the corresponding column (step S151).
Further, the inability to pay history database 124 writes information that there is no inability to pay in the “payable / not payable” column of the inability history information (step S152).

Next, the overlap condition evaluation unit 205 reads the financial institution code from the insolvency notification to identify the destination financial institution (step S153).
Then, the relay device 10 evaluates the overlapping state of the business areas of the branch of the specified financial institution and the branch of the bank (Step S154).
Specifically, for each branch of the bank, the overlap condition evaluation unit 205 compares the information on the branch with the address of the branch stored in the address management database 123 for the specified destination financial institution. The presence / absence of overlap is determined, and the determination result is output to the insolvency history database 124. The non-payable history database 124 writes the determination result of the overlap evaluation unit 205 in the “overlap presence / absence” column of the non-payable history information.
After step S154, the process in FIG.

FIG. 22 is a flowchart illustrating an example of a processing procedure in which the history generation unit 114 generates additional information of insolvency history (own account) information. When the history generation unit 114 acquires the insolvency notification transmitted by the server device 30, the history generation unit 114 performs the process illustrated in FIG.
In the process shown in FIG. 10, the financial institution determining unit 202 determines whether or not the destination financial is its own bank based on the financial institution code of the destination financial institution included in the insolvency notification (step S201). If it is determined that the destination financial is from another bank (step S201: NO), the processing in FIG.

  On the other hand, when it is determined that the destination finance is own bank (step S201: YES), the history generation unit 114 and the insolvency history (own bank account) database 125 include an ID, a financial institution code, a transfer reference date, a notification interface management number, About each information of a user number, it writes in the applicable column of the new line of payment failure history (own bank account) information similarly to the case of payment failure history information (Step S211).

Further, for each information of the account number, account type, account number, and account name, the history generation unit 114 obtains from the user information based on the user number, and the non-payable history (own bank account) database 125 cannot be paid. The history (own account) information is written in the corresponding column of a new line (step S212).
Thereafter, the process of FIG.

FIG. 23 is a flowchart illustrating an example of a procedure of processing performed by the online processing unit 140 when searching for insolvency history. When the online processing unit 140 obtains (receives) an insolvency history search request from the person-in-charge terminal device 21 or the approval authority terminal device 22, the online processing unit 140 performs the processing illustrated in FIG.
In the process of FIG. 9, the case extraction unit 145 identifies the financial institution from which the search request is transmitted from the search request (step S301).

Then, the case extraction unit 145 extracts information on the insolvent case corresponding to the search request from the history information for the financial institution identified in step S301 among the history information stored in the insolvency history database 124 and the like. Then, the search result is output to the display data generation unit 146 (step S302).
The display data generation unit 146 generates display data based on the search result from the case extraction unit 145, and outputs the display data to the output unit 147 (step S303).
The output unit 147 transmits the display data generated by the display data generation unit 146 to the person-in-charge terminal device 21 or the approval authority terminal device 22 that is the transmission source of the search request.
Thereafter, the process of FIG.

As described above, the destination financial institution information acquisition unit 201 acquires information on the destination financial institution of the electronic record receivable that has become unpaid based on the insolvency notification transmitted by the recording institution of the electronic record receivable. Then, the financial institution determination unit 202 determines whether or not the destination financial institution is own based on the information of the destination financial institution, and the output unit 147 outputs the determination result of the financial institution determination unit 202.
If the bank is a destination financial institution, it may directly affect the bank, and in this respect it is considered a highly insolvent project. Therefore, the output unit 147 outputs the determination result of the financial institution determination unit 202, so that the device (for example, the person-in-charge terminal device 21) that has acquired the determination result can deal with the insolvent case where the bank is the destination financial institution and the others Can be displayed separately from other cases. As a result, it is possible to show the importance of the insolvent case and to call the attention of the person in charge. That is, a person who refers to insolvency information indicating that payment of an electronic financial receivable has not been made can more reliably grasp the importance of the insolvency information.

Further, the debtor information acquisition unit 203 acquires information on the debtor of the electronic record receivable that has become unpaid based on the insolvency notification. Based on the debtor information, the account presence / absence determination unit 204 determines whether the debtor has an account in the bank, and the output unit 147 outputs the determination result of the account presence / absence determination unit 204.
A non-payable case in which a user who has become unable to pay has an account in his / her bank has a relatively high possibility of affecting his / her bank, and is considered to be a highly important case in this respect. Therefore, the output unit 147 outputs the determination result of the account presence / absence determination unit 204, so that the device that acquired the determination result (for example, the person-in-charge terminal device 21) has the account that the user who has become unable to pay has his / her own account. A non-payable item and other items can be displayed separately. As a result, it is possible to show the importance of the insolvent case and to call the attention of the person in charge. That is, a person who refers to insolvency information indicating that payment of an electronic financial receivable has not been made can more reliably grasp the importance of the insolvency information.

Further, the overlap condition evaluation unit 205 evaluates the overlap state between the business area of the destination financial institution of the electronic record receivable that cannot be paid and the business area of the bank, and the output unit 147 displays the evaluation result of the overlap condition evaluation part. indicate.
The greater the overlap of business areas, the more likely it is that users who are unable to pay will visit their bank for loan consultations, etc. . Therefore, the output unit 147 outputs the evaluation result of the overlap condition evaluation unit 205 so that the device (for example, the person-in-charge terminal device 21) that has acquired the determination result displays the overlap state of the business areas for the insolvent case. Can do. As a result, it is possible to show the importance of the insolvent case and to call the attention of the person in charge. That is, a person who refers to insolvency information indicating that payment of an electronic financial receivable has not been made can more reliably grasp the importance of the insolvency information.

In addition, the destination financial institution information acquisition unit 201 acquires information on the destination financial institution of the electronic record receivable that has become unpaid based on the insolvency notification transmitted by the recording institution of the electronic record receivable. Further, the financial institution determining unit 202 determines whether or not the destination financial institution is own based on the information of the destination financial institution. Further, the debtor information acquisition unit 203 acquires information on the debtor of the electronic record receivable that has become unpaid based on the insolvency notification. And the account presence determination part 204 determines whether the said obligor has an account in an own bank based on information of a obligor. Then, the display data generation unit 146 displays the determination result of the financial institution determination unit 202 and the determination result of the account presence / absence determination unit 204 in the same display manner when the destination financial institution is its own bank and when it is another bank. Display data to be generated is output, and the output unit 147 outputs the display data generated by the display data generation unit 146.
In this way, the display data generation unit 146 generates display data that is not highlighted (displayed in the same display mode), so that the device (for example, the person-in-charge terminal device 21) that acquired the display data Impossible information can be displayed clearly.

  In the above, the case where the present invention is applied to the insolvency history has been described as an example, but the scope of application of the present invention is not limited thereto. For example, the relay device 10 responds to the insolvency notification transmitted by the server device 30 with respect to whether or not the user who has become unable to pay, the presence or absence of payment in the bank account, the bank of the destination financial institution and the bank Information on the degree of overlap of the business area with the branch office or a combination thereof may be added. Furthermore, as described with reference to FIG. 13, the relay device 10 may set highlighting.

Note that the relay device 10 may add information on the relationship between users based on the electronically recorded receivables, such as information on creditors who are unable to pay debts, to the unpaid information (for example, non-payable history information).
In addition, the relay device 10 adds information on the amount of unpaid debt (the amount of claims), such as the ratio of the amount of unpaid debt to the creditors of the unpaid debt, to the unpaid information. Also good.

Further, the relay device 10 may compare the location of the user who has become unable to pay and the location of the financial institution to which the service is provided, and add the comparison result to the inability to pay information.
For example, the overlap condition evaluation unit 205 reads the address of the user who has become unpaid from the non-payment notification management database 122, and reads the location of each branch of the financial institution to be provided from the address management database 123. Then, the overlap condition evaluation unit 205 determines whether or not there is a branch of the financial institution to be provided in the same area as the address of the user who has become unable to pay. When it is determined that there is a branch in the same area, the overlap condition evaluation unit 205 adds the branch number and branch name of the corresponding branch to the insolvency information.

In this way, the overlap condition evaluation unit 205 determines whether or not the location of the debtor of the electronic record receivable that has become unpaid is included in the business area of a predetermined financial institution (service providing target financial institution). . The overlap condition evaluation unit 205 corresponds to an example of an inclusion determination unit.
Then, in response to a search request from the person-in-charge terminal device 21 or the approver terminal device 22, the display data generation unit 146 generates display data that is displayed by including the determination result of the overlap condition evaluation unit 205 in the search result. The output unit 147 outputs the determination result of the overlap evaluation unit 205 by transmitting the display data to the person-in-charge terminal device 21 and the approver terminal device 22.

  Stores that include the location of a user who has become unable to pay, such as a branch in the same area as the address of the user who has become unable to pay, such as a branch office, etc. For this reason, the possibility of visiting the branch is relatively high, and attention should be paid to this point. Therefore, the overlap condition evaluation unit 205 compares the location of the user who has become unable to pay with the location of the financial institution to which the service is provided, and the person-in-charge terminal device 21 or the approval authority terminal device 22 compares the comparison results. By displaying the result, it is possible to more reliably call attention to the person concerned in the corresponding store.

Each unit is recorded by recording a program for realizing all or part of the functions of the relay apparatus 10 on a computer-readable recording medium, causing the computer system to read and execute the program recorded on the recording medium. You may perform the process of. Here, the “computer system” includes an OS and hardware such as peripheral devices.
Further, the “computer system” includes a homepage providing environment (or display environment) if a WWW system is used.
The “computer-readable recording medium” refers to a portable medium such as a flexible disk, a magneto-optical disk, and a compact disk, and a storage device such as a hard disk built in the computer system. Furthermore, the “computer-readable recording medium” dynamically holds a program for a short time like a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line. In this case, a volatile memory in a computer system serving as a server or a client in that case, and a program that holds a program for a certain period of time are also included. The program may be a program for realizing a part of the functions described above, and may be a program capable of realizing the functions described above in combination with a program already recorded in a computer system.

  The embodiment of the present invention has been described in detail with reference to the drawings. However, the specific configuration is not limited to this embodiment, and includes design changes and the like within a scope not departing from the gist of the present invention.

DESCRIPTION OF SYMBOLS 10 Relay apparatus 110 Batch processing part 111 File reception part 112 File transmission part 113 Notification reception part 114 History generation part 201 Destination financial institution information acquisition part 202 Financial institution judgment part 203 Debtor information acquisition part 204 Account presence / absence judgment part 205 Overlap condition evaluation Unit 115 Notification transmission unit 120 Database function unit 121 Inter-account remittance settlement database 122 Non-payment notification management database 123 Address management database 124 Unpaid history database 125 Unpaid history (own account) database 126 Unpaid history information management database 127 Unpaid management Database 128 Contractor database 129 Account information database 130 Account information database 140 Online processing unit 141 Request reception unit 142 Approval reception unit 143 Transmitting section 144 search request receiving unit 145 projects extracting unit 146 display data generating unit 147 output unit

Claims (5)

A destination financial institution information acquisition unit for acquiring information on a destination financial institution of the electronic record receivable that has become insolvent based on the insolvency notification transmitted by the recording institution of the electronic record receivable;
A financial institution determination unit that determines whether or not the destination financial institution is a predetermined financial institution based on the information of the destination financial institution;
Based on the insolvency notification, a debtor information acquisition unit that acquires information on the debtor of the electronic record receivable that has become unpaid;
An account presence / absence determining unit that determines whether the obligor has an account at the predetermined financial institution based on the information of the obligor;
An output unit that outputs the determination result of the financial institution determination unit and the determination result of the account presence determination unit;
A non-payable information processing apparatus comprising: Comprising an overlapping condition evaluation unit for evaluating the overlapping condition between the business area of the financial institution of the electronic record receivable that has become insolvent and the business area of the predetermined financial institution;
The output unit displays the evaluation result of the overlap condition evaluation unit.
The non-payable information processing apparatus according to claim 1. An inclusion determination unit that determines whether the location of the debtor of the electronic record receivable that has become unpaid is included in the business area of the predetermined financial institution;
The output unit displays a determination result of the inclusion determination unit.
The non-payable information processing apparatus according to claim 1 or 2. A destination financial institution information acquisition unit for acquiring information on a destination financial institution of the electronic record receivable that has become insolvent based on the insolvency notification transmitted by the recording institution of the electronic record receivable;
A financial institution determination unit that determines whether or not the destination financial institution is a predetermined financial institution based on the information of the destination financial institution;
Based on the insolvency notification, a debtor information acquisition unit that acquires information on the debtor of the electronic record receivable that has become unpaid;
An account presence / absence determining unit that determines whether the obligor has an account at the predetermined financial institution based on the information of the obligor;
The determination result of the financial institution determination unit and the determination result of the account existence determination unit are obtained when the destination financial institution is the predetermined financial institution and the destination financial institution is a financial institution other than the predetermined financial institution. A display data generation unit for generating display data to be displayed in the same display mode, and
An output unit for outputting the display data;
A non-payable information processing apparatus comprising: A non-payable information processing method for an unpaid information processing apparatus,
A destination financial institution information acquisition step for acquiring information on a destination financial institution of the electronic record receivable that has become unpaid based on the insolvency notification transmitted by the recording institution of the electronic record receivable;
A financial institution determination step of determining whether or not the destination financial institution is a predetermined financial institution based on the information of the destination financial institution;
A debtor information acquisition step of acquiring information on the debtor of the electronic record receivable that has become unpaid based on the insolvency notification;
Based on the debtor information, an account presence determination step for determining whether the debtor has an account at the predetermined financial institution;
An output step for outputting the determination result in the financial institution determination step and the determination result in the account presence determination step;
A non-payable information processing method comprising:

Images