Systems and methods for bridging targets - Patents.com

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 hereby incorporated by reference in its entirety.

[0002] FIELD OF THEINVENTION The present disclosure relates to target bridging techniques that allow a service provider's payer to present targets of another service provider. The present disclosure also relates to a system and method for target bridging services that allows transactions between service providers of different target types. [Background technology]

[0003] A payment method is the way in which 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 has 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] Of these popular 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), a consumer pays by scanning a QR code displayed by the merchant with their smartphone. On the other hand, in Consumer Present Mode (CPM), 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 payment cards, payment networks, payment terminals and merchant accounts. The 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 acquired their own users and merchants. However, because the two service providers use different QR code formats, a payer of one service provider and a payee of the other service provider cannot complete a transaction via QR code. For example, a payer (e.g., a consumer) of a first service provider cannot purchase an item from a payee (e.g., a merchant) of 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 terminal (e.g., a smartphone). One solution to this problem is for the first service provider and the second service provider to enter into a bilateral cooperation agreement and modify their systems to enable the payee of the second service provider, such as a merchant, to recognize the QR code of the first service provider provided by the payer of the first service provider, such as a user. However, modifying both systems to provide such functionality can be costly and time-consuming. Moreover, the complexity grows exponentially if more service providers want to recognize each other's QR codes.

[0007] Moreover, the global village is steadily facilitating an increasing number of international businesses travelling around the world for both business and leisure. To purchase overseas goods and services arising from such businesses, cross-border QR code payments need to be made. Generally, all the service providers available for QR code payments at overseas participating stores are different from the service providers the customer uses in his or her own country. 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] It is therefore 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, a 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 in the world that uses target standards, formats, and / or rules ("target formats") different from those of the first service provider. Thus, the target bridging technology solves the problem of transactions between service providers and fulfills a long-standing need, while also providing unexpected results that may revolutionize and improve transactions in related industries around the world.

[0011] The present disclosure relates to a system and method for a bridge service that enables transactions between two or more service providers with different target types, each service provider having 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 bridge target generated based on the target content from a bridge system of a payer bridge service provider, and (2) providing, by the first management system of the first service provider, the target content or the bridge target of the second service provider wirelessly to a payer mobile device to present the bridge target generated based on the target content to a scan system of a payee of the second service provider that recognizes the bridge target.

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

[0013] In one embodiment, the 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 and allow the second service provider to initiate a transaction upon scanning or sensing the target.

[0014] In one embodiment, a request for the target 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 second service provider's target content or a bridge connection target generated based on the target content. In one embodiment, the second service provider's target content 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 only valid for a predetermined period of time. An 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 difference between the first and second timestamps exceeds the 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 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 bridging service provider's bridging system may generate a bridge transaction identifier for the transaction such that related transaction information may be linked via the bridge 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 bridge transaction identifier, which may be stored in a distributed ledger such as a blockchain.

[0019] In one embodiment, the bridge connection service provider's bridge connection system may record each transaction including a job ID, the payer virtual wallet, the payee virtual wallet, the amount, and the currency type. In another embodiment, the bridge connection service provider's bridge connection system may generate multiple job IDs for a single bridge connection transaction identifier, where multiple parts of a transaction may be recorded with different job IDs, all corresponding to one bridge connection transaction identifier. [Brief description 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. [Diagram 2] FIG. 1 illustrates an embodiment of the present invention for bridging targets in Consumer Present Mode (CPM), where 1st SP and 2nd SP stand for 1st Service Provider and 2nd Service Provider, respectively. [Diagram 3] 13 is a flow chart illustrating the steps for requesting a bridge connection target from a payer in the present system. [Figure 4]10 is a flow chart illustrating the steps for providing targeted content or bridged targets from a target generator in the present system. [Diagram 5] 1 is a flow chart illustrating the steps of scanning a bridge connection target and processing a transaction between a payer of a first service provider and a payee of a second service provider. [Figure 6] 10 is a flow chart illustrating the steps of an alternative embodiment for providing targeted content or bridge connection targets without prior request. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0021] The terms used in the following description are intended to be interpreted in the broadest reasonable manner, even when used in conjunction with a detailed description 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 to that effect 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 transfer of digital assets between payers and payees utilizing targets for exchanging information such as payer identifiers, payee identifiers, timestamps, and transaction requests. A service provider typically includes a management system that performs functions related to digital asset transactions.

[0023] The term "payer" as used herein refers to a party, individual or entity that authorizes a transaction to transfer their digital assets to another party. A payer of a service provider is also a user of the service provider who holds an account with the service provider. The user can transfer digital assets stored in the 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 his / her mobile device.

[0024] The term "Payee" refers to a party, individual or entity that receives digital assets transferred from another party. A service provider payee may be either a service provider user or a merchant. A service provider merchant may be aware of the service provider's target. However, a service provider merchant may not have an account with the service provider and therefore may not be a service provider user. In other words, a service provider 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 multiple types of digital assets, credits, and debt, such as, but not limited to, 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, digital US dollars, digital Japanese yen, digital euros, and digital New Taiwan dollars. Digital securities may include, but are not limited to, digital Apple stocks, digital Google stocks, 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 corresponding metadata.

[0026] As used herein, the term "target" refers to a medium that contains 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. The 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 to extract 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 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. A 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 term "bridge" or "bridging" refers to systems and methods that allow a payer of a first service provider to present a target of a second service provider to a payee of the second service provider that does not recognize the target of 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 of the second service provider does not recognize the target of the first service provider. In some embodiments, the bridging service allows 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 QR code of the consumer's service provider in consumer presentment mode (CPM).

[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 the first service provider nor the 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 presented below may be implemented by programmable circuitry 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 the first service provider and a payee of the second service provider by scanning or sensing a target. Targets such as QR codes play a role in the mobile payment industry similar to credit card numbers in the traditional payment industry. A credit card holder can only use the card to make payments at merchants that recognize the credit card number. 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) at a payee (usually a merchant of the first service provider) that recognizes the target. The payee of the first service provider cannot recognize the second service provider's target on their device (e.g., POS). Similarly, the payee of the second service provider cannot recognize the first service provider's target on their device. In one embodiment, the bridging service provider may provide bridging targets or target content of multiple other service providers (such as the second service provider and many other similar service providers) around the world to the first service provider's payer, allowing the first service provider's payer to complete transactions at all merchants that recognize targets of any one of these multiple other service providers. For example, there may be 10 major service providers in a first country and 5 major service providers in a second country. It may be complicated for each of the 10 service providers in the first country to engage with each of the 5 service providers in the second country. In this situation, the bridging service provider may provide such target bridging services to connect all 15 service providers in both countries, allowing the payer of any service provider to complete transactions at the payee (e.g., merchant) side of 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 transfers digital assets to the payee 150. The bridge connection service provider 130 has a bridge connection system 135 communicatively connected 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 targeted content or bridged 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 targeted content or bridged targets for multiple service providers.

[0034] Each of the first service provider 120 and the second service provider 140 operates a transaction network between users and merchants and has its own targeting standards, formats, and / or rules. Therefore, the payer and payee of the first service provider 120, e.g., the user (payer) and the merchant (payee), can complete a transaction (e.g., a payment or transfer) within the first service provider's network by scanning a target. The same situation applies to the payer and payee of the second service provider 140. However, to complete a transaction and / or other communication between the payer of the first service provider 120 and the payee of the second service provider 140, the two service providers are configured to communicatively connect to the bridging service provider 130.

[0035] Among other functions of the service providers, the first management system 125 of the first service provider 120 is configured to implement additional functions 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 bridge targets from the second service provider 140 via the bridging system 135; (3) receiving and providing target content or bridge targets to the payer 110; (4) receiving a transaction request 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 bridge targets for each of multiple service providers around the world, which 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 the service providers available 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 bridge connection target, the first management system 125 of the first service provider 120 may assign a bridge connection payer identifier to the payer 110 and associate the bridge connection payer identifier with the target request. The target request may then be relayed to the bridge connection system 135 of the bridge connection service provider 130 along with the bridge connection payer identifier. The bridge connection 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 added security, the first management system 125 of the first service provider 120 may separately create a bridge connection payer identifier that is different from the original user identifier of the payer 110. Additionally, the service provider's payers, such as users of the first service provider, may be assigned a virtual wallet including the bridge connection wallet identifier by the bridge connection system 135. Thus, the first service provider 120 may use the bridged wallet identifier assigned by the bridged 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 the 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 a bridge connection payer identifier provided by the bridge connection system 135. After the payer 110 approves the transaction and returns the approval, the first management system 125 of the first service provider 120 may return the transaction approval to the bridge connection system 135 for processing the transaction. Alternatively, based on the settings or agreement, the first service provider 120 may be authorized to approve the transaction without a new confirmation from the payer 110. For example, the payment amount is within a predetermined numerical value. 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 on its own.

[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 act as a third-party authentication proxy to relay transaction requests and authorizations between the first management system 125 and the second management system 145. Third, the bridging system 135 of the bridging service provider 130 may act as a third-party clearing house to bridge and clear transactions between different service providers using a transaction bridge mechanism (e.g., clear multiple transactions between a first service provider and a second service provider) based on the relevant transaction information on record.

[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). Such 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 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 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 the targeted 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 that initiated the request for the bridge connection target. After receiving the targeted content or bridge connection target from the target generator 160, the bridge connection system 135 of the bridge connection service provider 130 may map the bridge connection transaction identifier to the bridge connection payer identifier and return the targeted content or bridge connection target to the first management system 125. Alternatively, the mapping between the bridge connection transaction identifier and the bridge connection payer identifier may occur before the bridge connection system 135 receives the targeted content or bridge connection target.

[0040] In another embodiment, the first management system 125 of the first service provider may request the second service provider's targeted content or bridge targets 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 proactively provide the second service provider's targeted content or bridge targets 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 bridge transaction identifier and the payee / merchant identifier provided by the second management system 145), the bridging system 135 of the bridging service provider 130 may use the bridge transaction identifier to find the bridge 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 to the second management system 145 and relay the transaction request, including the bridge 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., clear 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 bridge payer identifier or another ID separately generated in the first management system 125. Similarly, the Y transaction ID may be a previously created payee / merchant identifier or another ID separately generated in the second management system 145. To bridge such transactions between different service providers, the bridging system 135 may use the bridging transaction identifiers to associate with the internal transaction IDs of the different service providers, such as X Transaction ID and Y Transaction ID, and link to the associated transaction information. The bridging system 135 of the bridging service provider 130 may store and maintain (1) an association between the bridging transaction identifiers and the internal transaction IDs of the first service provider, and (2) an association between the bridging transaction identifiers and the internal transaction IDs 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 include information about the payer 110, the first service provider 120, the payee 150, and the second service provider 140. In this embodiment, the bridge connection system 135 stores and maintains a correspondence between the bridge connection transaction identifier and the job ID. The bridge connection 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 bridge connection 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 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 payments, refunds, and cancellations for the single bridge connection transaction identifier and may be recorded in a database, such as, but not limited to, a distributed ledger such as a blockchain. As such, the bridge connection system 135 of the bridge connection service provider 130 may provide a clearing service for the transaction between the first service provider 120 and the second service provider 140 based on the relevant transaction information recorded in the database. For details of transaction recording and clearing, please refer to International Patent Application No. PCT / US17 / 12635, entitled "DIGITAL PROPERTY MANAGEMENT ON A DISTRIBUTED TRANSACTION CONSENSUS NETWORK," filed on 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 scanning system 155 of the payee 150. The bridge targets are generated based on the target format and the second service provider's rules, so that the scanning system 155 recognizes the bridge targets as well as targets from another payer of the second service provider and generates the scanned information. The second management system 145 parses the scanned information to identify the bridge service provider 130, the target generator 160, the 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 of the goods or services sold by the payee 150, the amount, and the type of currency. In one embodiment, the second management system 145 may further resolve the identity of the payer through the bridged transaction identifier and the associated association. 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 payee / merchant identifier and maintain such association. The second management system 145 of the second service provider 140 may then provide a transaction request (e.g., a payment request) to the bridged 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 notify the payee 150 of the outcome (e.g., successful payment).

[0046] The target generator 160 is configured to receive the target request and generate a bridge connection target or target content for the second service provider. The bridge connection target is recognizable by the scanning system 155 of the payee 150 and the second management system 145 of the second service provider 140. The target request may include a bridge connection transaction identifier and / or a bridge connection 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 bridge connection target with the bridge connection transaction identifier and / or the bridge connection wallet identifier and maintain the association. The target generator 160 then provides the target content or bridge connection target to the bridge connection system 135. After the scanning system 155 of the payee 150 scans the bridge connection target, the target generator 160 may provide the bridge connection transaction identifier associated with the scanned bridge connection target to the second management system 145 upon request. As mentioned above, the target generator 160 may be a module embedded in or connected to the second management system 145. Thus, each service provider in the bridge 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 bridging targets to a payer 110 of a first service provider 120, so that the payer 110 may present the second service provider 140 bridging targets to a payee 150 (e.g., an affiliate of the second service provider 140). A scanning system 155 of the payee 150 (e.g., an affiliate) scans and recognizes the second service provider 140 bridging 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 a 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 be further distributed to the payee 150 (e.g., a merchant).

[0048] In alternative embodiments, the bridge connection service provider 130 may be the first service provider 120 or the second service provider 140 at the same time. 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 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 of a first service provider (e.g., LINE Pay Taiwan) travels from Taiwan to Japan and wants to make a mobile payment at a merchant in Japan (e.g., a Watsons store). The merchant is here the payee 150. As shown in FIG. 2, the merchant accepts PayPay, Rakuten Pay, and FamiPay, which are all different mobile payment services from the payer's use. Therefore, the target bridging service of the present invention needs to be utilized to complete the transaction between the two mobile payment service providers. In this example, Line Pay Taiwan (i.e., the first service provider 120) is used by the payer 110 to make the payment, and PayPay (i.e., the second service provider 140) is selected by the payee 150 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, i.e., consumer-presented mode (CPM) or merchant-presented mode (MPM). Some embodiments of a transaction between service providers in merchant-presented mode are described in International Patent Application No. PCT / US21 / 27370, entitled “METHOD AND SYSTEM FOR RESOLVING A TARGET,” filed April 14, 2021, which is incorporated herein by reference in its entirety. In the 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 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 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.Then, HIVEX records the bridged transaction after receiving the 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 target bridging 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 pick list of the area in which the payer's 110's mobile device 115 is located, the pick list being 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 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 shows 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 the information of the service provider 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 the information of the service provider in the bridge connection network, it may locally generate the pick list by selecting the service providers available in its region and in the bridge connection network. In step S116, based on the 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 to request 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 the 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 the 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 of 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 mobile device 115 of the payer 110. In step S121, the target generator 160 may generate the bridge connection target or target content and associate it with the bridge connection transaction identifier. In one embodiment, the target generator 160 may also generate a first timestamp indicating a 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 together 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 a 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 bridge connection target becomes invalid.

[0054] In step S125, after receiving the bridge connection target or target content, the bridge connection system 135 may map the bridge connection transaction identifier to 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 mobile device 115 of the payer 110. In practice, 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 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 when the bridge connection target is scanned. The second timestamp may be generated by the second management system 145 when the second management system 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 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 decrypt the bridge connection transaction identifier of the scanned bridge connection target into a bridge connection payer identifier representing the payer 110 of the first service provider 120. If the decryption is successful, the bridge connection system 135 of the bridge connection service provider 130 may return an acknowledgement 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, 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 by the payer 110. Alternatively, payer approval for the transaction is required to improve security of the transaction. 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 approval, the bridging system 135 may process the transaction using the bridging payer identifier associated with the payer's account. The 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 mentioned above, the X transaction ID may be the bridging payer identifier or may be a separately generated ID. Similarly, the Y transaction ID may be the payee / merchant identifier or may be 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 bridge connection system 135 of the bridge connection service provider 130 may generate a job ID for each bridge connection transaction identifier to record the transaction, 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 payee'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 the transaction corresponding to payments, refunds, and cancellations may be recorded with different job IDs, all corresponding to one bridge connection transaction identifier. The bridge connection system 135 may then send a notification of successful payment to the first management system 125 (step S1381) and receive a receipt confirmation from the first management system 125 (step S1382). Upon receiving the acknowledgement, 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 a predetermined criterion, 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 some criterion is met. For example, the target generator 160 may monitor the usage of previously sent bridged targets or target content and provide the newly generated bridged target 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 bridge connection target or target content from the target generator 160 and receiving the target request from the first management system 125, the bridge connection system 135 of the bridge connection service provider 130 may map the bridge connection transaction identifier (provided by the target generator 160) to the bridge connection payer identifier (provided by the first management system 125) and provide the bridge connection target or target content to the first management system 125. In another embodiment, the target generator 160 may automatically provide the bridge connection 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 bridge connection target being used by the payer 110 in the transaction network, the first management system 125 may notify the bridge connection system 135, which may map the bridge connection transaction identifier to the bridge connection payer identifier provided by the first management system 125 and then provide the bridge connection 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 bridge target or target content for a digital coupon that the payer 110 can use to redeem a gift from the payee 150 who is a merchant. In this embodiment, the target generator 160 may not need to provide a bridge transaction identifier for the generated bridge target or target content. In this case, the bridge target may be allowed to be freely distributed by the bridge service provider 130 to promote the payee 150 (e.g., the merchant). Upon recognizing the target, the second management system 145 of the second service provider 140 may simply record which target is being used, and the gift may be provided directly to the payer 110 without recording the 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 appended 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. It is therefore 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 for 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, the method comprising: receiving, by a first management system of the first service provider, 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; providing the target content or the bridge connection target of the second service provider wirelessly to the payer's mobile device by the first management system of the first service provider, and presenting the bridge connection target generated based on the target content to the scanning system of the payee of the second service provider that recognizes the bridge connection target; A method comprising: the scanning system of the recipient does not recognize the target of the first service provider; method.

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. prior to receiving the second service provider's targeted content or the bridge connection target; wirelessly receiving, by the first management system, a targeted content request from the mobile device of a payer for the targeted content of the second service provider; providing, by the first management system, a request for targeted content to the bridge connection system; The method of claim 1 further comprising:

5. wirelessly providing the second service provider's targeted content or the bridge target to the payer's mobile device and presenting the bridge target to the payee's scanning system; 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; providing a transaction approval by the first management system to the bridge connection system; receiving the transaction notification from the bridge connection system by the first management system after the bridge connection system records the transaction associated with the transaction notification; The method of claim 1 further comprising:

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

7. authenticating both the payer and the payer's portable device with the first management system. 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 targeted content to the bridging system.

9. determining, by the first management system, 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 time at which the targeted content is generated.

11. The target content includes: a first timestamp indicating a first 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 a 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. 2. The method of claim 1, wherein the bridging system of the bridging service provider is capable of providing targeted content from a number 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. 5. The method of claim 4, wherein the bridging system generates a bridge transaction identifier after receiving the request for the targeted content from the first management system.

18. wirelessly providing the second service provider's targeted content or the bridge target to the payer's mobile device and presenting the bridge target to the payee's scanning system; 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; providing a transaction approval by the first management system to the bridge connection system; receiving the transaction notification from the bridge connection system by the first management 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. The method according to claim 17, characterized in that

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

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

21. 1. A method for 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, the method comprising: receiving from a target generator a target content of a second service provider or a bridge connection target generated based on the target content by a bridge connection system of a bridge connection service provider; providing the target content or the bridge connection target by a bridge connection system of the bridge connection service provider to a first management system of the first service provider, and causing the payer's mobile device to present the bridge connection target generated based on the target content to the payee's scanning system that recognizes the bridge connection target; A method comprising: The recipient's scanning system does not recognize the first service provider's target. A method comprising:

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 a system of the bridge connection service provider.

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

27. 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; providing, by the bridge connection system, the transaction request to the first management system; receiving, by the bridge connection system, a transaction approval from the first management system after the transaction associated with the transaction request is approved; recording said transaction by said bridge connection system; 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 targeted content or the bridging target.

29. the bridging system receiving from the target generator a first timestamp 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 that the scanning system scans the target.

28. The method of claim 27.

30. Determining whether a 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 number of different service providers.

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

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

35. 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; providing, by the bridge connection system, the transaction request to the first management system; receiving, by the bridge connection system, a transaction approval from the first management system after the transaction associated with the transaction request is approved; recording said transaction by said bridge connection system; 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 a location of the payer's mobile device.

Images