System and method for facilitating object bridging

Abstract

The invention relates to a system and method for target bridging between a portable device of a payer of a first service provider and a merchant device of a recipient of a second service provider different from the first service provider. The payment system of the second service provider is logged in with a bridge account through a simulator system, so that the first service provider can perform a transaction with the second service provider through the bridge account even if the first service provider uses a format different from the target format of the second service provider.

Description

Technical Field

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

[0002] The present invention relates to a system and method capable of conducting transactions between two payment service providers with different target formats, particularly for two mobile payment service providers (MPSPs) with different transaction QR code formats. Background Art

[0003] QR code payment is a contactless payment method performed by scanning a QR code through a mobile device application or a merchant point of sale (POS) system. There are two QR code payment methods: the merchant presented mode (MPM) and the consumer presented mode (CPM), which differ in which party presents the QR code for the other party to scan. In the merchant presented mode (MPM), the consumer scans the QR code displayed by the merchant for payment. Conversely, in the consumer presented mode (CPM), the merchant scans the QR code displayed by the consumer to receive payment. Through QR code payment, transactions can be completed even without the traditional infrastructure related to electronic payment (such as payment cards, payment networks, payment terminals, and merchant accounts).

[0004] A mobile payment service provider (MPSP) is a closed-loop payment network that can provide QR code payment services. In such a closed-loop network, the system of any MPSP can facilitate transactions between users and merchants as long as they are both within the network of that MPSP. However, if the user and the merchant are from different networks, transactions cannot be conducted because their respective QR codes cannot be recognized by the other party's system. In other words, both the user and the merchant need to be within the same MPSP network to conduct payment transactions.

[0005] If cross-MPSP transactions are required, a universal payment interface is needed, such as a universal target, an integrated system, and an API. In some instances, a national QR standard is adopted to display a compliant merchant QR (MPM mode) for users of participating MPSPs to scan and make payments. However, it is difficult to popularize this method to all MPSPs because MPSPs lack the motivation to adopt this standard. Summary of the Invention

[0006] The present invention provides a method for performing a transaction between two MPSP systems (one as an issuer and one as an acquirer). This operation can be completed when the issuer has at least one valid account in the acquirer - the Issuer General Account (IGA).

[0007] In one aspect, the present invention provides a method for bridging an object between a portable device of a payer of a first service provider and a merchant device of a recipient of a second service provider different from the first service provider, comprising the following steps: (1) wirelessly receiving, by a first management system of the first service provider, an object or object content of the second service provider from the portable device of the payer; and (2) transmitting, by the first management system of the first service provider, the object or object content of the second service provider to a simulator system, so that the simulator system parses the object or object content and transmits the parsed object or object 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 object of the second service provider and transmit the object or object content of the second service provider to the first management system; the portable device does not recognize an object of the second service provider; and the simulator system recognizes an object of the second service provider. In one embodiment, the object is a QR code.

[0008] Before transmitting the object or object content of the second service provider to the simulator system, the method may further include: identifying the second service provider from a plurality of acquirers. In one embodiment, the second service provider is identified from the plurality of acquirers by receiving an identity information. In another embodiment, the second service provider is identified from the plurality of acquirers by performing a pattern comparison of the object with an acquirer logo library.

[0009] A second aspect of the present invention is to provide a second method for bridging a target between a portable device of a payer of a first service provider and a merchant device of a recipient of a second service provider different from the first service provider, including the following steps: (1) receiving, by a first management system of the first service provider, a target or target content of the second service provider from a simulator system; and (2) wirelessly providing, by the first management system of the first service provider, the target or the target content of the second service provider to the merchant device of the recipient to present the target to the merchant device of the recipient of the second service provider. In this method, the simulator system can generate or receive the target or the target content of the second service provider; and the merchant device of the recipient does not recognize a target of the first service provider. In an embodiment, the target is a QR code.

[0010] Before receiving the target or the target content of the second service provider, the method may further include: (1) wirelessly receiving, by the first management system, a target request for the target of the second service provider from the portable device of the payer; and (2) providing, by the first management system, the target request to the simulator system. In an embodiment, before providing the target request to the simulator system, it further includes: identifying, by the first management system, the second service provider from a plurality of acquirers. The second service provider can be identified from the plurality of acquirers by receiving an identity information, or it can be identified from the plurality of acquirers by performing a pattern comparison of the target with an acquirer logo library.

[0011] To approve a transaction, the method may further include: (1) receiving a transaction request from the simulator system; and (2) providing a transaction permission for approving the transaction request to the simulator system.

[0012] To process a transaction in the network of the first service provider, the method may further include: (1) receiving, by the first management system, a transaction result from the simulator system; (2) processing, by the first management system, a transaction corresponding to the transaction result from the payer to the first service provider; and (3) wirelessly providing, by the first management system, the transaction result to the portable device of the payer.

[0013] A third aspect of the present invention is to provide a third method for object bridging between a portable device of a payor of a first service provider and a merchant device of a recipient of a second service provider different from the first service provider, comprising the following steps: (1) receiving, by an emulator system, an object or object content of the second service provider from a first management system of the first service provider; (2) parsing, by the emulator system, the object or object content of the second service provider; and (3) providing, by the emulator system via a bridging account as a member of the second service provider, the parsed object or object content of the second service provider to a second management system of the second service provider. In an embodiment, the object is a QR code.

[0014] Before receiving the object or object content of the second service provider from the first management system, the method may further include: receiving, by the emulator system, identity information of the second service provider selected from multiple acquirers.

[0015] A fourth aspect of the present invention is to provide a fourth method for object bridging between a portable device of a payor of a first service provider and a merchant device of a recipient of a second service provider different from the first service provider, comprising the following steps: (1) obtaining, by an emulator system via a bridging account as a member of the second service provider, an object or object content of the second service provider; and (2) providing, by the emulator system, the object or object content of the second service provider to a first management system of the first service provider, so that the portable device of the payor presents the object generated based on the object content to the merchant device of the recipient, and the merchant device recognizes the object of the second service provider. In this method, the merchant device does not recognize an object of the first service provider. In an embodiment, the object is a QR code.

[0016] Before obtaining the object or object content of the second service provider, the method may further include: (1) receiving, by the emulator system, an object request for the object of the second service provider from the first management system; and (2) providing, by the emulator system via the bridging account, the object request to the second service provider.

[0017] In an embodiment, an identity of the second service provider is provided together with the object request, and the bridging account corresponds to the second service provider.

[0018] For conducting a bridging transaction, the method may further include: (1) receiving a transaction request from the second management system after the merchant device of the recipient scans the subject; (2) providing the transaction request to the first management system; (3) receiving from the first management system a transaction permission for approving the transaction request; and (4) providing the transaction permission to the second management system via the bridging account. After providing the subject or the subject content of the second service provider to the first management system, the method may further include: (1) receiving a transaction result from the second management system through the bridging account; and (2) providing the transaction result to the first management system.

[0019] In one embodiment, the simulator system runs in the first management system. In another embodiment, the simulator system runs in a bridging system of a bridging service provider different from the first service provider and the second service provider.

[0020] In one embodiment, the simulator system logs in to the second management system of the second service provider as a member of the second service provider using a bridging account. The simulator system may register multiple simulator accounts with multiple acquirers, and the bridging account may be selected from the multiple simulator accounts.

[0021] A fifth aspect of the present invention is to provide a simulator system for bridging a subject between a portable device of a payer of a first service provider and a merchant device of a recipient of a second service provider different from the first service provider, including: (1) an execution module for communicatively connecting to at least one issuer management system; and (2) a simulator module communicatively connected to the execution module and configured to communicatively connect to multiple acquirer management systems. The execution module includes instructions stored thereon for performing actions in response to the execution of the instructions, the actions including: (1) receiving an input from a first management system, where the first management system is one of the at least one issuer management systems; (2) identifying a second management system from the multiple acquirer management systems based on the input; (3) providing the input to the simulator module based on the second management system; (4) receiving an output from the simulator module; and (5) providing the output to the first management system. The simulator module is used to log in to the multiple acquirer management systems using multiple simulator accounts, and each of the multiple simulator accounts is registered with one of the multiple acquirer management systems. In one embodiment, the input is a subject request and the output is a subject or subject content of the second management system. In another embodiment, the input is a subject or subject content of the second management system and the output is a payment request initiated by the second management system.

[0022] In this simulator system, the simulator module can run mobile applications of multiple acquirers to log in to the management systems of the multiple acquirers. The simulator system is configured to record the identity of the first management system and the identity of the payor when receiving the input. None of the multiple acquirer management systems recognize a target of each other.

[0023] Other objects, advantages and novel features of the present invention will become more apparent in the following detailed implementation manners in conjunction with the accompanying drawings. Brief Description of the Drawings

[0024] Figure 1 Showing a system for facilitating bridging transactions in the present invention.

[0025] Figure 2 Showing the process of a Merchant Presented Mode (MPM) bridging transaction.

[0026] Figure 3 Showing the process of a Consumer Presented Mode (CPM) bridging transaction.

[0027] Figure 4A Showing a network of six MPSPs independently executing a target bridging method; Figure 4B Showing a network of six MPSPs executing a target bridging method through a bridging service provider (Bridging SP).

[0028] Figure 5 Showing a modified embodiment of the system for facilitating bridging transactions in the present invention.

[0029] Figure 6 Showing the process of a modified Merchant Presented Mode (MPM) bridging transaction with a bridging service provider.

[0030] Figure 7 Showing the process of a modified Consumer Presented Mode (CPM) bridging transaction with a bridging service provider. Detailed Description of the Invention

[0031] The terms used in the following in this specification are intended to be interpreted in the broadest reasonable manner, even if it is used in conjunction with the detailed implementation manners of certain specific embodiments of the present technology. Certain terms may even be emphasized specifically below; however, any term intended to be interpreted in a restricted manner will be specifically defined in this detailed implementation manners section.

[0032] The embodiments described below can be implemented by programmable circuits programmed or configured in software and / or solid state, or entirely by special-purpose circuits, or in a combination of these forms. Such special-purpose circuits (if any) can be, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), graphics processing units (GPUs), etc.

[0033] This application relates to a method for facilitating transactions 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, barcodes, QR codes, NFC (Near Field Communication) tags, voice signatures, and fingerprints. The target information can be parsed by extracting the features embedded in the target, such as by scanning a QR code, sensing an NFC tag, extracting a voice signature from voice, or scanning a fingerprint, to extract the features and obtain the target information contained therein. In one embodiment of the present invention, the target is a QR code.

[0034] As described above, there are two different MPSPs participating in cross-MPSP transactions, one of which is the issuer and the other is the acquirer. The issuer is a financial institution that provides consumers with payment tools for initiating transactions. On the other hand, the acquirer is a financial institution that provides merchants with the tools required to collect payments from the issuing institution. In this framework, consumers are usually the payers, while merchants are usually the recipients. Depending on their roles in different transactions, a financial institution may sometimes act as an issuer and sometimes as an acquirer. In this document, the mobile payment service provider (MPSP) on the consumer side (issuer) of a cross-MPSP transaction 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).

[0035] To communicate with the acquirer, the issuer creates at least one valid account in the acquirer, namely, the Issuer General Account (IGA). When communicating with the acquirer, the issuer's system (referred to as the First Management System) can use the above-mentioned registered account (i.e., IGA), or a token associated with the above-mentioned registered account or a securely encrypted registered account. In subsequent sections, IGA may be interchangeably referred to as an Issuer General Account, its token, or its encrypted form.

[0036] To enable the issuer and its users to present or recognize the target of the acquirer (which is an MPSP with different target formats), the issuer establishes a simulator system similar to the mobile application provided by the acquirer to its users and uses the IGA as the login account. The IGA used to log in to the acquirer system in this simulator system is called the simulator account. From the perspective of the acquirer, this simulator account is the same as other members, and this simulator system can execute all the functions of the mobile application. That is to say, this mobile application can be installed on the simulator system as if it were an ordinary mobile device, except that the simulator system can have the ability to link user identities, targets, transaction details, and transfer the required data to different parties participating in the transaction. This simulator system is used to execute transactions with the acquirer on behalf of the issuer's users.

[0037] Framework of the bridging transaction system

[0038] A cross-MPSP transaction is called a bridging transaction, and the system that allows such cross-MPSP transactions is called a bridging transaction system, as Figure 1 shown. The bridging transaction system includes two main participants: the first service provider 120 (the issuer) and the second service provider 140 (the acquirer). The payer 110 is a user of the first service provider 120 and has a registered account in the first service provider 120. The portable device 115 of the payer 110 is a device with the ability to connect to the Internet and execute the program of the first service provider 120 for presenting and scanning targets (such as QR codes). Common portable devices include but are not limited to smartphones and tablets. The portable device 115 is wirelessly connected to the first management system 125 of the first service provider 120, where the first management system 125 is the operating system of the first service provider 120. In addition to all the functions of a common MPSP operating system, this first management system 125 also includes a simulator system 135 to execute functions related to bridging transactions. The normal mobile application of the second service provider 140 can be installed on this simulator system 135, so that the simulator system 135 can act as a member of the second service provider 140, where the simulator system 135 uses a simulator account as the login account to participate in the payment network of the second service provider 140 (the acquirer). The second service provider 140 has a second management system 145, which is an operating system that executes the functions of a common MPSP. The recipient 150 (such as a merchant) uses a merchant device 155 (such as a smartphone, tablet, or merchant POS system) to connect to the second management system 145 and the payment network of the second service provider 140.

[0039] As described above, from the perspective of the second service provider, the simulator account is the same as other members. When the payer 110 (usually a consumer) wants to make a payment to the payee 150 (usually a merchant), the payer 110 sends a payment request from his / her portable device 115 to the first management system 125. The first management system 125 then forwards the request via the simulator system 135 to the second management system 145 of the second service provider 140, where the second management system 145 is the operating system of the second service provider 140. The second management system 145 treats the simulator account the same as other members of the second service provider 140 (such as the payee 150). The second service provider 140 receives the payment request from the simulator account and makes the payment to the payee 150. In this system, the payer 110 makes a payment to the first service provider or the simulator account in the payment network of the first service provider 120, and the simulator account makes a payment to the payee in the payment network of the second service provider 140.

[0040] If the first service provider 120 holds multiple simulator accounts in different MPSPs (acquirers), the payer 110 can choose one of these MPSPs (acquirers) as the second service provider 140. For example, the user application of the first service provider 120 can provide a list of acceptable MPSPs (acquirers) based on the geographical location of the portable device 115, and the payer 110 can choose an MPSP that can be accepted by the merchant 150. The selection list of MPSPs can be programmatically controlled or predefined based on preferences or incentives or other business requirements. Alternatively, the selection process can also be automated. For example, the user application of the first service provider 120 can allow the payer 110 to scan the logo of an MPSP and automatically select an MPSP as the second service provider 140 if the user application can identify any MPSP. Then, the first service provider 120 can use one of the multiple simulator accounts as a bridging account to perform the function of the bridging transaction with the selected second service provider 140.

[0041] Simulator System and Simulator Account

[0042] The simulator system 135 is similar to a mobile application provided by the second service provider 140 to its users. However, only the first management system 125 (and not any of the users) can send data to or receive data from the second management system 145 via the simulator system 135. The first service provider 120 establishes a simulator 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 simulator account is an account registered by the first service provider 120 and acts as an ordinary member of the second service provider 140. The simulator system 135 can access data transmitted to the simulator account by the second management system 145.

[0043] A simulator system that performs the bridging transaction function may include an execution module and a simulator module. These two modules can be communicatively connected to each other. In this case, the execution module is the part connected to the issuer (e.g., the first service provider), while the simulator module is the part connected to the acquirer (e.g., the second service provider). The simulator system can be run by the issuer (e.g., the first service provider) as part of the issuer system, or it can be run by a bridging service provider that is neither the issuer nor the acquirer (which will be described in detail below). The simulator module can perform the functions of one or more acquirer mobile applications. The simulator system can use a registered acquirer account (referred to as a simulator account) to log in to the acquirer system (e.g., the second management system of the second service provider). The simulator system can be connected to multiple acquirers, enabling the issuer to conduct bridging transactions with multiple acquirers. In the case where the simulator system is operated by a bridging service provider, it can also be connected to multiple issuers to provide bridging services to multiple issuers.

[0044] The emulator module in the emulator system can simply be the acquirer mobile application installed in the emulator that simulates the mobile phone environment. Alternatively, the emulator module can also be designed as an integrated module that runs the functions of multiple acquirer applications (in the case where multiple acquirers allow the development of such an integrated module, enabling the module to send and receive data like a normal mobile application). The execution module is used to transmit the input sent by the payer to the mobile application and obtain the data received by the mobile application as the output. More specifically, the functions performed by the execution module can include, but are not limited to: (1) receiving an input from a first management system, which is one of the at least one issuer management systems; (2) identifying a second service provider from multiple acquirers based on the input; (3) providing the input to the emulator module based on the identity of the second service provider; (4) receiving an output from the emulator module; (5) providing the output to the first management system. The identity of the second service provider is used to direct the input from the first service provider to the correct second service provider. In an embodiment of the CPM bridging transaction, the above input can be a target request, and the output can be a target or target content of the second management system. In an embodiment of the MPM bridging transaction, the input can be a target or target content of the second management system, and the output can be a payment request initiated by the second management system. In one embodiment, the functions of the above execution module and emulator module can be further integrated into a single module.

[0045] In one embodiment, a mobile application of the acquirer is installed in the emulator system, and the emulator can have one or more of the following functions. The emulator can simulate the appearance and feel of a mobile device using all the functions and features of the mobile payment application, enabling the acquirer's application to operate normally as if it were installed in a mobile device. The emulator can obtain and transmit content (such as a QR image) through the interface between the emulator and the payer application and the acquirer application (in the emulator), allowing the payer to present or scan the acquirer target to execute a transaction with a recipient of the acquirer. The emulator can be integrated with other business systems of the issuer (such as a financial system, a transaction decision system, a fraud / risk system, a user profile system, etc.), enabling the payer to conduct transactions with the recipient similar to those within the issuer's payment system. If multiple copies of the application are installed in the emulator, the emulator can browse and identify different "screens" of the acquirer application, as well as their content and data input fields. The emulator can also interact with the acquirer application according to prompts (such as confirmation, exception, and / or error handling).

[0046] In one example, the recipient 150 presents the target (e.g., a merchant presents a transaction QR code in a model transaction), then the payer 110 scans the target and transmits the target to the simulator system 135 through the first management system 125. In one example, the target is a complete QR code image. Then the simulator system 135 "scans" the received target to initiate a payment request using the identity of the simulator account in the payment system of the second service provider 140. After receiving the payment request, the second management system 145 can execute the transaction based on the information of the target.

[0047] In another example, when the recipient 150 needs a target (e.g., a consumer presents a transaction QR code in a model transaction) to conduct a transaction, the simulator system 135 will generate the target using the identity of the simulator account. Then, the simulator system transmits the generated target to the portable device 115 of the payer 110 through the first management system 125. An example of the transmitted target is a complete QR code image for the recipient to scan. Then the payer 110 can present the target to the recipient 150 for scanning. After the merchant device 155 (e.g., a POS system) of the recipient 150 scans it, it will transmit the target information to the second management system 145 to execute the transaction.

[0048] Features of the simulator account

[0049] The simulator account, or simulator account number, is a master account similar to a corporate account in the credit card industry, where the corporate account has many authorized users (employees). It may require a password and link the password to the simulator account to log in to the acquirer's (second service provider's) mobile application. The password of the simulator account is highly protected. It can be protected by encryption, stored in a vault similar to the Secure Element in iOS, and the password is constantly rotated. In one embodiment, the simulator account is not transmitted to the users of the issuer and acquirer in its original value or format.

[0050] When communicating with the acquirer, the issuer can use the above-registered account, the simulator account, or a token associated with the above simulator account. The token can also be securely encrypted. According to the system and communication settings in the acquirer's mobile application, the simulator account can be tokenized to provide better security. The simulator account may also have a Time To Live (TTL) function similar to the expiration date of a credit card.

[0051] Since the simulator accounts are used in multiple transactions from different users, the simulator system can be configured to link the original transactions from the issuer (first service provider) side to the transactions on the acquirer (second service provider) side. Once the payer initiates a transaction, a pending transaction can be established. The transaction can be updated based on the response of the actual transaction in the second management system of the acquirer. In one embodiment of the CPM, a requested item can be traced back to the original payer and / or the transaction request.

[0052] In addition, many simulator accounts can be established in a single acquirer (second service provider) to (1) relieve the transaction volume, (2) avoid transaction conflicts, (3) provide redundancy to avoid single points of failure, and (4) prevent account theft. For example, if there are many bridging transaction requests to the same acquirer, different simulator accounts can be assigned to different payers for transactions because each simulator account registered in the acquirer may not be allowed to execute multiple transactions simultaneously. The account selected from the multiple simulator accounts to conduct transactions with the acquirer is called the bridging account.

[0053] When a merchant (in MPM) or a user (in CPM) transmits an item (such as a QR code), the item can be encrypted to avoid man-in-the-middle (MITM) attacks. An additional security feature is to append or link the transaction amount to the item for use as a second layer of confirmation. The method of encrypting the simulator account will be introduced in detail later.

[0054] Process of Merchant Presented Mode Bridging Transaction

[0055] The process of a merchant presented mode (MPM) bridging transaction is as Figure 2 shown and will be described in detail below. The issuer (first service provider) has registered simulator accounts with multiple available acquirers, where each available acquirer has at least one simulator account registered in its network.

[0056] S111: A payer browses on a mobile application and selects an acquirer (i.e., selects the second service provider) from a list of acceptable MPSPs in a certain region (such as Japan); then the payer scans a merchant item (such as a merchant QR code), enters the transaction amount, and submits the payment.

[0057] S111(a) and S111(b) describe different forms of confirmation at the merchant storefront.

[0058] S111(a): Alternatively, the payer can also first scan the merchant item and pass it to the simulator system for parsing and confirmation of the merchant information.

[0059] S111(b): The simulator system transmits the merchant information to the payer for confirmation, and the payer enters the transaction amount. If the merchant label already includes the transaction amount, the payer only needs to confirm the payment and does not need to enter the transaction amount.

[0060] S112: The payer sends the user identifier (user ID), the merchant label, and the transaction amount to the first management system (the first MS) of the issuer.

[0061] S113: The first MS parses the user ID and records the transaction data in the payment system of the issuer; then, the first MS logs in to the simulator account (referred to as the bridging account) registered by the issuer and uses it or scans the merchant label to execute the transaction, including detailed transaction information such as the currency and amount of the payment.

[0062] S114: The second management system (the second MS) of the acquirer (the second service provider) uses the existing process to execute the payment request with the user (in the IGA), the merchant (parsing the merchant label), and other payment information such as currency and amount.

[0063] S121: If applicable, the second MS confirms the payment transaction with the merchant.

[0064] S122: The second MS confirms the payment transaction with the simulator system.

[0065] S123: The first MS obtains the payment confirmation sent by the second MS from the simulator system.

[0066] S124: The first MS sends the payment confirmation to the payer's portable device. The payment confirmation can be acquirer-specific confirmation page information, which can be generated in the simulator system and transmitted to the portable device via the first MS.

[0067] S125: If the payer receives the confirmation page information from the first MS, or if the issuer's mobile application can generate the confirmation page information based on the transaction result, he / she can present the acquirer-specific confirmation page information. Or, if the recipient can confirm the transaction result via the merchant device, it may not be necessary to present the acquirer-specific confirmation page.

[0068] Process of the consumer-presented mode bridging transaction

[0069] The process of the consumer-presented mode (CPM) bridging transaction is as Figure 3 shown and will be described in detail below. Similar to the MPM, the issuer (the first service provider) has registered simulator accounts with multiple available acquirers, and each of the available acquirers has at least one simulator account registered in its network.

[0070] S211: The payer browses on the mobile application and selects an acquirer (selects the second service provider) from the list of acceptable MPSPs in a certain region (e.g., Japan); then, the payer requests from the issuer a target (e.g., a QR code) that the recipient (e.g., the merchant of the acquirer) can scan and accept.

[0071] S212: The first management system (the first MS) of the issuer sends a target request to the simulator system.

[0072] S213: The simulator system generates a target based on the bridging account (which is a simulator account for logging into the second MS).

[0073] S214: The first MS sends the generated target to the payer's portable device. Depending on the settings of the acquirer's mobile application or the functions implemented by the issuer, the target can be time-based (e.g., TTL), tokenized, or uniquely encrypted (only the intended mobile user can decrypt the target).

[0074] S215: The payer's portable device displays the target to the merchant device of the recipient (e.g., the merchant POS).

[0075] S221: The recipient scans the target.

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

[0077] S223: The second MS analyzes the target and the recipient information and confirms the payment transaction to the recipient.

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

[0079] S225: The second MS confirms the payment to the simulator system.

[0080] S226: The first MS obtains the payment confirmation from the simulator system.

[0081] S227: The payer's portable device receives the payment confirmation from the first MS. The payment confirmation can be in the format of the issuer, or in the format of the acquirer, or both. Similar to S125, the payment confirmation in the acquirer's format is the acquirer-specific confirmation page information, which can be generated in the simulator system and transmitted to the portable device via the first MS.

[0082] Simulator account encryption

[0083] Simulator accounts can be encrypted in various ways. One of the methods for encrypting simulator accounts is to use the mobile device ID as the encryption key, and only the accepted mobile devices can decrypt it during the CPM process. The mobile device ID is sent in S211 of the CPM when the user first requests the target. Before S213, the simulator system can use the mobile device ID as the encryption key to encrypt the target. Then, before displaying the target to the merchant in S215, the payer's portable device can use its device ID to decrypt the target.

[0084] Taking the iOS environment used in the iPhone as an example, any of the following IDs can be used as the encryption key:

[0085] - SEID (Secure Element Identifier): This is the unique identifier of the secure element chip in the Apple device, used to store sensitive data such as credit card information and biometric data.

[0086] - EID (Enterprise Identifier): This is the unique identifier used by enterprises to manage and deploy Apple devices within their organizations.

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

[0088] - ICCID (Integrated Circuit Card Identifier): This is a unique 19 - 20 - digit code used to identify SIM cards. Mobile networks use it to authenticate and activate SIM cards.

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

[0090] - IMEI2: This is the second IMEI number that some dual - SIM mobile phones have, allowing them to use two different SIM cards simultaneously.

[0091] Bridge transactions with bridging service providers

[0092] An issuer needs to establish at least one simulator account in each acquirer that wishes to establish a bridging transaction. Therefore, when the issuer decides to implement this method in N acquirers in multiple markets, the issuer needs to set up at least N simulator accounts. Similarly, if there are M issuers connected to the same acquirer, the acquirer needs to manage at least M accounts. Since there are many MPSPs in each country, this creates a multiplicative problem. Figure 4A A sample showing 6 MPSPs. If all 6 MPSPs wish to implement a system for bridging transactions with the other 5 MPSPs, each MPSP needs to run a simulator system with the functions of 5 MPSP mobile applications (or run 5 independent simulator systems for 5 mobile applications). As a result, at least 30 mobile applications and 30 simulator accounts will be running in the entire network. And if there are 100 MPSPs wishing to implement the above system and method for bridging transactions, any one MPSP must run at least 99 simulator accounts in its system to achieve bridging transactions with all other MPSPs. If there is someone who can act as a node between all MPSPs, such as Figure 4B shown as the "Bridging Service Provider (Bridging SP)", then the network will be more concise.

[0093] To simplify this problem, in this example, a Bridging Service Provider with a bridging system (referred to as HIVEX, as Figure 6 and Figure 7 shown) can be introduced, as Figure 5 shown. The bridging transaction system includes three main participants: the first service provider 120 (issuer), the second service provider 140 (acquirer), and the bridging service provider 130 (HIVEX). The payer 110 is a user of the first service provider 120 and has a registered account in the first service provider 120. The portable device 115 of the payer 110 is a device capable of connecting to the Internet and executing the program of the first service provider 120 to present and scan a target (e.g., QR code). The portable device 115 is wirelessly connected to the first management system 125 of the first service provider 120, where the first management system 125 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 a simulator system 135 to execute functions related to bridging transactions. In this example, it is HIVEX 130 rather than the issuer 120 that registers the simulator account with the acquirer 140.

[0094] Through the HIVEX bridging network, the issuer and the acquirer can seamlessly execute transactions simply by joining as members of the network. In an embodiment of this type, the bridging service provider acts as a "bridge" connecting the issuer and the acquirer, and the simulator system is part of the bridging system of the bridging service provider, rather than any issuer's system. However, the steps for executing MPM and CPM transactions are substantially the same as those described previously ( Figure 2 and Figure 3 ), as shown in Figure 6 (MPM) and Figure 7 (CPM).

[0095] (I) Merchant Presentation Mode

[0096] The process of a Merchant Presentation Mode (MPM) bridging transaction with a bridging service provider is as shown in Figure 6 and will be described in detail below. HIVEX (the bridging service provider) has registered simulator accounts with multiple available acquirers, where each available acquirer has at least one simulator account registered in its network.

[0097] S311: This step is similar to S111. The payer browses the mobile application, selects an acquirer (i.e., selects the second service provider) from the list of acceptable MPSPs in a certain region (e.g., Japan); the payer scans the merchant target (e.g., merchant QR code), enters the transaction amount, and submits the payment.

[0098] The alternative embodiments described in S111(a) and S111(b) also apply here, except that the merchant target needs to be passed to the bridging system for parsing by the simulator system. In an alternative embodiment, the second service provider can be identified from multiple acquirers without being selected by the payer. For example, the second service provider can be identified by the first management system or the simulator system by performing pattern matching on the target image and the acquirer logo library.

[0099] S312: This step is similar to S112. The payer transmits the user ID and the merchant target, together with the transaction amount, to the first management system (First MS) of the issuer.

[0100] S313: The First MS forwards the user ID and the merchant target to HIVEX (the bridging system).

[0101] S314: HIVEX (the bridging system) parses the user ID and records the transaction data in the HIVEX database; then HIVEX logs in using a bridging account selected from multiple simulator accounts and uses or scans the merchant target to execute the transaction, including detailed transaction information such as the currency and amount of payment.

[0102] S315: This step is similar to S114. The second management system (second MS) of the acquirer (second service provider) uses an existing process to execute a payment request with the user (in the bridging account), the merchant (parsing the merchant target), and other payment information such as currency and amount.

[0103] S321: This step is similar to S121. If applicable, the second MS confirms the payment transaction with the merchant.

[0104] S322: This step is similar to S122. The second MS confirms the payment transaction with the HIVEX simulator system.

[0105] S323: HIVEX (bridging system) obtains the payment confirmation sent by the second MS from the simulator system.

[0106] S324: HIVEX transmits the obtained payment confirmation information to the first MS.

[0107] S325: This step is similar to S124. The first MS sends the payment confirmation to the payor's portable device. The payment confirmation can be an acquirer-specific confirmation page information, which can be generated in the simulator system and transmitted to the portable device via the first MS.

[0108] S326: This step is similar to S125. If the payor receives the confirmation page information from the first MS, or if the issuer's mobile application can generate the confirmation page information based on the transaction result, then he / she can present the acquirer-specific confirmation page information. Or, if the recipient can confirm the transaction result via the merchant device, it may not be necessary to present the acquirer-specific confirmation page.

[0109] (2) Consumer Presentation Mode

[0110] The process of a consumer presentation mode (CPM) bridging transaction with a bridging service provider is as Figure 7 shown and will be described in detail below. Similar to the MPM, HIVEX (bridging service provider) has registered simulator accounts with multiple available acquirers, where each available acquirer has at least one simulator account registered in its network.

[0111] S411: This step is similar to S211. The payor browses on the mobile application and selects an acquirer (selecting the second service provider) from the list of MPSPs acceptable in a certain region (e.g., Japan); then the payor requests from the issuer a target (e.g., a QR code) that the recipient (e.g., the merchant of the acquirer) can scan and accept.

[0112] S412: The first management system (first MS) of the issuer sends a target request to HIVEX (bridging system).

[0113] S413: HIVEX sends a target request to the simulator system to generate a target specific to the acquirer.

[0114] S414: This step is similar to S213. The simulator system generates a target based on a bridging account selected from multiple simulator accounts.

[0115] S415: HIVEX (the bridging system) transmits the generated target to the first MS of the issuer.

[0116] S416: This step is similar to S214. The first MS sends the generated target to the portable device of the payee. Depending on the settings of the acquirer mobile application or the functions implemented by the issuer, the target can be time-based (e.g., TTL), tokenized, or uniquely encrypted (only the intended mobile user can decrypt the target).

[0117] S417: This step is similar to S215. The portable device of the payee displays the target to the merchant device of the recipient (e.g., merchant POS).

[0118] S421: This step is similar to S221. The recipient scans the target.

[0119] S422: This step is similar to S222. The target or the target content is transmitted to the second management system (second MS) of the recipient (second service provider).

[0120] S423: This step is similar to S223. The second MS parses the target and the recipient information and confirms the payment transaction to the recipient.

[0121] S424: This step is similar to S224 and S225. The second MS confirms the payment to the simulator system.

[0122] S425: This step is similar to S226. HIVEX obtains a payment confirmation from the simulator system.

[0123] S426: HIVEX transmits the obtained payment confirmation to the first MS.

[0124] S427: This step is similar to S227. The portable device of the payee receives the payment confirmation from the first MS. The payment confirmation can be in the format of the issuer, or in the format of the acquirer, or both. Similar to S125, the payment confirmation in the acquirer format is the acquirer-specific confirmation page information, which can be generated in the simulator system and transmitted to the portable device via the first MS.

[0125] In addition to the advantages of scalability, introducing a bridging system as a simulator system also has other advantages, such as enabling transactions to be written into the blockchain. The bridging system (HIVEX) can record transactions between two different service providers in the blockchain to achieve features such as an immutable and decentralized ledger, as well as a faster settlement process. Examples of facilitating blockchain settlement processes are described in PCT International Patent Publication No. WO2018 / 022131, which is incorporated herein by reference.

[0126] The embodiments provided above are used to enable any person skilled in the art to make and use the claimed invention. Various modifications to these embodiments will be obvious to those skilled in the art, and the novel principles disclosed herein and the claimed invention can be applied to other embodiments without the use of inventive faculty. The invention claimed in this application is not intended to be limited to the embodiments shown herein, but rather to the broadest scope consistent with the principles and novel features disclosed herein. Additional embodiments are expected to fall within the spirit of the invention disclosed herein and the scope of the claims. Accordingly, the present invention is intended to cover modifications and variations that fall within the scope of this application and its equivalents.

Claims

1. A method for bridging a subject between a portable device of a payer for a first service provider and a merchant device of a recipient of a second service provider different from the first service provider, comprising: Wirelessly receiving, by a first management system of the first service provider, the subject or subject content of the second service provider from the portable device of the payer; And Transmitting, by the first management system of the first service provider, the subject or the subject content of the second service provider to a simulator system, so that the simulator system parses the subject or the subject content and transmits the parsed subject or subject content of the second service provider to a second management system of the second service provider; wherein: The portable device is configured to scan the subject of the second service provider and transmit the subject or the subject content of the second service provider to the first management system; The portable device does not recognize the subject of the second service provider; and The simulator system recognizes the subject of the second service provider.

2. The method according to claim 1, wherein the subject is a QR code.

3. The method according to claim 1, further comprising, before transmitting the subject or the subject content of the second service provider to the simulator system: Identifying the second service provider by the first service provider from a plurality of acquirers.

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

5. The method according to claim 3, wherein the second service provider is identified from the plurality of acquirers by performing a pattern comparison between the subject and an acquirer logo library.

6. The method according to claim 1, further comprising, after transmitting the subject or the subject content of the second service provider to the simulator system: Receiving, by the first management system, a transaction request from the simulator system; And Providing, by the first management system, a transaction permission for approving the transaction request to the simulator system.

7. The method according to claim 6, further comprising, after transmitting the subject or the subject content of the second service provider to the simulator system: Receiving, by the first management system, a transaction result from the simulator system; Processing, by the first management system, the payment from the payer to the first service provider corresponding to the transaction result; And Wirelessly providing, by the first management system, the transaction result to the portable device of the payer.

8. The method according to claim 1, wherein the simulator system runs in the first management system.

9. The method according to claim 1, wherein the simulator system runs in a bridging system of a bridging service provider different from the first service provider and the second service provider.

10. The method according to claim 1, wherein the simulator system logs in to the second management system of the second service provider as a member of the second service provider with a bridging account.

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

12. A target bridging method between a portable device of a payer of a first service provider and a merchant device of a recipient of a second service provider different from the first service provider, comprising: receiving, by a first management system of the first service provider, a target or target content of the second service provider from a simulator system; and wirelessly providing, by the first management system of the first service provider, the target or the target content of the second service provider to the merchant device of the recipient to present the target to the merchant device of the recipient of the second service provider; wherein the simulator system can generate or receive the target or the target content of the second service provider; and the merchant device of the recipient does not recognize the target of the first service provider.

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

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

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

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

17. The method according to claim 15, wherein the second service provider is identified from the plurality of acquirers by performing a pattern comparison of the target with an acquirer logo library.

18. The method according to claim 12, further comprising, after wirelessly providing the target or the target content of the second service provider to the portable device of the payer to present the target to the merchant device of the recipient: receiving, by the first management system, a transaction request from the simulator system after the merchant device of the recipient scans the target; and providing, by the first management system, a transaction permission for approving the transaction request to the simulator system.

19. The method according to claim 18, further comprising, before providing the transaction permission to the simulator system: wirelessly providing, by the first management system, the transaction request to the portable device of the payer; and wirelessly receiving, by the first management system, the transaction permission from the portable device of the payer.

20. The method according to claim 12, further comprising, after wirelessly providing the target or the target content of the second service provider to the portable device of the payer to present the target to the merchant device of the recipient: Receiving, by the first management system, a transaction result from the simulator system; Processing, by the first management system, a transaction from the payer to the first service provider corresponding to the transaction result; And Wirelessly providing, by the first management system, the transaction result to the portable device of the payer.

21. The method according to claim 12, wherein the simulator system runs in the first management system.

22. The method according to claim 12, wherein the simulator system runs in a bridging system of a bridging service provider different from the first service provider and the second service provider.

23. The method according to claim 12, wherein the simulator system logs in to the second management system of the second service provider as a member of the second service provider with a bridging account.

24. The method according to claim 23, wherein the bridging account is selected from multiple simulator accounts.

25. A method for bridging an object between a portable device of a payer for a first service provider and a merchant device of a recipient for a second service provider different from the first service provider, comprising: Receiving, by the simulator system, an object or object content of the second service provider from a first management system of the first service provider; Parsing, by the simulator system, the object or the object content of the second service provider; And Providing, by the simulator system via a bridging account as a member of the second service provider, the parsed object or the object content of the second service provider to a second management system of the second service provider.

26. The method according to claim 25, wherein the object is a QR code.

27. The method according to claim 25, further comprising, before receiving the object or the object content of the second service provider from the first management system: Receiving, by the simulator system, identity information of the second service provider selected from multiple acquirers.

28. The method according to claim 25, further comprising, after providing the object or the object content of the second service provider to the second management system: Receiving, by the simulator system, a transaction request from the second management system via the bridging account; Providing, by the simulator system, the transaction request to the first management system; Receiving, by the simulator system, a transaction permission for approving the transaction request from the first management system; And Providing, by the simulator system, the transaction permission to the second management system via the bridging account.

29. The method according to claim 25, further comprising, after providing the object or the object content of the second service provider to the second management system: Receiving, by the simulator system, a transaction result from the second management system via the bridging account; And Providing, by the simulator system, the transaction result to the first management system.

30. The method according to claim 25, wherein the simulator system runs in the first management system.

31. The method according to claim 25, wherein the simulator system runs in a bridging system of a bridging service provider, and the bridging service provider is different from the first service provider and the second service provider.

32. The method according to claim 27, wherein the simulator system registers multiple simulator accounts with multiple acquirers, and the bridging account is selected from the multiple simulator accounts.

33. A target bridging method between a portable device of a payer for a first service provider and a merchant device of a recipient of a second service provider different from the first service provider, comprising: obtaining, by the simulator system, a target or target content of the second service provider as a member of the second service provider via a bridging account; and providing, by the simulator system, the target or the target content of the second service provider to a first management system of the first service provider, so that the portable device of the payer presents the target generated based on the target content to the merchant device of the recipient, and the merchant device recognizes the target of the second service provider; wherein the merchant device does not recognize the target of the first service provider.

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

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

36. The method according to claim 33, wherein the identity of the second service provider is provided together with the target request, and the bridging account corresponds to the second service provider.

37. The method according to claim 33, further comprising, after providing the target or the target content of the second service provider to the first management system: receiving, by the simulator system, a transaction request from the second management system after the merchant device of the recipient scans the target; providing, by the simulator system, the transaction request to the first management system; receiving, by the simulator system, a transaction permission for approving the transaction request from the first management system; and providing, by the simulator system, the transaction permission to the second management system via the bridging account.

38. The method according to claim 33, further comprising, after providing the target or the target content of the second service provider to the first management system: receiving, by the simulator system, a transaction result from the second management system through the bridging account; and providing, by the simulator system, the transaction result to the first management system.

39. The method according to claim 33, wherein the simulator system runs in the first management system.

40. The method according to claim 33, wherein the simulator system runs in a bridging system of a bridging service provider, and the bridging service provider is different from the first service provider and the second service provider.

41. The method according to claim 36, wherein the bridging account is selected from a plurality of simulator accounts.

42. A simulator system for bridging between a portable device of a payer of a first service provider and a merchant device of a recipient of a second service provider different from the first service provider, comprising: An execution module for communicatively connecting to at least an issuer management system; And A simulator module communicatively connected to the execution module, which is configured to communicatively connect to a plurality of acquirer management systems; Wherein the execution module includes instructions stored thereon for performing actions in response to the execution of instructions, and the actions include: Receiving an input from a first management system, where the first management system is one of the at least issuer management systems; Based on the input, identifying a second management system from the plurality of acquirer management systems; Based on the second management system, providing the input to the simulator module; Receiving an output from the simulator module; and Providing the output to the first management system; And Wherein the simulator module is used to log in to the plurality of acquirer management systems with a plurality of simulator accounts, and each of the plurality of simulator accounts is registered with one of the plurality of acquirer management systems.

43. The simulator system according to claim 42, wherein the simulator module runs mobile applications of a plurality of acquirers to log in to the plurality of acquirer management systems.

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

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

46. The simulator system according to claim 42, wherein none of the plurality of acquirer management systems knows the targets of each other.

47. The simulator system according to claim 42, wherein the simulator system is configured to record the identity of the first management system and the identity of the payer when receiving the input.

Images