Systems and methods for bridging targets

Abstract

The present disclosure relates to a target bridging technique that allows a payer of a first service provider to present a target of a second service provider to a payee of a second service provider who does not recognize the target of the first service provider. The target bridging service system of the present invention requires all or part of a payer's mobile device, a first management system of the first service provider, a payee's scanning system, a second management system of the second service provider, a bridge connection system of the bridge connection service provider, and a target generator.

Description

[Technical Field]

[0001] Related Applications This application claims the benefit of U.S. Provisional Application No. 63 / 297,791, entitled "SYSTEMS AND METHODS FOR TARGET BRIDGING TECHNOLOGY," filed January 9, 2022, which is incorporated herein by reference in its entirety.

[0002] FIELD OF THE INVENTION The present disclosure relates to target bridging techniques that enable a service provider's payer to present a target of another service provider. The present disclosure also relates to a target bridging service system and method that enables transactions between service providers of different target types. [Background technology]

[0003] A payment method is the way a merchant can collect payment from a customer. Payments can be made through a variety of channels, including cash, check, debit card, credit card, bank transfer, or mobile payment.

[0004] Contactless payment is a method of making payments without physical contact. Common examples of contactless payment include radio frequency identification (RFID) payments, near field communication (NFC) payments, and quick response code (QR code) payments via smartphones and other mobile devices. Traditional credit cards, debit cards, and smart cards may also be used for contactless payment if the merchant is equipped with the appropriate sensing equipment. Recently, due to the COVID-19 pandemic, contactless payment is considered a safer payment method compared to traditional cash and card transactions.

[0005] Among these common contactless payment methods, QR code payment is made by scanning a QR code from a mobile app or a merchant's Point of Sale (POS) system. In Merchant Present Mode (MPM), consumers pay by scanning a QR code displayed by the merchant with their smartphone. In Consumer Present Mode (CPM), on the other hand, the merchant scans the QR code displayed by the consumer to receive payment. QR code payment allows transactions to be conducted without the infrastructure traditionally associated with electronic payments, such as a payment card, payment network, payment terminal, and merchant account. The system implementing this payment method between the payer and payee of a single service provider runs within the service provider's network.

[0006] In recent years, many mobile payment service providers have emerged, attracting users and merchants. However, because the two service providers use different QR code formats, a payer from one service provider and a payee from another service provider cannot complete a transaction via QR code. For example, a payer (e.g., a consumer) from one service provider cannot purchase goods from a payee (e.g., a merchant) from a second service provider because the payee's device (e.g., a POS) does not recognize the QR code of the first service provider presented on the payer's mobile device (e.g., a smartphone). One solution to this problem is for the first and second service providers to enter into a bilateral cooperation agreement and modify their systems to enable a payee (e.g., a merchant) from the second service provider to recognize the QR code of the first service provider provided by a payer (e.g., a user) from the first service provider. However, modifying both systems to provide such functionality can be costly and time-consuming. Furthermore, the complexity increases exponentially when more service providers want to recognize each other's QR codes.

[0007] Furthermore, the global village is steadily driving an increasing number of international businesses traveling around the world for both business and leisure. Purchasing overseas goods and services arising from these businesses requires cross-border QR code payments. Generally, the service providers available for QR code payments at overseas merchants are all different from the service providers customers use in their home countries. The same problem arises in this situation. [Prior art documents] [Patent documents]

[0008] [Patent Document 1] U.S. Provisional Application No. 63 / 297,791 [Patent Document 2] International Patent Application No. PCT / US17 / 12635 [Patent Document 3] International Patent Application No. PCT / US21 / 27370 Summary of the Invention [Problem to be solved by the invention]

[0009] Therefore, it is desirable to develop a method and system that enables QR code recognition between service providers to facilitate transactions. [Means for solving the problem]

[0010] To solve the problem of QR code recognition and facilitate transactions between two different service providers, target bridging technology is provided to enable transactions between a payer (e.g., a consumer) of a first service provider and a payee (e.g., a merchant) of a second service provider. The second service provider may be any other service provider worldwide that uses target standards, formats, and / or rules ("target formats") different from those of the first service provider. In this way, target bridging technology solves the problem of transactions between service providers, fulfilling a long-felt need, and offering unexpected results that may revolutionize transactions in related industries worldwide.

[0011] The present disclosure relates to a system and method for bridging services that enable transactions between two or more service providers with different target types, each with its own network, users, and merchants. In one aspect, the present invention includes the steps of (1) receiving, by a first management system of the first service provider, target content of a second service provider or a bridged target generated based on the target content from a bridge system of a payer bridge service provider, and (2) wirelessly providing, by the first management system of the first service provider, the target content or the bridged target of the second service provider to a payer's mobile device, and presenting the bridged target generated based on the target content to a scan system of a payee of the second service provider that recognizes the bridged target.

[0012] In another aspect, the present invention includes the steps of (1) receiving, from a target generator, target content or a bridged target generated based on the target content of a second service provider by a bridge connection system of a bridge connection service provider, and (2) providing, by the bridge connection system of the bridge connection service provider, the target content or the bridged target to a first management system of a first service provider, so that a payer's mobile device presents the bridged target generated based on the target content to a payee's scanning system that recognizes the bridged target. In either of the above aspects, the payee's scanning system of the second service provider does not recognize the target of the first service provider. Furthermore, the second service provider may be located in a different country from the country of the first service provider.

[0013] In one embodiment, targets used by the first and second service providers include, but are not limited to, one-dimensional, two-dimensional, and three-dimensional quick response codes (QR codes), NFC (near field communication) tags, voice signatures, and fingerprints. Each service provider may have its own proprietary data format for targets and target content. Targets such as QR codes may contain payer and / or payee information, allowing the second service provider to initiate a transaction upon scanning or sensing the target.

[0014] In one embodiment, a request for the targeted content is made by the payer's mobile device and relayed to the bridge connection service provider before the first management system of the first service provider receives the targeted content of the second service provider or a bridge connection target generated based on the targeted content. In one embodiment, the targeted content of the second service provider or the bridge connection target is generated by a target generator and provided to the first management system of the first service provider via the bridge connection system of the bridge connection service provider. The target generator may be a system / module of the second service provider or a system / module of the bridge connection service provider.

[0015] In one embodiment, the second management system of the second service provider may make a transaction (e.g., payment) request to the bridging service provider to process the transaction between the payer and the payee. The bridging system of the bridging service provider may then relay the transaction request to the first management system of the first service provider, which may further relay the transaction request to the payer's mobile device for approval or approve the transaction if pre-authorized, e.g., if the payment amount is below a predetermined amount.

[0016] In one embodiment, the bridged target is valid only for a predetermined period of time. An associated system may record a first timestamp indicating the time the target content or bridged target is created and a second timestamp indicating the time the bridged target is scanned. If the difference between the first and second timestamps exceeds a predetermined period of time, the transaction may be considered invalid. In another embodiment, the target content or bridged target may include a first timestamp and a period of time thereafter the target content or bridged target remains valid.

[0017] In one embodiment, the bridging service provider is the first service provider or the second service provider, while in another embodiment, the bridging service provider is neither the first service provider nor the second service provider.

[0018] In one embodiment, the bridging service provider's bridging system may generate a bridged transaction identifier for the transaction such that related transaction information may be linked by the bridged transaction identifier. To enhance privacy protection, the bridging service provider's bridging system may generate a job identifier (job ID) for recording the transaction for each bridged transaction identifier, which may be stored in a distributed ledger such as a blockchain.

[0019] In one embodiment, the bridging service provider's bridging system may record each transaction including a job ID, the payer's virtual wallet, the payee's virtual wallet, the amount, and the currency type. In another embodiment, the bridging service provider's bridging system may generate multiple job IDs for a single bridged transaction identifier, in which case multiple parts of a transaction may be recorded with different job IDs, all corresponding to one bridged transaction identifier. [Brief explanation of the drawings]

[0020] [Figure 1] FIG. 1 is a block diagram illustrating an embodiment of a system for bridging targets between a payer of a first service provider and a payee of a second service provider. [Figure 2] 1 illustrates an embodiment of the present invention for bridging targets in Consumer Presented Mode (CPM), where First SP and Second SP stand for First Service Provider and Second Service Provider, respectively. [Figure 3] 10 is a flowchart illustrating the steps for requesting a bridge connection target from a payer in the present system. [Figure 4]10 is a flowchart illustrating the steps for providing target content or bridge connection targets from a target generator in the present system. [Figure 5] 10 is a flow chart illustrating the steps of scanning a bridge connection target and processing a transaction between a payer at a first service provider and a payee at a second service provider. [Figure 6] 10 is a flowchart illustrating the steps of an alternative embodiment for providing targeted content or bridged targets without prior request. DETAILED DESCRIPTION OF THE INVENTION

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

[0022] As used herein and in the claims, the term "service provider" refers to a party that provides digital asset transfer services through the transmission and / or receipt of target information or targets. In one embodiment of the present disclosure, a service provider is a provider of an electronic payment or transfer system that enables electronic payments or transfers of digital assets between payers and payees, utilizing targets for exchanging information such as a payer identifier, a payee identifier, a timestamp, and a transaction request. A service provider typically includes a management system that performs functions related to digital asset transactions.

[0023] As used herein, the term "payer" refers to a party, individual, or entity that authorizes a transaction to transfer their digital assets to another party. A service provider's payer is also a service provider user who holds an account with the service provider. A user can transfer digital assets stored in their account to others and receive digital assets from others. In one embodiment, the account is realized by a virtual wallet. The payer may present a target to the payee via their mobile device.

[0024] The term "recipient" refers to a party, individual, or entity that receives digital assets transferred from another party. A service provider's recipient may be either a service provider's user or a merchant. A service provider's merchant may be aware of the service provider's target. However, a service provider's merchant may not have an account with the service provider and therefore may not be a service provider's user. In other words, a service provider's merchant may perform merchant functions through the merchant's acquirer and has no direct relationship with the service provider.

[0025] As used herein, the term "digital asset" refers to anything that exists in digital form and has economic value, including, but not limited to, multiple types of digital assets, credits, and debt, such as digital currency, digital securities, digital bonds, digital futures, digital precious metals, non-fungible tokens (NFTs), digital coupons, and digital fee tokens. Digital currency may include, but is not limited to, a digital US dollar, a digital Japanese yen, a digital euro, and a digital New Taiwan dollar. Digital securities may include, but are not limited to, digital Apple stock, digital Google stock, and digital mutual funds. Digital precious metals may include, but are not limited to, digital gold, digital platinum, and digital silver. Digital futures may include, but are not limited to, digital futures for coffee beans, soybeans, and corn. NFTs may be electronic records owned / controlled by a party and in which the party has rights or interests, including, but not limited to, photographs, logos, illustrations, animations, audiovisual media, presentations, spreadsheets, digital paintings, Word documents, emails, websites, and many other digital formats and their corresponding metadata.

[0026] As used herein, the term "target" refers to a medium containing information in a form that can be recognized or sensed by a particular device. Examples include, but are not limited to, barcodes, QR codes, NFC (near field communication) tags, voice signatures, and fingerprints. Target information may be resolved by extracting features embedded in the target, such as by scanning a QR code, sensing an NFC tag, extracting a voice signature from audio, or scanning a fingerprint and extracting features to obtain the target information contained therein. In one embodiment of the present invention, the target is a QR code.

[0027] As used herein, the term "target content" refers to information contained in a target, including, but not limited to, a locator, an identifier, and a tracker. The target content may be in the form of a string of characters. In one embodiment of the present invention, the target content includes a payer identifier, a payee identifier, and / or a request for a transaction, which provides payer and / or payee information. The target may be generated based on the target content.

[0028] As used herein, the term "mobile device" refers to a device that has basic computing resources (in the form of a processor, memory, and storage) and wireless communications such as telecommunications networks, WiFi, Bluetooth, satellite, broadcast radio, microwave, infrared, etc. Examples include, but are not limited to, laptops, tablets, and smartphones.

[0029] As used herein, the terms "bridge" or "bridging" refer to systems and methods that enable a payer at a first service provider to present a target at a second service provider to a payee at the second service provider who does not recognize the target at the first service provider, thereby completing a transaction between the payer and payee. The first service provider and the second service provider use different target formats or conventions, and therefore the payee at the second service provider does not recognize the target at the first service provider. In some embodiments, the bridging service, in consumer presentment mode (CPM), enables a consumer's mobile device to present a QR code that can be recognized by a merchant's device (e.g., a POS) that does not recognize the consumer's service provider's QR code.

[0030] The term "bridging service provider" refers to a service provider that provides bridging technology to other service providers. The bridging service provider may be a first service provider, a second service provider, or another bridging service provider that is neither a first service provider nor a second service provider. The term "bridging system" refers to a system of a bridging service provider for performing the functions of a bridging service.

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

[0032] The present invention relates to providing a target bridging service between a first service provider and a second service provider to enable a transaction between a payer of a first service provider and a payee of a second service provider by scanning or sensing a target. Targets, such as QR codes, play a role in the mobile payment industry similar to that of credit card numbers in the traditional payment industry. A credit card holder can only use their card to make payments at merchants that recognize their credit card numbers. Similarly, a payer of a first mobile payment company (first service provider) can only use the first mobile payment company's target (e.g., QR code) with a payee (usually a merchant of the first service provider) that recognizes the target. A payee of the first service provider cannot recognize the second service provider's target on their own device (e.g., a POS). Similarly, a payee of the second service provider cannot recognize the first service provider's target on their own device. In one embodiment, a bridging service provider may provide bridge targets or target content from multiple other service providers around the world (e.g., a second service provider and many other similar service providers) to a first service provider's payer, allowing the first service provider's payer to complete transactions at all merchants that recognize targets from any one of these multiple other service providers. For example, a first country may have 10 major service providers and a second country may have 5 major service providers. It may be complicated for each of the 10 service providers in the first country to interact with each of the 5 service providers in the second country. In this situation, a bridging service provider may provide such a target bridging service to connect all 15 service providers in both countries, allowing a payer from any service provider to complete transactions at a payee (e.g., a merchant) from any other service provider.

[0033] As shown in FIG. 1 , the target bridging service 100 system includes a mobile device 115 of a payer 110, a first management system 125 of a first service provider 120, a scan system 155 of a payee 150, a second management system 145 of a second service provider 140, a bridge system 135 of a bridge service provider 130, and a target generator 160. The payer 110 is a user of the first service provider 120 who has a mobile device 115, such as a smartphone, wirelessly connected to the first management system 125 of the first service provider 120. The payee 150 is a merchant or user of the second service provider 140 who has a scan system 155 wirelessly or wired connected to the second management system 145 of the second service provider 140. In the example shown in FIG. 1 , the payer 110 is transferring digital assets to the payee 150. The bridging service provider 130 has a bridging system 135 communicatively coupled to both the first management system 125 and the second management system 145, acting as a "bridge" between the two different service providers. A target generator 160 is coupled to the bridging system 135 and / or the second management system 145. In one embodiment, the target generator 160 is configured to be coupled to or embedded in the second management system 145 and may generate targeted content or bridged targets for the second service provider 140. In an alternative embodiment, the target generator 160 is a module separate from any service provider. In this case, the target generator 160 may be a system embedded in or connected to the bridging system 135 and may generate targeted content or bridged targets for multiple service providers.

[0034] The first service provider 120 and the second service provider 140 each operate a transaction network between users and merchants and have their own target standards, formats, and / or rules. As such, payers and payees of the first service provider 120, e.g., users (payers) and merchants (payees), can complete transactions (e.g., payments or transfers) within the first service provider's network by scanning targets. The same situation applies to payers and payees of the second service provider 140. However, to complete transactions and / or other communications between payers of the first service provider 120 and payees of the second service provider 140, the two service providers are configured to communicatively connect to a bridging service provider 130.

[0035] Among other service provider functions, the first management system 125 of the first service provider 120 is configured to implement additional functionality related to bridged transactions. This functionality may include (1) selecting an acquirer (i.e., a second service provider) for the transaction, (2) requesting target content or bridged targets from the second service provider 140 via the bridging system 135, (3) receiving and providing the target content or bridged targets to the payer 110, (4) receiving transaction requests from the bridging system 135, (5) returning transaction approval to the bridging system 135, and (6) processing notifications from the bridging system 135. The bridging system 135 may provide target content or bridged targets for each of multiple service providers worldwide, which form a bridged network. The payer 110 or the first management system may select the second service provider from the bridged network. Alternatively, based on the location of the payer's mobile device, the mobile device may display all available service providers in the region / country that the payer 110 selects for the transaction. The location may be revealed by the GPS system of the payer's mobile device.

[0036] To identify the payer requesting a bridged target, the first management system 125 of the first service provider 120 may assign a bridged payer identifier to the payer 110 and associate the bridged payer identifier with the target request. The target request may then be relayed to the bridging system 135 of the bridging service provider 130 along with the bridged payer identifier. The bridged payer identifier assigned to the first management system 125 may be the payer's 110's original user identifier used within the first service provider's 120 network, such as the payer's account number or virtual wallet ID. Alternatively, for added security, the first management system 125 of the first service provider 120 may separately create a bridged payer identifier that is different from the payer's 110's original user identifier. Furthermore, a service provider's payer, such as a first service provider's user, may be assigned a virtual wallet including the bridged wallet identifier by the bridging system 135. Thus, the first service provider 120 may use the bridged wallet identifier assigned by the bridging system 135 as the bridged payer identifier for the target request instead of using the bridged payer identifier created by the first management system 125 of the first service provider 120. To provide the returned bridged target to the requesting payer 110, the first management system 125 of the first service provider 120 is configured to receive the returned target content or bridged target along with the previously provided bridged payer identifier, and thereafter provide the target content or bridged target to the payer 110 based on the bridged payer identifier associated with the payer 110.

[0037] To approve a bridge transaction, the first management system 125 of the first service provider 120 is configured to receive a transaction request (e.g., a payment request) from the bridge connection system 135 and return a transaction authorization (e.g., a payment authorization) to the bridge connection system 135. The first management system 125 of the first service provider 120 may relay the transaction request to the payer 110 based on a bridge connection payer identifier provided by the bridge connection system 135. After the payer 110 approves the transaction and returns the authorization, the first management system 125 of the first service provider 120 may return the transaction authorization to the bridge connection system 135 for processing the transaction. Alternatively, based on configuration or agreement, the first service provider 120 may be authorized to approve the transaction without further confirmation from the payer 110. For example, if the payment amount is within a predetermined range, the first management system 125 of the first service provider 120 may return the transaction authorization to the bridge connection system 135 itself.

[0038] The bridging system 135 of the bridging service provider 130 may be configured to perform three functions: third-party target content / bridge target provider, third-party authentication proxy, and third-party clearing house. First, the bridging system 135 of the bridging service provider 130 may provide target content or bridge targets (e.g., target content or bridge targets of the second service provider 140 in one embodiment) to the first management system 125. Second, the bridging system 135 of the bridging service provider 130 may function as a third-party authentication proxy to relay transaction requests and approvals between the first management system 125 and the second management system 145. Third, the bridging system 135 of the bridging service provider 130 may function as a third-party clearing house to bridge and clear transactions between different service providers using a transaction bridge mechanism (e.g., clearing multiple transactions between a first service provider and a second service provider) based on recorded related transaction information.

[0039] To provide the bridge target, the bridge system 135 of the bridge service provider 130 is configured to receive a request for a bridge target from the first management system 125, relay the request to the target generator 160, and send the target content or bridge target back to the first management system 125. The bridge system 135 of the bridge service provider 130 may first identify the location of the payer's mobile device 115 and then determine a list of service providers available in the bridge network for that location (e.g., an overseas region / country). This list of available service providers is provided to the mobile device 115 for selection by the payer 110. In this embodiment, after the payer 110 selects the second service provider 140 as the bridge target, the bridge system 135 receives a request for a bridge target from the second service provider. The bridging system 135 may then assign a bridged transaction identifier to the request and relay the request along with the bridged transaction identifier and / or bridged wallet / payer identifier to the target generator 160 to generate the targeted content or bridged target for the second service provider 140. As previously mentioned, the bridged wallet identifier is a type of payer identifier from the perspective of the bridging service provider 130 and may be used to identify the payer 110 that initiated the request for the bridged target. After receiving the targeted content or bridged target from the target generator 160, the bridging system 135 of the bridging service provider 130 may associate the bridged transaction identifier with the bridged payer identifier and return the targeted content or bridged target to the first management system 125. Alternatively, the association between the bridged transaction identifier and the bridged payer identifier may occur before the bridging system 135 receives the targeted content or bridged target.

[0040] In another embodiment, the first management system 125 of the first service provider may request the targeted content or bridged targets of the second service provider from the bridging system 135 of the bridging service provider without any action from the payer. In another embodiment, the bridging service provider 135 may voluntarily provide the targeted content or bridged targets of the second service provider to the first management system 125 without any action from the first management system 125.

[0041] To act as a third-party authentication proxy relaying transaction requests and authorizations, the bridging system 135 of the bridging service provider 130 may be configured to relay transaction requests (e.g., payment requests) from the second management system 145 to the first management system 125 and to relay transaction authorizations from the first management system 125 to the second management system 145. The second management system 145 may provide a payee / merchant identifier representing the identity of the payee 150 along with the transaction request. Upon receiving the transaction request (which may include the bridged transaction identifier and payee / merchant identifier provided by the second management system 145), the bridging system 135 of the bridging service provider 130 may use the bridged transaction identifier to find the bridged payer identifier representing the payer 110 of the first service provider 120. The bridging system 135 of the bridging service provider 130 may then return an acknowledgement of receipt to the second management system 145 and relay the transaction request, including the bridging payer identifier and the payee / merchant identifier, to the first management system 125. After the first management system 125 approves the transaction request, the bridging system 135 may record the transaction and send a message to the first management system 125 and the second management system 145 indicating that the transaction has been confirmed (e.g., payment successful), possibly along with some transaction details.

[0042] To function as a third-party clearing house, the bridging system 135 of the bridging service provider 130 is configured to clear transactions between different service providers (e.g., clearing multiple transactions between a first service provider and a second service provider) using a transaction bridge mechanism. In one embodiment, the first service provider and the second service provider each create an internal transaction ID corresponding to such inter-service provider transactions. For example, the first service provider 120 generates an X transaction ID associated with the payer, and the second service provider generates a Y transaction ID associated with the payee. The X transaction ID may be a previously created bridged payer identifier or a separate ID separately generated by the first management system 125. Similarly, the Y transaction ID may be a previously created payee / merchant identifier or a separate ID separately generated by the second management system 145. To bridge such transactions between different service providers, the bridging system 135 may use the bridging transaction identifier to associate with the internal transaction IDs of the different service providers, such as Transaction ID X and Transaction ID Y, and link to related transaction information. The bridging system 135 of the bridging service provider 130 may store and maintain (1) an association between the bridging transaction identifier and the internal transaction ID of a first service provider, and (2) an association between the bridging transaction identifier and the internal transaction ID of a second service provider.

[0043] In one embodiment, to enhance privacy protection, the bridging system 135 of the bridging service provider 130 may generate a job ID for each bridged transaction identifier. In one embodiment, to enhance privacy protection, the job ID may be a serial number or a randomly generated number that does not include information about the payer 110, the first service provider 120, the payee 150, and the second service provider 140. In this embodiment, the bridging system 135 stores and maintains a mapping between the bridged transaction identifier and the job ID. The bridged transaction identifier and / or the job ID may be recorded in a database, such as, but not limited to, a distributed ledger such as a blockchain. As a result, in one embodiment, the bridging system 135 may record each transaction with a job ID, the payer's virtual wallet, the payee's virtual wallet, the amount, and the currency.

[0044] In another embodiment, the bridging system 135 of the bridging service provider 130 may generate multiple job IDs for a single bridged transaction identifier. Each job ID corresponds to one of the payments, refunds, and cancellations for the single bridged transaction identifier and may be recorded in a database, such as, but not limited to, a distributed ledger such as a blockchain. Therefore, the bridging system 135 of the bridging service provider 130 may provide a clearing service for transactions between the first service provider 120 and the second service provider 140 based on the associated transaction information recorded in the database. For details about transaction recording and clearing, see International Patent Application No. PCT / US17 / 12635, entitled "DIGITAL PROPERTY MANAGEMENT ON A DISTRIBUTED TRANSACTION CONSENSUS NETWORK," filed January 6, 2017, which is incorporated herein by reference in its entirety.

[0045] Among other service provider functions, the second management system 145 of the second service provider 140 is configured to recognize bridge targets scanned by the scan system 155 of the payee 150. Because the bridge targets are generated based on the target format and the second service provider's rules, the scan system 155 recognizes the bridge targets as targets from other payers of the second service provider and generates scanned information. The second management system 145 parses the scanned information to identify the bridge service provider 130, the target generator 160, a bridge transaction identifier, and / or the payee / merchant identifier of the payee 150. In one embodiment, the second management system 145 may request the target generator 160 to provide a bridge transaction identifier associated with the bridge target scanned by the payee 150. Additionally, the second management system 145 may receive relevant transaction information, such as a description, amount, and currency type of the goods or services sold by the payee 150. In one embodiment, the second management system 145 may further resolve the identity of the payer through the bridged transaction identifier and the associated mapping. The second management system 145 may separately generate an internal transaction ID (e.g., Y Transaction ID) to map with the bridged transaction identifier and the payee / merchant identifier and maintain such mapping. The second management system 145 of the second service provider 140 may then provide a transaction request (e.g., a payment request) to the bridging system 135. The transaction request may include the bridged transaction identifier, the payee / merchant identifier, and associated transaction information. Finally, upon receiving a message confirming the bridged transaction, the second management system 145 may send a message to the payee 150 notifying the outcome (e.g., successful payment).

[0046] The target generator 160 is configured to receive a target request and generate a bridged target or target content for the second service provider. The bridged target is recognizable by the scan system 155 of the payee 150 and the second management system 145 of the second service provider 140. The target request may include a bridged transaction identifier and / or a bridged wallet identifier that can be linked to the first service provider 120 and / or the payer 110. Furthermore, the target generator 160 may associate the generated target content or bridged target with the bridged transaction identifier and / or the bridged wallet identifier and maintain the association. The target generator 160 then provides the target content or bridged target to the bridging system 135. After the scan system 155 of the payee 150 scans the bridged target, the target generator 160 may provide the bridged transaction identifier associated with the scanned bridged target to the second management system 145, upon request. As previously mentioned, the target generator 160 may be a module embedded in or connected to the second management system 145. Thus, each service provider in the bridged network has its own target generator that generates corresponding bridged targets. Alternatively, the target generator 160 may be a module embedded in or connected to the bridged system 135, which may not be a service provider, to generate targeted content or bridged targets corresponding to multiple service providers.

[0047] In summary, a bridging service provider 130, such as HIVEX® from TBCASoft, Inc., provides second service provider 140 target content or bridge targets to the payer 110 of the first service provider 120 so that the payer 110 may present the second service provider 140 bridge targets to the payee 150 (e.g., a merchant of the second service provider 140). A scanning system 155 of the payee 150 (e.g., a merchant) scans and recognizes the second service provider 140 bridge targets. After scanning, a transaction request generated by the payee 150 is relayed through the bridging service provider 130 to the first service provider 120. The first service provider 120 may request the payer 110 to approve the transaction. Upon receiving transaction approval from the first management system 125 of the first service provider 120, the bridging system 135 of the bridging service provider 130 records the transaction in a database or a distributed ledger, such as a blockchain, after which the transaction is considered complete. The associated transaction record is then distributed to both the first management system 125 and the second management system 145. The approval and associated transaction record may then be distributed to the payee 150 (e.g., a merchant).

[0048] In alternative embodiments, the bridge connection service provider 130 may simultaneously be the first service provider 120 or the second service provider 140. For example, if the bridge connection service provider is a second service provider, the second service provider performs the functions of the bridge connection service provider in addition to the functions of the second service provider. In one embodiment, the second management system also performs the functions of the bridge connection system. As a result, data transmission between the bridge connection system 135 and the first management system 125 or the second management system 145 may be omitted, although the structure of the system is essentially the same as when the bridge connection service provider 130 is neither the first service provider 120 nor the second service provider 140, as described above.

[0049] FIG. 2 illustrates an embodiment of the present invention performing target bridging in consumer-presented mode (CPM). In this scenario, a payer 110 from a first service provider (e.g., LINE Pay® Taiwan) travels from Taiwan to Japan and wishes to make a mobile payment at a participating merchant in Japan (e.g., a Watsons® store). The participating merchant is here the payee 150. As shown in FIG. 2, the merchant accepts PayPay®, Rakuten Pay, and FamiPay®, all of which are different mobile payment services from the payer's mobile payment service. Therefore, the target bridging service of the present invention must be utilized to complete the transaction between the two mobile payment service providers. In this example, the payer 110 uses Line Pay Taiwan (i.e., the first service provider 120) to make the payment, and the payee 150 selects PayPay (i.e., the second service provider 140) to receive the payment. After the payer 110 selects PayPay as the second service provider 140, the app on the mobile phone (i.e., mobile device 115) may further prompt the payer 110 to select a payment method: consumer-presented mode (CPM) or merchant-presented mode (MPM). Some embodiments of transactions between service providers in merchant-presented mode are described in International Patent Application No. PCT / US21 / 27370, filed April 14, 2021, entitled "METHOD AND SYSTEM FOR RESOLVING A TARGET," which is incorporated herein by reference in its entirety. In consumer-presented mode, the payer 110 selects "present QR code," and the app receives a bridged QR code that can be displayed on the payer's 110's mobile device 115. The scanning system 155 of the merchant (e.g., Watsons as the payee 150) then scans the QR code displayed on the payer's 110's mobile device 115. Upon receiving the scanned information from the merchant, PayPay (the second service provider 140) may provide a transaction request to HIVEX, the bridging service provider 130.HIVEX then records the bridged transaction after receiving transaction approval from LINE Pay Taiwan (first service provider 120), and HIVEX provides transaction confirmation to LINE Pay Taiwan (first service provider 120) and PayPay (second service provider 140).

[0050] 3-6 show a sequence diagram of a target bridging connection in one embodiment of the present invention. As shown in FIG. 3, the payer 110 may request a bridge connection target. In step S111, the payer 110 may send a request to the first service provider 120 for a picklist of second service providers available in the region where the payer's 110's mobile device 115 is located. In one embodiment, the first management system 125 of the first service provider 120 may authenticate both the payer 110 and its mobile device 115 before further processing the payer's request, as shown in steps S112, S1121, and S1122. Step S1121 indicates that an authentication request may be sent from the first management system 125 of the first service provider 120 to the payer's 110's mobile device 115. The mobile device 115 of the payer 110 may return the information to verify its authenticity, as shown in step S1122. In step S113, after receiving the request from the payer 110, the first management system 125 of the first service provider 120 may relay the request to the bridging system 135 of the bridging service provider 130.

[0051] In step S114, after receiving the request, the bridge connection system 135 may look up service provider information in the bridge connection network based on the location of the mobile device 115 and then return a pick list of available second service providers to the first management system 125. In step S115, the first management system further relays the pick list to the payer 110 after receiving it from the bridge connection system 135. As mentioned above, the payer 110 may receive the pick list from the first management system 125 of the first service provider 120. Alternatively, if the mobile device 115 has updated service provider information in the bridge connection network, it may generate the pick list locally by selecting service providers available in its region and in the bridge connection network. In step S116, based on a picklist received from the first service provider 120 or generated locally, the payer 110 may select a second service provider 140 from the picklist displayed on the mobile device 115 and send a target request to the first management system 125 requesting a bridge connection target for the selected second service provider 140.

[0052] In step S117, after receiving the target request, the first management system 125 of the first service provider 120 may send the target request, including the bridge payer identifier, to the bridge connection system 135 of the bridge connection service provider 130. Finally, in step S118, the bridge connection system 135 of the bridge connection service provider 130 may identify the selected second service provider 140, generate a bridge connection transaction identifier for the received request, and send the request to the target generator 160 to request a bridge connection target or target content from the second service provider 140. In one embodiment, the target generator 160 is a system of the second service provider 140, and the bridge connection target or target content is provided by the second service provider 140. In another embodiment, the target generator 160 is not a system of the second service provider 140, but is authorized to generate a bridge connection target or target content based on the target format and the rules of the second service provider 140.

[0053] FIG. 4 shows an example sequence diagram for generating a bridge connection target or target content and providing it to the first service provider's payer 110. After receiving the target request, the target generator 160 may generate and provide the bridge connection target or target content to the payer's 110's mobile device 115. In step S121, the target generator 160 may generate the bridge connection target or target content and associate it with a bridge connection transaction identifier. In one embodiment, the target generator 160 may also generate a first timestamp indicating the first time point for generating the bridge connection target or target content. The first timestamp may be stored separately or as part of the bridge connection target or target content. In step S123, the target generator 160 then provides the bridge connection target or target content along with the first timestamp (if any) to the bridge connection system 135 of the bridge connection service provider 130. In addition to the first timestamp, the target generator 160 may also provide a validity period indicating the period for which the target content or bridge connection target remains valid. Alternatively, the target generator 160 may directly provide an expiration date that indicates when the targeted content or bridged target becomes invalid.

[0054] In step S125, after receiving the bridged target or target content, the bridged system 135 may associate the bridged transaction identifier with the bridged payer identifier and return the bridged target or target content to the first management system 125 of the first service provider 120. In step S127, the first management system 125 may convert the received target content into a bridged target and provide the bridged target to the mobile device 115 of the payer 110. In practice, the target content may be converted into a bridged target by the target generator 160, the bridged system 135 of the bridged service provider 130, or the mobile device 115 of the payer 110.

[0055] The bridge connection target may be presented to the payee 150 to proceed with the transaction as shown in FIG. 5 . In step S131, the scan system 155 of the payee 150 may scan the bridge connection target presented by the payer 110 on the mobile device 115. In step S132, after scanning the bridge connection target, the scan system 155 may send the scanned information to the second management system 145 of the second service provider 140 to initiate a transaction request. The scan system 155 may also send a second timestamp indicating the second time the bridge connection target is scanned. The second timestamp may be generated by the second management system 145 when it receives the scanned information from the scan system 155. To ensure the security of the transaction, if the time difference between the first timestamp and the second timestamp exceeds a predetermined period, the transaction may be deemed invalid. Upon receiving the scanned information, the second management system 145 of the second service provider 140 may request the target generator 160 to return a bridge connection transaction identifier associated with the scanned bridge connection target, as shown in step S1331, and the target generator 160 may return the bridge connection transaction identifier based on the associated association previously generated in step S121, as shown in step S1332.

[0056] In step S134, the second management system 145 may send the transaction request along with the bridged transaction identifier to the payer 110 via the bridging system 135. In step S135, upon receiving the transaction request, the bridging system 135 of the bridging service provider 130 may decrypt the bridged transaction identifier of the scanned bridged target into a bridged payer identifier representing the payer 110 of the first service provider 120. If this decryption is successful, the bridging system 135 of the bridging service provider 130 may return an acknowledgement of receipt to the second management system 145, as shown in step S1351. The bridging system 135 may then forward the transaction request including the bridged payer identifier to the first management system 125 of the first service provider 120, as shown in step S1352.

[0057] In step S136, if authorization is granted, the first management system 125 of the first service provider 120 may approve the transaction. The first management system 125 may be authorized to automatically approve the transaction, without further authorization from the payer 110. Alternatively, payer approval for the transaction may be required to improve transaction security. In this case, the first management system 125 may identify the payer 110 with a bridged payer identifier and request the payer 110 to approve the transaction via the mobile device 115, which may then provide transaction authorization to the first management system 125, as shown in steps S1361 and S1362. The first management system 125 may further send transaction authorization to the bridged system 135, as shown in step S137.

[0058] In step S138, upon receiving the transaction authorization, the bridging system 135 may process the transaction using the bridging payer identifier associated with the payer's account. Related transaction information may be linked by the bridging transaction identifier. For each bridging transaction identifier, the first service provider 120 may have a corresponding X transaction ID, and the second service provider 140 may have a corresponding Y transaction ID. As previously mentioned, the X transaction ID may be the bridging payer identifier or a separately generated ID. Similarly, the Y transaction ID may be the payee / merchant identifier or a separately generated ID. The association between the bridging transaction identifier and the X transaction ID may be stored and maintained by the bridging system 135 and / or the first management system 125. The association between the bridging transaction identifier and the Y transaction ID may be stored and maintained by the bridging system 135 and / or the second management system 145. In one embodiment, to enhance privacy protection, the bridging system 135 of the bridging service provider 130 may generate a job ID for each bridging transaction identifier to record the transaction, which may be stored in a distributed ledger such as a blockchain. As a result, the bridging system 135 may record each transaction including the job ID, the payer's virtual wallet, the recipient's virtual wallet, the amount, and the currency. In another embodiment, the bridging system 135 of the bridging service provider 130 may generate multiple job IDs for a single bridging transaction identifier, and multiple portions of the transaction corresponding to payments, refunds, and cancellations may be recorded using different job IDs, all corresponding to a single bridging transaction identifier. The bridging system 135 may then send a notification of successful payment to the first management system 125 (step S1381) and receive a confirmation of receipt from the first management system 125 (step S1382). Upon receiving the confirmation of receipt, the bridging system 135 may send a notification of successful payment to the second management system 145, as shown in step S1383.Finally, notification of successful payment may be sent separately from the first management system 125 of the first service provider 120 to the mobile device 115 of the payer 110 (step S1391) and from the second management system 145 of the second service provider 140 to the scanning system 155 of the payee 150 (step S1392).

[0059] In another embodiment, the target request is not sent by the bridging system 135, and the target generator 160 may automatically provide the bridged target or target content based on predetermined criteria, such as historical usage data of the bridged target, as shown in FIG. 6 . In step S141, the target generator 160 may generate a bridged target or target content and then associate it with a bridged transaction identifier. In step S142, the target generator 160 may automatically send the bridged target or target content associated with the bridged transaction identifier to the bridging system 135 when certain criteria are met. For example, the target generator 160 may monitor the usage of previously sent bridged targets or target content and provide newly generated bridged targets or target content when the number of unused targets falls below a predetermined value. In this case, the bridging system 135 of the bridging service provider 130 may recognize the bridged transaction identifier generated by the target generator 160 and associate the bridged transaction identifier with the bridged payer identifier of the payer 110. In step S143, the payer 110 may request a bridge connection target, and the detailed procedure is similar to the description of steps S111 to S117.

[0060] In step S145, after receiving the bridged target or target content from the target generator 160 and receiving the target request from the first management system 125, the bridged system 135 of the bridged service provider 130 may map the bridged transaction identifier (provided by the target generator 160) to the bridged payer identifier (provided by the first management system 125) and provide the bridged target or target content to the first management system 125. In another embodiment, the target generator 160 may automatically provide the bridged target or target content to the payer 110 via the first management system 125 without a request. As an example, when the first management system 125 detects a bridged target being used by a payer 110 in the transaction network, the first management system 125 may notify the bridged system 135, and the bridged system 135 may map the bridged transaction identifier to the bridged payer identifier provided by the first management system 125 and then provide the bridged target or target content. The bridging system 135 may also provide the bridged target or target content to the payer 110 without a request from the first management system 125. In this case, when a bridged transaction is requested, the bridging system 135 may detect the event and add the bridged target or target content according to the bridged payer identifier provided by the first management system 125. The target content or bridged target may then be provided to the payer 110 from the first management system 125 without first requesting it. In step S147, the first management system 125 of the first service provider 120 may convert the received target content into a bridged target and provide the bridged target to the mobile device 115 of the payer 110. Alternatively, the target content may be converted into a bridged target by the target generator 160, the bridging system 135, or the mobile device 115.

[0061] In another embodiment, the target generator 160 may generate a bridged target or target content for a digital coupon that the payer 110 can use to redeem a gift from a recipient 150 who is a merchant. In this embodiment, the target generator 160 may not need to provide a bridged transaction identifier for the generated bridged target or target content. In this case, the bridged target may be permitted to be freely distributed by the bridging service provider 130 to promote the recipient 150 (e.g., a merchant). Upon recognizing the target, the second management system 145 of the second service provider 140 need only record which target is being used, and the gift may be provided directly to the payer 110 without recording a transaction.

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

Claims

1. 1. A method of bridging targets between a mobile device of a payer of a first service provider and a scanning system of a payee of a second service provider different from the first service provider, comprising: a first management system of the first service provider receiving target content of a second service provider or a bridging target generated based on the target content from a bridging system of a payer bridging service provider; the first management system of the first service provider wirelessly providing the target content or the bridge connection target of the second service provider to the payer's mobile device, thereby presenting the bridge connection target generated based on the target content to a scanning system of the payee of the second service provider, the scanning system recognizing the bridge connection target; A method comprising: The method, wherein the scanning system of the recipient does not recognize the target of the first service provider.

2. The method of claim 1 , wherein the target and the bridge connection target are each a QR code.

3. 2. The method of claim 1, wherein the first service provider is located in a first country and the second service provider is located in a second country, the first country being different from the second country.

4. before receiving the second service provider's target content or the bridge connection target; wirelessly receiving, by the first management system, a targeted content request from the payer's mobile device for the targeted content from the second service provider; the first management system providing a request for targeted content to the bridge connection system; The method of claim 1 further comprising:

5. presenting the bridged target to the payee's scanning system by wirelessly providing the second service provider's target content or the bridged target to the payer's mobile device; receiving, by the first management system, a transaction request from the bridge connection system after the scan system of the recipient scans the bridge connection target; the first management system providing a transaction approval to the bridge connection system; the first management system receiving the transaction notification from the bridge connection system after the bridge connection system records the transaction associated with the transaction notification; The method of claim 1 further comprising:

6. before providing said transaction approval to said bridge connection system; the first management system wirelessly providing the transaction request to the payer's portable device; the first management system wirelessly receiving the transaction authorization from the payer's mobile device; The method of claim 5 further comprising:

7. the first management system authenticating both the payer and the payer's mobile device; The method of claim 4 further comprising:

8. 8. The method of claim 7, wherein the first management system authenticates both the payer and the payer's mobile device before providing the request for the targeted content to the bridging system.

9. The first management system determines whether the transaction is valid before providing the transaction approval to the bridge connection system. The method of claim 5 further comprising:

10. 10. The method of claim 1, wherein the targeted content includes a first timestamp indicating a first point in time at which the targeted content is generated.

11. The target content includes: a first timestamp indicating a first point in time at which the targeted content is generated; The transaction request includes a second timestamp indicating a second time at which the recipient's scanning system scans the bridged target.

6. The method according to claim 5.

12. Determining whether the time difference between the first timestamp and the second timestamp exceeds a predetermined period. The method of claim 11 further comprising:

13. 2. The method of claim 1, wherein the bridge connection service provider is the first service provider or the second service provider.

14. 2. The method of claim 1, wherein the bridging service provider is neither the first service provider nor the second service provider.

15. 10. The method of claim 1, wherein the bridging system of the bridging service provider is capable of providing targeted content from a plurality of different service providers.

16. 16. The method of claim 15, wherein the plurality of different service providers are located in a plurality of different countries.

17. The method of claim 4 , wherein the bridging system generates a bridging transaction identifier after receiving the request for the targeted content from the first management system.

18. and presenting the bridged target to the payee's scanning system by wirelessly providing the second service provider's target content or the bridged target to the payer's mobile device; receiving, by the first management system, a transaction request from the bridge connection system after the scan system of the recipient scans the bridge connection target; the first management system providing a transaction approval to the bridge connection system; the first management system receiving the transaction notification from the bridge connection system after the bridge connection system records the transaction associated with the transaction notification; The method further comprising: the bridge connection system generates at least one job ID corresponding to the bridge connection transaction identifier and records the transaction based on the job ID.

18. The method of claim 17, wherein:

19. 6. The method of claim 5, wherein the bridging system records the transaction on a distributed ledger.

20. 10. The method of claim 1, wherein the list of second service providers is selected based on the location of the payer's mobile device.

21. 1. A method of bridging targets between a mobile device of a payer of a first service provider and a scanning system of a payee of a second service provider different from the first service provider, comprising: a bridge connection system of a bridge connection service provider receiving from a target generator target content of a second service provider or a bridge connection target generated based on the target content; a bridge connection system of the bridge connection service provider providing the target content or the bridge connection target to a first management system of the first service provider, so that the bridge connection target generated based on the target content is presented to a scanning system of the payee, the scanning system recognizing the bridge connection target, via the payer's mobile device; A method comprising: The recipient's scanning system does not recognize the first service provider's target. A method characterized by:

22. 22. The method of claim 21, wherein the target and the bridge connection target are each a QR code.

23. 22. The method of claim 21, wherein the first service provider is located in a first country and the second service provider is located in a second country, the first country being different from the second country.

24. 22. The method of claim 21, wherein the target generator is a system of the second service provider.

25. 22. The method of claim 21, wherein the target generator is the bridging service provider's system.

26. before receiving the targeted content from the second service provider; receiving, by the bridging system, a request for targeted content from the first management system for the targeted content of the second service provider; the bridging system providing the request for the targeted content to the target generator; 22. The method of claim 21 further comprising:

27. After providing the target content or the bridge connection target to the first management system, receiving, by the bridge connection system, a transaction request from a second management system of the second service provider after the scanning system scans the bridge connection target; the bridge connection system providing the transaction request to the first management system; receiving a transaction approval from the first management system after the transaction associated with the transaction request is approved by the bridge connection system; said bridge connection system recording said transaction; 22. The method of claim 21 further comprising:

28. 22. The method of claim 21, wherein the bridging system receives a first timestamp from the target generator in addition to the target content or the bridged target.

29. the bridging system receives a first timestamp from the target generator in addition to the target content or the bridge target, the first timestamp indicating a first time at which the target content or the bridge target is provided; The bridging system receives a second timestamp from the second management system in addition to the transaction request, the second timestamp indicating a second time at which the scanning system scans the target.

28. The method of claim 27.

30. Determining whether the time difference between the first timestamp and the second timestamp exceeds a predetermined period.

30. The method of claim 29, further comprising:

31. 22. The method of claim 21, wherein the bridging service provider is neither the first service provider nor the second service provider.

32. 32. The method of claim 31, wherein the bridging system of the bridging service provider is capable of providing targeted content from a plurality of different service providers.

33. 33. The method of claim 32, wherein the different service providers are located in a plurality of different countries.

34. 27. The method of claim 26, wherein the bridging system generates a bridged transaction identifier after receiving the request for the targeted content from the first management system.

35. After providing the target content or the bridge connection target to the first management system, receiving, by the bridge connection system, a transaction request from a second management system of the second service provider after the scanning system scans the bridge connection target; the bridge connection system providing the transaction request to the first management system; receiving a transaction approval from the first management system after the transaction associated with the transaction request is approved by the bridge connection system; said bridge connection system recording said transaction; The method further comprising: the bridge connection system generates at least one job ID corresponding to the bridge connection transaction identifier and records the transaction based on the job ID.

35. The method of claim 34, wherein:

36. 22. The method of claim 21, wherein the second management system of the second service provider records the transaction on a distributed ledger.

37. 22. The method of claim 21, wherein the list of second service providers is selected based on the location of the payer's mobile device.

Images