Systems and methods for facilitating target bridging - Patents.com

Abstract

The present invention relates to a system and method for bridging targets between a payer portable device of a first service provider and a payee merchant device of a second service provider different from the first service provider, using an emulator system to log in to the second service provider's payments with a bridging account, thereby allowing the first service provider to execute transactions with the second service provider through the bridging account even if the first service provider executes a different target format than the second service provider.

Description

[Technical Field]

[0001] Related Applications This application claims the benefit of U.S. Provisional Application No. 63 / 378,050, entitled "SYSTEMS AND METHODS TO PROCESS TARGETS," filed September 30, 2022, which is incorporated herein by reference in its entirety.

[0002] The present invention relates to a system and method for enabling transactions between two payment service providers with different target formats, in particular two Mobile Payment Service Providers (MPSPs) with different QR Code formats for the transactions. [Background technology]

[0003] QR code payment is a contactless payment method performed by scanning a QR code from a mobile app or a merchant's point-of-sale (POS) system. There are two types of QR code payment methods: merchant-presented mode (MPM) and consumer-presented mode (CPM), which differ in which party presents the QR code for the other party to scan. In merchant-presented mode (MPM), consumers pay by scanning a QR code displayed by a merchant with their smartphone. In consumer-presented mode (CPM), the merchant scans the QR code displayed by the consumer and receives the payment. QR code payment allows transactions to be conducted without the infrastructure traditionally associated with electronic payments, such as a payment card, payment network, payment terminal, and merchant account.

[0004] A Mobile Payment Service Provider (MPSP) is a closed-loop payment network that can offer QR code payment services. In such a closed-loop network, any MPSP's system can facilitate transactions between a user and a merchant as long as both parties are within the MPSP network. If the user and merchant belong to different networks, the transaction cannot be carried out because their respective QR codes cannot be recognized by the other party's system. In other words, both the user and the merchant must be within the same MPSP network to facilitate a payment transaction.

[0005] If transactions between MPSPs are required, a common payment interface such as a common target, integration system, or API is required. There are implementations that use national QR standards to display the appropriate Merchant QR (MPM) for participating MPSP users to scan and make payments. However, this approach is difficult to generalize to all MPSPs as there is no impetus for MPSPs to adopt such standards. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] U.S. Provisional Application No. 63 / 378,050 [Patent Document 2] PCT International Publication No. 2018 / 022131 Summary of the Invention [Problem to be solved by the invention]

[0007] This specification provides a method for conducting transactions between the systems of two MPSPs, one acting as an issuer and one acting as an acquirer, where the issuer has at least one valid account, an Issuer General Account (IGA), with the acquirer. [Means for solving the problem]

[0008] In one aspect, the present invention provides a method for bridging targets between a portable device of a payer of a first service provider and a merchant device of a payee of a second service provider different from the first service provider, the method comprising: (1) wirelessly receiving, by a first management system of the first service provider, a target or target content of the second service provider from the payer's portable device; and (2) transmitting, by the first management system of the first service provider, the target or target content of the second service provider to an emulator system, whereby the emulator system decrypts the target or target content and transmits the decrypted target or target content of the second service provider to a second management system of the second service provider. In this method, the portable device is configured to scan the target of the second service provider and transmit the target or target content of the second service provider to the first management system, wherein the portable device does not recognize the target of the second service provider and the emulator system recognizes the target of the second service provider. In one embodiment, the target is a QR code.

[0009] Prior to sending the second service provider target or target content to the emulator system, the method may further include identifying the second service provider from the plurality of acquirers. In one embodiment, the second service provider is identified from the plurality of acquirers by receiving identity information. In another embodiment, the second service provider is identified from the plurality of acquirers by performing pattern matching on the target with an acquirer logo library.

[0010] A second aspect of the present invention provides a second method for bridging targets between a payer's portable device of a first service provider and a payee's merchant device of a second service provider different from the first service provider, the method including: (1) receiving, by a first management system of the first service provider, targets or target content of the second service provider from an emulator system; and (2) wirelessly providing, by the first management system of the first service provider, targets or target content of the second service provider to the payer's portable device and presenting the targets to the payee's merchant device of the second service provider. In this method, the emulator system can generate or receive targets or target content of the second service provider, and the payee's merchant device does not recognize the targets of the first service provider. In one embodiment, the targets are QR codes.

[0011] Prior to receiving the second service provider target or targeted content, the method may further include (1) wirelessly receiving, by the first management system, a targeted request from the payer's portable device for the second service provider target, and (2) providing, by the first management system, the targeted request to the emulator system. In one embodiment, prior to providing the targeted request to the emulator system, the method further includes identifying the second service provider from the plurality of acquirers. The second service provider may be identified from the plurality of acquirers by receiving ID information or by performing pattern matching on the target with an acquirer logo library.

[0012] For trade approval, the method may further include (1) receiving a trade request from the emulator system, and (2) providing a trade approval to the emulator system approving the trade request.

[0013] To process the transaction on the first service provider's network, the method may further include (1) receiving, by the first management system, a transaction result from the emulator system; (2) processing, by the first management system, a payment from the payer to the first service provider according to the transaction result; and (3) wirelessly providing, by the first management system, the transaction result to the payer's portable device.

[0014] A third aspect of the present invention provides a third method for bridging a target between a payer's portable device of a first service provider and a payee's merchant device of a second service provider different from the first service provider, the method including: (1) receiving, by an emulator system, a target or target content of the second service provider from a first management system of the first service provider; (2) decrypting, by the emulator system, the target or target content of the second service provider; and (3) providing, by the emulator system, the decrypted target or target content of the second service provider to a second management system of the second service provider via a bridging account as a member of the second service provider. In one embodiment, the target is a QR code.

[0015] Prior to receiving the second service provider targets or targeted content from the first management system, the method may further include receiving identity information of the selected second service provider from a plurality of acquirers.

[0016] A fourth aspect of the present invention provides a fourth method for bridging targets between a payer's portable device of a first service provider and a recipient's scan system of a second service provider different from the first service provider, the method including: (1) acquiring, by an emulator system, targets or target content of the second service provider through a bridging account as a member of the second service provider; and (2) providing, by the emulator system, the targets or target content of the second service provider to a first management system of the first service provider, whereby the payer's portable device presents a target generated based on the target content to a recipient's merchant device that recognizes the targets of the second service provider. In this method, the recipient's merchant device does not recognize the targets of the first service provider. In one embodiment, the targets are QR codes.

[0017] Before acquiring the target or target content of the second service provider, the method may further include (1) receiving, by the emulator system, a target request from the first management system for the target of the second service provider, and (2) providing, by the emulator system, the target request to the second service provider via the bridging account.

[0018] In one embodiment, the identity of a second service provider selected from a plurality of acquirers is provided with the target request, and the bridging account corresponds to the second service provider.

[0019] To execute the bridging transaction, the method may further include (1) receiving a transaction request from the second management system after the recipient's merchant device scans the target, (2) providing the transaction request to the first management system, (3) receiving a transaction authorization from the first management system approving the transaction request, and (4) providing the transaction authorization to the second management system via the bridging account. After providing the second service provider's target or target content to the first management system, the method may further include (1) receiving a transaction result from the second management system via the bridging account, and (2) providing the transaction result to the first management system.

[0020] In one embodiment, the emulator system operates in a first management system, while in another embodiment, the emulator system operates in a bridging system of a bridging service provider that is different from both the first and second service providers.

[0021] In one embodiment, the emulator system logs into the second management system of the second service provider as a member of the second service provider with a bridging account. The emulator system may have multiple emulator accounts registered with multiple acquirers, and the bridging account may be selected from the multiple emulator accounts.

[0022] A fifth aspect of the present invention provides an emulator system for bridging targets between a payer portable device of a first service provider and a payee merchant device of a second service provider different from the first service provider, the emulator system including: (1) an execution module configured to communicatively couple to at least one issuer management system; and (2) an emulator module communicatively coupled to the execution module and configured to communicatively couple to a plurality of acquirer management systems. The execution module has instructions stored thereon and is configured to perform the following operations in response to execution of the instructions: (1) receive input from a first management system that is one of the at least one issuer management systems; (2) identify a second management system from the plurality of acquirer management systems based on the input; (3) provide the input to the emulator module based on the second management system; (4) receive output from the emulator module; and (5) provide the output to the first management system. The emulator module is configured to log in to a plurality of acquirer management systems with a plurality of emulator accounts, each emulator account registered with one of the plurality of acquirer management systems. In one embodiment, the input is a target request and the output is a target or target content of the second management system. In another embodiment, the input is a target or target content of the second management system and the output is a payment request initiated by the second management system.

[0023] In the emulator system, an emulator module may execute mobile apps of multiple acquirers to log into the multiple acquirer management systems. Upon receiving input, the emulator system is configured to record the identity of the first management system and the identity of the payer. None of the multiple acquirer management systems recognize each other's target.

[0024] Other objects, advantages and novel features of the present invention will become more apparent from the following detailed description when considered in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0025] [Figure 1] FIG. 1 illustrates a system for facilitating bridging transactions in accordance with the present invention. [Figure 2] FIG. 1 illustrates the process flow for a bridging transaction in merchant presented mode (MPM). [Figure 3] FIG. 1 illustrates the process flow for bridging transactions in consumer presented mode (CPM). [Figure 4A] FIG. 1 illustrates a network in which six MPSPs are independently implementing a target bridging method. [Figure 4B] FIG. 1 illustrates a network in which six MPSPs implement a target bridging method via a bridging service provider (Bridging SP). [Figure 5] FIG. 1 illustrates an improved embodiment of a system for facilitating bridging transactions in accordance with the present invention. [Figure 6] FIG. 1 illustrates a process flow for conducting a bridging transaction with a bridging service provider in an enhanced merchant presentment mode (MPM). [Figure 7] FIG. 1 illustrates a process flow for a bridging transaction with a bridging service provider in consumer presented mode (CPM). DETAILED DESCRIPTION OF THE INVENTION

[0026] The terms used in the following description are intended to be interpreted in the broadest reasonable manner, even when used in conjunction with detailed descriptions of certain specific embodiments of the technology. Although certain terms may be emphasized below, terms intended to be interpreted in a restrictive manner are specifically defined in this detailed description section.

[0027] The embodiments described below may be implemented by programmable circuitry that is programmed or configured by software and / or firmware, or entirely by special purpose circuitry, which (if any) may take the form of, for example, one or more application specific integrated circuits (ASICs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), graphics processing units (GPUs), etc.

[0028] This application relates to a method for facilitating a transaction between two mobile payment service providers (MPSPs) with different target formats. A target is a medium containing information that can be recognized by a specific device. Examples include, but are not limited to, one of a barcode, a QR code, an NFC (near field communication) tag, a voice signature, and a fingerprint. The target itself is information obtained by extracting features embedded in the original target information, such as by scanning a QR code, sensing an NFC tag, extracting a voice signature from audio, or scanning a fingerprint to extract features and obtain the target according to the outline of the original target information. In one embodiment of the present invention, the target is a QR code.

[0029] As mentioned above, two different MPSPs participate in a transaction between MPSPs: one is the issuer and the other is the acquirer. The issuer is a financial institution that provides the consumer with the payment tools they use to initiate the transaction. The acquirer, on the other hand, is a financial institution that provides the merchant with the tools they need to collect payment from the issuer. In this system, the consumer is typically the payer, and the merchant is typically the payee. Depending on their role in various transactions, financial institutions may function as either issuers or acquirers. In this specification, the mobile payment service provider (MPSP) on the consumer side (issuer) of a transaction between MPSPs is referred to as the first service provider (first SP), and the MPSP on the merchant side (acquirer) is referred to as the second service provider (second SP).

[0030] To communicate with an acquirer, an issuer creates at least one Issuer General Account (IGA), which is a valid account with the acquirer. When communicating with the acquirer, the issuer's system (referred to as the first management system) can use either the IGA, which is said registered account, or a token associated with said registered account, or a securely encrypted registered account. In the following paragraphs, IGA is used synonymously with issuer general account or its token or its encrypted form.

[0031] To allow issuers and their users to present and recognize acquirer targets (MPSPs with different target formats), issuers establish an emulator system similar to the mobile app provided by the acquirer to its users, and use an IGA as a login account. The IGA used in the emulator system to log in to the acquirer's system is called an emulator account. From the acquirer's perspective, the emulator account is the same as any other member, and the emulator system can perform all the functions of the mobile app. That is, the mobile app can be installed on the emulator system like a regular mobile device, but the emulator system may have the ability to link user IDs, targets, and transaction details, and pass necessary data to the various parties involved in the transaction. The emulator system is used to execute transactions with the acquirer on behalf of the issuer's users.

[0032] Bridging trading system structure A transaction between MPSPs is called a bridging transaction, and a system that enables such transactions between MPSPs is called a bridging transaction system, as shown in FIG. 1. The bridging transaction system has two main participants: a first service provider 120 (issuer) and a second service provider 140 (acquirer). The payer 110 is a user of the first service provider 120 and has a registered account with the first service provider 120. The payer's 110 portable device 115 is a device that connects to the Internet, runs the first service provider's 120 program, and has the capability to present and scan a target (such as a QR code). Commonly used portable devices include, but are not limited to, smartphones and tablets. The portable device 115 is wirelessly connected to a first management system 125 of the first service provider 120, which is the operating system of the first service provider 120. The first management system 125 has all the functions of a typical MPSP operating system, as well as an emulator system 135 for performing bridging transaction-related functions. A typical mobile app of the second service provider 140 may be installed on the emulator system 135 so that the emulator system 135 can operate as a member of the second service provider 140. In this case, the emulator system 135 joins the payment network of the second service provider 140 (acquirer) using an emulator account as a login account. The second service provider 140 has a second management system 145, which is an operating system that performs the functions of a typical MPSP. A payee 150 (e.g., a merchant) connects to the second management system 145 and the payment network of the second service provider 140 using a merchant device 155 (e.g., a smartphone, tablet, or merchant POS system).

[0033] As previously mentioned, the emulator account is the same as any other member from the perspective of the second service provider. When a payer 110 (typically a consumer) wants to make a payment to a payee 150 (typically a merchant), the payer 110 sends a payment request from their portable device 115 to the first management system 125. The first management system 125 then relays the request to the second management system 145 of the second service provider 140 via the emulator system 135. The second management system 145 is the operating system of the second service provider 140. The second management system 145 treats the emulator account the same as any other member of the second service provider 140, such as the payee 150. The second service provider 140 receives the payment request from the emulator account and issues the payment to the payee 150. In this system, a payer 110 pays a first service provider or an emulator account in the payment network of a first service provider 120, and the emulator account pays a payee in the payment network of a second service provider 140.

[0034] If the first service provider 120 maintains multiple emulator accounts with different MPSPs (acquirers), the payer 110 may select one of the MPSPs (acquirers) as the second service provider 140. For example, the user app of the first service provider 120 may provide a list of acceptable MPSPs (acquirers) based on location information on the portable device 115, and the payer 110 may select one MPSP that is acceptable to the merchant 150. The MPSP selection list may be programmable or predefined based on preferences, incentives, or other business needs. Alternatively, the selection process may be automated. For example, the user app of the first service provider 120 may allow the payer 110 to scan an MPSP logo and automatically select it as the second service provider 140 if the user app recognizes it. The first service provider 120 may then perform the function of a bridging transaction with the selected second service provider 140 using one of the multiple emulator accounts as a bridging account.

[0035] Emulator System and Emulator Account The emulator system 135 resembles a mobile app that the second service provider 140 provides to its users. However, only the first management system 125 (rather than a single user) can send data to and receive data from the second management system 145 through the emulator system 135. The first service provider 120 creates an emulator account in the payment system of the second service provider 140 to interact with other members of the payment system. In the payment system of the second service provider 140, the emulator account is an account registered by the first service provider 120 and functions like a regular member of the second service provider 140. The emulator system 135 has access to data sent to the emulator account from the second management system 145.

[0036] An emulator system that performs bridging transaction functions may include an execution module and an emulator module. These two modules may be communicatively connected to each other. In this case, the execution module is a component that connects to an issuer (e.g., a first service provider), and the emulator module is a component that connects to an acquirer (e.g., a second service provider). The emulator system may be operated by an issuer (e.g., a first service provider) as part of the issuer system, or by a bridging service provider that is neither an issuer nor an acquirer (as described in more detail below). The emulator module may perform the functions of one or more acquirer mobile apps. The emulator system may log in to the acquirer's system (e.g., a second management of a second service provider) using an acquirer's registered account, called an emulator account. The emulator system may be connected to multiple acquirers so that an issuer can conduct bridging transactions with multiple acquirers. If the emulator system is operated by a bridging service provider, the emulator system may be connected to multiple issuers to provide bridging services to multiple issuers.

[0037] The emulator module of the emulator system may simply be an acquirer's mobile app installed in an emulator that emulates the mobile phone environment. Alternatively, the emulator module may be designed as an integrated module that executes the functions of multiple acquirer apps (if multiple acquirers allow the development of such an integrated module and the module can send and receive data like a regular mobile app). The execution module is configured to send input sent by the payer to the mobile app and obtain as output data received by the mobile app. More specifically, the functions performed by the execution module may include, but are not limited to, (1) receiving input from a first management system, which is one of at least one issuer management system; (2) identifying a second service provider from the multiple acquirers based on the input; (3) providing input to the emulator module based on the identity of the second service provider; (4) receiving output from the emulator module; and (5) providing the output to the first management system. The identity of the second service provider is used to direct input from the first service provider to the correct second service provider. In a CPM bridging transaction embodiment, the aforementioned input may be a target request and the output may be a target or target content of the second management system. In an MPM bridging transaction embodiment, the input may be a target or target content of the second management system and the output may be a payment request initiated by the second management system. In one embodiment, the functionality of the execution module and emulator module described above may be further integrated into a single module.

[0038] In one embodiment, the emulator system has the acquirer's mobile app installed, and the emulator may have one or more of the following capabilities: The emulator may emulate the look and feel of all the functions and features of a mobile device using the target mobile payment app, allowing the acquirer app to function normally as if it were installed on the mobile device; The emulator may capture and pass through content, such as target content (e.g., QR images), between the emulator and the interface between the payer's app and the acquirer app (within the emulator), allowing the payer to present or scan the acquirer's target to transact with the acquirer's payee; The emulator may be integrated with the issuer's other business systems, such as financial systems, transaction decision systems, fraud / risk systems, and user profile systems, so that the payer may transact with the payee in the same way as within the issuer's payment system; If multiple copies of the app are installed on the emulator, the emulator may programmatically navigate and identify the various "screens" of the acquirer app, their content, and data entry fields. The emulator may interact with the acquirer app with prompts such as confirmations, exceptions, and / or error handling.

[0039] In one example, the payee 150 presents a target (such as a transaction QR code in a merchant presentment mode transaction), which the payer 110 then scans and transmits to the emulator system 135 via the first management system 125. In one example, the target is a complete QR code image. The emulator system 135 then "scans" the received target and initiates a payment request using the identity of the emulator account in the payment system of the second service provider 140. After receiving the payment request, the second management system 145 can execute such transaction based on the target information.

[0040] In another example, if the payee 150 needs a target (such as a transaction QR code in a consumer-presented mode transaction) to proceed with the transaction, the emulator system 135 generates such a target using the emulator account ID. The emulator system then transmits the generated target to the payer 110's portable device 115 via the first management system 125. An example of a transmitted target is a complete QR code image for the payee to scan. The payer 110 may then present the target to the payee 150 for scanning. After scanning, the payee's 150's merchant device 155 (such as a POS system) transmits the target information to the second management system 145 to complete the transaction.

[0041] Emulator Account Properties The emulator account, or emulator account number, is a master account similar to corporate accounts in the credit card industry, which have many authorized users (employees). A password may be required and associated with the emulator account to allow login to the acquirer's (second service provider's) mobile app. The emulator account password is highly protected. The password may be cryptographically protected, stored in a vault similar to iOS's Secure Element, and periodically updated with a new password. In one embodiment, the emulator account is never transmitted in its original value or form to both the issuer and acquirer users.

[0042] When communicating with an acquirer, an issuer can use either the aforementioned registered account, the emulator account, or a token associated with the aforementioned emulator account. The token can also be securely encrypted. Depending on the acquirer's mobile app system and communication preferences, the emulator account can be tokenized for added security. The emulator account may also have a Time To Live (TTL) feature, similar to the expiration date of a credit card.

[0043] Since the emulator account is used for multiple transactions from various users, the emulator system may be configured to connect the original transaction from the issuer (first service provider) side to the transaction at the acquirer (second service provider). A pending transaction may be created once the payer initiates the transaction. The transaction can be updated based on the response from the actual transaction at the acquirer's second management system. In one embodiment of CPM, a requested target is tied to the original payer and / or transaction request.

[0044] Additionally, multiple emulator accounts may be created with a single acquirer (second service provider) to (1) reduce transaction volume, (2) avoid transaction collisions, (3) provide redundancy to avoid single points of failure, and (4) prevent account takeover. For example, when multiple bridging transactions are requested with the same acquirer, different emulator accounts may be assigned to different payers of the transactions, since each emulator account registered with the acquirer may not be able to execute multiple transactions simultaneously. The account selected from multiple emulator accounts to execute a transaction with an acquirer is called a bridging account.

[0045] When sending a target (e.g., a QR code) from a merchant (MPM) or user (CPM), the target can be encrypted to avoid MITM (man-in-the-middle) attacks. An added security feature is to attach or associate the transaction amount with the target, which can be used as a second layer of verification. The encryption method for emulator accounts is explained in more detail below.

[0046] Bridging transaction process in merchant presentment mode The process of bridging transactions in merchant presentment mode (MPM) is shown in Figure 2 and described in detail below: An issuer (first service provider) has registered emulator accounts with multiple available acquirers, and each available acquirer has registered at least one emulator account in its network.

[0047] S111: The payer browses the mobile app and selects an acquirer (i.e., selects a second service provider) from a list of MPSPs accepted in their region (e.g., Japan). The payer then scans the merchant target (e.g., merchant QR code), enters the transaction amount, and submits the payment.

[0048] S111(a) and S111(b) describe variations of merchant verification.

[0049] S111(a): Alternatively, the payer can first scan the merchant target and send it to the emulator system to decrypt and verify the merchant information.

[0050] S111(b): The emulator system then sends the merchant information to the payer for confirmation, and the payer enters the transaction amount. If the merchant target already contains the transaction amount, the payer only needs to confirm the payment amount and does not need to enter the transaction amount.

[0051] S112: The payer sends the user identifier (user ID) and the merchant target together with the transaction amount to the issuer's first management system (first MS).

[0052] S113: The first MS decrypts the user ID and records the transaction data in the issuer's payment system. Then, the first MS logs in using the issuer's registered emulator account (called a bridging account) and executes the transaction or scans the merchant target with transaction details such as payment currency and amount.

[0053] S114: The second management system (second MS) of the acquirer (second service provider) executes the payment request using existing processes with the user (in the IGA) and the merchant (decrypting the merchant's target) who has other payment information such as currency and amount.

[0054] S121: The second MS confirms the payment transaction with the merchant, if applicable.

[0055] S122: The second MS confirms the payment transaction to the emulator system.

[0056] S123: The first MS extracts the payment confirmation from the emulator system sent from the second MS.

[0057] S124: The first MS sends a payment confirmation to the payer's portable device. The payment confirmation may be acquirer-specific confirmation page information, which may be generated in the emulator system and sent to the portable device via the first MS.

[0058] S125: If the payer receives acquirer-specific confirmation page information from the first MS or if the issuer's mobile app can generate acquirer-specific confirmation page information based on the transaction result, the payer may present the information. Alternatively, the acquirer-specific confirmation page may not be necessary if the payee can confirm the transaction result via the merchant device.

[0059] The process of bridging transactions in consumer presentation mode The process of bridging transactions in Consumer Present Mode (CPM) is shown in Figure 3 and described in more detail below. Similar to MPM, the issuer (first service provider) registers emulator accounts with multiple available acquirers, and each available acquirer registers at least one emulator account within its network.

[0060] S211: The payer browses the mobile app and selects an acquirer (selects a second service provider) from a list of MPSPs accepted in the region (e.g., Japan). The payer then requests a target (e.g., QR code) from the issuer that the payee (e.g., acquirer merchant) can scan and accept.

[0061] S212: The first management system (first MS) of the issuer sends the target request to the emulator system.

[0062] S213: The emulator system generates a target based on the bridging account (the emulator account used to log in to the second MS).

[0063] S214: The first MS sends the generated target to the payer's portable device. Depending on the acquirer mobile app settings or issuer implemented features, the target can be time-based (TTL - Time To Live), tokenized, or uniquely encrypted so that only the intended mobile user can decrypt the target.

[0064] S215: The payer's portable device displays the target on the payee's merchant device (e.g., merchant POS).

[0065] S221: The recipient scans the target.

[0066] S222: The target or target content is sent to a second management system (second MS) of the acquirer (second service provider).

[0067] S223: The second MS decrypts the target and payee information and confirms the payment transaction to the payee.

[0068] S224: The second MS confirms the payment.

[0069] S225: The second MS confirms the payment to the emulator system.

[0070] S226: The first MS extracts the payment confirmation from the emulator system.

[0071] S227: The payer's portable device receives a payment confirmation from the first MS. The payment confirmation may be in the issuer's form, the acquirer's form, or both. As in S125, the acquirer's form of payment confirmation is acquirer-specific confirmation page information that may be generated in the emulator system and sent to the portable device via the first MS.

[0072] Emulator Account Encryption The emulator account may be encrypted in a variety of ways. One way to encrypt the emulator account is to use the mobile device ID as an encryption key that can only be decrypted by the receiving mobile device in the CPM flow. The mobile device ID is sent to the CPM in S211 when the user first requests the target. The emulator system may encrypt the target using the mobile device ID as the encryption key before S213. The payer's portable device may then decrypt the target using the device ID before presenting it to the merchant in S215.

[0073] Taking the iOS environment implemented on the iPhone as an example, any of the following IDs may be used as the encryption key:

[0074] SEID (Secure Element Identifier): This is a unique identifier for the Secure Element chip in Apple devices, which is used to store sensitive data like credit card information and biometric data.

[0075] -EID (Enterprise Identifier): This is a unique identifier used by companies to manage and use Apple devices within their organization.

[0076] IMEI (International Mobile Equipment Identity): This is a 15-digit unique code used to identify GSM and WCDMA mobile phones. It is used by mobile networks to identify valid devices and prevent fraud.

[0077] -ICCID (Integrated Card Identifier): This is a unique 19-20 digit code used to identify a SIM card. It is used by mobile networks to authenticate and activate the SIM card.

[0078] MEID (Mobile Equipment Identifier): This is a 14-digit unique code used to identify a CDMA mobile phone. It is similar to the IMEI used in GSM and WCDMA phones.

[0079] -IMEI2: This is the second IMEI number that some dual SIM phones have, allowing you to use two different SIM cards at the same time.

[0080] Bridging transactions with bridging service providers An issuer must create at least one emulator account with every acquirer with which it wants to establish bridging transactions. Thus, if an issuer decides to implement this method in various markets with N acquirers, the issuer must set up at least N emulator accounts. Similarly, if there are M issuers connected to a single acquirer, that acquirer must manage at least M accounts. This becomes a multiplication problem when there are many MPSPs in each country. Figure 4A shows an example with six MPSPs. If all six MPSPs are implementing a system for bridging transactions with the other five MPSPs, each MPSP must run an emulator system with five MPSP mobile app capabilities (or run five separate emulator systems for each of the five mobile apps). As a result, the entire network would run at least 30 mobile apps and 30 emulator accounts. Also, if there are 100 MPSPs that want to implement the above-described system and method for bridging transactions, any one MPSP would need to run at least 99 emulator accounts in the system to enable bridging transactions with all other MPSPs. The network becomes simpler if someone can act as a node between all MPSPs, such as a "Bridging Service Provider (Bridging SP)" shown in Figure 4B.

[0081] To simplify this issue, a bridging service provider (named HIVEX® as shown in FIGS. 6 and 7) with a bridging system may be introduced into this example, as shown in FIG. 5. The bridging transaction system has three main participants: a first service provider 120 (issuer), a second service provider 140 (acquirer), and a bridging service provider 130 (HIVEX). The payer 110 is a user of the first service provider 120 and has a registered account with the first service provider 120. The portable device 115 of the payer 110 is a device that connects to the Internet, runs the program of the first service provider 120, and has the capability to present and scan targets (e.g., QR codes). The portable device 115 is wirelessly connected to a first management system 125 of the first service provider 120, which is the operating system of the first service provider 120. The bridging service provider 130 (HIVEX) runs an operating system called the bridging system 131, which includes an emulator system 135 that performs functions related to bridging transactions. In this example, it is HIVEX 130, not the issuer 120, that registers the emulator account with the acquirer 140.

[0082] In HIVEX's bridging network, issuers and acquirers only need to join as members of the network, and transactions can be carried out seamlessly. In this variant, a bridging service provider acts as a "bridge" connecting issuers and acquirers, and the emulator system is part of the bridging service provider's bridging system, not any issuer's system. However, the process for carrying out MPM and CPM transactions is essentially the same as above (Figures 2 and 3), as shown in Figures 6 (MPM) and 7 (CPM).

[0083] (A) Merchant presentation mode The process of bridging transactions in merchant presentment mode (MPM) with a bridging service provider is shown in Figure 6 and is described in detail below: HIVEX (a bridging service provider) has registered emulator accounts with multiple available acquirers, and each available acquirer has registered at least one emulator account with its network.

[0084] S311: This step is the same as S111. The payer browses the mobile app and selects an acquirer (i.e., selects a second service provider) from a list of MPSPs accepted in the region (e.g., Japan). The payer then scans the merchant target (e.g., merchant QR code), enters the transaction amount, and submits the payment.

[0085] The alternative embodiment described in S111(a) and S111(b) also applies here, except that the merchant target must be passed through a bridging system for decoding by the emulator system. In the alternative embodiment, the second service provider may be identified from multiple acquirers without the payer having to make a selection. For example, the second service provider may be identified by the emulator system's first management system pattern matching an image of the target against a library of acquirer logos.

[0086] S312: This step is the same as S112. The payer sends the user ID and the merchant target together with the transaction amount to the issuer's first management system (first MS).

[0087] S313: The first MS relays the user ID and the target of the affiliated store to HIVEX (Bridging System).

[0088] S314: HIVEX (Bridging System) decrypts the user ID and records the transaction data in HIVEX's database. Then HIVEX logs in using a bridging account selected from multiple emulator accounts to execute the transaction or scan the target merchant for detailed transaction information such as payment currency and amount.

[0089] S315: This step is the same as S114. The second management system (second MS) of the acquirer (second service provider) executes the payment request using the existing process with the user (in the bridging account) and the merchant (decrypting the merchant's target) who has other payment information such as currency and amount.

[0090] S321: This step is the same as S121. The second MS confirms the payment transaction with the merchant, if applicable.

[0091] S322: This step is the same as S122. The second MS confirms the payment transaction to the emulator system of HIVEX.

[0092] S323: HIVEX (Bridging System) extracts the payment confirmation from the emulator system sent from the second MS.

[0093] S324: HIVEX sends the extracted payment confirmation to the first MS.

[0094] S325: This step is the same as S124. The first MS sends a payment confirmation to the payer's portable device. The payment confirmation may be acquirer-specific confirmation page information, which may be generated in the emulator system and sent to the portable device via the first MS.

[0095] S326: This step is the same as S125. If the payer has received acquirer-specific confirmation page information from the first MS, or if the issuer's mobile app can generate acquirer-specific confirmation page information based on the transaction result, the payer may present that information. Alternatively, the acquirer-specific confirmation page may not be necessary if the payee can confirm the transaction result via the merchant device.

[0096] (B) Consumer Presentation Mode The process of bridging transactions in Consumer Present Mode (CPM) with a Bridging Service Provider is shown in Figure 7 and is described in detail below. Similar to MPM, HIVEX (the Bridging Service Provider) has registered emulator accounts with multiple available acquirers, and each available acquirer has at least one emulator account registered with its network.

[0097] S411: This step is the same as S211. The payer browses the mobile app and selects an acquirer (selects a second service provider) from a list of MPSPs accepted in the region (e.g., Japan). The payer then requests a target (e.g., QR code) from the issuer that the payee (e.g., acquirer merchant) can scan and accept.

[0098] S412: The issuer's first management system (first MS) sends the target request to HIVEX (the bridging system).

[0099] S413: HIVEX sends the target request to the emulator system to generate an acquirer-specific target.

[0100] S414: This step is the same as S213. The emulator system generates a target based on a bridging account selected from multiple emulator accounts.

[0101] S415: HIVEX (Bridging System) sends the generated target to the issuer's first MS.

[0102] S416: This step is the same as S214. The first MS sends the generated target to the payer's portable device. Depending on the acquirer mobile app settings or features implemented by the issuer, the target can be time-based (TTL - Time To Live), tokenized, or uniquely encrypted so that only the intended mobile user can decrypt the target.

[0103] S417: This step is the same as S215. The payer's portable device displays the target on the payee's merchant device (e.g., merchant POS).

[0104] S421: This step is the same as S221. The recipient scans the target.

[0105] S422: This step is the same as S222. The target or target content is sent to a second management system (second MS) of the acquirer (second service provider).

[0106] S423: This step is the same as S223. The second MS decrypts the target and payee information and confirms the payment transaction to the payee.

[0107] S424: This process is the same as S224 and S225. The second MS confirms the payment to the emulator system.

[0108] S425: This step is the same as S226. HIVEX extracts the payment confirmation from the emulator system.

[0109] S426: HIVEX sends the extracted payment confirmation to the first MS.

[0110] S427: This step is the same as S227. The payer's portable device receives a payment confirmation from the first MS. The payment confirmation may be in the issuer's form, the acquirer's form, or both. As in S125, the acquirer's form of payment confirmation is acquirer-specific confirmation page information, which may be generated in the emulator system and sent to the portable device via the first MS.

[0111] Deploying a bridging system as an emulator system provides scalability benefits as well as additional benefits, such as the ability to write transactions to the blockchain. The bridging system (HIVEX) may record transactions between two different service providers on the blockchain to enable features such as an immutable, decentralized ledger and a faster settlement process. An example of facilitating a blockchain settlement process is described in PCT Publication WO 2018 / 022131, which is incorporated herein by reference.

[0112] The foregoing description of the embodiments is provided to enable one skilled in the art to make and use the subject matter. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the novel principles and subject matter disclosed herein may be applied to other embodiments without the exercise of innovative faculty. The claimed subject matter as set forth in the following claims is not intended to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein. Additional embodiments are contemplated within the spirit and true scope of the disclosed subject matter. Thus, it is intended that the present invention cover modifications and variations that come within the scope of the appended claims and their equivalents.

Claims

1. 1. A method of bridging targets between a payer portable device of a first service provider and a payee merchant device of a second service provider different from the first service provider, comprising: wirelessly receiving, by a first management system of the first service provider, targets or targeted content of the second service provider from a payer portable device; and transmitting, by the first management system of the first service provider, the target or target content of the second service provider to an emulator system, whereby the emulator system decrypts the target or target content, and transmits the decrypted target or target content of the second service provider to a second management system of the second service provider; the portable device is configured to scan the targets of the second service provider and transmit the targets or target content of the second service provider to the first management system; the portable device does not recognize the target of the second service provider; the emulator system recognizes the target of the second service provider; method.

2. The method of claim 1 , wherein the target is a QR code.

3. 10. The method of claim 1, further comprising identifying the second service provider from a plurality of acquirers by the first service provider before sending the target or target content of the second service provider to the emulator system.

4. 4. The method of claim 3, wherein the second service provider is identified from the plurality of acquirers by receiving identification information.

5. 4. The method of claim 3, wherein the second service provider is identified from the plurality of acquirers by performing pattern matching on the target with an acquirer logo library.

6. After transmitting the target or target content of the second service provider to the emulator system, receiving a trade request from the emulator system by the first management system; and The method of claim 1 , further comprising providing a trade approval to the emulator system by the first management system approving the trade request.

7. After transmitting the target or target content of the second service provider to the emulator system, receiving trading results from the emulator system by the first management system; processing a payment from the payer to the first service provider by the first management system according to the transaction result; and 7. The method of claim 6, further comprising wirelessly providing the transaction result by the first management system to the payer's portable device.

8. 2. The method of claim 1, wherein the emulator system operates on the first management system.

9. 2. The method of claim 1, wherein the emulator system operates in a bridging system of a bridging service provider that is different from both the first service provider and the second service provider.

10. 2. The method of claim 1, wherein the emulator system logs into the second management system of the second service provider with a bridging account as a member of the second service provider.

11. 11. The method of claim 10, wherein the bridging account is selected from a plurality of emulator accounts.

12. 1. A method of bridging targets between a payer portable device of a first service provider and a payee merchant device of a second service provider different from the first service provider, comprising: receiving, by a first management system of the first service provider, targets or target content of the second service provider from an emulator system; and wirelessly providing the target or target content of the second service provider to a payer's portable device by the first management system of the first service provider and presenting the target to the merchant device of the payee of the second service provider; the emulator system is capable of generating or receiving the target or target content from the second service provider; the recipient's merchant device does not recognize the target of the first service provider; method.

13. The method of claim 12 , wherein the target is a QR code.

14. before receiving the target or target content of the second service provider; wirelessly receiving, by the first management system, a target request from a payer portable device for the target at the second service provider; and The method of claim 12 , further comprising providing the target request to the emulator system by the first management system.

15. 15. The method of claim 14, further comprising identifying the second service provider from a plurality of acquirers by the first management system before providing the target request to the emulator system.

16. 16. The method of claim 15, wherein the second service provider is identified from a plurality of acquirers by receiving identification information.

17. 16. The method of claim 15, wherein the second service provider is identified from the plurality of acquirers by performing pattern matching on the target with an acquirer logo library.

18. wirelessly providing the target or target content of the second service provider to the payer's portable device and presenting the target to the payee's merchant device; receiving a transaction request from the emulator system by the first management system after the payee merchant device scans the target; and 13. The method of claim 12, further comprising providing a trade approval to the emulator system by the first management system approving the trade request.

19. before providing said transaction authorization to said emulator system; providing the transaction request wirelessly to the payer's portable device by the first management system; and 20. The method of claim 18, further comprising receiving, by the first management system, the transaction authorization wirelessly from the payer's portable device.

20. wirelessly providing the target or target content of the second service provider to the payer's portable device and presenting the target to the payee's merchant device; receiving trading results from the emulator system by the first management system; processing a payment from the payer to the first service provider by the first management system according to the transaction result; and 13. The method of claim 12, further comprising wirelessly providing the transaction result by the first management system to the payer's portable device.

21. 13. The method of claim 12, wherein the emulator system operates on the first management system.

22. 13. The method of claim 12, wherein the emulator system operates in a bridging system of a bridging service provider that is different from both the first service provider and the second service provider.

23. 13. The method of claim 12, wherein the emulator system logs into the second management system of the second service provider with a bridging account as a member of the second service provider.

24. 24. The method of claim 23, wherein the bridging account is selected from a plurality of emulator accounts.

25. 1. A method of bridging targets between a payer portable device of a first service provider and a payee merchant device of a second service provider different from the first service provider, comprising: receiving, by an emulator system, targets or target content of the second service provider from a first management system of the first service provider; decrypting the target or target content of the second service provider by the emulator system; and providing, by the emulator system, the decrypted target or target content of the second service provider to a second management system of the second service provider via a bridging account as a member of the second service provider; method.

26. 26. The method of claim 25, wherein the target is a QR code.

27. before receiving the target or target content of the second service provider from the first management system; 26. The method of claim 25, further comprising receiving, by the emulator system, identity information of the second service provider selected from a plurality of acquirers.

28. After providing the target or target content of the second service provider to the second management system, receiving, by the emulator system, a trade request from the second management system via the bridging account; providing the transaction request by the emulator system to the first management system; receiving, by the emulator system, a transaction approval from the first management system approving the transaction request; and 26. The method of claim 25, further comprising providing, by the emulator system, the trade approval to the second management system via the bridging account.

29. After providing the target or target content of the second service provider to the second management system, receiving, by the emulator system, a trading result from the second management system via the bridging account; and 26. The method of claim 25, further comprising providing the trading results by the emulator system to the first management system.

30. 26. The method of claim 25, wherein the emulator system operates on the first management system.

31. 26. The method of claim 25, wherein the emulator system operates in a bridging system of a bridging service provider that is different from both the first service provider and the second service provider.

32. 28. The method of claim 27, wherein the emulator system has a plurality of emulator accounts registered with the plurality of acquirers, and the bridging account is selected from the plurality of emulator accounts.

33. 1. A method of bridging targets between a portable device of a payer of a first service provider and a scanning system of a payee of a second service provider different from the first service provider, comprising: acquiring, by an emulator system, targets or target content of the second service provider as a member of the second service provider via a bridging account; and providing the target or target content of the second service provider to a first management system of the first service provider by the emulator system, whereby the payer's portable device presents the target generated based on the target content to the payee's merchant device, which recognizes the target of the second service provider; the recipient's merchant device does not recognize the target of the first service provider; method.

34. 34. The method of claim 33, wherein the target is a QR code.

35. before acquiring the target or target content of the second service provider; receiving, by the emulator system, a target request from the first management system for the target of the second service provider; and 34. The method of claim 33, further comprising providing, by the emulator system, the target request to the second service provider via the bridging account.

36. 34. The method of claim 33, wherein an identity of the second service provider selected from a plurality of acquirers is provided with the target request, and the bridging account corresponds to the second service provider.

37. After providing the target or target content of the second service provider to the first management system, receiving, by the emulator system, a transaction request from the second management system after the recipient's merchant device scans the target; providing the transaction request by the emulator system to the first management system; receiving, by the emulator system, a transaction approval from the first management system approving the transaction request; and 34. The method of claim 33, further comprising providing, by the emulator system, the trade approval to the second management system via the bridging account.

38. After providing the target or target content of the second service provider to the first management system, receiving, by the emulator system, a trading result from the second management system via the bridging account; and 34. The method of claim 33, further comprising providing the trading results by the emulator system to the first management system.

39. 34. The method of claim 33, wherein the emulator system operates on the first management system.

40. 34. The method of claim 33, wherein the emulator system operates in a bridging system of a bridging service provider that is different from both the first service provider and the second service provider.

41. 37. The method of claim 36, wherein the emulator system has a plurality of emulator accounts registered with the plurality of acquirers, and the bridging account is selected from the plurality of emulator accounts.

42. 1. An emulator system for bridging targets between a payer portable device of a first service provider and a payee merchant device of a second service provider different from the first service provider, comprising: an execution module configured to communicatively connect to at least one issuer management system; and an emulator module communicatively coupled to the execution module and configured to communicatively couple to a plurality of acquirer management systems, The execution module stores instructions, and in response to executing the instructions: receiving an input from a first management system, the first management system being one of the at least one issuer management system; identifying a second management system from the plurality of acquirer management systems based on the input; providing said input to said emulator module based on said second management system; receiving an output from the emulator module; and providing the output to the first management system; the emulator module is configured to log in to the plurality of acquirer management systems with a plurality of emulator accounts, each of the emulator accounts being registered with one of the plurality of acquirer management systems; Emulator system.

43. 43. The emulator system of claim 42, wherein the emulator module executes multiple acquirer mobile apps to log into the multiple acquirer management systems.

44. 43. The emulator system of claim 42, wherein the input is a target request and the output is a target or target content of the second management system.

45. 43. The emulator system of claim 42, wherein the input is a target or target content of the second management system and the output is a payment request initiated by the second management system.

46. 43. The emulator system of claim 42, wherein none of the plurality of acquirer management systems recognizes each other's targets.

47. 43. The emulator system of claim 42, wherein the emulator system is configured to record the identity of the first administrative system and the identity of the payer upon receiving the input.

Images