How to bridge targets

Abstract

This invention provides a system and method for a bridge connection service that enables transactions between two or more service providers with different target formats. [Solution] The system includes the steps of: receiving target content from the second service provider 140 or bridge connection targets generated based on the target content from the bridge connection system 135 of the payer's bridge connection service provider 130 by the first management system 125 of the first service provider 120; and wirelessly providing the target content or bridge connection targets of the second service provider to the payer's 110 mobile device 115 by the first management system of the first service provider, and presenting the bridge connection targets generated based on the target content to the scanning system 155 of the second service provider's recipient 150, which recognizes bridge connection targets.

Description

Technical Field

[0001] Related Applications This specification claims the benefit of U.S. Provisional Application No. 63 / 297,791, filed on January 9, 2022, entitled "SYSTEMS AND METHODS FOR TARGET BRIDGING TECHNOLOGY", and incorporates by reference the entirety of the same into this specification.

[0002] Field of the Invention The present invention relates to target bridging technology that enables a payer of a service provider to present a target of another service provider. The present disclosure also relates to systems and methods for a target bridging service that enables transactions between service providers with different target formats.

Background Art

[0003] A settlement method is a method by which a merchant can collect payment from a customer. Settlement can be made through various routes such as cash, checks, debit cards, credit cards, bank transfers, or mobile payments.

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

[0005] Of these common contactless payment methods, QR code payments are made by scanning a QR code from a mobile app or a merchant's POS (Point of Sale) system. In merchant-presented mode (MPM), consumers scan a QR code displayed by the merchant with their smartphone to make a payment. In consumer-presented mode (CPM), the merchant scans a QR code displayed by the consumer to receive payment. QR code payments allow transactions to be conducted without the infrastructure traditionally associated with electronic payments, such as payment cards, payment networks, payment terminals, and merchant accounts. Systems implementing this payment method between payers and payees of a single service provider run within the service provider's network.

[0006] In recent years, many mobile payment service providers have emerged and are acquiring users and merchants. However, because two service providers use different QR code formats, payers of one service provider and recipients of the other service provider cannot complete transactions via QR code. For example, a payer of the first service provider (e.g., a consumer) cannot purchase goods from a recipient of the second service provider (e.g., a merchant) because the recipient's device (e.g., a POS system) does not recognize the first service provider's QR code 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 so that recipients of the second service provider, such as merchants, can recognize the first service provider's QR code provided by payers of the first service provider, such as users. However, modifying both systems to provide such functionality can be costly and time-consuming. Moreover, the complexity increases rapidly if more service providers want to recognize each other's QR codes.

[0007] Furthermore, Global Village is certainly driving an increasing number of international businesses that travel the world for both business and leisure. Purchasing overseas goods and services resulting from these businesses requires cross-border QR code payments. Generally, all service providers that can be used for QR code payments at overseas merchants are different from the service providers that customers use in their home country. The same problem arises in this situation as well. [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 [Overview of the project] [Problems that the invention aims to solve]

[0009] Therefore, it is desirable to develop methods and systems that enable QR code recognition between service providers to facilitate transactions. [Means for solving the problem]

[0010] To solve the problems of QR code recognition and facilitate transactions between two different service providers, we provide targeted bridge connectivity technology that enables transactions between payers (such as consumers) of a first service provider and recipients (such as merchants) of a second service provider. The second service provider may be any other service provider around the world using different targeting criteria, formats, and / or rules ("targeted formats") than the first service provider. Thus, targeted bridge connectivity technology solves the problems of transactions between service providers and fulfills a long-standing need. It also has the potential to bring unexpected results that could drastically improve transactions in relevant industries worldwide.

[0011] This disclosure relates to a system and method for a bridge connection service that enables transactions between two or more service providers with different target formats. Each service provider has its own network, users, and merchants. In one aspect, the present invention includes (1) a first management system of a first service provider receiving target content of a second service provider or bridge connection targets generated based on target content from a bridge connection system of a payer's bridge connection service provider, and (2) a first management system of the first service provider wirelessly providing the target content of the second service provider or bridge connection targets to the payer's mobile device, presenting the bridge connection targets generated based on target content to a scanning system of the second service provider's recipient that recognizes bridge connection targets.

[0012] In another embodiment, the present invention includes (1) the step of receiving, by the bridge connection system of the bridge connection service provider, the target content of the second service provider or a bridge connection target generated based on the target content from a target generator; and (2) the step of providing, by the bridge connection system of the bridge connection service provider, the target content or bridge connection target to the first management system of the first service provider, so that the payer's mobile device presents the bridge connection target generated based on the target content to the recipient's scanning system that recognizes bridge connection targets. In any of the above embodiments, the recipient'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 country different from the country of the first service provider.

[0013] In one embodiment, targets used by the first and second service providers may 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 recipient information, and when the target is scanned or sensed, the second service provider can initiate a transaction.

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

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

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

[0017] In one embodiment, the bridge connection service provider is the first service provider or the second service provider. In another embodiment, the bridge connection service provider is neither the first service provider nor the second service provider.

[0018] In one embodiment, the bridge connection system of the bridge connection service provider may generate a bridge connection transaction identifier for a transaction so that related transaction information may be connected by the bridge connection transaction identifier. To enhance privacy protection, the bridge connection system of the bridge connection service provider may generate a job identifier (job ID) for recording the transaction for each bridge connection transaction identifier, and save this in a distributed ledger such as a blockchain.

[0019] In one embodiment, the bridge connection system of the bridge connection service provider may record each transaction including the job ID, the payer's virtual wallet, the payee's virtual wallet, the amount, and the type of currency. In another embodiment, the bridge connection system of the bridge connection service provider may generate multiple job IDs for a single bridge connection transaction identifier. In that case, multiple parts of the transaction may be recorded using different job IDs, and all the job IDs correspond to one bridge connection transaction identifier.

Brief Description of the Drawings

[0020] [Figure 1] It is a block diagram showing an embodiment of a system for bridging a target between a payer of a first service provider and a payee of a second service provider. [Figure 2] It is a diagram showing an embodiment of the present invention for bridging a target in consumer presentation mode (CPM). The first SP and the second SP are abbreviations for the first service provider and the second service provider, respectively. [Figure 3] It is a flowchart showing the process of requesting a bridge connection target from a payer in this system. [Figure 4]This is a flowchart showing the process of providing target content or bridge-connected targets from a target generator in this system. [Figure 5] This is a flowchart showing the process of scanning bridge-connected targets and processing transactions between payers of the first service provider and recipients of the second service provider. [Figure 6] This is a flowchart showing the process of an alternative embodiment that provides target content or bridge-connected targets without prior request.

Embodiments for Carrying Out the Invention

[0021] The terms used in the descriptions below are intended to be interpreted in the broadest reasonable way, even when used in conjunction with the detailed description of specific embodiments of the technology. Although specific terms may be emphasized below, terms intended to be construed restrictively are specifically defined to that effect in this section of the detailed description.

[0022] As used in this specification and the claims, the term "service provider" refers to a party that provides a digital asset transfer service through the transmission and / or reception 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 the transfer of electronic payments or digital assets between a payer and a recipient by using targets for exchanging information such as payer identifiers, recipient identifiers, timestamps, and transaction requests. 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 its digital assets to another party. A service provider’s payer is also a service provider’s user who holds an account with the service provider. A user can transfer digital assets stored in their account to another party and receive digital assets from another party. In one embodiment, the account is realized by a virtual wallet. The payer may present the target to the recipient via their mobile device.

[0024] The term "recipient" refers to the party, individual, or entity that receives digital assets transferred from another party. A service provider's recipient may be either a user or a merchant of the service provider. A service provider's merchant can recognize the service provider's target audience. However, a service provider's merchant may not be a user of the service provider, as they may not have an account with the service provider. In other words, a service provider's merchant may perform merchant functions through their acquirer and may not have a 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, and includes, but is not limited to, several types of digital assets, such as digital currencies, digital securities, digital bonds, digital futures, digital precious metals, non-fungible tokens (NFTs), digital coupons, and digital fee tokens, as well as credit and debt. Digital currencies may include, but are not limited to, digital US dollars, digital Japanese yen, digital euros, and digital New Taiwan dollars. Digital securities may include, but are not limited to, digital Apple shares, digital Google shares, 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 the parties and in which the parties have rights or interests, and may include, but are 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 decomposed by extracting features embedded in the target, for example, by scanning a QR code, sensing an NFC tag, extracting a voice signature from a voice, or scanning a fingerprint to extract features and 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 “targeted content” refers to information contained in a target, which includes, but is not limited to, locators, identifiers, and trackers. Targeted content may be in the form of a string. In one embodiment of the present invention, targeted content includes a payer identifier, a payee identifier, and / or a transaction request, which provides information about the payer and / or payee. A target may be generated based on targeted content.

[0028] As used herein, the term “portable device” refers to a device equipped with basic computing resources (in the form of a processor, memory, and storage) and wireless communication such as telecommunications networks, Wi-Fi, Bluetooth®, satellite, radio broadcasting, microwave, and infrared. Examples include, but are not limited to, laptops, tablets, and smartphones.

[0029] As used herein, the terms “bridge” or “bridge connection” refer to a system and method that enables a payer of a first service provider to present a target of a second service provider to a recipient of the second service provider who is unaware of the target of the first service provider, thereby enabling the completion of a transaction between the payer and the recipient. Because the first and second service providers use different target formats or rules, the recipient of the second service provider is unaware of the target of the first service provider. In some embodiments, the bridge connection service enables a consumer’s mobile device to present a QR code that is recognizable by a merchant’s device (e.g., a POS) that is unaware of the consumer’s service provider’s QR code, in Consumer Presentation Mode (CPM).

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

[0031] The embodiments described below can be implemented by programmable circuits programmed or configured by software and / or firmware, by dedicated circuits, or by a combination of these forms. Such dedicated circuits can (if any) 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 bridge connection service between a first service provider and a second service provider to enable transactions between a payer of the first service provider and a recipient of the second service provider by scanning or sensing a target. Targets, such as QR codes, play a similar role in the mobile payment industry to 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 number. Similarly, a payer of the first mobile payment company (first service provider) can only use the first mobile payment company's target (e.g., a QR code) at a recipient (usually a merchant of the first service provider) that recognizes the target. A recipient of the first service provider cannot recognize the second service provider's target on their own device (e.g., a POS). Similarly, a recipient of the second service provider cannot recognize the first service provider's target on their own device. In one embodiment, a bridge connection service provider may provide a payer of a first service provider with bridge connection targets or target content from several other service providers worldwide (such as a second service provider and many other similar service providers), so that the payer of the first service provider may complete transactions at all merchants that recognize any one of these other service providers' targets. For example, there may be 10 major service providers in the first country and 5 major service providers in the second country. It may be complex 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, the bridge connection service provider may provide such a targeted bridge connection service to connect all 15 service providers in both countries, so that a payer of any service provider may complete transactions at any other service provider's recipient (e.g., merchant).

[0033] As shown in Figure 1, the Target Bridge Connection Service 100 system includes the Payer 110's mobile device 115, the First Service Provider 120's first management system 125, the Recipient 150's scanning system 155, the Second Service Provider 140's second management system 145, the Bridge Connection Service Provider 130's bridge connection system 135, and a target generator 160. 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 Service Provider 120's first management system 125. Recipient 150 is a merchant or user of the Second Service Provider 140 who has a scanning system 155 wirelessly or wired connected to the Second Service Provider 140's second management system 145. In the example shown in Figure 1, Payer 110 is transferring digital assets to Recipient 150. The bridge connection service provider 130 has a bridge connection system 135 that is communicated to both the first management system 125 and the second management system 145, and acts as a "bridge" between the two different service providers. The target generator 160 is connected to the bridge connection system 135 and / or the second management system 145. In one embodiment, the target generator 160 is configured to be connected to or embedded in the second management system 145 and may generate target content or bridge connection targets for the second service provider 140. In an alternative embodiment, the target generator 160 is a module independent of any service provider. In this case, the target generator 160 may be a system embedded in or connected to the bridge connection system 135 and may generate target content or bridge connection 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 criteria, formats, and / or rules. Therefore, payers and recipients of the first service provider 120, for example, users (payers) and merchants (recipients), can complete transactions (e.g., settlement or transfer) within the first service provider's network by scanning targets. The same applies to payers and recipients of the second service provider 140. However, in order to complete transactions and / or other communications between payers of the first service provider 120 and recipients of the second service provider 140, the two service providers are configured to communicate with a bridge service provider 130.

[0035] Among the other functions of the service provider, the first management system 125 of the first service provider 120 is configured to implement additional functions related to bridged transactions. These functions may include (1) selecting the acquirer of a transaction (i.e., the second service provider), (2) requesting target content or bridged target from the second service provider 140 via the bridged system 135, (3) receiving target content or bridged target and providing it to the payer 110, (4) receiving transaction requests from the bridged system 135, (5) returning transaction approval to the bridged system 135, and (6) processing notifications from the bridged system 135. The bridged system 135 may provide target content or bridged targets from multiple service providers worldwide, and these multiple service providers 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 service providers available in the region / country selected by the payer 110 for the transaction. The location may be determined 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 that bridged payer identifier with the target request. The target request may then be relayed, along with the bridged payer identifier, to the bridged system 135 of the bridged service provider 130. The bridged payer identifier assigned to the first management system 125 may be the original user identifier of the payer 110 used within the network of the first service provider 120, such as the payer's account number or virtual wallet ID. Alternatively, for enhanced security, the first management system 125 of the first service provider 120 may create a separate bridged payer identifier that is different from the original user identifier of the payer 110. Furthermore, the bridged system 135 may assign a virtual wallet containing a bridged wallet identifier to the service provider's payers, such as users of the first service provider. Therefore, instead of using the bridged wallet identifier assigned by the bridged system 135, the first service provider 120 may use the bridged wallet identifier assigned by the bridged system 135 as the bridged wallet identifier for the target request. In order to provide the returned bridged target to the requesting payer 110, the first service provider 120's first management system 125 is configured to receive the returned target content or bridged target along with the previously provided bridged wallet identifier, and then provide the target content or bridged target to the payer 110 based on the bridged wallet 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 approval (e.g., a payment approval) to the bridge system 135. The first management system 125 of the first service provider 120 may relay the transaction request to the payer 110 based on the bridge connection payer identifier provided by the bridge connection system 135. After the payer 110 approves the transaction and returns an approval, the first management system 125 of the first service provider 120 may return the transaction approval to the bridge connection system 135 to process the transaction. Alternatively, based on a setting or agreement, the first service provider 120 may be authorized to approve the transaction without requiring further confirmation from the payer 110. For example, the payment amount is within a predetermined range. In this case, the first management system 125 of the first service provider 120 may return the transaction approval to the bridge connection system 135 itself.

[0038] The bridge connection system 135 of the bridge connection service provider 130 may be configured to perform three functions: a third-party targeted content / bridge connection target provider, a third-party authentication proxy, and a third-party clearing agency. Firstly, the bridge connection system 135 of the bridge connection service provider 130 may provide targeted content or bridge connection targets (e.g., targeted content or bridge connection targets of a second service provider 140 in one embodiment) to the first management system 125. Secondly, the bridge connection system 135 of the bridge connection 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. Thirdly, the bridge connection system 135 of the bridge connection service provider 130 may function as a third-party clearing agency to bridge and clear transactions between different service providers using a transaction bridging mechanism based on the relevant transaction information recorded (e.g., clearing multiple transactions between a first service provider and a second service provider).

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

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

[0041] To function as a third-party authentication proxy relaying transaction requests and approvals, the bridge connection system 135 of the bridge connection 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 transaction approvals from the first management system 125 to the second management system 145. The second management system 145 may provide a recipient / merchant identifier representing the identity of the recipient 150 along with the transaction request. Upon receiving a transaction request (which may include the bridge connection transaction identifier and recipient / merchant identifier provided by the second management system 145), the bridge connection system 135 of the bridge connection service provider 130 may use the bridge connection transaction identifier to find the bridge connection payer identifier representing the payer 110 of the first service provider 120. Next, the bridge connection system 135 of the bridge connection service provider 130 may return an acknowledgment of receipt to the second management system 145 and relay the transaction request, including the bridge connection payer identifier and the recipient / merchant identifier, to the first management system 125. After the first management system 125 approves the transaction request, the bridge connection system 135 may record the transaction and send a message indicating that the transaction has been confirmed (e.g., payment successful), along with some transaction details, to the first management system 125 and the second management system 145.

[0042] To function as a third-party clearing agency, the bridge connection system 135 of the bridge connection service provider 130 is configured to use a transaction bridging mechanism to clear transactions between different service providers (for example, clearing multiple transactions between a first service provider and a second service provider). In one embodiment, each of the first and second service providers creates 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 bridge connection payer identifier or another ID separately generated by the first management system 125. Similarly, the Y transaction ID may be a previously created payee / merchant identifier or another ID separately generated by the second management system 145. To bridge such transactions between different service providers, the bridge connection system 135 may use a bridge connection transaction identifier to associate it with internal transaction IDs of different service providers, such as X transaction ID and Y transaction ID, and link it to the relevant transaction information. The bridge connection system 135 of the bridge connection service provider 130 may store and maintain (1) the association between the bridge connection transaction identifier and the internal transaction ID of the first service provider, and (2) the association between the bridge connection transaction identifier and the internal transaction ID of the second service provider.

[0043] In one embodiment, to enhance privacy protection, the bridge connection system 135 of the bridge connection service provider 130 may generate a job ID for each bridge connection 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 contain information about the payer 110, the first service provider 120, the recipient 150, and the second service provider 140. In this embodiment, the bridge connection system 135 stores and maintains the association between the bridge connection transaction identifier and the job ID. The bridge connection transaction identifier and / or job ID may be recorded in a database, which may be a distributed ledger such as a blockchain, but is not limited to this. As a result, in one embodiment, the bridge connection system 135 may record each transaction together with the job ID, the payer's virtual wallet, the recipient's virtual wallet, the amount, and the currency.

[0044] In another embodiment, the bridge connection system 135 of the bridge connection service provider 130 may generate multiple job IDs for a single bridge connection transaction identifier. Each job ID corresponds to one of the following: payment, refund, or cancellation of the single bridge connection transaction identifier, and may be recorded in a database, which may be, but is not limited to, a distributed ledger such as a blockchain. Thus, the bridge connection system 135 of the bridge connection service provider 130 may provide a transaction clearing service between the first service provider 120 and the second service provider 140 based on the relevant transaction information recorded in the database. Details of transaction recording and clearing are incorporated herein by reference to International Patent Application No. PCT / US17 / 12635, “DIGITAL PROPERTY MANAGEMENT ON A DISTRIBUTED TRANSACTION CONSENSUS NETWORK,” filed on January 6, 2017.

[0045] Among the other functions of the service provider, the second management system 145 of the second service provider 140 is configured to recognize bridge-connected targets scanned by the recipient 150's scanning system 155. Since bridge-connected targets are generated based on the target format and the second service provider's rules, the scanning system 155 recognizes bridge-connected targets in the same way as targets from another payer of the second service provider and generates scanned information. The second management system 145 parses the scanned information to identify the bridge-connected service provider 130, the target generator 160, the bridge-connected transaction identifier and / or the recipient / merchant identifier of the recipient 150. In one embodiment, the second management system 145 may request the target generator 160 to provide the bridge-connected transaction identifier associated with the bridge-connected target scanned by the recipient 150. Furthermore, the second management system 145 may receive relevant transaction information, such as a description of the goods or services sold by the recipient 150, the amount, and the type of currency. In one embodiment, the second management system 145 may further elucidate the payer's identity through the bridged transaction identifier and associated mapping. The second management system 145 may separately generate an internal transaction ID (e.g., Y transaction ID) to associate with the bridged transaction identifier and the recipient / merchant identifier and maintain such mapping. Next, the second management system 145 of the second service provider 140 may provide a transaction request (e.g., a payment request) to the bridged system 135. The transaction request may include the bridged transaction identifier, the recipient / merchant identifier, and associated transaction information. Finally, upon receiving a message confirming the bridged transaction, the second management system 145 may send a message notifying the recipient 150 of the result (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 a second service provider. The bridged target is recognizable by the recipient 150's scanning system 155 and the second service provider 140's second management system 145. 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 payer 110. Furthermore, the target generator 160 may associate the generated target content or bridged target with the bridged transaction identifier and / or bridged wallet identifier and maintain that association. Next, the target generator 160 provides the target content or bridged target to the bridged system 135. After the recipient 150's scanning system 155 scans the bridged target, the target generator 160 may, if requested, provide the bridged transaction identifier associated with the scanned bridged target to the second management system 145. As mentioned above, the target generator 160 may be a module embedded in or connected to the second management system 145. Therefore, 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, in order to generate target content or bridged targets that correspond to multiple service providers.

[0047] In summary, a bridge connection service provider 130, such as TBCASoft, Inc.'s HIVEX®, provides a second service provider 140 target content or bridge connection target to the payer 110 of the first service provider 120, allowing the payer 110 to present the second service provider 140's bridge connection target to a recipient 150 (e.g., a merchant of the second service provider 140). The recipient 150's (e.g., merchant) scanning system 155 scans and recognizes the second service provider 140's bridge connection target. After scanning, the transaction request generated by the recipient 150 is relayed to the first service provider 120 through the bridge connection service provider 130. 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 bridge connection system 135 of the bridge connection service provider 130 records the transaction in a distributed ledger such as a database or blockchain, and the transaction is then considered complete. The relevant transaction record is then distributed to both the first management system 125 and the second management system 145. The approval and the relevant transaction record may further be distributed to the recipient 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 the 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, but the system structure is basically the same as described above, in the case where the bridge connection service provider 130 is neither the first service provider 120 nor the second service provider 140.

[0049] Figure 2 illustrates an embodiment of the present invention in which a target bridge connection is performed in Consumer Presented Mode (CPM). In this scenario, payer 110 of a first service provider (e.g., LINE Pay® Taiwan) is traveling from Taiwan to Japan and wishes to pay by mobile payment at a merchant in Japan (e.g., a Watsons® store). The merchant is, in this case, the recipient 150. As shown in Figure 2, this store accepts PayPay®, Rakuten Pay, and FamiPay®, all of which are different mobile payment services used by the payer. Therefore, the Target Bridge Connection Service of the present invention is needed to complete the transaction between the two mobile payment service providers. In this example, payer 110 uses Line Pay Taiwan (i.e., the first service provider 120) to make the payment, and recipient 150 chooses PayPay (i.e., the second service provider 140) to receive the payment. After payer 110 selects PayPay as the second service provider 140, the app on the mobile phone (i.e., mobile device 115) may further instruct payer 110 to select a payment method, namely consumer-presented mode (CPM) or merchant-presented mode (MPM). Several embodiments of a transaction between service providers in merchant-presented mode are described in International Patent Application PCT / US21 / 27370, “METHOD AND SYSTEM FOR RESOLVING A TARGET,” filed on 14 April 2021, which is incorporated herein by reference in its entirety. In consumer-presented mode, payer 110 selects “Present QR code,” and the app receives a bridged QR code that can be displayed on payer 110’s mobile device 115. The merchant’s (e.g., Watsons as recipient 150) scanning system 155 then scans the QR code displayed on payer 110’s mobile device 115. Upon receiving scanned information from the merchant, PayPay (second service provider 140) may provide the transaction request to HIVEX, which is the bridge connection service provider 130.Next, HIVEX records the bridged transaction after receiving transaction approval from LINE Pay Taiwan (first service provider 120). HIVEX then provides transaction confirmation to LINE Pay Taiwan (first service provider 120) and PayPay (second service provider 140).

[0050] Figures 3 to 6 show sequence diagrams of a target bridge connection in one embodiment of the present invention. As shown in Figure 3, payer 110 may request a bridge connection target. In step S111, payer 110 may send a request to first service provider 120 for a pick list of the area where payer 110's mobile device 115 is located, which is a list of second service providers available in that area. In one embodiment, the first management system 125 of the first service provider 120 may authenticate both payer 110 and its mobile device 115 before further processing the payer's request, as shown in steps S112, S1121, and S1122. Step S1121 shows that the first management system 125 of the first service provider 120 may send an authentication request to payer 110's mobile device 115. The payer's 110 portable device 115 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 bridge connection system 135 of the bridge connection service provider 130.

[0051] In step S114, after receiving the request, the bridge connection system 135 may look up service provider information within 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, after receiving it from the bridge connection system 135, the first management system further relays the pick list to the payer 110. As previously stated, 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 within the bridge connection network, it may generate a pick list locally by selecting available service providers in that region and within the bridge connection network. In step S116, based on a pick list received from the first service provider 120 or generated locally, the payer 110 may select a second service provider 140 from the pick list displayed on the mobile device 115 and send a target request to the first management system 125 to request a bridged target of 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 connection 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 second service provider 140 bridge connection target or target content. 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 has the authority to generate a bridge connection target or target content based on the target format and rules of the second service provider 140.

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

[0054] In step S125, after receiving the bridge connection target or target content, the bridge connection system 135 may associate the bridge connection transaction identifier with the bridge connection payer identifier and return the bridge connection 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 bridge connection target and provide the bridge connection target to the payer's mobile device 115. In fact, the target content may be converted into a bridge connection target by the target generator 160, the bridge connection system 135 of the bridge connection service provider 130, or the payer's mobile device 115.

[0055] The bridge connection target may be presented to the recipient 150 to proceed with the transaction as shown in Figure 5. In step S131, the recipient 150's scanning system 155 may scan the bridge connection target presented by the payer 110 to the mobile device 115. In step S132, after scanning the bridge connection target, the scanning system 155 may transmit the scanned information to the second management system 145 of the second service provider 140 to initiate the transaction request. The scanning system 155 may also transmit 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 scanning 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 considered 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 bridge connection transaction identifier to the payer 110 via the bridge connection system 135. In step S135, upon receiving the transaction request, the bridge connection system 135 of the bridge connection service provider 130 may decode the bridge connection transaction identifier of the scanned bridge connection target to a bridge connection payer identifier representing the payer 110 of the first service provider 120. If this decoding is successful, the bridge connection system 135 of the bridge connection service provider 130 may return an acknowledgment of receipt to the second management system 145, as shown in step S1351. The bridge connection system 135 may then forward the transaction request, including the bridge connection payer identifier, to the first management system 125 of the first service provider 120, as shown in step S1352.

[0057] In step S136, once permission is granted, the first management system 125 of the first service provider 120 may approve the transaction. The first management system 125 may have the authority to automatically approve the transaction without requiring further permission from the payer 110. Alternatively, the payer's approval of the transaction is required to enhance the security of the transaction. In this case, the first management system 125 may identify the payer 110 by the bridged payer identifier and request the payer 110 to approve the transaction via the mobile device 115, which may then provide the transaction approval to the first management system 125 as shown in steps S1361 and S1362. The first management system 125 may further transmit the transaction approval to the bridged system 135 as shown in step S137.

[0058] In step S138, upon receiving transaction approval, the bridge connection system 135 may process the transaction using a bridge connection payer identifier associated with the payer's account. The relevant transaction information may be linked by the bridge connection transaction identifier. For each bridge connection 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 mentioned above, the X transaction ID may be a bridge connection payer identifier or a separately generated ID. Similarly, the Y transaction ID may be a recipient / merchant identifier or a separately generated ID. The association between the bridge connection transaction identifier and the X transaction ID may be stored and maintained by the bridge connection system 135 and / or the first management system 125. The association between the bridge connection transaction identifier and the Y transaction ID may be stored and maintained by the bridge connection system 135 and / or the second management system 145. In one embodiment, to enhance privacy protection, the bridge connection system 135 of the bridge connection service provider 130 may generate a job ID for each bridge connection transaction identifier to record transactions, which may be stored in a distributed ledger such as a blockchain. As a result, the bridge connection 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 bridge connection system 135 of the bridge connection service provider 130 may generate multiple job IDs for a single bridge connection transaction identifier, and multiple parts of a transaction corresponding to payments, refunds, and cancellations may be recorded using different job IDs, all of which correspond to a single bridge connection transaction identifier. Next, the bridge connection system 135 may send a payment success notification to the first management system 125 (step S1381) and receive an acknowledgment of receipt from the first management system 125 (step S1382). Upon receiving confirmation of receipt, the bridge connection system 135 may send a notification of successful payment to the second management system 145, as shown in step S1383.Finally, a notification of successful payment may be sent separately from the first management system 125 of the first service provider 120 to the payer's mobile device 115 (step S1391), and from the second management system 145 of the second service provider 140 to the recipient's scanning system 155 (step S1392).

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

[0060] In step S145, after receiving a bridged target or target content from the target generator 160 and a target request from the first management system 125, the bridged system 135 of the bridged service provider 130 may associate the bridged transaction identifier (provided by the target generator 160) with 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 even without a request. As one example, when the first management system 125 detects a bridged target being used by the payer 110 in the transaction network, the first management system 125 may notify the bridged system 135, which may associate the bridged transaction identifier with the bridged payer identifier provided by the first management system 125 and then provide the bridged target or target content. The bridge connection system 135 may also provide bridge connection targets or target content to the payer 110 even without a request from the first management system 125. In this case, when a bridge connection transaction is requested, the bridge connection system 135 may detect the event and add bridge connection targets or target content according to the bridge connection payer identifier provided by the first management system 125. The target content or bridge connection targets may then be provided to the payer 110 from the first management system 125 without an initial request. In step S147, the first management system 125 of the first service provider 120 may convert the received target content into a bridge connection target and provide the bridge connection target to the payer 110's mobile device 115. Alternatively, the target content may be converted into a bridge connection target by the target generator 160, the bridge connection system 135, or the mobile device 115.

[0061] In another embodiment, the target generator 160 may generate bridged target or target content for a digital coupon that payer 110 can use to redeem a prize from recipient 150, which 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 freely distributed by the bridged service provider 130 to advertise recipient 150 (e.g., a merchant). Once a target is recognized, the second management system 145 of the second service provider 140 only needs to record which target is being used, and the prize may be provided directly to payer 110 without recording the transaction.

[0062] The foregoing description of the embodiments is provided so that those skilled in the art can manufacture 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 requiring innovative capabilities. The subject matter of the claims described herein is not intended to be limited to the embodiments shown herein, but rather to encompass the broadest range consistent with the principles and novel features disclosed herein. Additional embodiments are considered to be within the spirit and true scope of the disclosed subject matter. Accordingly, the present invention is intended to cover modifications and variations that fall within the scope of the appended claims and their equivalents.

Claims

1. A method for bridging a target between a payer's mobile device of a first service provider and a recipient's scanning system of a second service provider different from the first service provider, The first management system of the first service provider receives the target content of the second service provider or a bridge connection target generated based on the target content from the bridge connection system of the payer's bridge connection service provider, The first management system of the first service provider wirelessly provides the target content or 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 recipient of the second service provider, which recognizes the bridge connection target. In a method including, A method characterized in that the recipient's scanning system does not recognize the target of the first service provider.

2. The method according to claim 1, characterized in that the target and the bridge-connected target are each QR codes (registered trademarks).

3. The method according to claim 1, characterized in that the first service provider is located in a first country, the second service provider is located in a second country, and the first country is different from the second country.

4. Before receiving the target content of the second service provider or the bridge connection target, The first management system wirelessly receives the payer's request for the target content from the payer's mobile device for the target content of the second service provider, The first management system provides the bridge connection system with a request for the target content. The method according to claim 1, further comprising:

5. After presenting the bridged target to the recipient's scanning system by wirelessly providing the target content of the second service provider or the bridged target to the payer's mobile device, The first management system receives a transaction request from the bridge connection system after the recipient's scanning system has scanned the bridge connection target, The first management system provides transaction approval to the bridge connection system, After the bridge connection system records the transaction related to the transaction notification, the first management system receives the transaction notification from the bridge connection system. The method according to claim 1, further comprising:

6. Before providing the aforementioned transaction approval to the bridge connection system, The first management system wirelessly provides the transaction request to the payer's mobile device, The first management system receives the transaction approval wirelessly from the payer's mobile device. The method according to claim 5, further comprising:

7. The first management system authenticates both the payer and the payer's mobile device. The method according to claim 4, further comprising:

8. The method according to claim 7, characterized in that, before providing the request for the target content to the bridge connection system, the first management system authenticates both the payer and the payer's mobile device.

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

10. The method according to claim 1, characterized in that the target content includes a first timestamp indicating a first time when the target content is generated.

11. The aforementioned target content is Includes a first timestamp indicating a first time when the target content is generated, The transaction request includes a second timestamp indicating a second point in time when the recipient's scanning system scans the bridged target. The method according to claim 5, characterized in that

12. To determine whether the time difference between the first timestamp and the second timestamp exceeds a predetermined period. The method according to claim 11, further comprising:

13. The method according to claim 1, characterized in that the bridge connection service provider is the first service provider or the second service provider.

14. The method according to claim 1, characterized in that the bridge connection service provider is neither the first service provider nor the second service provider.

15. The method according to claim 1, characterized in that the bridge connection system of the bridge connection service provider can provide target content from multiple different service providers.

16. The method according to claim 15, characterized in that the plurality of different service providers are located in a plurality of different countries.

17. The method according to claim 4, characterized in that the bridge connection system generates a bridge connection transaction identifier after receiving a request for the target content from the first management system.

18. After presenting the bridged target to the recipient's scanning system by wirelessly providing the target content of the second service provider or the bridged target to the payer's mobile device, The first management system receives a transaction request from the bridge connection system after the recipient's scanning system has scanned the bridge connection target, The first management system provides transaction approval to the bridge connection system, After the bridge connection system records the transaction related to the transaction notification, the first management system receives the transaction notification from the bridge connection system. In a method that further includes, 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. The method according to claim 17, characterized by the above.

19. The method according to claim 5, characterized in that the bridge connection system records the transaction in a distributed ledger.

20. The method according to claim 1, characterized in that the list of second service providers is selected based on the location of the payer's mobile device.

21. A method for bridging a target between a payer's mobile device of a first service provider and a recipient's scanning system of a second service provider different from the first service provider, The bridge connection system of the bridge connection service provider receives from the target generator a target content of the second service provider or a bridge connection target generated based on said target content, The bridge connection system of the bridge connection service provider provides the target content or the bridge connection target to the first management system of the first service provider, so that the bridge connection target generated based on the target content is presented to the recipient's scanning system, which recognizes the bridge connection target, via the payer's mobile device. In a method including, The recipient's scanning system does not recognize the target of the first service provider. A method characterized by the following features.

22. The method according to claim 21, characterized in that the target and the bridge-connected target are each QR codes.

23. The method according to claim 21, characterized in that the first service provider is located in a first country, the second service provider is located in a second country, and the first country is different from the second country.

24. The method according to claim 21, characterized in that the target generator is a system of the second service provider.

25. The method according to claim 21, characterized in that the target generator is a system of the bridge connection service provider.

26. Before receiving the target content from the second service provider, The bridge connection system receives the target content request from the first management system for the second service provider's target content, The bridge connection system provides the target content request to the target generator. The method according to claim 21, further comprising:

27. After providing the target content or the bridged target to the first management system, After the scanning system has scanned the bridge connection target, the bridge connection system receives a transaction request from the second management system of the second service provider, The bridge connection system provides the transaction request to the first management system, After the transaction request and the transaction related thereto are approved, the bridge connection system receives the transaction approval from the first management system, The bridge connection system records the transaction. The method according to claim 21, further comprising:

28. The method according to claim 21, characterized in that the bridge connection system receives a first timestamp from the target generator in addition to the target content or the bridge connection target.

29. The bridge connection system receives a first timestamp from the target generator in addition to the target content or the bridge connection target, and the first timestamp indicates a first time when the target content or the bridge connection target is provided. The bridge connection system receives a second timestamp from the second management system in addition to the transaction request, and the second timestamp indicates a second time when the scanning system scans the target. The method according to claim 27, characterized in that

30. To determine whether the time difference between the first timestamp and the second timestamp exceeds a predetermined period. The method according to claim 29, further comprising:

31. The method according to claim 21, characterized in that the bridge connection service provider is neither the first service provider nor the second service provider.

32. The method according to claim 31, characterized in that the bridge connection system of the bridge connection service provider can provide targeted content from multiple different service providers.

33. The method according to claim 32, characterized in that the different service providers are located in multiple different countries.

34. The method according to claim 26, characterized in that the bridge connection system generates a bridge connection transaction identifier after receiving a request for the target content from the first management system.

35. After providing the target content or the bridged target to the first management system, After the scanning system has scanned the bridge connection target, the bridge connection system receives a transaction request from the second management system of the second service provider, The bridge connection system provides the transaction request to the first management system, After the transaction request and the transaction related thereto are approved, the bridge connection system receives the transaction approval from the first management system, The bridge connection system records the transaction. In a method that further includes, 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. The method according to claim 34, characterized by the above.

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

37. The method according to claim 21, characterized in that the list of second service providers is selected based on the location of the payer's mobile device.

Images