Systems and methods for object bridging

Through the target bridging technology, transaction barriers caused by inconsistent QR code formats between different service providers are solved, and bridges between cross-service providers are realized, cross-border payment needs are met, international transaction processes are simplified and system modifications are reduced. cost.

CN119156629APending Publication Date: 2024-12-17TBCASOFT INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202280087885.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2022-01-09
Filing Date
2022-11-09
Publication Date
2024-12-17

AI Technical Summary

Technical Problem

The inconsistent QR code format of different service providers leads to inability to conduct transactions between cross-service providers, and the service providers used by merchants and users are often different when making cross-border payments, resulting in transaction barriers.

Method used

Through the subject bridging technology, the payer of the first service provider can bridge the QR code that it cannot be identified by the second service provider receiver, generate the bridge target, and provide it to the identifiable receiver through the bridging system , realize transactions between service providers.

Benefits of technology

It realizes transactions between different service providers, meets cross-border payment needs, simplifies international transaction processes, reduces system modification costs, and improves transaction complexity management.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure HDA0005070032970000011
    Figure HDA0005070032970000011
  • Figure HDA0005070032970000021
    Figure HDA0005070032970000021
  • Figure HDA0005070032970000031
    Figure HDA0005070032970000031
Patent Text Reader

Abstract

The present disclosure relates to an object bridging technique that enables a payer belonging to a first service provider to show an object of a second service provider to a recipient belonging to the second service provider, the recipient being unable to recognize the object of the first service provider. The innovation system of the target bridging service includes a portable device of the payer, a first management system of the first service provider, a scanning system of the receiver, a second management system of the second service provider, a bridging system of a bridging service provider, and all or part of a target generator.
Need to check novelty before this filing date? Find Prior Art

Description

Background Art

[0001] Related Applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 297,791, filed on January 9, 2022, entitled “SYSTEMS AND METHODS FOR TARGETBRIDGING TECHNOLOGY,” the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present invention relates to a bill bridging technology, which enables a payee of a service provider to present a bill of another service provider. The present disclosure also relates to a system and method of a bill bridging service, which enables transactions between service providers with different bill formats.

[0004] Related technical notes

[0005] Payment methods are the ways in which merchants can collect money from customers. Payments can be made through a variety of methods, including cash, cheque, debit card, credit card, bank transfer or mobile payment.

[0006] Contactless payment is a method of performing payments without physical contact. Common examples of contactless payments include radio frequency identification (RFID) payments, near field communication (NFC) payments, and quick response matrix code (QR code) payments through smartphones and other portable devices. Traditional credit cards, debit cards, and smart cards can also be used for contactless payments, provided that the merchant has the appropriate proximity equipment. Recently, due to the COVID-19 pandemic, contactless payments have been considered a safer payment method compared to traditional cash and card transactions.

[0007] Among these common contactless payment methods, QR code payment is performed by scanning a QR code from an application on a mobile device or a merchant point of sale (POS) system. In merchant presented mode (MPM), consumers use their smartphones to scan a QR code displayed by a merchant to make payments. Conversely, in consumer presented mode (CPM), merchants scan a QR code displayed by a consumer to receive payment. With QR code payment, transactions can be completed even without the infrastructure traditionally associated with electronic payments, such as payment cards, payment networks, payment terminals, and merchant accounts. For payers and receivers belonging to a single service provider, the system that implements this payment method is executed in the network of the service provider.

[0008] In recent years, many mobile payment service providers have emerged, and they have their own users and merchants. However, since the two service providers use different QR code formats, the payer to one service provider and the receiver to another service provider cannot complete the transaction through the QR code. For example, the payer (e.g., consumer) of the first service provider cannot purchase products from the receiver (e.g., merchant) of the second service provider because the receiver's device (e.g., POS) cannot recognize the QR code of the first service provider presented by the payer's portable device (e.g., smart phone). One way to solve this problem is that the first service provider and the second service provider reach a bilateral cooperation agreement and modify the system so that the receiver (e.g., merchant) of the second service provider can recognize the QR code provided by the payer (e.g., user) of the first service provider. However, modifying the system to provide such a function may be expensive and time-consuming. In addition, when more service providers want to recognize each other's QR codes, the complexity will increase exponentially.

[0009] In addition, the global village is undoubtedly promoting more and more international travel for business and leisure around the world. In order to purchase foreign goods and services during these activities, there will be a need for cross-border QR code payments. Generally, all service providers that can be used for QR code payments at a foreign merchant are different from the service providers that users use in their own country. In this case, the same problem will arise.

[0010] Therefore, there is a need to develop methods and systems to enable QR code recognition across service providers to facilitate transactions. Summary of the invention

[0011] In order to solve the QR code recognition problem to facilitate transactions between two different service providers, this case provides a target bridging technology to enable transactions between the payer (e.g., consumer) of the first service provider and the receiver (e.g., merchant) of the second service provider. The second service provider can be any other service provider in the world that uses a different target standard, format and / or rule (target format) from the first service provider. Therefore, the target bridging technology solves the transaction problem across service providers and meets a long-standing demand. It also brings unexpected results and may revolutionize transactions in related industries around the world.

[0012] The present disclosure relates to a system and method for a bridging 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 the following steps: (1) a first management system of a first service provider receives target content belonging to a second service provider or a bridging target generated based on the target content from a bridging system of a bridging service provider for a payee; and (2) the first management system of the first service provider wirelessly provides the target content or the bridging target of the second service provider to a portable device of the payee, so as to present the bridging target generated based on the target content to a scanning system of a recipient belonging to the second service provider, which can recognize the bridging target.

[0013] In another aspect, the present invention includes the following steps: (1) a bridging system of a bridging service provider receives a target content of a second service provider or a bridging target generated based on the target content from a target generator; and (2) the bridging system of the bridging service provider provides the target content or the bridging target to a first management system of a first service provider, so that a portable device of a payee presents the bridging target generated based on the target content to a scanning system of a recipient that can identify the bridging target. In both aspects, the scanning system of the recipient of the second service provider cannot identify the target of the first service provider. In addition, the second service provider may even be located in a country different from that of the first service provider.

[0014] In one embodiment, the targets used by the first service provider and the second service provider include, but are not limited to, one-dimensional, two-dimensional, and three-dimensional quick response matrix codes (QR codes), near-field communication (NFC) tags, voice signatures, and fingerprints. Each service provider may have its own proprietary target and target content data format. The target, such as a QR code, may contain information about the payer and / or the recipient, and enable the second service provider to initiate a transaction when the target is scanned or sensed.

[0015] In one embodiment, before the first management system of the first service provider receives the target content or the generated bridge target of the second service provider, the portable device of the payer generates a request for the target content and forwards it to the bridge service provider. In one embodiment, the target content or bridge target of the second service provider is generated by the target generator and provided to the first management system of the first service provider through the bridge system of the bridge service provider. The target generator can be a system / module belonging to the second service provider or a system / module belonging to the bridge service provider.

[0016] In one embodiment, the second management system of the second service provider may send a transaction (e.g., payment) request to the bridging service provider to process the transaction between the payee and the receiver. The bridging system of the bridging service provider may then forward the transaction request to the first management system of the first service provider, which may further forward the transaction request to the portable device of the payee for approval, or may directly approve the transaction if previously authorized (e.g., the payment amount is less than a predetermined amount).

[0017] In one embodiment, the bridge token is valid only within a predetermined period. The relevant system may record a first timestamp indicating the time point when the content of the token or the bridge token is generated, and may record a second timestamp indicating the time point when the bridge token is scanned. If the time difference between the first timestamp and the second timestamp exceeds the predetermined period, the transaction is deemed invalid. In another embodiment, the content of the token or the bridge token may include the first timestamp and the period during which the content of the token or the bridge token remains valid.

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

[0019] In one embodiment, the bridging system of the bridging service provider may generate a bridging transaction identification code for the transaction, and then connect related transaction information through the bridging transaction identification code. In order to enhance privacy protection, the bridging system of the bridging service provider may generate a job identification code (job ID) for each bridging transaction identification code to record the transaction, and the job identification code may be stored in a distributed ledger, such as a blockchain.

[0020] In one embodiment, the bridging system of the bridging service provider can record each transaction with a work identification code, a payer virtual wallet, a receiver virtual wallet, an amount, and a currency type. In another embodiment, the bridging system of the bridging service provider can generate multiple work identification codes for a single bridge transaction identification code, in which case multiple parts of the transaction can be recorded with different work identification codes that all correspond to the same bridge transaction identification code. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 A block diagram of an embodiment of a system for subject bridging between a payer of a first service provider and a receiver of a second service provider is illustrated.

[0022] Figure 2 An embodiment of the present invention is shown to perform consumer presented mode (CPM) target bridging. st SP and 2 nd SP stands for the first service provider and the second service provider respectively.

[0023] Figure 3 The present invention is a flowchart illustrating the steps of requesting a bridge target from a payer in the system.

[0024] Figure 4 A flow chart illustrating the steps of providing content or bridge tags from a tag generator in a system.

[0025] Figure 5 A flow chart illustrating the steps of scanning a bridge object and processing a transaction between a payer of a first service provider and a receiver of a second service provider.

[0026] Figure 6 A flowchart of steps illustrating an alternative embodiment of providing subject matter or bridging subject matter without prior request. DETAILED DESCRIPTION

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

[0028] In this specification and claims, the term "service provider" refers to a party that provides services for transferring digital assets by sending and / or receiving subject information or subject matter. In one embodiment of this document, the service provider is a provider of an electronic payment or transfer system that uses subject matter to exchange information (such as payer identification code, recipient identification code, timestamp, and transaction request) to enable electronic payment or transfer of digital assets between its payer and recipient. The service provider typically includes a management system to perform its functions related to digital asset transactions.

[0029] The term "payer" as used herein refers to a party, a person or an entity that authorizes a transaction to transfer its digital assets to another person. 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 the digital assets stored in the account to others, or receive digital assets from others. In one embodiment, the account is implemented as a virtual wallet. The payer can present the subject to the recipient through its mobile device.

[0030] The term "recipient" refers to a party, a person, or an entity that receives a digital asset transferred by another person. A recipient of a service provider may be a user or a merchant of the service provider. A merchant of a service provider is able to identify the subject matter of the service provider. However, a merchant of a service provider may not hold an account with the service provider and therefore may not be a user of the service provider. In other words, the merchant of the service provider may perform the functions of a merchant through a merchant acquirer without being directly associated with the service provider.

[0031] The term "digital asset" as used herein refers to anything that exists in digital form and has economic value, including but not limited to digital assets, claims and liabilities such as digital currency, digital securities, digital bonds, digital futures, digital precious metals, non-fungible tokens (NFTs), digital coupons and digital fee tokens. Digital currency may include but is not limited to digital dollars, digital yen and digital euros. 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 of coffee beans, soybeans and corn. NFTs can be electronic records owned / controlled by one party and in which the party has rights or interests, including but not limited to photography, logos, illustrations, animations, audio-visual media, speeches, spreadsheets, digital paintings, text archives, emails, websites, and many other digital formats and their respective metadata.

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

[0033] The term "target content" as used herein refers to the information contained in the indicator, including but not limited to the positioning code, identification code and tracking code. The target content can be in the format of a string. In one embodiment of the present invention, the target content includes a payer identification code, a recipient identification code and / or a transaction request, which provides information of the payer and / or the recipient. The target can be generated based on the target content.

[0034] As used herein, the term "portable device" refers to a device that has basic computing resources (in the form of a processor, memory, and storage) and wireless communication equipment (e.g., telecommunication network, WiFi, Bluetooth, satellite, radio, microwave, infrared, etc.). Examples include, but are not limited to, laptops, tablets, and smartphones.

[0035] The term "bridging" as used herein refers to a system or method that enables a payer of a first service provider to present a subject of a second service provider to a receiver of the second service provider (who cannot recognize the subject of the first service provider) in order to complete a transaction between the payer and the receiver. Because the first service provider and the second service provider use different target formats or rules, the receiver of the second service provider cannot recognize the subject of the first service provider. In some embodiments, in a consumer presentation mode (CPM), a bridging service enables a consumer's mobile device to present a QR code recognizable by a merchant device (e.g., POS) to the merchant who cannot recognize the consumer's service provider QR code.

[0036] The term "bridge service provider" refers to a service provider that provides bridge technology to other service providers. The bridge service provider can be a first service provider, a second service provider, or a separate bridge service provider that is neither a first service provider nor a second service provider. In addition, the term "bridge system" refers to a system used by a bridge service provider to perform bridge service functions.

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

[0038] The present invention relates to providing a target bridging service between a first service provider and a second service provider, so that a payer belonging to the first service provider and a receiver belonging to the second service provider can conduct transactions by scanning or sensing a target. The target, such as a QR code, plays a role in the mobile payment industry similar to a credit card number in the traditional payment industry. A credit card holder can only use the card to pay at a merchant that can recognize the credit card number. Similarly, a payer of a first mobile payment company (first service provider) can only use the target (such as a QR code) at a receiver that can recognize the target of the first mobile payment company (usually a merchant belonging to the first service provider). The receiver belonging to the first service provider cannot recognize the target of the second service provider through its device (such as a POS). Similarly, the receiver belonging to the second service provider cannot use its device to recognize the target of the first service provider. In one embodiment, the bridging service provider can provide the payer of the first service provider with bridging targets or target contents of multiple other service providers around the world (such as the second service provider and many other similar service providers) so that the payer of the first service provider can complete the transaction in all stores that can identify the targets of any of these multiple service providers. 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 complicated to make each of the 10 service providers in the first country reach an agreement with each of the 5 service providers in the second country. In this case, the bridging service provider can provide such a target bridging service to connect all 15 service providers in the two countries so that the payer of any service provider can complete the transaction at the receiver (such as a merchant's store) of any other service provider.

[0039] like Figure 1As shown, the target bridging service system 100 includes a portable device 115 of a payer 110, a first management system 125 of a first service provider 120, a scanning system 155 of a receiver 150, a second management system 145 of a second service provider 140, a bridging system 135 of a bridging service provider 130, and a target generator 160. The payer 110 is a user of the first service provider 120, and has a portable device 115 (such as a smart phone) that is wirelessly connected to the first management system 125 of the first service provider 120. The receiver 150 is a merchant or user of the second service provider 140, and has a scanning system 155 that is wirelessly or wiredly connected to the second management system 145 of the second service provider 140. Figure 1 In the example shown, the payer 110 transfers the digital asset to the receiver 150. The bridging service provider 130 has a bridging system 135, which is communicatively connected to the first management system 125 and the second management system 145 and acts as a "bridge" between two different service providers. The target generator 160 is connected to the bridging 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 can generate target content or bridge 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 can be a system embedded or connected to the bridging system 135, and can generate target content or bridge targets for multiple service providers.

[0040] Each of the first service provider 120 and the second service provider 140 operates a transaction network between its users and merchants, and has its own target standards, formats and / or rules. In this way, the payer and the recipient of the first service provider 120, such as the user (payer) and the merchant (recipient), can complete transactions (such as payment or transfer) within the network of the first service provider by scanning the target. The same situation also applies to the payer and the recipient of the second service provider 140. However, in order to complete the transaction and / or other communication between the payer of the first service provider 120 and the recipient of the second service provider 140, the two service providers are configured to communicate and connect to the bridge service provider 130.

[0041] Among other functions of the service provider, the first management system 125 of the first service provider 120 is configured to implement additional functions associated with bridging transactions. These functions may include (1) selecting an acquirer (i.e., a second service provider) for the transaction, (2) requesting the subject matter or bridging subject matter of the second service provider 140 through the bridging system 135, (3) receiving the subject matter or bridging subject matter and providing it to the payee 110, (4) receiving the transaction request from the bridging system 135, (5) transmitting transaction approval back to the bridging system 135, and (6) processing notifications from the bridging system 135. The bridging system 135 may provide the subject matter or bridging subject matter of each of a plurality of service providers around the world, wherein these plurality of service providers form a bridging network. The payee 110 or the first management system may select a second service provider from the bridging network. Alternatively, based on the location of the payee's portable device, the portable device may display all available service providers in the region / country for the payee 110 to select for the transaction. The location may be determined by the GPS system of the payee's portable device.

[0042] In order to identify the payee requesting the bridge target, the first management system 125 of the first service provider 120 may assign a bridge payee identification code to the payee 110 and associate the bridge payee identification code with the target request. The target request may then be forwarded to the bridge system 135 of the bridge service provider 130 together with the bridge payee identification code. The bridge payee identification code assigned by the first management system 125 may be the original user identification code used by the payee 110 in the network of the first service provider 120, such as the payee's account number or virtual wallet ID. Alternatively, in order to enhance security, the first management system 125 of the first service provider 120 may specifically create a bridge payee identification code that is different from the original user identification code of the payee 110. In addition, the payee of the service provider (e.g., the user of the first service provider) may be assigned a virtual wallet with a bridge wallet identification code by the bridge system 135. Therefore, the first service provider 120 may also use the bridge wallet identification code assigned by the bridge system 135 as the bridge payer identification code of the target request, instead of using the bridge payer identification code created by the first management system 125 of the first service provider 120. In order to return the bridge target to the payer 110 who made the request, the first management system 125 of the first service provider 120 is configured to receive a return target content or bridge target with a previously provided bridge payer identification code, and then provide the target content or bridge target to the payer 110 based on the bridge payer identification code mapped to the payer 110.

[0043] In order 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 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 forward the transaction request to the payer 110 based on the bridge payer identification code provided by the bridge system 135. After the payer 110 approves the transaction and returns the transaction approval, the first management system 125 of the first service provider 120 may return the transaction approval to the bridge system 135 to process the transaction. Alternatively, based on its settings or agreements, the first service provider 120 may also be authorized to approve the transaction without further confirmation from the payer 110. For example, the payment amount is within a predetermined amount. In this case, the first management system 125 of the first service provider 120 may return the transaction approval to the bridge system 135 on its own.

[0044] The bridging system 135 of the bridging service provider 130 can be configured to perform three functions: third-party subject content / bridging subject provider, third-party authorization agent, and third-party clearing house. First, the bridging system 135 of the bridging service provider 130 can provide subject content or bridging subject (for example, in one embodiment, subject content or bridging subject of the second service provider 140) to the first management system 125. Second, the bridging system 135 of the bridging service provider 130 can act as a third-party authorization agent to forward transaction requests and permissions between the first management system 125 and the second management system 145. Third, the bridging system 135 of the bridging service provider 130 can act as a third-party clearing house to bridge and settle transactions between different service providers using a bridging mechanism, such as settling multiple transactions between the first service provider and the second service provider based on the recorded relevant transaction information.

[0045] In order to provide a bridging target, the bridging system 135 of the bridging service provider 130 is configured to receive a request for a bridging target from the first management system 125, forward the request to the target generator 160, and return the target content or the bridging target to the first management system 125. The bridging system 135 of the bridging service provider 130 can first identify the location of the payee's portable device 115, and then determine a list of available service providers in that location (such as an overseas region / country) in the bridging network. The list of available service providers is provided to the portable device 115 for the payee 110 to select. In this embodiment, after the payee 110 selects the second service provider 140 to obtain its bridging target, the bridging system 135 will receive a request for the bridging target of the second service provider. Then, the bridging system 135 may assign a bridging transaction identifier to the request, and forward the request together with the bridging transaction identifier and / or the bridging wallet / payer identifier to the target generator 160 to generate the target content or bridging target of the second service provider 140. As mentioned above, the bridging wallet identifier is a payer identifier from the perspective of the bridging service provider 130, and can be used to identify the payer 110 who initiated the bridging target request. After receiving the target content or bridging target by the target generator 160, the bridging system 135 of the bridging service provider 130 may map the bridging transaction identifier to the bridging payer identifier, and return the target content or bridging target to the first management system 125. Alternatively, the mapping relationship between the bridging transaction identifier and the bridging payer identifier may also be generated before the bridging system 135 receives the target content or bridging target.

[0046] In another embodiment, without any action from the payee, the first management system 125 of the first service provider can request the subject matter or bridge subject matter of the second service provider from the bridge system 135 of the bridge service provider. In another embodiment, without any action from the first management system 125, the bridge service provider 135 actively provides the subject matter or bridge subject matter of the second service provider to the first management system 125.

[0047] In order to act as a third-party authorization agent for forwarding transaction requests and approvals, the bridge system 135 of the bridge service provider 130 may be configured to forward transaction requests (e.g., payment requests) from the second management system 145 to the first management system 125, and to forward 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 recipient 150 along with the transaction request. Upon receiving the transaction request (which may be accompanied by a bridge transaction identifier and a recipient / merchant identifier provided by the second management system 145), the bridge system 135 of the bridge service provider 130 may use the bridge transaction identifier to find the bridge payee identifier representing the payee 110 of the first service provider 120. The bridge system 135 of the bridge service provider 130 may then send a confirmation back to the second management system 145, and forward the transaction request together with the bridge payee identifier and the recipient / merchant identifier to the first management system 125. After the first management system 125 approves the transaction request, the bridge system 135 may record the transaction and push information indicating that the transaction is confirmed (eg, successful payment, which may include some transaction details) to the first management system 125 and the second management system 145 .

[0048] In order to act as a third-party clearing house, the bridging system 135 of the bridging service provider 130 is configured to settle transactions between different service providers through a transaction bridging mechanism, such as settling multiple transactions between a first service provider and a second service provider. In one embodiment, each of the first service provider and the second service provider establishes an internal transaction identifier corresponding to such cross-service provider transactions. For example, the first service provider 120 generates an X transaction identifier associated with the payer, and the second service provider generates a Y transaction identifier associated with the recipient. The X transaction identifier can be a previously generated bridge payer identifier, or a different identifier generated separately by the first management system 125. Similarly, the Y transaction identifier can be a previously generated recipient / merchant identifier, or a different identifier generated separately by the second management system 145. In order to bridge such transactions between different service providers, the bridging system 135 can use the bridge transaction identifier to map to the internal transaction identifiers of different service providers, such as the X transaction identifier and the Y transaction identifier, and connect the relevant transaction information. The bridging system 135 of the bridging service provider 130 may store and preserve (1) a mapping relationship between a bridging transaction identification code and an internal transaction identification code of a first service provider, and (2) a mapping relationship between a bridging transaction identification code and an internal transaction identification code of a second service provider.

[0049] In one embodiment, to enhance privacy protection, the bridging system 135 of the bridging service provider 130 may generate a work identification code for each bridging transaction identification code. In one embodiment, to enhance privacy protection, the work identification code may be a serial number, or a randomly generated number that does not include information related to the payer 110, the first service provider 120, the receiver 150, and the second service provider 140. The bridging system 135 in this embodiment stores and saves the mapping between the bridging transaction identification code and the work identification code. The bridging transaction identification code and / or the work identification code may be recorded in a database, including but not limited to a distributed ledger, such as a blockchain. Therefore, in one embodiment, the bridging system 135 may record each transaction using the work identification code, the payer virtual wallet, the receiver virtual wallet, the amount, and the currency.

[0050] In another embodiment, the bridging system 135 of the bridging service provider 130 can generate multiple working identification codes for a single bridging transaction identification code. Each working identification code can correspond to one of the payment, refund, and cancellation of a single bridging transaction identification code, and be recorded in a database, including but not limited to a distributed ledger, such as a blockchain. Therefore, the bridging system 135 of the bridging service provider 130 can provide settlement services 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 on transaction records and settlements, the international patent application PCT / US17 / 12635, entitled "DIGITAL PROPERTY MANAGEMENT ON A DISTRIBUTED TRANSACTION CONSENSUS NETWORK" filed on January 6, 2017, is incorporated herein by reference in its entirety.

[0051] Among other functions of the service provider, the second management system 145 of the second service provider 140 is configured to identify a bridged token scanned by the scanning system 155 of the recipient 150. Since the bridged token is generated based on the token format and rules of the second service provider, the scanning system 155 can recognize the bridged token as a token of another payer from the second service provider and generate scan information. The second management system 145 can parse the scanned information to identify the bridge service provider 130, the token generator 160, the bridged transaction identification code and / or the recipient / merchant identification code of the recipient 150. In one embodiment, the second management system 145 can request the token generator 160 to provide a bridged transaction identification code associated with the bridged token scanned by the recipient 150. In addition, the second management system 145 can receive relevant transaction information, such as a description of the product or service sold by the recipient 150, its amount and currency. In one embodiment, the second management system 145 can also resolve the identity of the payer through the bridged transaction identification code and its related mapping relationship. The second management system 145 may also generate an internal transaction identification code, such as a Y transaction identification code, and map it with the bridge transaction identification code and the recipient / merchant identification code, and save such a mapping relationship. Next, the second management system 145 of the second service provider 140 may provide a transaction request, such as a payment request, to the bridge system 135. The transaction request may include the bridge transaction identification code, the recipient / merchant identification code, and related transaction information. Finally, upon receiving the information confirming the bridge transaction, the second management system 145 may push information to notify the recipient 150 of the result, such as a successful payment.

[0052] The target generator 160 is configured to receive a target request and generate a bridge target or target content of the second service provider. The bridge target can be identified by the scanning system 155 of the recipient 150 and the second management system 145 of the second service provider 140. The target request can include a bridge transaction identification code and / or a bridge wallet identification code that can be connected to the first service provider 120 and / or the payer 110. In addition, the target generator 160 can map the generated target content or bridge target to the bridge transaction identification code and / or the bridge wallet identification code, and save such mapping. Next, the target generator 160 provides the target content or bridge target to the bridge system 135. After the scanning system 155 of the recipient 150 scans the bridge target, the target generator 160 can provide the bridge transaction identification code mapped to the scanned bridge target to the second management system 145 according to the request. As mentioned above, the target generator 160 can be a module embedded in or connected to the second management system 145. Therefore, each service provider in the bridge network has its own target generator to generate corresponding bridge targets. Alternatively, the target generator 160 can be a module embedded in or connected to the bridge system 135 (which is not a service provider) to generate target content or bridge targets corresponding to multiple service providers.

[0053] In summary, the bridge service provider 130, such as HIVEX of TBCASoft, Inc. TM , which provides the subject content or bridge subject of the second service provider 140 to the payer 110 of the first service provider 120, so that the payer 110 can present the bridge subject of the second service provider 140 to the receiver 150 of the second service provider 140, such as a merchant. The scanning system 155 of the receiver 150 (e.g., a merchant) scans the bridge subject of the second service provider 140 and identifies it. After scanning, the transaction request generated by the receiver 150 is forwarded to the first service provider 120 through the bridge service provider 130. The first service provider 120 can request the payer 110 to approve the transaction. After receiving the transaction approval from the first management system 125 of the first service provider 120, the bridge system 135 of the bridge service provider 130 will then record the transaction in a database or distributed ledger (e.g., blockchain), and then the transaction will be considered completed. The relevant transaction records will then be distributed to the first management system 125 and the second management system 145. The permission and related transaction records may be further distributed to a recipient 150 (eg, the merchant).

[0054] In an alternative embodiment, the bridge service provider 130 may be the first service provider 120 or the second service provider 140 at the same time. For example, when the bridge service provider is the second service provider, the second service provider also performs the functions of the bridge service provider in addition to its functions as the second service provider. In one embodiment, the second management system also performs the functions of the bridge system. Therefore, data transmission between the bridge system 135 and the first management system 125 or the second management system 145 may be omitted, although the system structure is substantially the same as the case where the bridge service provider 130 is neither the first service provider 120 nor the second service provider 140 (as described above).

[0055] Figure 2 The embodiment of the present invention performing target bridging in the consumer presentment mode (CPM) is shown. In this case, the payee 110 of the first service provider (Mobile Payment A) travels from Country A to Country B and wants to pay at a merchant store in Country B via mobile payment. Here, the merchant store is the receiver 150. Figure 2As shown, the store accepts mobile payment from B, mobile payment from C, and mobile payment from D, all of which are different from the mobile payment services used by the payer. Therefore, the target bridging service of the present invention must be used to complete transactions between two mobile payment service providers. In this example, mobile payment A (i.e., the first service provider 120) is used to make payments for payer 110, and mobile payment B (i.e., the second service provider 140) is selected to accept payments for recipient 150. After payer 110 selects mobile payment B as the second service provider 140, the application on its mobile phone (i.e., portable device 115) can further instruct payer 110 to select a payment mode, i.e., consumer present mode (CPM) or merchant present mode (MPM). The international patent application PCT / US21 / 27370, filed on April 14, 2021, entitled “METHOD AND SYSTEM FOR RESOLVING ATARGET”, describes some embodiments of cross-service provider transactions in merchant present mode, the entire contents of which are incorporated herein. In consumer presentation mode, the payee 110 selects "Show QR code", and the application then receives a bridging QR code, which can be displayed on the payee's 110 portable device 115. The merchant's scanning system 155 (the merchant as the receiver 150) then scans the QR code displayed on the payee's 110 portable device 115. After receiving the scanned information from the merchant, Mobile Payment B (the second service provider 140) can provide a transaction request to HIVEX, a bridging service provider. Next, HIVEX records the bridging transaction after receiving the transaction approval from Mobile Payment A (the first service provider 120). HIVEX then provides transaction confirmation to Mobile Payment A (the first service provider 120) and Mobile Payment B (the second service provider 140).

[0056] Figure 3-6 A sequence diagram showing the bridge connection in one embodiment of the present invention. Figure 3As shown, the payer 110 may request a bridge target. In step S111, the payer 110 may send a request for a selection list of the area where the portable device 115 of the payer 110 is located to the first service provider 120, wherein the selection list is a list of second service providers available in the area. In one embodiment, the first management system 125 of the first service provider 120 may also authenticate the payer 110 and its portable 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 the portable device 115 of the payer 110. The portable device 115 of the payer 110 may then send back information to verify its identity, 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 forward the request to the bridging system 135 of the bridging service provider 130 .

[0057] In step S114, after receiving the request, the bridge system 135 can search for information of service providers in the bridge network according to the location of the portable device 115, and then return a selection list of available second service providers to the first management system 125. In step S115, after receiving the selection list from the bridge system 135, the first management system further forwards the selection list to the payee 110. As described above, the payee 110 can receive the selection list from the first management system 125 of the first service provider 120. Alternatively, if the portable device 115 has updated the information of the service providers in the bridge network, it can generate a selection list locally by selecting service providers available in the area and the bridge network. In step S116, based on the selection list received from the first service provider 120 or generated locally, the payee 110 can select a second service provider 140 from the selection list displayed on the portable device 115, and send a target request to the first management system 125 to request the bridge target of the selected second service provider 140.

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

[0059] Figure 4 1 is a timing diagram showing an example of generating a bridging target or target content and providing it to a payer 110 of a first service provider. After receiving a target request, the target generator 160 can generate a bridging target or target content and provide it to the portable device 115 of the payer 110. In step S121, the target generator 160 can generate a bridging target or target content and map it to a bridging transaction identification code. In one embodiment, the target generator 160 can also generate a first timestamp representing the first time point at which the bridging target or target content is generated. The first timestamp can be stored separately or can be stored as part of the bridging target or target content. In step S123, the target generator 160 then provides the bridging target or target content, and the first timestamp (if available), to the bridging system 135 of the bridging service provider 130. In addition to the first timestamp, the target generator 160 can also provide a valid period representing the time period during which the target content or bridging target remains valid. Alternatively, the token generator 160 may directly provide an expiration time to indicate the time point at which the content of the token or the bridge token expires.

[0060] In step S125, after receiving the bridge target or target content, the bridge system 135 may map the bridge transaction identification code to the bridge payee identification code, and transmit the bridge target or target content back 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 target, and provide the bridge target to the portable device 115 of the payee 110. In practice, the target content may be converted into a bridge target by the bridge target generator 160, the bridge system 135 of the bridge service provider 130, or the portable device 115 of the payee 110.

[0061] like Figure 5 As shown, the bridge token may be presented to the recipient 150 for a transaction. In step S131, the scanning system 155 of the recipient 150 may scan the bridge token presented by the payer 110 on the portable device 115. In step S132, after scanning the bridge token, the scanning system 155 may transmit the scanned information to the second management system 145 of the second service provider 140 to initiate a transaction request. The scanning system 155 may also send a second timestamp indicating a second time point at which the bridge token is scanned. The second timestamp may also be generated by the second management system 145 after it receives the scan information from the scanning system 155. In order 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. After receiving the scanned information, the second management system 145 of the second service provider 140 can request the target generator 160 to return the bridging transaction identification code mapped to the scanned bridging target, as shown in step S1331. Then, the target generator 160 can return the bridging transaction identification code according to the relevant mapping previously generated in step S121, as shown in step S1332.

[0062] In step S134, the second management system 145 may send a transaction request to the payer 110 through the bridge system 135 and the bridge transaction identification code. In step S135, after receiving the transaction request, the bridge system 135 of the bridge service provider 130 may resolve the scanned bridge transaction identification code of the bridge target into the bridge payer identification code representing the payer 110 of the first service provider 120. If the resolution is successful, the bridge system 135 of the bridge service provider 130 may return a confirmation to the second management system 145, as shown in step S1351. The bridge system 135 may then forward the transaction request with the bridge payer identification code to the first management system 125 of the first service provider 120, as shown in step S1352.

[0063] In step S136, after authorization, the first management system 125 of the first service provider 120 may approve the transaction. The first management system 125 may be authorized to automatically approve the transaction without further authorization from the payer 110. Alternatively, the transaction permission of the payer is required to improve the security of the transaction. In this case, the first management system 125 may identify the payer 110 through the bridge payer identification code, and request the payer 110 to approve the transaction through the portable device 115, and then the portable device 115 may provide the transaction permission to the first management system 125, as shown in steps S1361 and S1362. The first management system 125 may also transmit the transaction permission to the bridging system 135, as shown in step S137.

[0064] In step S138, after receiving the transaction approval, the bridging system 135 may process the transaction according to the bridging payer identification code mapped to the payer account. The relevant transaction information may be connected through the bridging transaction identification code. For each bridging transaction identification code, the first service provider 120 may have a corresponding X transaction identification code, and the second service provider 140 may have a corresponding Y transaction identification code. As described above, the X transaction identification code may be a bridging payer identification code, or a separately generated identification code. Similarly, the Y transaction identification code may be a recipient / merchant identification code, or a separately generated identification code. The mapping between the bridging transaction identification code and the X transaction identification code may be stored and saved by the bridging system 135 and / or the first management system 125. The mapping between the bridging transaction identification code and the Y transaction identification code may be stored and saved by the bridging system 135 and / or the second management system 145. In one embodiment, in order to enhance privacy protection, the bridging system 135 of the bridging service provider 130 may generate a work identification code for each bridging transaction identification code as a record of the transaction, which may be stored in a distributed ledger, such as a blockchain. Therefore, the bridging system 135 may record each transaction with a work identification code, a payer virtual wallet, a receiver virtual wallet, an amount, and a currency. In another embodiment, the bridging system 135 of the bridging service provider 130 may generate multiple work identification codes for a single bridging transaction identification code, wherein the transaction corresponds to multiple parts of payment, refund, and cancellation, which may be recorded using different work identification codes corresponding to one bridging transaction identification code. The bridging system 135 may then push a notification of successful payment to the first management system 125 (step S1381), and receive a confirmation from the first management system 125 (step S1382). After receiving the confirmation, the bridging system 135 may push a notification of successful payment to the second management system 145, as shown in step S1383. Finally, the notification of successful payment can be pushed by the first management system 125 of the first service provider 120 to the portable device 115 of the payer 110 (step S1391), and by the second management system 145 of the second service provider 140 to the scanning system 155 of the recipient 150 (step S1392).

[0065] In another embodiment, the bridge system 135 does not send a request for a tag, and the tag generator 160 can automatically provide a bridge tag or tag content based on some predetermined criteria, such as historical data of the use of the bridge tag, such as Figure 6As shown. In step S141, the target generator 160 can generate a bridging target or target content, and then map it to a bridging transaction identification code. In step S142, the target generator 160 can automatically send the bridging target or target content mapped with the bridging transaction identification code to the bridging system 135 when certain conditions are met. For example, the target generator 160 can monitor the use of previously sent bridging targets or target content, and provide a newly generated bridging target or target content when the number of unused targets is lower than a predetermined value. In this case, the bridging system 135 of the bridging service provider 130 may be able to recognize the bridging transaction identification code generated by the target generator 160 and map the bridging transaction identification code to the bridging payer identification code of the payer 110. In step S143, the payer 110 can request a bridging target, and its detailed process is similar to that described in steps S111-S117.

[0066] In step S145, after receiving the bridge target or target content from the target generator 160 and the target request from the first management system 125, the bridge system 135 of the bridge service provider 130 may map the bridge transaction identification code (provided by the target generator 160) to the bridge payee identification code (provided by the first management system 125), and provide the bridge target or target content to the first management system 125. In another embodiment, the target generator 160 may also automatically provide the bridge target or target content to the payee 110 through the first management system 125 without a request. One example is that when the first management system 125 detects that the payee 110 of its transaction network uses a bridge target, the first management system 125 may notify the bridge system 135, and the bridge system 135 may map the bridge transaction identification code to the bridge payee identification code provided by the first management system 125, and then provide the bridge target or target content. The bridging system 135 may provide the bridging target or target content to the payer 110 even without a request from the first management system 125. In this case, when a bridging transaction is requested, the bridging system 135 may detect the event and supplement a bridging target or target content based on the bridging payer identification code provided by the first management system 125. The target content or bridging target may then be provided by the first management system 125 to the payer 110 without first requesting one. In step S147, the first management system 125 of the first service provider 120 may convert the received target content into a bridging target and provide the bridging target to the portable device 115 of the payer 110. Alternatively, the target content may be converted into a bridging target by the target generator 160, the bridging system 135, or the portable device 115.

[0067] In another embodiment, the target generator 160 may generate a bridging target or target content for a digital coupon, which can be used by the payer 110 to redeem a free gift from the receiver 150, which is a merchant. In this embodiment, the target generator 160 may not need to provide a bridging transaction identification code for the bridging target or the generated target content. In this case, the bridging service provider 130 may be allowed to freely issue bridging targets to promote the receiver 150, such as the merchant's store. At the time of target identification, the second management system 145 of the second service provider 140 may only record which target was used, and the gift may be directly provided to the payer 110 without recording the transaction.

[0068] The embodiments provided above are intended to enable any person skilled in the art to make and use the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the novel principles disclosed herein and the present invention may be applied to other embodiments without the use of innovative capabilities. The invention claimed in the claims is not intended to be limited to the embodiments shown herein, but to the widest scope consistent with the principles and novel features disclosed herein. Additional embodiments are expected to fall within the spirit and scope of the invention disclosed in this case. Therefore, the present invention is intended to cover modifications and variations that fall within the scope of the appended claims and their equivalents.

Claims

1. A method for bridging a target between a portable device of a payer of a first service provider and a scanning system of a receiver of a second service provider different from the first service provider, comprising: The first management system of the first service provider receives, for the payer, a subject content belonging to the second service provider or a bridge subject generated based on the subject content from a bridge system of the bridge service provider; as well as The first management system of the first service provider wirelessly provides the target content or the bridge target of the second service provider to the portable device of the payer, so as to present the bridge target generated based on the target content to the scanning system of the receiver to which the second service provider belongs, so that the scanning system can recognize the bridge target; The scanning system of the receiver is unable to identify the target of the first service provider. 2 . The method of claim 1 , wherein the target and the bridge target are both QR codes.

3. The method of claim 1, wherein 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. The method of claim 1, before receiving the target content or the bridge target from the second service provider, further comprising: wirelessly receiving, by the first management system, a request for the subject content of the subject content of the second service provider from the portable device of the payer; as well as The first management system provides a request for the subject content to the bridge system.

5. The method of claim 1, after wirelessly providing the content of the token or the bridge token of the second service provider to the portable device of the payee to present the bridge token to the scanning system of the payee, further comprising: The first management system receives a transaction request from the bridge system after the scanning system of the receiver scans the bridge target; The first management system provides transaction permission to the bridge system; as well as The first management system receives the transaction notification associated with the transaction from the bridge system after the bridge system records the transaction notification.

6. The method of claim 5, before providing the transaction approval to the bridge system, further comprising: The first management system wirelessly provides the transaction request to the portable device of the payer; as well as The first management system wirelessly receives the transaction permission from the portable device of the payer.

7. The method of claim 4, further comprising: The first management system authenticates the payer and the portable device of the payer. 8 . The method of claim 7 , wherein the first management system authenticates the payee and the portable device of the payee before providing the target content request to the bridge system.

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

10. The method of claim 1, wherein the target content includes a first time stamp indicating a first time point when the target content was generated.

11. The method of claim 5, wherein: The subject content includes a first time stamp indicating a first time point at which the subject content was generated; and The transaction request includes a second time stamp indicating a second time point when the scanning system of the recipient scans the bridge token.

12. The method of claim 11, further comprising: It is determined whether a time difference between the first time stamp and the second time stamp exceeds a predetermined period.

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

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

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

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

18. The method of claim 17, after wirelessly providing the content of the token or the bridge token of the second service provider to the portable device of the payer to present the bridge token to the scanning system of the receiver, further comprising: The first management system receives a transaction request from the bridge system after the scanning system of the receiver scans the bridge target; The first management system provides transaction permission to the bridge system; as well as receiving, by the first management system, a transaction notification from the bridging system after the bridging system records the transaction notification associated with the transaction; The bridging system generates at least one work identification code corresponding to the bridging transaction identification code, and records the transaction according to the work identification code.

19. The method of claim 5, wherein the bridge system records the transaction in a distributed ledger.

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

21. A method for bridging a target between a portable device of a payer of a first service provider and a scanning system of a receiver of a second service provider different from the first service provider, comprising: The bridging system of the bridging service provider receives, from a target generator, target content of a second service provider or a bridging target generated based on the target content; as well as The bridging system of the bridging service provider provides the target content or the bridging target to the first management system of the first service provider, so that the portable device of the payee presents the bridging target generated based on the target content to the scanning system of the receiver that can identify the bridging target; The scanning system of the receiver is unable to identify the target of the first service provider.

22. The method of claim 21, wherein the target and the bridge target are both QR codes.

23. The method of claim 21, wherein 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 of claim 21, wherein the target generator is a system of the second service provider.

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

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

27. The method of claim 21, after providing the content of the subject or the bridge subject to the first management system, further comprising: The bridging system receives a transaction request from a second management system of the second service provider after the scanning system scans the bridging target; The bridge system provides the transaction request to the first management system; receiving, by the bridge system, a transaction approval from the first management system after the transaction associated with the transaction request is approved; as well as The transaction is recorded by the bridge system.

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

29. The method of claim 27, wherein: The bridging system receives, in addition to the content of the subject or the bridge subject, a first time stamp from the generator of the subject, the first time stamp indicating a first time point when the content of the subject or the bridge subject is provided; as well as In addition to the transaction request, the bridge system also receives a second time stamp from the second management system, where the second time stamp indicates a second time point when the scanning system scans the target.

30. The method of claim 29, further comprising: It is determined whether a time difference between the first time stamp and the second time stamp exceeds a predetermined period.

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

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

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

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

35. The method of claim 34, after providing the content of the subject or the bridge subject to the first management system, further comprises: The bridging system receives a transaction request from a second management system of the second service provider after the scanning system scans the bridging target; The bridge system provides the transaction request to the first management system; receiving, by the bridge system, a transaction approval from the first management system after the transaction associated with the transaction request is approved; as well as recording the transaction by the bridge system; The bridging system generates at least one work identification code corresponding to the bridging transaction identification code, and records the transaction according to the work identification code.

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

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