Systems and methods to facilitate target bridging

Abstract

This invention relates to a system and method for bridging objects between a portable device of a first service provider's payer and a merchant device of a second service provider's receiver, which is different from the first service provider. By logging into the second service provider's payment system with a bridging account through an emulator system, the first service provider can conduct transactions with the second service provider through the bridging account even if the object format is different from that of the second service provider.

Description

System and method for facilitating target bridging Related Applications: 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 contents of which are incorporated herein by reference. The present invention relates to a system and method for conducting transactions between two payment service providers with different code formats, in particular, two mobile payment service providers (MPSPs) with different transaction QR code formats. QR code payment is a contactless payment method performed by scanning a QR code via a mobile device 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). The difference lies in who presents the QR code for scanning. In merchant presented mode (MPM), consumers use their smartphones to scan a QR code displayed by the merchant to make payments. Conversely, in consumer presented mode (CPM), merchants scan a QR code displayed by the consumer to receive payment. QR code payment allows transactions to be completed even without traditional electronic payment infrastructure (such as payment cards, payment networks, payment terminals, and merchant accounts). A Mobile Payment Service Provider (MPSP) is a closed-loop payment network that offers QR code payment services. Within this closed-loop network, any MPSP's system can facilitate transactions between users and merchants, as long as both are part of the MPSP's network. However, if the user and merchant are on different networks, transactions will be impossible because their respective QR codes will not be recognized by the other's system. In other words, both the user and merchant must be part of the same MPSP network to conduct payment transactions. If transactions are to be conducted across MPSPs, a common payment interface is required, such as a common token, integrated systems, and APIs. In some cases, a national QR code standard is adopted to display a standard merchant QR code (MPM model) for users of participating MPSPs to scan and pay. However, this approach is difficult to scale to across all MPSPs, as MPSPs lack the incentive to adopt the standard. This article provides a method for executing transactions between the systems of two MPSPs (one acting as an issuer and one acting as an acquirer). This can be done when the issuer has at least one valid account (Issuer General Account (IGA)) with the acquirer. In one aspect, the present invention provides a 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, comprising the following steps: (1) wirelessly receiving a target or target content of the second service provider from the portable device of the payer by a first management system of the first service provider; and (2) transmitting the target or target content of the second service provider to a simulator system by the first management system of the first service provider, so that the simulator system parses the target or target content and transmits the parsed 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; the portable device does not recognize the target of the second service provider; and the simulator system recognizes the target of the second service provider. In one embodiment, the target is a QR code. Before transmitting the subject or content of the subject 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 identity information. In another embodiment, the second service provider is identified from the plurality of acquirers by performing a pattern comparison on the subject against an acquirer signature library. A second aspect of the present invention provides 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 receiver of a second service provider different from the first service provider, comprising the following steps: (1) a first management system of the first service provider receives a target or target content of the second service provider from a simulator system, and (2) the first management system of the first service provider wirelessly provides the target or target content of the second service provider to the merchant device of the receiver to present the target to the merchant device of the receiver of the second service provider. In this method, the simulator system can generate or receive the target or target content of the second service provider; and the merchant device of the receiver does not recognize the target of the first service provider. In one embodiment, the target is a QR code. Before receiving the subject or content of the subject from the second service provider, the method may further include: (1) wirelessly receiving, by the first management system, a subject request for the subject from the payee's portable device; and (2) providing, by the first management system, the subject request to the simulator system. In one embodiment, before providing the subject request to the simulator system, the method further includes: identifying, by the first management system, the second service provider from a plurality of acquirers. The second service provider may be identified from the plurality of acquirers by receiving identity information, or by performing a pattern comparison on the subject with an acquirer signature library. To approve the transaction, the method may further include: (1) receiving a transaction request from the simulator system; and (2) providing a transaction approval to the simulator system approving the transaction request. In order to process the transaction in the network of the first service provider, the method may also include: (1) receiving a transaction result from the simulator system by the first management system; (2) processing a transaction corresponding to the transaction result from the payer to the first service provider by the first management system; and (3) wirelessly providing the transaction result to the portable device of the payer by the first management system. A third aspect of the present invention provides a third 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, comprising the following steps: (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) parsing, by the emulator system, the target or target content of the second service provider; and (3) providing, by the emulator system as a member of the second service provider via a bridging account, the parsed target or target content of the second service provider to a second management system of the second service provider. In one embodiment, the target is a QR code. Before receiving the subject or subject content of the second service provider from the first management system, the method may further include: receiving, by the simulator system, identity information of the second service provider selected from a plurality of acquirers. A fourth aspect of the present invention is to provide a fourth 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, comprising the following steps: (1) obtaining a target or target content of the second service provider by a simulator system as a member of the second service provider via a bridging account; and (2) providing the target or target content of the second service provider to a first management system of the first service provider by the simulator system, 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. In this method, the merchant device does not recognize a target of the first service provider. In one embodiment, the target is a QR code. Before obtaining the subject or the subject content of the second service provider, the method may also include: (1) receiving, by the simulator system, a request for the subject of the second service provider from the first management system; and (2) providing, by the simulator system, the subject request to the second service provider via the bridge account. In one embodiment, an identity of the second service provider is provided with the subject request, and the bridge account corresponds to the second service provider. To perform a bridge 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 object; (2) providing the transaction request to the first management system; (3) receiving a transaction approval from the first management system approving the transaction request; and (4) providing the transaction approval to the second management system via the bridge account. After providing the object or the object 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 via the bridge account; and (2) providing the transaction result to the first management system. In one embodiment, the simulator system is run in the first management system. In another embodiment, the simulator system is run in a bridging system of a bridging service provider that is different from the first service provider and the second service provider. In one embodiment, the simulator system logs into the second management system of the second service provider as a member of the second service provider using a bridge account. The simulator system can register multiple simulator accounts at multiple acquirers, and the bridge account can be selected from the multiple simulator accounts. A fifth aspect of the present invention provides a simulator system 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, comprising: (1) an execution module for communication connection to at least one issuer management system; and (2) a simulator module communicatively connected to the execution module, which is configured to communicate with multiple acquirer management systems. The execution module includes instructions stored thereon for performing actions in response to execution of the instructions, the actions comprising: (1) receiving an input from a first management system, the first management system being one of the at least one issuer management system; (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, each of the multiple simulator accounts being registered with one of the multiple 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. In the simulator system, the simulator module can run multiple acquirer mobile applications to log into the multiple acquirer management systems. The simulator system is configured to record the identity of the first management system and the identity of the payer upon receiving the input. None of the multiple acquirer management systems recognizes a target of another. Other objects, advantages and novel features of the present invention will become more apparent from the following detailed description of the embodiments in conjunction with the accompanying drawings. FIG1 shows a system for facilitating bridge transactions according to the present invention. Figure 2 shows the flow of a Merchant Present Mode (MPM) bridge transaction. Figure 3 shows the flow of a Consumer Present Mode (CPM) bridge transaction. FIG4A shows a network of six MPSPs independently executing the target bridging method; FIG4B shows a network of six MPSPs executing the target bridging method through a bridging service provider (bridging SP). FIG5 shows a modified embodiment of the system for facilitating bridging transactions according to the present invention. FIG6 shows the modified flow of a merchant present mode (MPM) bridge transaction with a bridge service provider. FIG7 shows the modified flow of a Consumer Presented Mode (CPM) bridge transaction with a bridge service provider. The terms used in this specification are intended to be interpreted in their broadest reasonable manner, even when used in conjunction with the detailed description of certain specific embodiments of the present technology. Certain terms may even be specifically emphasized below; however, any term intended to be interpreted in any limited manner will be specifically defined in this detailed description section. The embodiments described below may be implemented using programmable circuits programmed or configured using software and / or firmware, or entirely using special-purpose circuits, or a combination thereof. Such special-purpose circuits, if any, may be, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), graphics processing units (GPUs), and the like. This application relates to a method for facilitating transactions between two mobile payment service providers (MPSPs) using different token formats. A token 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. Token information can be parsed by extracting features embedded in the token, such as by scanning a QR code, sensing an NFC tag, extracting a voice signature from speech, or scanning a fingerprint to extract the features and obtain the token information contained therein. In one embodiment of the present invention, the token is a QR code. As mentioned above, two different MPSPs participate in an inter-MPSP transaction: one is the issuer and the other is the acquirer. The issuer is the financial institution that provides consumers with the payment instruments they use to initiate transactions. The acquirer, on the other hand, is the financial institution that provides merchants with the instruments they need to receive payments from the issuer. In this framework, the consumer is typically the payer, while the merchant is typically the receiver. Depending on its role in different transactions, a financial institution may sometimes act as the issuer and sometimes as the acquirer. In this article, the mobile payment service provider (MPSP) on the consumer side (issuer) of an inter-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). To communicate with an acquirer, the issuer creates at least one valid account with the acquirer, namely an Issuer General Account (IGA). When communicating with the acquirer, the issuer's system (referred to as the first management system) can use this registered account (i.e., IGA) or a token associated with this registered account or a securely encrypted registered account. In the following sections, "IGA" will interchangeably refer to an Issuer General Account, its token, or its encrypted form. To enable issuers and their users to present or identify tokens from an acquirer (an MPSP with a different token format), the issuer established a simulator system similar to the mobile application provided by the acquirer to its users, using the IGA as the login account. The IGA used to log into the acquirer's system within the simulator system is called a simulator account. From the acquirer's perspective, the simulator account is identical to any other member, and the simulator system can perform all the functions of the mobile application. In other words, the mobile application can be installed on the simulator system just like a regular mobile device, except that the simulator system can link user identity, tokens, and transaction details, and transmit the required information to the various parties involved in the transaction. The simulator system is used to execute transactions with the acquirer for the issuer's users. Bridge Trading System Framework A cross-MPSP transaction is called a bridge transaction, and the system that enables such cross-MPSP transactions is called a bridge transaction system, as shown in Figure 1. The bridge transaction system involves two key participants: a first service provider 120 (issuer) and a second service provider 140 (acquirer). Payer 110 is a user of first service provider 120 and has a registered account with first service provider 120. Payer 110's portable device 115 is a device capable of connecting to the internet and running the first service provider's 120 program, used to present and scan objects (such as QR codes). Common portable devices include, but are not limited to, smartphones and tablets. Portable device 115 wirelessly connects to first service provider 120's first management system 125, which serves as its operating system. In addition to all the functions of a standard MPSP operating system, first management system 125 also includes an emulator system 135 to perform bridge transaction-related functions. Second service provider 140's standard mobile application can be installed on emulator system 135, allowing emulator system 135 to act as a member of second service provider 140. Emulator system 135 uses a emulator account as a login to participate in the payment network of second service provider 140 (acquirer). Second service provider 140 has a second management system 145, an operating system that performs the functions of a standard MPSP. Recipient 150 (e.g., a merchant) uses a merchant device 155 (e.g., a smartphone, tablet, or merchant POS system) to connect to second management system 145 and the payment network of second service provider 140. As described above, from the perspective of the second service provider, the simulator account is treated the same as any other member. When a payer 110 (typically a consumer) wishes to make a payment to a recipient 150 (typically a merchant), payer 110 sends a payment request from their portable device 115 to the first management system 125. First management system 125 then forwards the request via simulator system 135 to the second management system 145 of the second service provider 140, which serves as the operating system of the second service provider 140. Second management system 145 treats the simulator account the same as any other member of the second service provider 140 (e.g., recipient 150). Second service provider 140 receives the payment request from the simulator account and executes the payment to recipient 150. In this system, payer 110 pays the first service provider 120 or the simulator account through its payment network, while the simulator account pays the recipient through its payment network. If the first service provider 120 maintains multiple simulator accounts with different MPSPs (acquirers), the payer 110 can select one of these MPSPs as the second service provider 140. For example, the user application of the first service provider 120 may provide a list of acceptable MPSPs (acquirers) based on the geographic location of the portable device 115, and the payer 110 may select an MPSP that is acceptable to the merchant 150. The selection list of MPSPs may be programmable or predefined based on preferences, incentives, or other business requirements. Alternatively, the selection process may be automated. For example, the user application of the first service provider 120 may allow the payer 110 to scan an MPSP logo and automatically select an MPSP as the second service provider 140 if the user application can identify any MPSP. The first service provider 120 can then use one of the multiple simulator accounts as a bridge account to perform bridge transactions with the selected second service provider 140. Simulator system and simulator account Simulator system 135 is similar to the mobile application provided by second service provider 140 to its users. However, only first management system 125 (not any user) can send or receive data to or from second management system 145 via simulator system 135. First service provider 120 establishes a simulator account in the payment system of second service provider 140 to interact with other members of the payment system. Within the payment system of second service provider 140, the simulator account is registered by first service provider 120 and acts as a regular member of second service provider 140. Simulator system 135 can access data transmitted to the simulator account by second management system 145. A simulator system that performs bridging transaction functions may include an execution module and a simulator module. These two modules may be communicatively connected to each other. In this case, the execution module is the component that connects to the issuer (e.g., the first service provider), while the simulator module is the component that connects 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's system, or it can be run by a bridging service provider that is neither an issuer nor an acquirer (as described in detail below). The simulator module can perform the functions of one or more acquirer mobile applications. The simulator system can log into the acquirer's system (e.g., the second management system of the second service provider) using a registered acquirer account (referred to as a simulator account). The simulator system can connect to multiple acquirers, allowing an issuer to conduct bridge transactions with multiple acquirers. If the simulator system is operated by a bridging service provider, it can also connect to multiple issuers to provide bridging services to multiple issuers. The simulator module in the simulator system can be simply an acquirer mobile application installed in a simulator that simulates a mobile phone environment. Alternatively, the simulator module can also be designed as an integrated module that runs the functions of multiple acquirer applications (if the multiple acquirers allow the development of such integrated modules, the module can send and receive data like an ordinary 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 output. In more detail, the functions performed by the execution module may include but are not limited to: (1) receiving an input from the first management system, which is one of the at least one issuer management system; (2) based on the input, identifying a second service provider from multiple acquirers; (3) providing the input to the simulator module based on the identity of the second service provider; (4) receiving an output from the simulator 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 a CPM bridge transaction, the input can be a bid request, and the output can be a bid or bid content from the second management system. In an embodiment of an MPM bridge transaction, the input can be a bid or bid content from 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 execution module and simulator module can be further integrated into a single module. In one embodiment, an acquirer's mobile application is installed in a simulator system, and the simulator can have one or more of the following functions. The simulator can simulate the look and feel of a mobile device using all the functions and features of the mobile payment application, allowing the acquirer's application to function normally as if installed on the mobile device. The simulator can capture and transmit content (such as a QR code image) through the interface between the simulator and the payer application and the acquirer application (within the simulator), allowing the payer to present or scan the acquirer's token to execute a transaction with a recipient of the acquirer. The simulator can integrate with other business systems of the issuer (e.g., financial systems, transaction decision systems, fraud / risk systems, user profile systems, etc.) to enable 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 simulator, the simulator can navigate and identify the different "screens" of the acquirer application, their content, and data entry fields. The simulator can also interact with the acquirer application based on prompts (e.g., confirmation, exception, and / or error handling). In one example, the recipient 150 presents a token (e.g., a QR code in a merchant-presented transaction). The payer 110 then scans the token and transmits it to the simulator system 135 via the first management system 125. In one example, the token is a complete QR code image. The simulator system 135 then "scans" the received token 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 token information. In another example, when a recipient 150 requires a token (e.g., a QR code in a consumer-presented transaction) to conduct a transaction, the simulator system 135 generates the token using the identity of the simulator account. The simulator system then transmits the generated token to the payer 110's portable device 115 via the first management system 125. An example of the transmitted token is a complete QR code image for the recipient to scan. The payer 110 can then present the token to the recipient 150 for scanning. After scanning, the recipient 150's merchant device 155 (e.g., a POS system) transmits the token information to the second management system 145 to execute the transaction. Features of simulator accounts A simulator account, or simulator account number, is a master account similar to a business account in the credit card industry, with multiple authorized users (employees). A password may be required and linked to the simulator account to log into the acquirer's (secondary service provider) mobile app. The simulator account password is highly protected. It can be encrypted, stored in a vault similar to the Secure Element in iOS, and continuously rotated with a new password. In one embodiment, the simulator account is never transmitted in its original value or format to users at the issuer or acquirer. When communicating with acquirers, issuers may use the registered account, a simulator account, or a token associated with the simulator account. This token can also be securely encrypted. Depending on the system and communication settings in the acquirer's mobile app, the simulator account can be tokenized for enhanced security. Simulator accounts may also have a time-to-live (TTL) feature similar to a credit card expiration date. Because simulator accounts are used for multiple transactions from different users, the simulator system can be configured to link the original transaction from the issuer (first service provider) to the transaction on the acquirer (second service provider). Once a payer initiates a transaction, a pending transaction is created. This transaction can be updated based on the actual transaction response in the acquirer's second management system. In one embodiment of CPM, a requested item can be traced back to the original payer and / or transaction request. In addition, many simulator accounts can be established in a single acquirer (second service provider) to (1) alleviate 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 bridge transaction requests to the same acquirer, different simulator accounts can be assigned to different payers to conduct transactions, because each simulator account registered with the acquirer may not be allowed to perform multiple transactions simultaneously. The account selected from the multiple simulator accounts to conduct transactions with the acquirer is called a bridge account. When a merchant (on an MPM) or user (on a CPM) transmits a token (e.g., a QR code), it can be encrypted to prevent man-in-the-middle (MITM) attacks. An additional security feature is to append or link the transaction amount to the token as a second layer of confirmation. Simulator account encryption methods are described in detail later. Merchant Presentation Mode Bridge Transaction Process The process of a Merchant Presented Mode (MPM) bridge transaction is shown in Figure 2 and described in detail below. The issuer (first service provider) has registered simulator accounts with multiple available acquirers, each of which has at least one simulator account registered in its network. S111: A payer browses on a mobile application and selects an acquirer (i.e., selects a second service provider) from a list of acceptable MPSPs in a certain region (e.g., Japan); the payer then scans a merchant identifier (e.g., a merchant QR code), enters the transaction amount, and submits the payment. S111(a) and S111(b) describe different forms of confirmation in merchant stores. S111 (a): Alternatively, the payer may first scan the merchant's label and pass it to the simulator system to parse and confirm the merchant information. S111(b): The simulator system transmits the merchant information to the payee for confirmation, and the payee enters the transaction amount. If the merchant bid already includes the transaction amount, the payee only needs to confirm the payment and does not need to enter the transaction amount. S112: The payer sends the user identifier (user ID) and the merchant target, along with the transaction amount, to the issuer's first management system (first MS). S113: The first MS parses the user ID and records the transaction information in the issuer's payment system; then, the first MS uses the simulator account (called a bridge account) registered by the issuer to log in and use or scan the merchant token to execute the transaction, including detailed transaction information, such as the currency and amount of payment. S114: The second management system (second MS) of the acquirer (second service provider) uses existing processes to execute the payment request with the user (in the IGA), the merchant (parsed merchant target) and other payment information such as currency and amount. S121: If applicable, the second MS confirms the payment transaction to the merchant. S122: The second MS confirms the payment transaction to the simulator system. S123: The first MS retrieves the payment confirmation sent by the second MS from the simulator system. S124: The first MS sends a payment confirmation to the payer's portable device. The payment confirmation may be a confirmation page message unique to the acquirer, which may be generated in the simulator system and transmitted to the portable device via the first MS. S125: If the payer receives a confirmation page message from the first mobile device, or if the issuer's mobile application can generate a confirmation page message based on the transaction results, he / she may present the acquirer-specific confirmation page message. Alternatively, if the recipient can confirm the transaction results via the merchant device, then presenting the acquirer-specific confirmation page may not be necessary. Process of bridging transactions in the consumer-presentation mode The process for a Consumer Present Mode (CPM) bridge transaction is shown in Figure 3 and described in detail below. Similar to MPM, the issuer (first service provider) has registered simulator accounts with multiple available acquirers, each of which has at least one simulator account registered on its network. S211: The payer browses on the mobile application and selects an acquirer (selects a second service provider) from a list of acceptable MPSPs in a certain region (e.g., Japan); the payer then requests from the issuer a symbol (e.g., a QR code) that the recipient (e.g., the acquirer's merchant) can scan and accept. S212: The issuer's first management system (first MS) sends a target request to the simulator system. S213: The simulator system generates a target according to the bridge account (which is the simulator account used to log in to the second MS). S214: The first MS sends the generated token to the payee's portable device. Depending on the acquirer's mobile application settings or the issuer's implemented functionality, the token can be time-based (e.g., TTL), tokenized, or uniquely encrypted (only the intended mobile user can decrypt the token). S215: The payer's portable device displays the target to the recipient's merchant device (eg, merchant POS). S221: The receiver scans the target. S222: The subject matter or subject matter content is transmitted to a second management system (second MS) of the acquirer (second service provider). S223: The second MS parses the target and recipient information and confirms the payment transaction with the recipient. S224: The second MS confirms the payment. S225: The second MS confirms the payment to the simulator system. S226: The first MS retrieves the payment confirmation from the simulator system. S227: The payer's portable device receives a payment confirmation from the first mobile station. This payment confirmation can be in the issuer's format, the acquirer's format, or both. Similar to S125, the acquirer-formatted payment confirmation is a unique confirmation page message generated in the simulator system and transmitted to the portable device via the first mobile station. Simulator account encryption Simulator accounts can be encrypted using a variety of methods. One method uses the mobile device ID as an encryption key, which can only be decrypted by the receiving mobile device during the CPM process. The mobile device ID is sent in S211 of the CPM when the user first requests a bid. Before S213, the simulator system can use the mobile device ID as the encryption key to encrypt the bid. The payee's portable device can then use its device ID to decrypt the bid before displaying the bid to the merchant in S215. Taking the iOS environment used in iPhone as an example, any of the following IDs can be used as encryption keys: - SEID (Secure Element Identifier): This is a unique identifier for the secure element chip in Apple devices, used to store sensitive data such as credit card information and biometric data. - EID (Enterprise Identifier): This is a unique identifier used by enterprises to manage and deploy Apple devices within their organization. - 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 fraudulent activity. - ICCID (Integrated Circuit Card Identifier): This is a unique 19-20 digit code that identifies the SIM card. Mobile networks use it to authenticate and activate the SIM card. - MEID (Mobile Equipment Identifier): This is a unique 14-bit code used to identify a CDMA mobile phone. It is similar to the IMEI used by GSM and WCDMA phones. - IMEI2: This is the second IMEI number that some dual SIM phones have, allowing them to use two different SIM cards at the same time. Bridge transactions with bridge service providers An issuer needs to establish at least one simulator account with each acquirer with which it wishes to establish bridge transactions. Therefore, if an issuer decides to implement this method with N acquirers across multiple markets, it will need to set up at least N simulator accounts. Similarly, if M issuers are connected to the same acquirer, that acquirer will need to manage at least M accounts. This multiplication problem arises because there are many MPSPs in each country. Figure 4A shows an example with six MPSPs. If all six MPSPs wish to implement a system that bridges transactions with five other MPSPs, each MPSP will need to run a simulator system with the functionality of five MPSP mobile applications (or five separate simulator systems for each of the five mobile applications). As a result, the entire network will have at least 30 mobile applications and 30 simulator accounts running. Furthermore, if 100 MPSPs wish to implement the system and method for bridge transactions, each MPSP must run at least 99 simulator accounts in its system to enable bridge transactions with all other MPSPs. If someone can act as a node between all MPSPs, such as the “Bridge Service Provider (Bridge SP)” shown in Figure 4B, the network will be much simpler. To simplify this issue, we can introduce a bridge service provider (called HIVEX, as shown in Figures 6 and 7) with a bridge system, as shown in Figure 5. The bridge transaction system includes three key participants: the first service provider 120 (issuer), the second service provider 140 (acquirer), and the bridge service provider 130 (HIVEX). Payer 110 is a user of the first service provider 120 and has a registered account with the first service provider 120. Payer 110's portable device 115 is capable of connecting to the internet and running the first service provider 120 program, allowing it to present and scan a token (e.g., a QR code). Portable device 115 is wirelessly connected to the first management system 125 of the first service provider 120, which serves as the operating system of the first service provider 120. Bridge service provider 130 (HIVEX) runs an operating system called the bridge system 131, which includes an emulator system 135 to perform functions related to bridge transactions. In this example, HIVEX 130, rather than the issuer 120, registers the simulator account with the acquirer 140. Through the HIVEX bridging network, issuers and acquirers simply join as network members to seamlessly execute transactions. In this type of embodiment, the bridging service provider acts as the "bridge" connecting issuers and acquirers, and the simulator system is part of the bridging service provider's bridging system, not any issuer's system. However, the steps for executing MPM and CPM transactions are essentially the same as described previously (Figures 2 and 3), as shown in Figures 6 (MPM) and 7 (CPM). (1) Merchant Presentation Mode The flow of a Merchant Presented Mode (MPM) bridge transaction with a bridge service provider is shown in Figure 6 and described in detail below. HIVEX (the bridge service provider) has registered simulator accounts with multiple available acquirers, each of which has at least one simulator account registered in its network. S311: This step is similar to S111. The payer browses the mobile app and selects an acquirer (i.e., a second service provider) from a list of acceptable MPSPs for a particular region (e.g., Japan). The payer scans the merchant identifier (e.g., the merchant's QR code), enters the transaction amount, and submits the payment. The alternative embodiments described in S111(a) and S111(b) also apply here, except that the merchant token must be passed to the bridge 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 simulator system by performing a pattern comparison on the token image against a library of acquirer signatures. S312: This step is similar to S112. The payer transmits the user ID and merchant identifier, along with the transaction amount, to the issuer's first management system (first MS). S313: The first MS transfers the user ID and the merchant target to HIVEX (bridge system). S314: HIVEX (the bridge system) resolves the user ID and records the transaction information in HIVEX's database; HIVEX then logs in using the bridge account selected from multiple simulator accounts and uses or scans the merchant token to execute the transaction, including detailed transaction information such as the currency and amount of payment. S315: This step is similar to S114. The acquirer's (second service provider's) second management system (second MS) uses existing processes to execute the payment request using the user (in the bridge account), the merchant (by parsing the merchant's target), and other payment information such as currency and amount. S321: This step is similar to S121. If applicable, the second MS confirms the payment transaction with the merchant. S322: This step is similar to S122. The second MS confirms the payment transaction to the HIVEX simulator system. S323: HIVEX (bridge system) captures the payment confirmation sent by the second MS from the simulator system. S324: HIVEX transmits the captured payment confirmation message to the first MS. S325: This step is similar to S124. The first MS sends the payment confirmation to the payee's portable device. The payment confirmation can be a unique confirmation page message of the acquirer, which can be generated in the simulator system and sent to the portable device via the first MS. S326: This step is similar to S125. If the payer receives a confirmation page message from the first mobile device, or if the issuer's mobile application can generate a confirmation page message based on the transaction results, the payer can present the acquirer-specific confirmation page message. Alternatively, if the recipient can confirm the transaction results via the merchant device, presenting the acquirer-specific confirmation page may not be necessary. (2) Consumer Presentation Mode The process of a Consumer Presented Mode (CPM) bridge transaction with a bridge service provider is shown in Figure 7 and described in detail below. Similar to MPM, HIVEX (the bridge service provider) registers simulator accounts with multiple available acquirers, each of which has at least one simulator account registered on its network. S411: This step is similar to S211. The payer browses on the mobile app and selects an acquirer (selecting the second service provider) from a list of acceptable MPSPs for a particular region (e.g., Japan). The payer then requests from the issuer a symbol (e.g., a QR code) that the recipient (e.g., the acquirer's merchant) can scan and accept. S412: The issuer's first management system (first MS) sends a target request to HIVEX (bridge system). S413: HIVEX sends a target request to the simulator system to generate a target specific to the acquirer. S414: This step is similar to S213. The simulator system generates a target based on the bridge account selected from the multiple simulator accounts. S415: HIVEX (the bridging system) transmits the generated target to the first MS of the issuer. S416: This step is similar to S214. The first mobile device sends the generated token to the payee's portable device. Depending on the acquirer's mobile application settings or the issuer's implemented functionality, the token can be time-based (e.g., TTL), tokenized, or uniquely encrypted (only the intended mobile user can decrypt the token). S417: This step is similar to S215. The payer's portable device displays the target to the receiver's merchant device (eg, merchant POS). S421: This step is similar to S221. The receiver scans the target. S422: This step is similar to S222. The subject or subject content is transmitted to a second management system (second MS) of the recipient (second service provider). S423: This step is similar to S223. The second MS parses the target and recipient information and confirms the payment transaction to the recipient. S424: This step is similar to S224 and S225. The second MS confirms payment to the simulator system. S425: This step is similar to S226. HIVEX retrieves the payment confirmation from the simulator system. S426: HIVEX transmits the captured payment confirmation to the first MS. S427: This step is similar to S227. The payer's portable device receives a payment confirmation from the first mobile station. This payment confirmation can be in the issuer's format, the acquirer's format, or both. Similar to S125, the acquirer-formatted payment confirmation is a unique acquirer-specific confirmation page message, which can be generated in the simulator system and transmitted to the portable device via the first mobile station. In addition to the scalability benefits, introducing a bridge system as a simulator offers other advantages, such as enabling transactions to be written to the blockchain. The bridge system (HIVEX) can record transactions between two different service providers on the blockchain, achieving features such as an immutable and decentralized ledger, as well as a faster settlement process. An example of facilitating blockchain settlement is described in PCT International Patent Publication No. WO2018 / 022131, which is incorporated herein by reference. The embodiments provided above are intended to enable anyone of ordinary skill in the art to make and use the present invention. Various modifications to these embodiments will be apparent to those of ordinary skill in the art, and the novel principles disclosed herein and the present invention may be applied to other embodiments without the use of innovative capabilities. The invention claimed in the claims is not intended to be limited to the embodiments shown herein, but is to be construed in the widest sense consistent with the principles and novel features disclosed herein. Additional embodiments are expected to fall within the spirit and scope of the invention disclosed in this case. Therefore, the present invention is intended to cover modifications and variations that fall within the scope of the appended claims and their equivalents. none

Claims

1. A method for bridging a subject matter between a portable device of a payer to a first service provider and a merchant device of a receiver to a second service provider whose subject matter format is not compatible with the first service provider, comprising: The first management system of the first service provider wirelessly receives a target or the content of a target from the payer's portable device; The first management system of the first service provider transmits 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; wherein: the first service provider is a payment service provider used by the payer to make payment by scanning the object; the second service provider is a payment service provider used by the receiver to make payment by scanning the object; 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 cannot parse an object of the second service provider; and the first management system needs to use the simulator system to parse an object of the second service provider.

2. As in request item 1, where the target is a QR code.

3. The method of request item 1, further comprising, before transmitting the object or content of the object of the second service provider to the simulator system: The first service provider identifies the second service provider from among multiple acquiring parties.

4. The method of request item 3, wherein the second service provider is identified from the plurality of acquirers by receiving an identity information.

5. The method of request item 3, wherein the second service provider is identified from the plurality of acquirers by performing a pattern comparison of the target with an acquirer identifier library.

6. The method of request item 1, further comprising, after transmitting the object or content of the object of the second service provider to the simulator system: The first management system receives a transaction request from the simulator system; And the first management system provides the simulator system with a transaction license to approve the transaction request.

7. The method of request item 6, after transmitting the object or content of the object of the second service provider to the simulator system, further includes: The first management system receives a transaction result from the simulator system; The first management system processes a payment from the payer to the first service provider corresponding to the transaction result; and the first management system wirelessly provides the transaction result to the payer's portable device.

8. The method of request item 1, wherein the simulator system runs in the first management system.

9. The method of request item 1, wherein the simulator system runs on a bridging system of a bridging service provider, which is different from the first service provider and the second service provider.

10. The method of request item 1, wherein the simulator system logs into the second management system of the second service provider as a member of the second service provider using a bridging account.

11. The method of request item 10, wherein the bridging account is selected from multiple emulator accounts.

12. A method for bridging a subject matter between a portable device of a payer to a first service provider and a merchant device of a receiver to a second service provider whose subject matter format is not compatible with the first service provider, comprising: The first management system of the first service provider receives a target or the content of a target from a simulator system; The first service provider's first management system wirelessly provides the second service provider's object or object content to the recipient's merchant device to present the object to the recipient's merchant device; wherein: the first service provider is a payment service provider used by the payer to make payment by scanning the object; the second service provider is a payment service provider used by the recipient to make payment by scanning the object; the simulator system can generate or receive the second service provider's object or object content; and the recipient's merchant device cannot parse an object from the first service provider.

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

14. The method of request item 12, further comprising, before receiving the subject matter or the content of the subject matter from the second service provider: The first management system wirelessly receives a request for a subject matter from the payer's portable device for the subject matter of the second service provider; And the request for the target is provided to the simulator system by the first management system.

15. The method of request item 14, further comprising, before providing the request for the subject matter to the simulator system: The first management system identifies the second service provider from among multiple acquiring parties.

16. The method of request item 15, wherein the second service provider is identified from the plurality of acquirers by receiving an identity information.

17. The method of 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 identifier library.

18. The method of claim 12, after wirelessly providing the subject matter or content of the subject matter of the second service provider to the payer's portable device to present the subject matter to the recipient's merchant device, further includes: After the merchant device of the recipient scans the target, the first management system receives a transaction request from the simulator system. And the first management system provides the simulator system with a transaction license to approve the transaction request.

19. The method of request item 18, further comprising, before providing the transaction license to the simulator system: The first management system wirelessly provides the transaction request to the payer's portable device; And the first management system wirelessly receives the transaction authorization from the payer's portable device.

20. The method of claim 12, after wirelessly providing the subject matter or content of the subject matter of the second service provider to the payer's portable device to present the subject matter to the recipient's merchant device, further includes: The first management system receives a transaction result from the simulator system; The first management system processes a transaction corresponding to the transaction result from the payer to the first service provider; and the first management system wirelessly provides the transaction result to the payer's portable device.

21. The method of request item 12, wherein the simulator system runs in the first management system.

22. The method of claim 12, wherein the simulator system runs on a bridging system of a bridging service provider, which is different from the first service provider and the second service provider.

23. The method of request item 12, wherein the simulator system logs into the second management system of the second service provider as a member of the second service provider using a bridging account.

24. The method of request item 23, wherein the bridging account is selected from multiple emulator accounts.

25. A method for bridging a subject matter between a portable device of a payer to a first service provider and a merchant device of a receiver of a second service provider whose subject matter format is not compatible with the first service provider, comprising: A simulator system receives a target or target content from a first management system of the first service provider; the simulator system parses the target or target content of the second service provider. The simulator system, via a bridging account as a member of the second service provider, provides the parsed object or the object content of the second service provider to a second management system of the second service provider; wherein: the first service provider is a payment service provider used by the payer to make payment by scanning the object; the second service provider is a payment service provider used by the recipient to make payment by scanning the object; and the first management system needs to use the simulator system to parse the object of the second service provider.

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

27. The method of claim 25, prior to receiving the subject matter or content of the subject matter from the second service provider from the first management system, further includes: The simulator system receives the identity information of the second service provider selected from multiple acquirers.

28. The method of claim 25, after providing the second service provider's subject matter or the content of the subject matter to the second management system, further includes: The simulator system receives a transaction request from the second management system via the bridging account; The simulator system provides the transaction request to the first management system; the simulator system receives a transaction license from the first management system approving the transaction request; and the simulator system provides the transaction license to the second management system via the bridging account.

29. The method of claim 25, after providing the second service provider's subject matter or the content of the subject matter to the second management system, further includes: The simulator system receives a transaction result from the second management system via the bridging account; The simulator system then provides the transaction result to the first management system.

30. The method of request item 25, wherein the simulator system runs in the first management system.

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

32. The method of request 27, wherein the simulator system has multiple simulator accounts registered with multiple acquiring parties, and the bridging account is selected from the multiple simulator accounts.

33. A method for bridging a subject matter between a portable device of a payer to a first service provider and a merchant device of a recipient of a second service provider whose subject matter format is not compatible with the first service provider, comprising: A simulator system, through a bridging account acting as a member of the second service provider, obtains a target or the content of a target from the second service provider; The simulator system provides the object or content of the object of the second service provider to a first management system of the first service provider, so that the payer's portable device can present the object generated based on the content of the object to the merchant device of the recipient, and the merchant device can parse the object of the second service provider; wherein: the first service provider is a payment service provider used by the payer to make payment by scanning the object; the second service provider is a payment service provider used by the recipient to make payment by scanning the object; and the merchant device cannot parse the object of the first service provider.

34. The method of request item 33, wherein the object is a QR code.

35. The method of claim 33, prior to obtaining the subject matter or the content of the subject matter from the second service provider, further includes: The simulator system receives a request for the target of the target from the first management system; And the request from the simulator system to provide the target to the second service provider via the bridging account.

36. The method of request item 33, wherein an identity of the second service provider is provided along with the subject request, and the bridging account corresponds to the second service provider.

37. The method of claim 33, after providing the first management system with the subject matter or content of the subject matter of the second service provider, further includes: The simulator system receives a transaction request from the second management system after the merchant device at the receiving party scans the target. The simulator system provides the transaction request to the first management system; the simulator system receives a transaction license from the first management system approving the transaction request; and the simulator system provides the transaction license to the second management system via the bridging account.

38. The method of claim 33, after providing the first management system with the subject matter or content of the subject matter of the second service provider, further includes: The simulator system receives a transaction result from the second management system through the bridging account; The simulator system then provides the transaction result to the first management system.

39. The method of request item 33, wherein the simulator system runs in the first management system.

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

41. The method of request item 36, wherein the bridging account is selected from multiple emulator accounts.

42. A simulator system for bridging objects between a portable device of a payer to a first service provider and a merchant device of a receiver to a second service provider whose object format is not compatible with the first service provider, comprising: An execution module is configured to communicatively connect to at least one issuer management system of at least one issuer; and an simulator module is configured to communicate with multiple acquirer management systems of multiple acquirers, connected to the execution module; wherein the first service provider is one of the at least one issuer, and the second service provider is one of the multiple acquirers; wherein the execution module includes instructions stored thereon for responding to the execution of instructions to perform actions, the actions including: receiving an input from a first management system of the first service provider, the first management system being one of the at least one issuer management systems; and based on the input, performing actions from the... A second management system identifies the second service provider among multiple acquiring management systems; based on the second management system, the input is provided to the simulator module; an output is received from the simulator module; and the output is provided to the first management system; wherein the simulator module is used to log in to the multiple acquiring management systems with multiple simulator accounts, each of the multiple simulator accounts being registered in one of the multiple acquiring management systems; wherein one of the input and the output is a target or the content of a target of the second management system; and wherein the first management system needs to use the simulator system to parse a target of the second service provider.

43. The simulator system as described in request item 42, wherein the simulator module runs multiple mobile applications of the acquiring parties to log in to the multiple acquiring party management systems.

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

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

46. ​​The simulator system as described in request item 42, wherein none of the multiple acquiring management systems can resolve one of each other's targets.

47. The simulator system of request item 42, wherein the simulator system is configured to record the identity of the first management system and the identity of the payer when the input is received.

Images