Incident response system

Abstract

We provide a fault response system that makes it easy to handle failures in credit card company systems. [Solution] The fault response server (fault response system) 1 is a fault response system that responds to a fault in the credit card company system 2 when a fault occurs, and comprises a request acquisition unit that acquires card transaction requests to the faulty system, which is the faulty credit card company system 2, and an alternative request unit that requests an alternative system, which is a different credit card company system 2 from the faulty system, to perform the processing that the faulty system should perform in response to the card transaction requests.

Description

Technical Field

[0001] The present invention relates to a fault response system for responding to a fault when a fault occurs in a credit card company system.

Background Art

[0002] In order to respond to a fault occurring in a financial institution system such as a credit card company system, various conventional technologies have been proposed. For example, Patent Document 1 discloses a financial transaction processing system including a transaction proxy response server that substitutes for financial transactions for a financial institution center where the service is stopped, and a cooperation server that cooperates the transaction proxy response server and an accounting system. In the case of this financial transaction processing system, the transaction proxy response server determines the availability of the financial transaction using the account information transmitted from the cooperation server in response to a request for a financial transaction for the financial institution center, and executes the financial transaction on behalf of the financial institution center when the transaction is possible. Thereby, even when the financial institution center is stopped, the financial transaction can be realized.

[0003] Also, as a response when a fault occurs in a credit card company system, Non-Patent Document 1 discloses a CAFIS suspension / fault substitution service. In this service, a CAFIS substitution center capable of executing the same processing as the credit card company system executes card transactions on behalf of the credit card company system during the occurrence of a fault.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Non-Patent Document 1

[0005] As described above, in the financial transaction processing system described in Patent Document 1, the transaction response authorization server acts on behalf of the financial institution center to perform financial transactions that the financial institution center should be executing. In this case, the transaction response authorization server needs to have a computer system that enables the execution of financial transactions, similar to the financial institution center. Since the execution of financial transactions often requires complex and enormous processing, the construction of such a computer system is not easy, and therefore the realization of the conventional financial transaction processing system described above is not easy either. Furthermore, similar problems can be observed in the CAFIS proxy center described in Non-Patent Document 1.

[0006] This invention was made in view of the above circumstances, and its primary purpose is to provide a fault response system that makes fault response easier by utilizing the resources of each credit card company's system. [Means for solving the problem]

[0007] The inventors focused on alternative transportation, which allows the use of other means of transportation when a transportation system such as a railway becomes inoperable, and found that, similar to this alternative transportation, it would be effective to have a mechanism in which, when a credit card company system fails, another credit card company system can take over the functions of that credit card company system. Based on this finding, the inventors invented the following failure response system. That is, a failure response system according to one aspect of the present invention is a failure response system that responds to a failure in a credit card company system, and comprises a request acquisition unit that acquires card transaction requests to the failing credit card company system, which is the failing credit card company system, and a substitution request unit that requests a substitute system, which is a different credit card company system from the failing credit card company system, to substitute the processing that the failing credit card company system should perform in response to the card transaction requests.

[0008] In the above embodiment, the system may further include an alternative system identification unit that identifies an alternative system from among a plurality of credit card company systems different from the system experiencing the failure, and the alternative request unit may request the identified alternative system to perform the alternative.

[0009] Furthermore, in the above embodiment, the request acquisition unit may acquire the card transaction request from a merchant terminal that receives the card transaction request from a credit card user, and the alternative request unit may request the merchant terminal to make the alternative request to the specified alternative system.

[0010] Furthermore, in the above embodiment, the system may further include a performance storage unit that stores the replacement history for each credit card during the occurrence of the failure, and the replacement request unit may determine whether or not to execute the replacement request based on the replacement history of the credit card related to the card transaction request.

[0011] Furthermore, in the above embodiment, the system may further include a replacement availability identification unit that identifies the number of replacements possible for each credit card based on the replacement record, and a number notification unit that notifies the user of each credit card of the number of replacements possible.

[0012] Furthermore, in the above embodiment, if the request is not accepted by the identified alternative system, the alternative system identification unit may identify a different credit card company system as a new alternative system, one that is different from the credit card company system previously identified as an alternative system.

[0013] Furthermore, in the above embodiment, the alternative system identification unit may identify a credit card company system designated in advance by the credit card company and / or a user of the credit card company related to the system experiencing the failure as an alternative system.

[0014] Furthermore, in the above embodiment, the system may further include an operational status acquisition unit that acquires the operational status of each credit card company system, and an operational status notification unit that notifies users of each credit card of the operational status information indicating the operational status. [Effects of the Invention]

[0015] According to the present invention, it becomes possible to easily handle failures in credit card company systems. [Brief explanation of the drawing]

[0016] [Figure 1] A block diagram showing the configuration of the fault response system and its communication destinations. [Figure 2] A diagram showing an example of the layout of an alternative configuration database. [Figure 3] A diagram showing an example of the layout of the alternative performance database. [Figure 4] A flowchart illustrating an example of the basic procedure for troubleshooting. [Figure 5A]Chart (first half) showing the process flow when the trouble response server makes a substitution request to the alternative system via the franchise terminal. [Figure 5B] Chart (second half) showing the process flow when the trouble response server makes a substitution request to the alternative system via the franchise terminal. [Figure 6] Flowchart showing an example of the procedure of the substitution feasibility determination process executed by the trouble response server. [Figure 7] Chart showing the process flow when the card company system in which a failure has occurred is restored. [Figure 8] Flowchart showing an example of the procedure of the substitution available quantity notification process executed by the trouble response server. [Figure 9A] Chart (first half) showing the process flow when the trouble response server makes a substitution request to the alternative system via the settlement system. [Figure 9B] Chart (second half) showing the process flow when the trouble response server makes a substitution request to the alternative system via the settlement system. [Figure 10] Block diagram showing a modified example of the configuration of the trouble response system and its communication destination.

Embodiments for Carrying Out the Invention

[0017] Hereinafter, preferred embodiments of the present invention will be described with reference to the drawings. Note that each of the embodiments shown below exemplifies methods and apparatuses for embodying the technical idea of the present invention, and the technical idea of the present invention is not necessarily limited to the following. The technical idea of the present invention can be variously modified within the technical scope described in the claims.

[0018] As will be described later, in this embodiment, when a failure occurs in a credit card company's system, the failure is addressed by utilizing the resources of other credit card companies. This failure response system is what makes this possible. Through this failure response system, each credit card company's system complements the others, and as a result, it is possible to improve convenience for users of each credit card company.

[0019] (System Configuration) Figure 1 is a block diagram showing the configuration of the fault response system and its communication destination in this embodiment. The fault response system in this embodiment consists of a fault response server 1. This fault response server 1 is a computer system that responds to faults when they occur in each credit card company system (hereinafter referred to as "card company system") 2.

[0020] The fault response server 1 and the card company system 2 send and receive data to each other via the payment system 3. This payment system 3 is a computer system for cashless payments using credit cards, etc., and CAFIS (Credit And Finance Information Switching system) is one example of such a system.

[0021] The payment system 3 is also connected to the merchant terminal 4 installed at the credit card merchant. The merchant terminal 4 sends and receives data with the fault response server 1 and the card company system 2 via the payment system 3.

[0022] As described above, in this embodiment, the fault response server 1, the card company system 2, and the merchant terminal 4 communicate with each other via the payment system 3, but this is not the only way. The fault response server 1, the card company system 2, and the merchant terminal 4 may communicate with each other without going through the payment system 3.

[0023] Card Company System 2 is a computer system operated by a credit card company (hereinafter referred to as "Card Company") that receives credit card payment requests from merchant terminals 4 and executes processing in accordance with those requests. Furthermore, Card Company System 2 can also receive and process similar payment requests from user terminals such as personal computers and smartphones via the internet.

[0024] The following describes the detailed configuration of the failure response server 1. The failure response server 1 consists of one or more computers equipped with a control unit including a CPU, RAM, and ROM, and a storage unit, and the various processes described later are executed by this control unit. The storage unit of the failure response server 1 is equipped with the following databases: a backup configuration database (DB) 11, a backup performance database (DB) 12, and a failure status database (DB) 13. The details of these databases are described below.

[0025] (A)Alternative setting DB11 The failure response server 1, in the event of a failure in a particular card company system 2, will have another card company system 2 take over the processing of card transactions that the first card company system 2 is unable to perform. The backup configuration DB 11 is a database that stores the information necessary to identify the backup card company system 2.

[0026] Figure 2 shows an example of the layout of the Alternative Settings DB11. As shown in Figure 2, the Alternative Settings DB11 stores information such as the card number of the credit card used by each user, the card company, and information identifying candidate card companies (candidate alternatives) that will take over payments made by that credit card in the event of a failure.

[0027] There may be one or more alternative cardholders. These alternative cardholders are designated by the card company and / or the user. For example, a card company may designate a specific partner card company as an alternative cardholder. Also, if a user holds credit cards from both a first and a second card company, they may designate the second card company as an alternative cardholder for the first card company's credit card, and the first card company as an alternative cardholder for the second card company's credit card.

[0028] The designation of a potential alternative card provider is made by the card company or the user declaring it to the failure response server 1 in advance. Alternatively, in the event of a failure, the merchant terminal 4 installed at the merchant used by the user may notify the failure response server 1 of the alternative card provider. In this case, the user may inform the merchant of the alternative provider, and the merchant's staff member who receives this information may input the alternative provider into the merchant terminal 4, which then transmits it to the failure response server 1. Alternatively, the identifier of the alternative card provider may be written in the memory of the credit card, and the merchant terminal 4 may read this and notify the failure response server 1.

[0029] (B) Replacement track record DB12 The Alternative History DB12 is a database that stores information on instances where other card company systems 2 have taken over the processing that a failing card company system 2 should have performed. Figure 3 shows an example of the layout of the Alternative History DB12. As shown in Figure 3, the Alternative History DB12 stores information such as the failure ID that identifies each failure, the date and time when the substituted processing (hereinafter referred to as "alternative processing") was performed during the failure, the card number of the user who requested payment by credit card, information that identifies the failing card company that is the source of the substitution and the receiving card company, and information that indicates the content of the alternative processing.

[0030] When the failure response server 1 requests alternative processing from the alternative card company system 2, or when alternative processing is performed, it registers the relevant information in the alternative performance DB 12. The information stored in this alternative performance DB 12 is used not only to confirm the results of the alternative process afterward, but also to identify the recipient to whom alternative processing should be requested in the future. This point will be explained later.

[0031] (C) Failure Status DB13 The Failure Status DB13 is a database that stores information regarding the failure status of each card company system 2. For example, the failure ID, the date and time when the failure occurred and when it was confirmed to have been resolved, and information to identify the card company system 2 that experienced the failure are stored in the Failure Status DB13.

[0032] (System operation) As described above, the fault response server 1, when a failure occurs in the card company system 2, identifies an alternative from among other card company systems 2 and requests its assistance. This entire process will be collectively referred to as the fault response process. The details of this fault response process will be explained below.

[0033] Figure 4 is a flowchart illustrating an example of the basic procedure for fault response processing performed by the fault response server 1. When a card transaction request occurs to the faulty card company system 2, a replacement request is issued from the payment system 3 or the merchant terminal 4 to request that the card transaction be performed on its behalf. Upon receiving the replacement request (S11), the fault response server 1 identifies a replacement system from among the other card company systems 2 that are not experiencing the fault (S12).

[0034] In step S12, the fault response server 1 refers to the alternative configuration DB 11 and extracts alternative candidate systems associated with the card number of the user who requested the current card transaction. If there is only one alternative candidate system, the fault response server 1 identifies that candidate system as the alternative system. On the other hand, if there are multiple alternative candidate systems, the fault response server 1 may identify any of them as the alternative system, or, if the card company or user has ranked them, it may identify the alternative system according to that ranking.

[0035] As described above, the fault response server 1 may receive information from the merchant terminal 4 indicating the alternative card company system 2. In that case, the fault response server 1 identifies the card company system 2 as the alternative system.

[0036] Incidentally, if it takes a considerable amount of time to restore the malfunctioning card company system 2, it is expected that the number of alternative processing requests will also be considerable. In that case, if the requests for alternative processing are concentrated on a specific card company system 2, a problem will arise in which the load on that card company system 2 will increase. Therefore, the failure response server 1 estimates the load on each card company system 2 according to the status of alternative requests and identifies an alternative system based on the results. For example, the failure response server 1 determines that the load on a card company system 2 that is receiving many alternative requests is high, and the load on a card company system 2 that is receiving few alternative requests is low, and then identifies the card company system 2 that is judged to have a low load as the alternative system. This ensures load balancing and prevents situations such as multiple card company systems 2 going down in a chain reaction.

[0037] Furthermore, the estimation of the load on each card company system 2 is not limited to the above. For example, the fault response server 1 may obtain information indicating the processing status of each card company system 2 from the payment system 3 or each card company at appropriate times, and estimate the load on each card company system 2 based on that information.

[0038] Next, the failure response server 1 sends a request to the alternative system (card company system 2) to replace the current card transaction (S13). In this case, the failure response server 1 may send the replacement request directly to the alternative system, or it may send the replacement request indirectly via the payment system 3 or the merchant terminal 4.

[0039] When the backup system receives a backup request for a card transaction, it determines whether to accept or reject the request and sends backup acceptance / rejection information indicating the result of that determination. When the failure response server 1 receives the backup acceptance / rejection information (S14), it determines whether the backup request has been accepted or rejected based on that information (S15).

[0040] If it is determined in step S15 that the replacement request was not accepted (NO in S15), the failure response server 1 returns to step S12, identifies another card company system 2 as the replacement system, and then executes the subsequent processing. In this case, the failure response server 1 may select from the card company systems 2 specified as replacement candidates in the replacement setting DB 11, or it may select any other card company system 2 as the replacement system.

[0041] On the other hand, if it is determined that the replacement request has been accepted (YES in S15), the failure response server 1 registers the results of the replacement process in the replacement results DB 12 (S16) and terminates the failure response process. As a result of this failure response process, the processes that would have been executed by the card company system 2 during the failure are executed by the replacement system, so that users can perform their desired card transactions as usual.

[0042] It should be noted that there may be cases where the backup system is unable to successfully perform the backup process. In such cases, the backup system will send information indicating this, and upon receiving this information, the failure response server 1 will return to step S12 and execute the subsequent processes. This will ensure that the backup process can be performed as much as possible.

[0043] The steps outlined above in the incident response process are fundamental and are performed regardless of the content of the alternative process; however, more specific steps may differ depending on the content of the alternative process. Examples of these specific steps are described below.

[0044] The following describes the more specific procedures for handling failures and the overall flow of processing in each device, including the failure response server 1, assuming two concrete scenarios. The first is when the failure response server 1 requests a replacement system for card transactions via the merchant terminal 4, and the second is when the same request is made via the payment system 3. In the following, it is assumed that a failure occurs in the card company system 2 of a certain card company A (hereinafter referred to as "Company A's system"), and that the card company system 2 of card company B (hereinafter referred to as "Company B's system") is identified as the replacement for Company A's system. Furthermore, in the following, a credit card issued by card company A will be referred to as Card A, and a credit card issued by card company B will be referred to as Card B.

[0045] (1) When the fault response server 1 makes a replacement request via the merchant terminal 4 Figures 5A and 5B are charts showing the processing flow when the fault response server 1 requests a replacement system via the merchant terminal 4, and Figure 6 is a flowchart showing an example of the procedure for determining whether a replacement is possible, which the fault response server 1 performs within that flow. Figure 7 is a chart showing the processing flow when Company A's system recovers from a failure.

[0046] As described above, in this embodiment, the fault response server 1, the card company system 2, and the merchant terminal 4 communicate with each other via the payment system 3. Therefore, communication between the fault response server 1, the card company system 2, and the merchant terminal 4 described below is performed via the payment system 3, even if it is not explicitly stated that the payment system 3 is involved.

[0047] A user of card A makes a purchase at a merchant using credit card payment. At this time, the merchant terminal 4 installed at the merchant reads the card information of card A used by the user, and a payment request addressed to Company A's system is sent from the merchant terminal 4 to the payment system 3 (S101).

[0048] When payment system 3 receives the above payment request, it sends the payment request to the A company system which is experiencing a failure (S201). Upon receiving this, the A company system, unable to process it properly due to the failure, returns an error to payment system 3 (S301). Upon receiving this error, payment system 3 sends an error to the merchant terminal 4 that sent the payment request (S202). It is assumed that the A company system has a program installed to send errors in the event of a failure in order to return an error to payment system 3 as described above. Note that if a certain amount of time has elapsed since sending the payment request to the A company system in step S201 and no response has been received from the A company system, payment system 3 may send an error to the merchant terminal 4 even if it has not received an error from the A company system.

[0049] When the merchant terminal 4 receives an error from the payment system 3 (S102), it sends an alternative request to the failure response server 1, requesting that the card company system 2 of a different card company than card company A perform the payment on behalf of company A's system (S103).

[0050] Upon receiving the alternative payment request from the merchant terminal 4, the fault response server 1 determines whether payment alternative is possible (S401). This determination is made according to the alternative eligibility determination process shown in Figure 6. As shown in Figure 6, the fault response server 1 refers to the alternative payment history stored in the alternative payment history DB 12 (S21) and identifies the number of alternative payments related to the credit card in question that were performed during the occurrence of the current failure (S22).

[0051] Next, the fault response server 1 determines whether the number of identified processing items is less than or equal to a predetermined value (S23). This predetermined value represents the number of alternative processing items that are permissible during the current fault, which is predetermined for each credit card. If the fault response server 1 determines that the number of identified processing items is less than or equal to the predetermined value (YES in S23), it determines that alternative processing can be performed and proceeds to step S403 in Figure 5A.

[0052] On the other hand, if it is determined that the number of identified processing items exceeds a predetermined value (NO in S23), the fault response server 1 sends information indicating that the number of attempts has exceeded the acceptable limit to the merchant terminal 4 (S24), and terminates the process. In this case, the merchant terminal 4, upon receiving the information indicating that the number of attempts has exceeded the acceptable limit, displays information on its display unit indicating that the execution of alternative processing was not permitted because the number of attempts exceeded the acceptable limit, and informs the merchant's representative of this. The explanation continues below assuming that it has been determined that the execution of alternative processing is possible.

[0053] Returning to Figure 5A, the failure response server 1 identifies the alternative card company system 2 (S402). In this case, as described above, the alternative card company system 2 designated in advance by the card company or user is identified as the alternative. Here, we assume that Company B's system is identified as the alternative.

[0054] Next, the fault response server 1 requests the B company system, which has been identified as the alternative, to take over the payment processing. In this example, as described above, the fault response server 1 makes the alternative request via the merchant terminal 4. Therefore, the fault response server 1 instructs the merchant terminal 4 to make an alternative payment request to the B company system (S403), and the merchant terminal 4, upon receiving this instruction, sends the alternative request to the B company system (S104). This completes the alternative request from the fault response server 1 to the B company system via the merchant terminal 4.

[0055] When Company B's system receives an alternative request from the merchant terminal 4, it determines whether to accept the alternative process, i.e., the execution of payment by credit card (S501). If Company B's system does not accept the execution of the alternative process, it notifies the fault response server 1 of this fact via the merchant terminal 4. Upon receiving this notification, the fault response server 1 returns to step S402, identifies the card company system 2 other than Company B's system as the alternative system, and instructs the merchant terminal 4 to submit an alternative request to the card company system 2 (S403). However, in this case, the fault response server 1 may also determine that it is impossible to execute the alternative process and send information to the merchant terminal 4 indicating that payment by credit card could not be completed. Here, we will continue the explanation assuming that Company B's system accepts the execution of the alternative process and that information to that effect is sent from Company B's system to the fault response server 1 via the merchant terminal 4.

[0056] The B company system, having agreed to execute the alternative processing, then executes the alternative processing, namely the credit card payment (S502). Here, if the user is a cardholder of both card company A and card company B, the B company system will execute the alternative processing only if the payment amount in the alternative processing is within the credit limit of card B used by the user. For example, if the payment amount is 100,000 yen, the alternative processing will only be executed if the credit limit of card B is 100,000 yen or more.

[0057] However, the possibility of executing an alternative transaction is not limited to the above. The B company system may be configured to determine whether the settlement amount in the alternative transaction falls within a predetermined range (e.g., 50,000 yen), and execute the alternative transaction if it determines that it does. In this case, the user does not need to be a cardholder of card company B.

[0058] Alternatively, the system could be configured so that the current credit limit of card A used by the user is obtained externally, and the alternative processing is executed if the settlement amount in the alternative processing is within that limit. In this case, each card company system 2 periodically notifies the payment system 3 or the failure response server 1 of the credit limits for each credit card, and if a failure occurs in any of the card company systems 2, the alternative system obtains the credit limit of the credit card involved in the alternative processing from the payment system 3 or the failure response server 1. In this case as well, the user does not need to be a cardholder of card company B.

[0059] After executing the alternative process, Company B's system sends an alternative completion notification to the fault response server 1 and the payment system 3 indicating that the alternative process has been completed (S503). Upon receiving this notification, the fault response server 1 registers information indicating the results of this alternative process in the alternative performance DB 12 (S404).

[0060] Furthermore, when payment system 3 receives a replacement completion notification from company B's system, it sends a similar replacement completion notification to merchant terminal 4 (S203) and stores information indicating the results of this replacement process (S204). When merchant terminal 4 receives a replacement completion notification from payment system 3, it displays payment completion information on its display unit indicating that the payment has been completed (S105). This allows the merchant's representative to confirm that the credit card payment has been made.

[0061] As mentioned above, Company B's system performs alternative settlements based on the credit limit of the user's Card B. Therefore, in preparation for the next use of Card B, Company B's system updates the credit limit by subtracting the amount of the current settlement from the credit limit of Card B (S504). For example, if the credit limit of Card B is 200,000 yen and the current settlement amount is 100,000 yen, the credit limit of Card B will be updated to 100,000 yen (= 200,000 yen - 100,000 yen).

[0062] Next, we will explain the process when the A company system, which was experiencing a failure, is restored after the above-mentioned alternative processing is completed. As shown in Figure 7, the A company system, which has recovered from the failure, notifies the payment system 3 that it has been restored (S303). Upon receiving this, the payment system 3 sends a similar recovery notification to the failure response server 1 and the B company system that performed the alternative processing (S205). When the failure response server 1 receives the notification from the payment system 3 and confirms that the A company system has been restored (S405), it registers information indicating that the A company system has been restored (such as the date and time of recovery) in the failure status DB 13 (S406).

[0063] Furthermore, once Company B's system confirms that Company A's system has been restored (S505), it bills Company A's system for the replacement costs, which are the costs of the replacement process that has already been performed (S506). Here, the replacement costs are the amount paid by credit card plus a predetermined replacement fee.

[0064] When Company A's system receives an invoice from Company B's system, it transfers the replacement cost to Company B's system (S304). Furthermore, Company A's system updates the credit limit of the user's card A by subtracting the amount of this transaction from the current credit limit (S305). For example, if the credit limit of card A is 200,000 yen and the current transaction amount is 100,000 yen, the credit limit of card A will be updated to 100,000 yen (= 200,000 yen - 100,000 yen).

[0065] On the other hand, Company B's system receives the remittance from Company A's system (S507). Furthermore, Company B's system updates the credit limit of Card B by adding the amount of this payment to the current credit limit of the user's Card B (S508). As a result, the credit limit of Card B returns to what it was before the alternative processing was executed. For example, if the credit limit of Card B was updated to 100,000 yen by step S504 above, and the amount of this payment is 100,000 yen, then the credit limit of Card B will be updated to 200,000 yen (= 100,000 yen + 100,000 yen).

[0066] In the example above, if the settlement amount in the alternative process is within the limit of card B, the alternative process is executed, and the limit of card A at that time is not referenced. Therefore, there may be cases where the settlement amount exceeds the limit of card A, which would result in the inconvenience of card A's limit becoming negative in step S305 above. To explain with a specific example, if card A's limit is 100,000 yen and card B's limit is 200,000 yen, and the settlement amount this time is 150,000 yen, the alternative process is executed because the settlement amount this time is within the limit of card B. However, in step S305 above, which is executed after the recovery of company A's system, it becomes -50,000 yen (= 100,000 yen - 150,000 yen). In this case, company B's system may deal with this by deducting 50,000 yen from card B's limit, or company A's system may deal with this by deducting 50,000 yen from the limit for the following month.

[0067] As described above, even if a failure occurs in Company A's system, Company B's system will perform alternative processing, making card transactions with Card A possible. Therefore, users of Card A can achieve their goal of making a payment with Card A without waiting for Company A's system to be restored.

[0068] Furthermore, by setting a limit on the number of alternative processes that can be executed during a failure, as in the alternative feasibility determination process described above, it is possible to suppress the increase in system load caused by the occurrence of alternative processes. While it could be argued that such a limit on the number of alternative processes is unnecessary when the alternative system has sufficient processing capacity, it is still effective in situations such as when recovery will take a considerable amount of time or when the number of alternative processes that will occur is unknown.

[0069] Incidentally, when limiting the number of alternative processes that can be executed during a failure, it is convenient for each user to be aware of the number of available alternative processes. For this reason, the failure response server 1 may identify the number of available alternative processes based on the alternative process history DB 12 and notify each user of that number. Figure 8 is a flowchart showing an example of the process for notifying the number of available alternative processes. This process is executed, for example, when a completion notification is sent from Company B's system to the failure response server 1 (S503). Upon receiving this completion notification, the failure response server 1, as shown in Figure 8, refers to the alternative process history DB 12 (S31) and identifies the number of alternative processes related to the credit card that were executed during the current failure (S32). Next, the failure response server 1 identifies the number of available alternatives by subtracting the identified number of alternative processes from a predetermined upper limit of available alternatives (S33), and notifies the payment system 3 and the merchant terminal 4 of the number of available alternatives (S34). In this case, the fault response server 1 may notify each user of the number of such incidents using email or SMS (Short Message Service).

[0070] (2) When the fault response server 1 makes a replacement request via the payment system 3 Next, we will explain the process when the failure response server 1 makes a replacement request via the payment system 3. In the following, detailed explanations of the process, which is the same as in (1) above when the failure response server 1 makes a replacement request via the merchant terminal 4, may be omitted.

[0071] Figures 9A and 9B are charts showing the processing flow when the failure response server 1 requests a replacement system via the payment system 3. When a user makes a purchase at a merchant using card A, a payment request addressed to Company A's system is sent from the merchant terminal 4 to the payment system 3 (S111). Upon receiving this, the payment system 3 sends the payment request to Company A's system, which is experiencing a failure (S211). Upon receiving this, Company A's system returns an error to the payment system 3 because it cannot process the request normally due to the failure (S311).

[0072] When payment system 3 receives an error from company A's system (S212), it sends an alternative request to fault response server 1 requesting that a card company system 2 other than company A's system perform the payment on behalf of company A's system (S213). Upon receiving this alternative request, fault response server 1 performs the same actions as in steps S401 and S402 described above: determining whether payment substitution is possible (S411) and identifying the alternative system (S412).

[0073] Next, the fault response server 1 requests the B company system, which has been identified as the alternative, to take over the payment processing. In this example, as described above, the fault response server 1 makes the alternative request via the payment system 3. Therefore, the fault response server 1 instructs the payment system 3 to make an alternative payment request to the B company system (S413), and the payment system 3, upon receiving this instruction, sends the alternative request to the B company system (S214). This completes the alternative request from the fault response server 1 to the B company system via the payment system 3.

[0074] The processing after the above-mentioned replacement request is the same as in (1) above when the fault response server 1 makes a replacement request via the merchant terminal 4. Specifically, in the B company system, steps S512 to S514 are executed as in steps S502 to S504; in the fault response server 1, step S414 is executed as in step S404; in the payment system 3, steps S215 and S216 are executed as in steps S203 and S204; and in the merchant terminal 4, step S112 is executed as in step S105.

[0075] As described above, even when the failure response server 1 requests an alternative via the payment system 3, users of card A can achieve their goal of making a payment with card A without waiting for the A company system to be restored. The processing after the A company system is restored is the same as in (1) above when the failure response server 1 requests an alternative via the merchant terminal 4, so the explanation is omitted.

[0076] In this embodiment, as described above, the fault response server 1 requests a different card company system 2 than the one experiencing the failure to perform a substitute card transaction, and the fault response is carried out when that card company system 2 performs the substitute processing. In this way, the resources of each existing card company system 2 are utilized, so fault response can be achieved at a relatively low cost.

[0077] (Other embodiments) The above embodiment illustrates a case where credit card payments made at the merchant's physical store are used as the alternative processing method, but it is not limited to this. For example, credit card payments for online shopping can also be used as the alternative processing method. Furthermore, card transactions other than payments, such as cash advances, can also be used as the alternative processing method.

[0078] Furthermore, in the above embodiment, the number of alternative processes that can be executed during a failure is limited by executing an alternative feasibility determination process, but this is not limited to this, and for example, a limit may be placed on the settlement amount by the alternative process. In this case, in the alternative feasibility determination process, the failure response server 1 identifies the total amount of money settled by alternatives during the failure based on the alternative performance DB 12, and if that amount is within a predetermined value, it is determined that the alternative process can be executed, while if that amount exceeds the predetermined value, it is determined that the alternative process cannot be executed.

[0079] Furthermore, although the above embodiment was described using the example of a sudden failure occurring in the card company system 2, the same applies to planned maintenance, in which normal processing cannot be performed. Therefore, the failure response system of the present invention can also be applied in such cases. In this case, the failure response server 1 can obtain information regarding the date and time of maintenance from each card company in advance, register that information in the failure status DB 13, and then execute the same processing as in the above embodiment.

[0080] Furthermore, it is convenient for each credit card user to be able to check the operating status of each card company system 2, as this allows them to determine whether or not a failure has occurred in each card company system 2 and whether or not their own credit card can be used. With this in mind, the failure response server 1 may have a function to check the operating status of each card company system 2 and provide various information regarding that operating status to each user. The configuration of the failure response server 1 having this function will be described below. Note that components similar to those in the above embodiment will be denoted by the same reference numerals and their explanation will be omitted.

[0081] Figure 10 is a block diagram showing a modified configuration of the fault response system and its communication destination. As shown in Figure 10, the fault response server 1 is equipped with an operational status database (DB) 14 for storing information regarding the operational status of each card company system 2. The fault response server 1 collects information regarding the operational status from each card company system 2 via the payment system 3. This information includes the load status, presence or absence of faults, and maintenance status of each card company system 2. Furthermore, this information also includes information regarding the alternative processing in the above embodiment. For example, the number and date / time of alternative processing, as well as which card company system 2 is being replaced, are included in the above information. The fault response server 1 may also directly collect information regarding the operational status from each card company system 2.

[0082] Furthermore, the fault response server 1 is connected to user terminals 5 used by each credit card user via the Internet 101. User terminals 5 consist of devices with communication capabilities, such as personal computers, smartphones, and tablet terminals. The fault response server 1 transmits various information stored in the operational status DB 14 to each user terminal 5 at appropriate times. For example, the fault response server 1 may transmit this information periodically at predetermined time intervals, or it may transmit the information when it receives a transmission request from a user terminal 5, when a failure occurs in any of the card company systems 2, when alternative processing is performed, or when the failed card company system 2 is restored. The above information is transmitted and received using email or SMS, etc.

[0083] The fault response server 1 can also collect information regarding the operational status of each card company system 2 from the payment system 3, rather than collecting it from each card company system 2 as described above. In this case, the fault response server 1 may, for example, collect information regarding so-called authorization processing by each card company system 2 from the payment system 3 and infer the operational status of each card company system 2 based on that information. To give a specific example, the fault response server 1 calculates the frequency of authorization processing per certain period of time based on the information collected from the payment system 3, and if that frequency deviates from the average value by a predetermined value or more, it determines that the card company system 2 is not operating normally or that a failure has occurred in the card company system 2, and stores information indicating this in the operational status DB 14. Note that the frequency of authorization processing differs depending on the card company, day of the week / holidays, and time of day, so it is preferable to compare and evaluate the operational status for each combination of these elements.

[0084] Furthermore, the fault response server 1 may perform the alternative feasibility determination process in the above embodiment based on the information stored in the operational status DB 14. For example, the fault response server 1 may determine, based on the information stored in the operational status DB 14, whether the load status of the card company systems 2 other than the one experiencing the failure is normal, and if it determines that it is normal, it may decide that it is possible to perform the alternative process.

[0085] Furthermore, the fault response server 1 may identify the alternative system (S402, S412) in the above embodiment based on the information stored in the operational status DB 14. For example, the fault response server 1 may identify the card company system 2 with the lowest load among the card company systems 2 other than the one experiencing the failure, based on the information stored in the operational status DB 14, and use that identified card company system 2 as the alternative system. [Explanation of Symbols]

[0086] 1. Failure recovery server (failure recovery system) 11 Alternative Configuration Database 12 Alternative Performance Calendar 13. Failure Status Database 14. Operational Status Database 2. Credit card company system 3. Payment System 4. Merchant terminals 5. User terminals 101 Internet

Claims

1. A system for responding to failures in a credit card company's system, A request acquisition unit that acquires card transaction requests to the malfunctioning system, which is a credit card company system experiencing a failure, A replacement request unit requests a replacement system, which is a different credit card company system from the aforementioned malfunctioning system, to perform the processing that the malfunctioning system would normally perform in response to the card transaction request. A fault tolerance system equipped with the necessary features.

2. The Alternative System Identification Unit identifies the alternative system from among multiple credit card company systems that are different from the system experiencing the failure. Furthermore, The substitute request unit requests the specified substitute system to perform the substitute. The fault response system according to claim 1.

3. The request acquisition unit acquires the card transaction request from the merchant terminal that receives the card transaction request from the credit card user. The substitute request unit requests the merchant terminal to make the substitute request to the identified substitute system. The fault response system according to claim 1 or 2.

4. A performance storage unit that stores alternative performance data for each credit card during the aforementioned failure. Furthermore, The substitute request unit determines whether or not to execute the substitute request based on the substitute history of the credit card related to the card transaction request. The fault response system according to claim 1 or 2.

5. Based on the aforementioned replacement record, a replacement-capable-number-determining unit identifies the number of replacements possible for each credit card, A unit that notifies each credit card user of the aforementioned number of transactions. Furthermore, The fault response system according to claim 4.

6. If the request is not accepted by the identified alternative system, the alternative system identification unit identifies a different credit card company system from the previously identified alternative system as a new alternative system. The fault response system according to claim 2.

7. The aforementioned alternative system identification unit identifies a credit card company system designated in advance by the credit card company and / or a user of the credit card company related to the system experiencing the failure as an alternative system. The fault response system according to claim 2.

8. A status acquisition unit that acquires the operational status of each credit card company's system, A status notification unit that notifies each credit card user of the status information indicating the status of operation, Furthermore, The fault response system according to claim 1 or 2.

Images