Methods and network system for offline bridging transaction

Abstract

A network system and methods for implementing offline bridging transactions are provided. The network system includes: a first management system of a first service provider, a second management system of a second service provider and a bridging system of a bridging service provider. The methods includes: presenting a preliminarily obtained offline payment target on a portable device of a payer; routing a transaction request including a parsed target content of the offline payment target to the first management system through the second management system and the bridging system, to request an offline payment; and as the transaction request is authorized, executing the offline payment by one of the first management system, the second management system and the bridging system. The routing of the offline payment target is navigated based on identities of the first and second service providers associated with the offline payment target and pre-stored in the network system.

Description

48222.0046US first draft20250417METHODS AND NETWORK SYSTEM FOR OFFLINE BRIDGING TRANSACTIONCROSS-REFERENCE TO RELATED APPLICATION5 This application claims the priority benefit of U.S. provisional application serial no. 63 / 635,606, filed on April 17, 2024. The entirety of the above-mentioned patent applications is hereby incorporated by reference herein and made a part of this specification.10BACKGROUNDField of the Invention

[0001] The present disclosure relates to methods and a network system for bridging different payment service providers to execute cross-provider transactions. In particular, some15 embodiments of the present disclosure relate to methods and a network system for bridging different service providers to execute offline cross-provider transactions.Description of Related Art

[0002] In recent years, mobile payment has become a popular payment method because of20 improved convenience, efficiency and security over traditional payment methods by using cash or credit cards, as well as prevention of physical contact for in-store transactions. Particularly, target scanning is frequently used for mobile payment. As an example, the target can be (but not limited to) a barcode, a quick response (QR) code or the like.

[0003] However, using target scanning for mobile payment is limited to closed-loop mobile25 payment application. Specifically, mobile payment service providers (MPSPs) with their own customers may use different code formats, resulting that a payer of a first MPSP and a receiver of a second MPSP may not complete transactions via code scanning. Undoubtedly, payers (e.g., customers) and receivers (e.g., merchants) would be both benefited if such barrier could be overcome.30SUMMARY

[0004] In an aspect of the present disclosure, a method for performing an offline bridging transaction through a bridging system of a bridging service provider is provided. The method 148222.0046US first draft 20250417 comprises: receiving a transaction request by the bridging system, wherein the transaction request includes a parsed target content obtained by reading an offline payment target presented on a portable device while the portable device is offline; sending the transaction request to a first management system of a first service provider by the bridging system, based on an identity of the5 first service provider associated with the offline payment target and stored in the bridging system, wherein the first service provider provides payment transfer service for a payer having the portable device, and the transaction request is provided to the first management system to request an offline payment; and upon receiving a transaction approval from the first management system, executing the offline payment and sending a transaction notice to the first management system by the10 bridging system.

[0005] In an aspect of the present disclosure, a bridging system for performing an offline bridging transaction is provided. The bridging system comprises a storage device and a processor configured to execute instructions stored in the storage device for performing the offline bridging transaction. The bridging system is communicatively connected with a first management system15 of a first service provider and a second management system of a second service provider. Performing the offline bridging transaction comprises: receiving a transaction request, wherein the transaction request includes a parsed target content obtained by reading an offline payment target presented on a portable device while the portable device is offline; sending the transaction request to the first management system, based on an identity of the first service provider associated with20 the offline payment target and stored in the bridging system, wherein the first service provider provides payment transfer service for a payer having the portable device, and the transaction request is provided to the first management system to request an offline payment; and upon receiving a transaction approval from the first management system, executing the offline payment and sending a transaction notice to the first management system.25

[0006] In an aspect of the present disclosure, a method for performing an offline bridging transaction through a first management system of a first service provider providing payment transfer service for a payer is provided. The method comprises: receiving a transaction request for an offline payment by the first management system, wherein the transaction request includes a parsed target content obtained by reading an offline payment target presented on a portable device30 while the portable device is offline, and an identity of the payer associated with the offline payment target is stored in the first management system before the offline payment target is presented on the portable device; and after execution of the offline payment and when the portable device is back online, sending a record of the completed offline payment to the portable device by the first management system.248222.0046US first draft 20250417

[0007] In an aspect of the present disclosure, a first management system of a first service provider providing payment transfer service for a payer is provided. The first management system comprises a storage device and a processor configured to execute instructions stored in the storage device for performing an offline bridging transaction, comprising: receiving a transaction request5 for an offline payment, wherein the transaction request includes a parsed target content obtained by reading an offline payment target presented on a portable device while the portable device is offline, and an identity of the payer associated with the offline payment target is stored in the first management system before the offline payment target is presented on the portable device; and after execution of the offline payment and when the portable device is back online, sending a10 record of the completed offline payment to the portable device.

[0008] In an aspect of the present disclosure, a method for performing an offline bridging transaction through a second management system of a second service provider providing payment transfer service for a receiver is provided. The method comprises: providing an offline payment target or its source target content to a portable device of a payer by the second management system;15 upon receiving a transaction request, directing the transaction request to a first management system of a first service provider via the second management system, to request an offline payment, wherein the first service provides payment transfer service for the payer, and the transaction request includes a parsed target content obtained by reading the offline payment target presented on the portable device while the portable device is offline; and upon execution of the offline20 payment, providing a payment confirmation to the receiver.

[0009] In an aspect of the present disclosure, a second management system of a second service provider providing digital property transfer service for a receiver is provided. The second management system comprises a storage device and a processor configured to execute instructions stored in the storage device for performing an offline bridging transaction, comprising: providing25 an offline payment target or its source target content to a portable device of a payer; upon receiving a transaction request, directing the transaction request to a first management system of a first service provider via the second management system, to request an offline payment, wherein the first service provides payment transfer service for the payer, and the transaction request includes a parsed target content obtained by reading the offline payment target presented on the portable30 device while the portable device is offline; and upon execution of the offline payment, providing a payment confirmation to the receiver.BRIEF DESCRIPTION OF THE DRAWINGS348222.0046US first draft 20250417

[0010] FIG. 1 is a block diagram schematically illustrating a network system for offline bridging transactions, according to some embodiments of the present disclosure.

[0011] FIG. 2A is a flow diagram illustrating a request initiation process in an advance request flow (ARF), according to some embodiments of the present disclosure.5

[0012] FIG. 2B is a flow diagram illustrating a target present process in the ARF, according to some embodiments of the present disclosure.

[0013] FIG. 2C is a flow diagram illustrating a transaction history update process in the ARF, according to some embodiments of the present disclosure.

[0014] FIG. 2D is a flow diagram illustrating an exception handling process, according to some10 embodiments of the present disclosure.

[0015] FIG. 3 is a flow diagram illustrating a request initiation process in a modified ARF, according to some embodiments of the present disclosure.

[0016] FIG. 4 A is a flow diagram illustrating a request initiation process in an on-demand flow(ODF), according to some embodiments of the present disclosure.15

[0017] FIG. 4B is a flow diagram illustrating a target present process in the ODF, according to some embodiments of the present disclosure.

[0018] FIG. 5 is a block diagram schematically illustrating a network system for offline bridging transactions, according to extended embodiments of the present disclosure.

[0019] FIG. 6A is a flow diagram illustrating a request initiation process in the ARF, according20 to the extended embodiments of the present disclosure.

[0020] FIG. 6B is a flow diagram illustrating a target present process in the ARF, according to the extended embodiments of the present disclosure.

[0021] FIG. 7 is a flow diagram illustrating a target present process in the ODF, according to the extended embodiments of the present disclosure.25

[0022] FIG. 8 is a flow diagram illustrating a target present process in the ARF, according to the further extended embodiments of the present disclosure.

[0023] FIG. 9 is a flow diagram illustrating a target present process in the ODF, according to the further extended embodiments of the present disclosure.

[0024] FIG. I0A is a block diagram further illustrating a target generator used in the network30 system shown in FIG. 1, according to some embodiments of the present disclosure.448222.0046US first draft 20250417

[0025] FIG. 10B is a block diagram further illustrating a target generator used in the network system shown in FIG. 5, according to some embodiments of the present disclosure.

[0026] FIG. 11 is a block diagram illustrating a network system for performing offline bridging transactions, according to some alternative embodiments of the present disclosure.5548222.0046US first draft20250417DETAILED DESCRIPTION OF EMBODIMENTS

[0027] The terminology used in the description presented below is intended to be interpreted in its broadest reasonable manner, even though it is used in conjunction with a detailed description of certain specific embodiments of the technology. Certain terms may even be emphasized below;5 however, any terminology intended to be interpreted in any restricted manner will be specifically defined as such in this Detailed Description section.

[0028] As used in the specification and claims, the term “service provider” refers to a party providing payment transfer service via sending and / or receiving target information or a target. In one embodiment of this disclosure, a service provider is an electronic payment or transfer system10 provider which enables electronic payments or transfers of digital property between its payers and receivers utilizing a target to exchange information, such as a payer identifier, a receiver identifier, a time stamp and a request for transaction. A service provider usually contains management system(s) to execute its functionalities related to digital property transactions.

[0029] The term “payer” used herein refers to a party, an individual or an entity, who authorizes15 a transaction to transfer his / her digital properties to others. A payer of a service provider is also a user of the service provider who holds an account of the service provider. The user is able to transfer digital properties stored in the account to others and receive digital properties from others. In one embodiment, the account is implemented by a virtual wallet. The payer may present a target via his / her mobile device to a receiver.20

[0030] The term “receiver” refers to a party, an individual or an entity, who receives digital properties transferred from others. A receiver of a service provider may be either a user or a merchant of the service provider. A merchant of a service provider is able to recognize a target of the service provider. However, a merchant of a service provider who may not hold an account of the service provider and, thus may not be a user of the service provider. In other words, the25 merchant of the service provider may cany out the merchant function through a merchant acquirer, and do not have direct relationship with the service provider.

[0031] The term “digital property” used herein refers to anything that exists in digital form and has economic value, including but not limited to multiple types of digital assets, credits, and obligations, such as digital currencies, digital securities, digital bonds, digital futures, digital30 precious metals, non-fungible tokens (NFTs), digital coupons, and digital fee tokens. Digital currencies may include but may not be limited to digital US Dollars, digital Japanese Yens, digital Euros, and digital New Taiwan Dollars. Digital securities may include but may not be limited to digital Apple stocks, digital Google stocks, and digital mutual funds. Digital precious metals may include but not limited to digital gold, digital platinum, and digital silver. Digital futures may648222.0046US first draft 20250417 include but may not be limited to digital futures of coffee beans, soy beans, and coms. An NET may be an electronic record a party owned / controlled in which the party has a right or interest, which includes but may not be limited to photography, logos, illustrations, animations, audiovisual media, presentations, spreadsheets, digital paintings, word documents, electronic mails, websites,5 and a multitude of other digital formats and their respective metadata. The term “target” used herein refers to a medium containing information in a format which can be recognized or sensed by specific devices. Examples include but may not be limited to barcode, QR code, NFC (Nearfield Communication) tag, voice signature, and fingerprint. The target information may be resolved by extracting features embedded in the target, for example, by scanning QR code, sensing10 NFC tag, extracting voice signature from voice, or scanning fingerprint to extract the features and obtain the target information contained therein. In an embodiment of the present invention, the target is a QR code.

[0032] The term “target content” used herein refers to the information contained in the target, which includes but may not be limited to locators, identifiers, and trackers. The target content15 may be in a format of a string. In one embodiment of the present invention, a target content contains a payer identifier, a receiver identifier, and / or a request for transaction, which provides the information of a payer and / or a receiver. A target may be generated based on the target content.

[0033] The term “portable device” used herein refers to a device with basic computing resources (in the form of a processor, memory, and storage) and wireless communication, such as20 telecommunication network, WiFi, Bluetooth, satellite, radio broadcast, microwave, infrared, etc. Examples include but may not be limited to laptops, tablets and smartphones.

[0034] The term “bridge” or “bridging” used herein refer to the system or the method that enables a payer of a first service provider to present a target recognizable for a second service provider to a receiver of the second service provider, who does not recognize a target of the first25 service provider, so that a transaction between the payer and the receiver can be completed. Since the first service provider and the second service provider use different target formats or rules, the receiver of the second service provider does not recognize a target of the first service provider. In some embodiments, in a consumer presented mode (CPM), the bridging service enables a consumer* s mobile device to present a QR code recognizable by the merchant device (e.g. POS)30 which cannot recognize a QR code of the consumer’s service provider.

[0035] The term “bridging service provider” refers to a service provider that provides bridging technology to other service providers. A bridging service provider may be the first service provider, the second service provider, or a separate bridging service provider which is neither the748222.0046US first draft 20250417 first service provider nor the second service provider. And the term “bridging system” refers to the system(s) of the bridging service provider to execute functionalities of bridging service.

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

[0037] The present disclosure provides a solution for realizing mobile transactions through different service providers, especially in a situation that a portable device of a payer is offline.10

[0038] FIG. 1 is a block diagram schematically illustrating a network system 10 for offline bridging transactions, according to some embodiments of the present disclosure.

[0039] The network system 10 for offline bridging transactions comprises a portable device 115 from a payer 110, a first management system 125 of a first service provider 120, a target reading system 155 from a receiver 150, a second management system 145 of a second service provider15 140 and a bridging system 135 of a bridging service provider 130.

[0040] The payer 110 is a user of the first service provider 120. In this way, the first service provider 120 provides payment transfer service for the payer 110, and the portable device 115 of the payer 110 is installed with a payment application of the first service provider 120, and is wirelessly connected to the first management system 125 of the first service provider 120. On the20 other hand, the receiver 150 is a merchant and / or a user of the second service provider 140. That is, the second service provider 140 provides payment transfer service for the receiver 150, and the target reading system 155 of the receiver is connected wirelessly or with wires to the second management system 145 of the second service provider 140. Based on an agreement to link the first and second service providers 120, 140 via the bridging service provider 130, the bridging25 system 135 of the bridging service provider 130 is communicatively connected to both the first management system 125 of the first service provider 120 and the second management system 145 of the second service provider 140. As an example (but not limited to), the portable device 115 from the payer 110 may be a smartphone installed with a payment application of the first service provider 120, while the target reading system 155 from the receiver 150 may be a point-of-sale30 (POS) device, and the management systems 125, 145 as well as the bridging system 135 may be respectively implemented by a server, a computer, a laptop or any suitable device with data processing and data storage capability. That is, in addition to a processor, a storage device may be included or coupled to each of the portable device 115, ±e first management system 125, the848222.0046US first draft 20250417 target reading system 155, the second management system 145 and the bridging system 135, for storing data and programmed instructions for the processors to perform bridging transactions.

[0041] To implement an offline bridging transaction via target scanning, the network system 10 is operated in a customer presented mode (CPM). Specifically, after obtaining an offline payment5 target (e.g., a QR code) or its source target content (e.g., a string for generating a QR code) in a format of the second service provider 140 by performing a request initiation process, the payer 110 presents the offline payment target on the portable device 115 without internet access, as a first step of a target present process. In subsequent steps of the target present process, the receiver 150 reads the offline payment target by using the target reading system 155, and the target reading10 system 155 then transmits an transaction request including a parsed target content read from the offline payment target, to the second management system 145 of the second service provider 140. In response, the second management system 145 relays the transaction request to the bridging system 135 of the bridging service provider 130, and the bridging system 135 routes the transaction request to the first management system 125 of the first service provider 120, to request an offline15 payment. As the first service provider 120 authorizes, a transaction approval is sent back to the bridging system 135 of the bridging service provider 130, and the bridging system 135 executes the offline payment and provides transaction notice to the target reading system 155 of the receiver 150. Lastly, when the portable device 115 is back online, a payment application on the portable device 115 updates transaction history by accessing the first management system 125 of the first20 service provider 120 in a transaction history update process.

[0042] As will be described in further details, an offline bridging transaction can be performed by following different flows, including an advance request flow (ARE) and an on-demand flow (ODF). The ARF requires the payer 110 to request an offline payment feature (OPF) ahead of time before any offline payment can be performed. On the other hand, according to the ODF, the25 payer 110 requests an OPF when the payment application on the portable device 115 detects offline internet connection and the payer 110 initiates a payment. It should be noted that the OPF described herein is defined as a payment transaction performed by the payer 110 presenting a payment target to the receiver 150 while the portable device 115 is offline.

[0043] FIG. 2A is a flow diagram illustrating a request initiation process in the ARF, according30 to some embodiments of the present disclosure.

[0044] At a step S200, the payment application on the portable device 115 may provide an OPF opt-in option for the payer 1 10 when the payer 110 enters a service range of the second service provider 140. As an example, when the payer 1 10 leaves a service range of the first service provider 120 (e.g., a first country) and enters the service range of the second service provider 140948222.0046US first draft 20250417 (e.g., a second country), the payment application may initiatively display the OFF opt-in option on a screen of the portable device 1 15 for the payer 110 to determine. If the payer 110 declines to request the OFF, then the request initiation process ends. On the other hand, if the payer 110 accepts the OFF request, a series of steps are performed to retrieve an offline payment target (or a5 target content for generating the offline payment target) recognizable to the second service provider 140, and save the offline payment target or the source target content on the portable device 115 for later use.

[0045] Specifically, if the payer 110 accepts the OFF request, a step S202 is performed, and the payment application on the portable device 115 sends a request for the offline payment target or10 the source target content to the first management system 125 of the first service provider 120 under an online environment, along with identity of the payer 110. The first management system 120 may store the identity of the payer 110, and generate a parent request link identifier (parent RLID). The parent RLID is an identifier to link the target request to the specific payer 110, and may be used for generating another RLID (e.g., a child RLID) in the subsequent targe present process.15

[0046] Further, in a step S204, the first management system 125 transmits the target request to the bridging system 135, along with the parent RLID and identity of the first service provider 120. Based on the agreement to link the first and second service providers 120, 140 via the bridging service provider 130, the bridging system 135 of the bridging service provider 130 directs the target request as well as the attached parent RLID and the identity of the first service provider 12020 to the second management system 145 of the second service provider 140 in a step S206.

[0047] In response, a step S208 is performed by the second management system 145 of the second service provider 140 to provide and return the offline payment target or the source target content to the bridging system 135 of the bridging service provider 130, along with the parent RLID, identities of the first and second service providers 120, 140 and status of the offline payment25 target. In this way, the offline payment target being read in the subsequent target present process is recognizable to the second management system 145 of the second service provider 140. As an example where the offline payment target is a QR code, the target content may be a string for generating the QR code.

[0048] In addition to providing and directing the offline payment target or the source target30 content, the second management system 145 of the second service provider 140 may further store the offline payment target (or the source target content) as well as the parent RLID, the status of the offline payment target (or the source target content) and identity of the first service provider 120 associated with the offline payment target (or the source target content) in the storage device of the second management system 145. Further, based on the agreement to link the first and second1048222.0046US first draft 20250417 service providers 120, 140 via the bridging service provider 130, settings and restrictions for offline bridging transactions between the first and second service providers 120, 140 may be determined and stored in the second management system 145 as well, including maximum amount per transaction (in either local or foreign currency), maximum number of offline bridging5 transactions per day or specified timeframe, maximum amount of offline bridging transactions per day or specified timeframe and an expiration timestamp indicating the duration in which the OPF is available.

[0049] Similarly, the bridging system 135 of the bridging service provider 130 may also store the offline payment target (or the source target content) as well as the parent RLED, the status of10 the offline payment target (or the source target content) and the identities of the first and second service providers 120, 140 linked to the offline payment target (or the source target content), and may store the settings and restrictions according to the agreement.

[0050] In a subsequent step S210, the offline payment target or the source target content is directed to the first management system 125 of the first service provider 120 by the bridging15 system 135 of the bridging service provider 130, along with attached information including the parent RLID and the identity of the second service provider 140. The first management system 125 may store the offline payment target (or the source target content) as well as the parent RLID, the status of the offline payment target (or the source target content) and the identity of the second service provider 140 linked to the offline payment target (or the source target content), and may20 store the settings and restrictions according to the agreement as similar to the second management system 145 of the second service provider 140.

[0051] Based on the parent RLID attached along with the offline payment target (or the source target content), the first management system 125 returns the offline payment target (or the source target content) to the portable device 115 in a step S212. The portable device 115 may store the25 offline payment target (or the source target content), which allows the offline payment target (or the source target content) to be retrieved by the payment application when an offline bridging transaction is needed.

[0052] FIG. 2B is a flow diagram illustrating a target present process in the ARF, according to some embodiments of the present disclosure.30

[0053] The target present process can be performed for implementing an offline bridging transaction when the portable device 1 15 is offline, by using the offline payment target or the source target content obtained from the request initiation process described with reference to FIG. 2A.I l48222.0046US first draft 20250417

[0054] Specifically, upon requesting an offline payment by the payer 110 in a step S220, the payer 110 presents the offline payment target to the receiver 150 in a step S222. The offline payment target may be retrieved from the storage device of the portable device 115, or generated from the source target content stored in the portable device 115 by operating the payment5 application. In some embodiments, the payment application on the portable device 115 performs a preliminary check on the request. If the request is found acceptable based on predetermined limits (e.g., amount, frequency etc.), then the payment application presents the offline payment target. Otherwise, the payment application may decline the request.

[0055] As described above, the receiver 150 is a user of the second service provider 140.10 Accordingly, after the receiver 150 reads the offline payment target by using the target reading system 155 in a step S224, the target reading system 155 sends a transaction request including a parsed target content read from the offline payment target and transaction details to the second management system 145 of the second service provider 140 in a step S226. As an example (but not limited to), the transaction details may include amount of the offline payment, currency used15 for the offline payment, identity of the receiver 150, timestamp of the transaction request, invoice number for the payer 110 and the like.

[0056] Since the parsed target content of the offline payment target is recognizable to the second service provider 140, the second management system 145 is able to process the transaction request. Specifically, the second management system 145 routs the parsed target content of the offline20 payment target and relevant information to the bridging system 135 of the bridging service provider 130 in a step S228, to direct the transaction request to the bridging system 135. According to certain embodiments, the second management system 145 identifies that the transaction request is a request for an offline bridging transaction based on the data (e.g. , the identity of the first service provider 140) stored in the second management system 145 and associated with the offline25 payment target, thus directs the transaction request to the bridging system 135 of the bridging service provider 130. Further, the relevant information sent to the bridging system 135 along with the parsed target content of the offline payment target may include a child RLID and the transaction details of the offline payment being requested. The child RLID is an identifier for the bridging system 135 to link the transaction request to the specific receiver 150 and the specific30 payer 110. As the parent RLID linking the offline payment target and the specific payer 110 is stored in the second management system 145 and the second management system 145 may receive the identity of the receiver 150 associated with the parsed target content of the offline payment target, the second management system 145 may generate the child RLID based on the parent RLID1248222.0046US first draft 20250417 and the identity of the receiver 150. In addition, the child RLID along with the transaction details may be stored in the storage device of the second management system 145.

[0057] In some embodiments, before performing the step S228, the second management system 145 of the second service provider 140 performs a validity check, to determine if the transaction5 request is in compliance with the settings and restrictions stored in the storage device and associated with the offline payment target in an optional step S227. If the transaction request is against the settings and restrictions, the second management system 145 may deny the transaction request. On the other hand, if the transaction request is in compliance with the settings and restrictions, the target presentation process may proceed further, which is assumed for illustration10 propose. As an example (but not limited to), the validity check may involve an expiration check based on the expiration timestamp stored in the second management system 145 and the timestamp of the transaction request in the transaction details sent to the second management system 145, and may involve checking if the status of the offline payment target has been updated as blocked.

[0058] After the step S228, the bridging system 135 directs the transaction request including the15 parsed target content of the offline payment target and the relevant information to the first management system 125 of the first service provider 120 in a step S230. In some embodiments, the bridging system 135 can link the parsed target content of the offline payment target with the identity of the first service provider 120 by accessing data stored during the request initiation process described with reference to FIG. 2A. In addition to being functioned as a hub, the bridging20 system 135 may further store the child RLID and the transaction details for later use.

[0059] Further, in some embodiments, before performing the step S230, the bridging system 135 performs a validity check, to determine if the transaction request is in compliance with the settings and restrictions stored in the storage device and linked to the offline payment target in an optional step S229. If the transaction request is against the settings and restrictions, the bridging25 system 135 may deny the offline payment request. On the other hand, if the transaction request is in compliance with the settings and restrictions, the target presentation process may proceed further, which is assumed for illustration purpose. As an example (but not limited to), the validity check may involve an expiration check based on the expiration timestamp stored in the second management system 145 and the timestamp of the transaction request in the transaction details30 sent to the second management system 145, and may involve checking if the status of the offline payment target has been updated as blocked.

[0060] In some embodiments, upon receiving the parsed target content of the offline payment target and the relevant information, the first management system 125 performs risk assessment in a step S232. In addition, the first management system 125 may store the child RLID and the1348222, 0046US first draft 20250417 transaction details received along with the parsed target content of the offline payment target. To perform the risk assessment, the first management system 125 is configured to decide an authorization threshold and determine if the transaction request reaches the authorization threshold. The first management system 125 may recognize the identity of the payer 110 involved in the5 transaction request, according to the child RLID included in the relevant information sent along with the parsed target content of the offline payment target and / or the parent RLID stored in the storage device of the first management system 125. Thereby, the first management system 125 may retrieve user score and / or risk level related to the payer 110. In addition, the first management system 125 can identify business type of the receiver 150 (e.g., a merchant category code (MCC))10 and location of the requested offline payment as well as time gap from previous similar offline payment (if any), based on the transaction details (and the child RLID) attached along with the parsed target content of the offline payment target. With these risk factors, the first management system 125 can decide the authorization threshold for offline bridging transaction(s) between the payer 110 and the receiver 150, which may be defined by (but not limited to) an maximum amount15 per offline bridging transaction, a maximum frequency of offline bridging transactions in a specified timeframe and a maximum total amount of offline bridging transaction(s) in a specified timeframe. In some embodiments, the first management system 125 performs the risk assessment by determining if the offline payment being requested lies withing the authorization threshold. For instance, the risk assessment may involve comparing the amount of the offline payment being20 requested with the maximum amount per offline bridging transaction.

[0061] In addition, the first management system 125 may further perform a validity check in the step S232, to determine if the transaction request is in compliance with the settings and restrictions stored in the storage device and associated with the offline payment target. If the transaction request does not pass the risk assessment or the validity check, then the first management system25 125 denies the transaction request. On the other hand, if the transaction request passes the risk assessment and the validity check, then the first management system 125 authorizes the transaction request, and sends a transaction approval back to the bridging system 135 of the bridging service provider 130 in a step S234.

[0062] Upon receiving the transaction approval, the bridging system 135 executes the requested30 offline payment in a step S236. In some embodiments, to execute the offline payment, the bridging system 135 actually transfers funds between the first management system 125 of the first service provider 120 and the second management system 145 of the second service provider 140, based on the identities of the first and second service providers 120, 140 associated with the offline payment target. For instance, the bridging system 135 may request a fund from the first1448222.0046US first draft 20250417 management system 125 of the first service provider 120 and send the fund to the second management system 145 of the second service provider 140. In alternative embodiments, the bridging system 135 executes the offline payment by recording the offline payment in its database or a distributed ledger (e.g., a blockchain), which is accessible to the first management system 1255 of the first service provider 120 and the second management system 145 of the second service provider 140, and allows account settlement for the first and second service providers 120, 140.

[0063] As the offline payment has been completed, the bridging service provider 130 notifies the first and second service providers 120, 140. Specifically, based on the identities of the first and second service providers 120, 140 associated with the offline payment target, the bridging10 system 135 of the bridging service provider 130 provides a transaction notice to the first management system 125 of the first service provider 120 in a step S238, and also provides the transaction notice to the second management system 145 of the second service provider 140 in a step S240. In response, the second management system 145 of the second service provider 140 provides a payment confirmation to the target reading system 155 of the receiver 150 in a step15 S242, based on the child RLID associated with the offline payment target.

[0064] Upon receiving the payment confirmation, the receiver 150 provides good(s) and / or service(s) to the payer 110 in a step S244, to complete the transaction between the payer 110 and the receiver 150.

[0065] According to some embodiments, the same offline payment target (or the source target20 content) obtained from the request initiation flow can be used multiple times, for performing offline payments to the same receiver 150 as a user of the second service provider 140, except that transaction details should be updated in each time. Alternatively, the same offline payment target (or the source target content) may be used multiple times for performing offline payments to different receivers 150 as users of the second service provider 140, as long as transaction details25 and child RLED are updated in each time. Further, it should be understood that total amount of the requested offline payments per day or specified timeframe and total number of the requested offline payments per day or specified timeframe must not reach predetermined limits, which are stored in the first management system 125, the second management system 145 and the bridging system 135, as the settings and restrictions. Otherwise, the transaction requests) over the limits30 would be declined. Moreover, as will be described in further details, the offline payment target (or the source target content) may be invalidated.

[0066] Since the portable device 115 of the payer 1 10 is still offline, the payment application on the portable device 115 cannot update the record(s) of the completed offline bridging transaction(s) at this point.1548222.0046US first draft 20250417

[0067] FIG. 2C is a flow diagram illustrating a transaction history update process in the ARF, according to some embodiments of the present disclosure.

[0068] When the portable device 115 resumes internet connection, the payment application on the portable device 115 sends a request to the first management system 125 of the first service5 provider 120 for update of transaction history in a step S250. In response, in a step S252, the first management system 125 may retrieve transaction logs from the corresponding storage device, and send to the portable device 115 for updating transaction history on the portable device 115. As a result, the transaction history on the payment application is synchronized with the transaction logs on the first management system 125 of the first service provider 120.10

[0069] As described, during the target present process, each of the second management system 145 of the second service provider 140, the bridging system 135 of the bridging service provider 130 and the first management system 125 of the first service provider 120 may check validity of the transaction request, and the first management system 125 of the first service provider 120 may further perform the risk assessment. If the transaction request fails to pass any of the validity15 checks and the risk assessment, the transaction request is declined. Further, in certain cases, an exception handling process may be further performed.

[0070] FIG. 2D is a flow diagram illustrating an exception handling process, according to some embodiments of the present disclosure.

[0071] When the transaction request fails to meet certain criteria of the validity check and / or the20 risk assessment performed by one of the members in the network system 10 during the target present process, such member invalidates the offline payment target in a step S260. Further, such member updates the status of the offline payment target to be a blocked status and stores the updated status of the offline payment target in a step S262. Thereafter, such member informs other members in the network system 10 to update the status of the offline payment target accordingly25 in a step S264. Once the offline payment target is invalidated and tagged with the blocked status, further use of the offline payment target would be prevented.

[0072] It should be understood that when the source target content of the offline payment target is generated and stored rather than the offline payment target itself, tagging the offline payment target with a blocked status may indicate tagging the source target content of the offline payment30 target with a blocked status, fri either case, the offline payment target would be prevented from further use.

[0073] As an example, when one of the second management system 145, the bridging system 135 and the first management system 125 identifies that the timestamp of the transaction request1648222.0046US first draft 20250417 exceeds the expiration timestamp indicating the duration in which the OFF is available, the transaction request is declined and the exception handling process is performed. As another example, the transaction request is declined and the exception handling process is performed to block the offline payment target when it is identified that total amount of offline payments per day5 is over the maximum amount of offline bridging transactions per day.

[0074] On the other hand, in other cases, the transaction request would be declined without blocking the offline payment target. As an example (but not limited to), when the amount of the requested offline payment exceeds the maximum amount per transaction, the transaction request would be declined, but the offline payment target may not be invalidated. That is, the offline10 payment target might be used for another offline payment request with lower transaction amount.

[0075] As another security mechanism, after the transaction history of the payment application on the portable device 115 is updated as a result of the transaction history update process, the payer 110 can determine if any of the offline bridging transactions is unauthorized by operating the payment application on the portable device 115. According to certain embodiments, when at least15 one unauthorized offline bridging transaction is found, the payment application on the portable device 115 may send a notification to the first management system 125 of the first service provider 120, and the first management system 125 can invalidate the offline payment target by updating the status of the offline payment target to be a blocked status, as similar to the step S262. Further, the first management system 125 may provide the blocked status to the second management system20 145 of the second service provider 140 and the bridging system 135 of the bridging service provider 130, as similar to the step S264. Once the offline payment target is invalidated and tagged with the blocked status, further use of the offline payment target would be prevented.

[0076] Up to here, the described ARF is used in a condition that the first service provider 120 is only linked to a single second service provider 140 via the bridging service provider 130. With25 several modifications, the ARF can be applied when the first service provider 120 is linked to several second service providers 140 via the bridging service provider 130.

[0077] FIG. 3 is a flow diagram illustrating a request initiation process in a modified ARF, according to some embodiments of the present disclosure.

[0078] The request initiation process is performed in a condition that the first service provider30 120 is bridged with multiple second service providers 140 via the bridging service provider 130, and is similar to the request initiation process described with reference to FIG. 2A. A few differences in between will be described, whereas the same or similar parts would be omitted.1748222.0046US first draft 20250417

[0079] Specifically, after the payment application on the portable device 115 presents an OFF opt-in option in the step S200, a step S201 may be performed by the payment application if the payer 110 accepts the option, to present all of the available second service providers 140 for the payer 1 10 to select. The payer 110 may be required to select at least one from the listed second5 service providers 140.

[0080] For illustration purpose, it is assumed that the payer 110 selects multiple ones from the available second service providers 140. Based on such selection, after the payment application sends a target request to the first management system 125 of the first service provider 120 in the step S202 and the first management system 125 directs the target request to the bridging system10 135 of the bridging service provider 130 in the step S204, the bridging system 135 routs the target request along with the attached parent RLID and the identity of ±e first service provider 120 to the second management system 145 of each of the selected second service providers 140 in the step S206.

[0081] In response, the second management system 145 of each selected second service provider15 140 provides a respective offline payment target (or its source target content) and returns the offline payment target (or the source target content) to the bridging system 135 of the bridging service provider 130 in the step S208. Along with the offline payment targets (or the source target contents), identities of the second service providers 140 are provided to the bridging system 135. In addition to other information, the bridging system 135 may store the offline payment targets (or20 the source target contents) and the identities of the second service providers 140 linked to the offline payment targets (or the source target contents).

[0082] In the subsequent step S210, the offline payment targets (or the source target contents) are sent to the first management system 125 of the first service provider 120 from the bridging system 135 of the bridging service provider 130, along with attached information including the25 identities of the second service providers 140, In addition to the offline payment targets (or the source target contents) and other information, the identities of the second service providers 140 linked to the offline payment targets may be stored in the first management system 125 of the first service provider 120.

[0083] Thereafter, the offline payment targets (or the source target contents) are sent to the30 portable devices 115 from the first management system 125 of the first service provider 120 in the step S212, and are stored in the portable device 115 for later use.1848222.0046US first draft20250417

[0084] When the portable device 115 is offline, the target present process described with reference to FIG. 2B can be used for implementing an offline bridging transaction, except that adjustment may be required to for the step S220.

[0085] Specifically, in the step S220, the payment application on the portable device 115 may5 be configured to present all of the second service providers 140 associated with the saved offline payment targets (or the source target contents) for the payer 110 to select after the payer 110 makes an transaction request. The selected second service provider 140 should be the service provider (or one of the service providers) providing payment transfer service for the receiver 150. Therefore, the offline payment target presented in the following step S222 can be recognizable to the target10 reading system 155 of the receiver 150. The following steps S224 to S244 may be performed to complete the transaction between the payer 110 and the receiver 150, if the offline payment request passes the validity check(s) and the risk assessment, as described with reference to FIG. 2B.

[0086] In addition to the ARF described above, the network system 10 in another mode is configured to perform offline bridging transactions according to the ODF, in which a request15 initiation process and a target present process can be performed even when the portable device 115 stays offline.

[0087] FIG. 4A is a flow diagram illustrating a request initiation process in the ODF, according to some embodiments of the present disclosure.

[0088] The request initiation process may start from a step S400, in which the payer 110 operates20 the payment application on the portable device 115 to request an OPF. Particularly, the step S400 can be performed when the portable device 1 15 is offline. In some embodiments, the payment application on the portable device 115 performs a preliminary check on the transaction request. If the transaction request is found acceptable based on predetermined limits (e.g., amount, frequency etc.), then the payment application proceeds further. Otherwise, the payment application may25 decline the request.

[0089] If the transaction request is acceptable, the payment application on the portable device 1 15 retrieves record(s) of completed CPM bridging transaction(s) (if any) from the storage device of the portable device 110 and presents the second service provider(s) 140 participated in the completed CPM bridging transaction(s) (if any) for the payer 1 10 to select in a step S402. If there30 is no any record of completed CPM bridging transaction, then the ODF may end. On the other hand, if one or more second service providers 140 is / are found being participated in completed CPM bridging transaction(s), a step S404 is performed, and the payment application on the portable device 115 retrieves a previously used payment target (or the source target content)1948222.0046US first draft 20250417 associated with the second service provider 140 (or one of the second service providers 140) providing digital property transfer service for the receiver 150 involved in the requested OFF, to be used as an offline payment target or used to generate an offline payment target.

[0090] If there is only a single second service provider 140 that matches the conditions, then the5 payment application on the portable device 115 retrieves a previously used payment target (or its source target content) associated with this second service provider 140. In addition, if multiple second service providers 140 match the conditions, then the payment application on the portable device 115 may ask the payer 110 to select one from the second service providers 140, and retrieve a previously used payment target (or its source target content) associated with the selected second10 service provider 140.

[0091] In some embodiments, the payment application is configured to check the status of the previously used payment target(s), to preclude invalidated payment target(s).

[0092] FIG. 4B is a flow diagram illustrating a target present process in the ODF, according to some embodiments of the present disclosure.15

[0093] The target present process in the ODF is similar to the target present process according to the ARF, as described with reference to FIG. 2B. Only differences in between will be discussed, the like or the same parts would not be repeated again, and the same or similar reference labels would be used for describing the same or similar operations.

[0094] When the portable device 11 Sis offline, the target present process may start from a target20 present step S222’, in which the payment application on the portable device 115 presents the previously used payment target retrieved by request, or reproduces the previously used payment target based on the retrieved source target content. The previously used payment target is functioned as an offline payment target in the target present process. Upon receiving the offline payment target, the receiver 150 reads the offline payment target by using the target reading system25 155 in the step S224, and sends a transaction request including the parsed target content of the offline payment target along with transaction details to the second management system 145 of the second service provider 140 in the step S226. As an example (but not limited to), the transaction details may include amount of the currently requested offline payment, currency used for the currently requested offline payment, identity of the receiver 150, timestamp of the current30 transaction request, invoice number for the payer 110 and the like.

[0095] Since the offline payment target has been presented to and successfully processed by the second service provider 140 in a previously completed CPM bridging transaction, the parsed target content of the offline payment target is recognizable to the second service provider 140. Further,2048222.0046US first draft 20250417 by accessing history data associated with the offline payment target, the second management system 145 may retrieve the RLID (e.g., the child RLID) included in the data associated with the previously completed CPM bridging transaction linked to the offline payment target, and generate a new child RLID for the current transaction request based on the previously used RLID (e.g., the5 previously used child RLID). Specifically, the new RLID may be generated by updating the identity of the receiver 150 of the used RLID. It should be understood that, if the receiver 150 for the previously completed CPM bridging transaction is the same as the receiver 150 for the currently requested offline payment, the new RLID may be identical with the used RLID in terms of identities of the payer 110 and the receiver 150. For later use, the new RLID may be stored in10 the storage device included in or coupled to the second management system 145, along with the received transaction details.

[0096] Moreover, by accessing the history data associated with the offline payment target, the second management system 145 may identify that the currently requested offline payment is also a bridging transaction. Thereby, the second management system 145 routs the transaction request15 including the parsed target content of the offline payment target and relevant information to the bridging system 135 of the bridging service provider 130 in the step S228. The relevant information includes the new RLID as an identifier for the bridging system 135 to link the current transaction request to the updated receiver 150 and the payer 110, and may further include the transaction details. In addition, the new RLID along with the transaction details may be stored in20 the storage device included in or coupled to the second management system 145. In some embodiments, before performing the step S228, the second management system 145 of the second service provider 140 performs a validity in an optional step S227, as described with reference to FIG. 2B.

[0097] By accessing history data associated with the offline payment target, the bridging system25 134 can identify the identity of the first service provider 120 linked to the current transaction request, thus directs the current transaction request including the parsed target content of ±e offline payment target and the relevant information to the first management system 125 of the first service provider 120 in the step S230. Further, the bridging system 135 may store the new RLID and the transaction details in the storage device included in or coupled to the bridging system 135. In30 some embodiments, before performing the step S230, the bridging system 135 further performs a validity check, as described with reference to FIG. 2B.

[0098] Upon receiving the transaction request including the parsed target content of the offline payment target and the relevant information, the first management system 125 may perform risk assessment and an optional validity check in the step S232, as described with reference to FIG. 2B.2148222.0046US first draft 20250417 In addition, the first management system 125 may store the new RLID and the transaction details received along with the parsed target content of the offline payment target. If the cunent transaction request does not pass the risk assessment or the validity check, then the first management system 125 denies the cunent transaction request. On the other hand, if the current5 transaction request passes the risk assessment and the validity check, then the first management system 125 authorizes the current transaction request, and sends a transaction approval back to the bridging system 135 of the bridging service provider 130 in the step S234.

[0099] Subsequently, the following steps S236, S238, S240, S242, S244 described with reference to FIG. 2B are performed for finishing the offline payment and the transaction between10 the payer 1 10 and the receiver 150. According to the request initiation process and the target present process discussed with reference to FIG. 4A and FIG. 4B, it is possible that the same offline payment target (or its source target content) may be reused multiple times if the same second service provider 140 is involved in the related offline bridging transactions, as long as these offline bridging transactions do not violate the stored settings and restrictions stored and can pass15 the risk assessment performed by the first management system 125 of the first service provider 120.

[0100] When the portable device 115 resumes internet connection, the transaction history update process described with reference to FIG. 2C can be performed to update transaction history on the portable device 115.20

[0101] If the transaction request fails to meet certain criteria of the validity check and / or the risk assessment performed by one of the members in the network system 10 during the target present process, the steps S260, S262, S264 in the exception handling process described with reference to FIG. 2D may be performed to invalidate the offline payment target. In this way, further use of such offline payment target would be prevented.25

[0102] As above, a network system and methods for implementing offline bridging transactions are provided. Particularly, the network system involves a bridging system bridging management systems of different service providers offering digital property transfer services for a payer (e.g., a customer) and a receiver (e.g., a merchant). Furthermore, processors of the network system are configured to execute programmed instructions for performing offline bridging transactions,30 which include an offline payment from the payer to the receiver. To implement the offline payment, the payer requests an offline payment target recognizable to the service provider of the receiver, or a source target content for generating the offline payment target. Even without internet access, the payer can present the offline payment target to the receiver, for requesting the offline payment. The management system of the service provider supporting the receiver is configured2248222.0046US first draft 20250417 to send a transaction request including parsed target content of the offline payment to the bridging system. As the bridging system has stored identities of both service providers associated with the offline payment, the bridging system routs the transaction request to the other service provider based on the stored data. Once the service provider of the payer authorizes the offline payment,5 the bridging system executes the offline payment, and provides transaction notice to both service providers. Accordingly, transaction between the payer and the receiver can be completed when a portable device of the payer is still offline. According to some embodiments, the offline payment target (or its source target content) is generated and saved in the portable device of the payer before the portable device goes offline and before requesting any offline payment. In other embodiments,10 the offline payment target is a previously used payment target stored in the portable device of the payer, and can be retrieved when the portable device is offline.

[0103] FIG. 5 is a block diagram schematically illustrating a network system for offline bridging transactions, according to extended embodiments of the present disclosure.

[0104] According to the extended embodiments, the bridging service provider 130 as well as15 the bridging system 135 are absent in the network system 50. In these embodiments, the second management system 145 of the second service provider 140 may directly communicate with the first management system 125 of the first service provider 120.

[0105] FIG. 6A is a flow diagram illustrating a request initiation process in the ARF, according to the extended embodiments of the present disclosure.20

[0106] The request initiation process shown in FIG. 6A is similar to the request initiation process described with reference to FIG. 2A. To avoid redundancy, only differences in between would be discussed. Specifically, upon receiving the target request for an offline payment target or its source target content from the portable device 115 (the step S202), the first management system 125 of the first service provider 120 may send the target request to the second management system 14525 of the second service provider 140 in a step S600, based on an agreement between the first and second service providers 120, 140 for offline bridging transactions. In addition to the request, the identity of the first service provider 120 and the identity of the payer 110 may be provided to the second management system 145 as well.

[0107] In response, a step S602 is performed by the second management system 145 of the30 second service provider 140 to provide the offline payment target or the source target content, and provide the offline payment target or the source target content back to the first management system 125 of the first service provider 120. In addition, the identity of the second service provider 140 may be provided to the first management system 125 as well.2348222.0046US first draft 20250417

[0108] As a result of the step S2I2, the offline payment target or the source target content is provided to the portable device 115, and is stored for later use.

[0109] FIG. 6B is a flow diagram illustrating a target present process in the ARF, according to the extended embodiments of the present disclosure.5

[0110] The target present process shown in FIG. 6B is similar to the target present process described with reference to FIG. 2B. To avoid redundancy, only differences in between would be discussed. Specifically, if the transaction request passes the validity check performed by the second management system 145 of the second service provider 140 (the step S227), the second management system 145 of the second service provider 140 may direct the transaction request to10 the first management system 125 of the first service provider 120 in a step S610. The identity of the first service provider 120 stored in the second management system 145 and associated with the offline payment target may navigate the routing of the request in the step S610. Further, the identity of the receiver 150 sent to the second management system 145 and the transaction details of the transaction request may also be provided to the first management system 125 in the step15 S610.

[0111] If the transaction request is authorized based on the risk assessment (the step S232) and an optional validity check performed by the first management system 125, the first management system 125 may execute the offline payment in a step 8612. In some embodiments, to execute the offline payment, the first management system 125 actually transfers funds between the first20 management system 125 of the first service provider 120 and the second management system 145 of the second service provider 140, based on the identities of the first and second service providers 120, 140 linked to the offline payment target. For instance, the first management system 125 of the first service provider 120 may send a fund to the second management system 145 of the second service provider 140. In alternative embodiments, the bridging system 135 executes the offline25 payment by recording the offline payment in its database or a distributed ledger (e.g., a blockchain), which is accessible to the first management system 125 of the first service provider 120 and the second management system 145 of the second service provider 140, and allows account settlement for the first and second service providers 120, 140.

[0112] Once the offline payment is completed, the first management system 125 may send a30 transaction notice to the second management system 145 in a step S614. In response, the second management system 145 of the second service provider 140 provides a payment confirmation to the target reading system 155 of the receiver 150 in the step S242, based on the identity of the receiver 150 linked to the offline payment target. In addition, the transaction between the payer 110 and the receiver 150 can be completed in the step S244. When the portable device 1 15 resumes2448222.0046US first draft 20250417 internet connection, the transaction history update process described with reference to FIG. 2C can be performed to update transaction history on the portable device 115.

[0113] If the first service provider 120 is linked to multiple second service providers 140, the step S201 described with reference to FIG, 3 may be further added to the request initiation process5 of FIG. 6A. For illustration purpose, it is assumed that the payer 110 selects multiple ones from the available second service providers 140 in the step S201 . Accordingly, the first management system 125 of the first service provider 120 may send the target request for the offline payment target or its source target content to the second management system 145 of each of the selected second service provider 140 in the step S600. In the following steps (i.e., the steps S602, S212),10 the generated offline payment targets or their source target contents are provided to the portable device 1 15 via the first management system 125.

[0114] The target present process described with reference to FIG. 6B can be performed for implementing an offline bridging transaction using one of the stored offline payment target (or its source target content), except that the payment application on the portable device 115 may present15 all of the available second service providers 140 for the payer 110 to select in the step S220. Further, when the portable device 1 15 is back online, the transaction history update process described with reference to FIG. 2C is performed to update transaction history on the portable device 1 15.

[0115] The network system 50 without the bridging service provider 130 and the bridging20 system 135 is also configured to perform the ODF. Specifically, a previously used payment target (or its source target content) is retrieved to serve as or to generate the offline payment target by operating the payment application on the portable device 115 while the portable device 115 is offline, according to the request initiation process described with reference to FIG. 4A.

[0116] FIG. 7 is a flow diagram illustrating a target present process in the ODF, according to25 the extended embodiments of the present disclosure.

[0117] After presenting the offline payment target in the step S222' described in greater details with reference to FIG. 4B, a series of the steps S224, S226, S227, S610, S232, S612, S614, S242, S244 described with reference to FIG. 6B can be performed to complete the offline payment and transaction between the payer 110 and the receiver 150. When the portable device 115 resumes30 internet connection, the transaction history update process described with reference to FIG. 2C can be performed to update transaction history on the portable device 115.

[0118] If the offline payment request fails to meet certain criteria of the validity check and / or the risk assessment performed by the second management system 145 of the second service2548222.0046US first draft 20250417 provider 140 or the first management system 125 of the first service provider 120 during the target present process in either the ARF mode or the ODF mode, the steps S260, S262, S264 in the exception handling process described with reference to FIG. 2D may be performed to invalidate the offline payment target. In this way, further use of such offline payment target would be5 prevented.

[0119] According to further extended embodiments, the network system 50 without the bridging service provider 130 and the bridging system 135 is configured to perform an offline bridging transaction in which an offline payment is executed by the second management system 145 of the second service provider 140.10

[0120] Based on the ARF, the offline payment target or its source target content can be obtained by performing the request initiation process described with reference to FIG. 6A. If the first service provider 120 is linked to multiple second service providers 140, the step S201 described with reference to FIG. 3 may be further added to the request initiation process of FIG.6A.

[0121] FIG. 8 is a flow diagram illustrating a target present process in the ARF, according to15 the further extended embodiments of the present disclosure.

[0122] The target present process according to the further extended embodiments is similar to the target present process described with reference to FIG. 6B, except for a few differences. Specifically, if the transaction request is authorized based on the risk assessment (the step S232) and an optional validity check performed by the first management system 125, the first20 management system 125 of the first service provider 120 may send a transaction approval to the second management system 145 of the second service provider 140 in a step S800.

[0123] In response, the second management system 145 may execute the requested offline payment in a step S802. In some embodiments, to execute the offline payment, the second management system 145 actually transfers funds between the first management system 125 of the25 first service provider 120 and the second management system 145 of the second service provider 140, based on the identities of the first and second service providers 120, 140 linked to the offline payment target. For instance, the second management system 145 may request a fund from the first management system 125 of the first service provider 120. In alternative embodiments, the second management system 145 executes the offline payment by recording the offline payment in30 its database or a distributed ledger (e.g., a blockchain), which is accessible to the first management system 125 of the first service provider 120 and the second management system 145 of the second service provider 140, and allows account settlement for the first and second service providers 120, 140.2648222.0046US first draft 20250417

[0124] As the offline payment has been completed, the second management system 145 sends a transaction notice to the first management system 125 of the first service provider 120 in a step S804, and sends a payment confirmation to the target reading system 155 of the receiver 150 in the step S242. Accordingly, the transaction between the payer 110 and the receiver 150 can be5 completed in the step S244. When the portable device 115 resumes internet connection, the transaction history update process described with reference to FIG. 2C can be performed to update transaction history on the portable device 115.

[0125] On the other hand, the network system 50 without the bridging service provider 130 and the bridging system 135 can be operated based on the ODF mode. Specifically, a previously used10 payment target (or its source target content) can be retrieved to serve as or to generate the offline payment target by operating the payment application on the portable device 115 without internet connection, according to the request initiation process described with reference to FIG. 4A.

[0126] FIG. 9 is a flow diagram illustrating a target present process in the ODF, according to the further extended embodiments of the present disclosure.15

[0127] After presenting the offline payment target in the step S222’ described in greater details with reference to FIG. 6B, a series of the steps S224, S226, S227, S610, S232, S800, S802, S804, S242, S244 described with reference to FIG. 8 can be performed to complete the offline payment and transaction between the payer 110 and the receiver 150, When the portable device 115 resumes internet connection, the transaction history update process described with reference to20 FIG. 2C can be performed to update transaction history on the portable device 115.

[0128] If the transaction request fails to meet certain criteria of the validity check and / or the risk assessment performed by the second management system 145 of the second service provider 140 or the first management system 125 of the first service provider 120 during the target present process in either the ARF mode or the ODF mode, the Steps S260, S262, S264 in the exception25 handling process described with reference to FIG. 2D may be performed to invalidate the offline payment target. In this way, further use of such offline payment target would be prevented.

[0129] According to various embodiments described above, the offline payment target presented on the portable device 115 is provided by the second management system 145 of the second service provider 140. Specifically, a target generator may be embedded in the second management system30 145, for generating the offline payment target or its source target content according to format and / or rules of the second service provider 140. As another alternative, the second management system 145 may be connected to an external target generator.2748222.0046US first draft20250417

[0130] FIG. 10A is a block diagram further illustrating a target generator 160 used in the network system 10 for performing offline bridging transactions, according to some embodiments of the present disclosure. In addition, FIG. 10B is a block diagram further illustrating a target generator 160 used in the network system 50 for performing offline bridging transactions,5 according to some embodiments of the present disclosure.

[0131] As shown in FIG. 10A and FIG. 10B, the second management system 145 of the second service provider 140 may direct a target request to the target generator 160 connected to the second management system 145. Upon receiving the offline payment target or its source target content generated by the target generator 160, the second management system 145 of the second service10 provider 140 provides the offline payment target or its source target content to the bridging system 135 or the first management system 125. As the offline payment target or its source target content is generated according to format and / or rules of the second service provider 140, the offline payment target presented on the portable device 115 is recognizable to the target reading system 155 of the receiver 150, which is a user of the second service provider 140.15

[0132] FIG. 11 is a block diagram illustrating a network system 10* for performing offline bridging transactions, according to some alternative embodiments of the present disclosure.

[0133] The network system 10’ is similar to the network system 10, except that the offline payment target (or its source target content) is provided by the bridging system 135 of the bridging service provider 130. Specifically, the bridging system 135 may direct the target request to the20 target generator 160 connected to the bridging system 135. Upon receiving the offline payment target or its source target content generated by the target generator 160, the bridging system 135 provides the offline payment target or its source target content to the first management system 125. Based on a bilateral agreement, the offline payment target or its source target content is generated according to format and / or rules of the second service provider 140. Thereby, the offline payment25 target presented on the portable device 115 is recognizable to the target reading system 155 of the receiver 150, which is a user of the second service provider 140.

[0134] Based on the network system 10’, the communications between the bridging system 135 and the second management system 145 during the request initiation process according to various embodiments can be reduced. For instance, in the embodiments described with reference to FIG.30 2A, the bridging system 135 may provide the offline payment target or its source target content upon receiving the target request from the first management system 125, rather than further directing the target request to the second management system 145. The generated offline payment target (or its source target content) may be directed to the first management system 125 in the step S210. In some embodiments, the generated offline payment target (or its source target content)2848222.0046US first draft 20250417 and relevant information may still be transmitted to the second management system 145 for navigating the subsequent target present process. Similar modifications may be made to the request initiation process described with reference to FIG. 3.

[0135] It should be appreciated that, as another alternative, the target generator 160 can be5 embedded into the bridging system 135, to further simplify the request initiation process. Moreover, with respect to further variations to the system and method for implementing bridging transactions throuhg the first and second service providers 120, 140, International Patent Application PCT / US2022 / 079513, filed on November 9, 2022, titled “SYSTEMS AND METHODS FOR TARGET BRIDGING”, is incorporated herein by reference at its entirety.10

[0136] The foregoing description of embodiments is provided to enable any person 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 use of the innovative faculty. The claimed subject matter set forth in the claims is not intended to be limited to the embodiments shown herein15 but is to be accorded the widest scope consistent with the principles and novel features disclosed herein. It is contemplated that additional embodiments are within the spirit and true scope of the disclosed subject matter. Thus, it is intended that the present invention covers modifications and variations that come within the scope of the appended claims and their equivalents.29

Claims

WHAT IS CLAIMED IS:

1. A method for performing an offline bridging transaction through a bridging system of a bridging service provider, comprising: receiving a transaction request by the bridging system, wherein the transaction request includes a parsed target content obtained by reading an offline payment target presented on a portable device while the portable device is offline; sending the transaction request to a first management system of a first service provider by the bridging system, based on an identity of the first service provider associated with the offline payment target and stored in the bridging system, wherein the first service provider provides payment transfer service for a payer having the portable device, and the transaction request is provided to the first management system to request an offline payment; and upon receiving a transaction approval from the first management system, executing the offline payment and sending a transaction notice to the first management system by the bridging system.

2. The method according to claim 1 , wherein the bridging system receives a transaction request link identifier (RLID) along with the transaction request, the transaction RLID links the transaction request to an identity of the payer and an identity of a receiver, and the bridging system circulates the transaction RLID to the first management system, along with the transaction request.

3. The method according to claim 2, wherein the bridging system receives the transaction approval if the offline payment is authorized by the first management system based on a risk assessment comprising: retrieving user score and / or risk level related to the payer, according to the transaction RLID.

4. The method according to claim I , wherein the offline payment is executed when a transaction of the offline payment is recorded in a distributed ledger.

5. The method according to claim 1, wherein the bridging system sends the transaction request received from a second management system of a second service provider which receives from a target reading system of a receiver as a user of the second service provider, and further sends the transaction notice to the second management system, and wherein the target reading system of the receiver does not recognize a payment target of the first service provider.

6. The method according to claim 5,30wherein at least one of the second management system, the bridging system and the first management system store settings and restrictions for offline bridging transactions, and wherein transaction details of the offline payment are circulated to the second management system, the bridging system and the first management system along with the transaction request.

7. The method according to claim 6, further comprising: performing a validity check by the at least one of the second management system, the bridging system and the first management system, wherein performing the validity check comprises comparing the transaction details with the settings and restrictions.

8. The method according to claim 7, wherein when the transaction request fails to pass the validity check performed by the at least one of the second management system, the bridging system and the first management system, the method further comprises: updating a status of the offline payment target to be a blocked status by the at least one of the second management system, the bridging system and the first management system; and sending the blocked status to another one of the second management system, the bridging system and the first management system by the at least one of the second management system, the bridging system and the first management system which updates the status of the offline payment target, wherein further use of the offline payment target or the parsed target content is prevented as a result of the blocked status associated to the offline payment target.

9. The method according to claim 5, further comprising: performing a request initiation process to obtain the offline payment target or its source target content before presenting the offline payment target on the portable device, wherein the request initiation process comprises: receiving a target request and sending the target request to the second management system by the bridging system; and routing the offline payment target or the source target content provided by the second management system to the first management system by the bridging system.

10. The method according to claim 9, wherein during the request initiation process, the bridging system receives the identity of the first service provider along with the target request from the first management system, and stores the identity of the first service provider, and wherein during the request initiation process, the bridging system stores the offline payment target or the source target content in addition to providing the offline payment target or the source target content to the first management system.3111. The method according to claim 10, wherein the request initiation process further comprises: receiving a target RLID from the first management system by the bridging system, wherein the target RLID links the target request to an identity of the payer; and circulating the target RLID to the second management system by the bridging system.

12. The method according to claim 5, further comprising: performing a request initiation process by the portable device to obtain the offline payment target or its source target content before presenting the offline payment target, wherein the request initiation process is performed by the portable device when the portable device is offline.

13. The method according to claim 12, wherein the request initiation process comprises: retrieving a previously used payment target or the source target content from the portable device, respectively to be used as or to generate the offline payment target, wherein the previously used payment target or the source target content is associated with a completed bridging transaction involving the first service provider, the second service provider and the bridging service provider.

14. The method according to claim 1, wherein the bridging system receives the transaction request provided from a second management system of a selected second service provider among multiple second service providers, and further sends the transaction notice to the second management system, and wherein a target reading system of a receiver as a user of the second service providers does not recognize a payment target of the first service provider.

15. The method according to claim 14, further comprising performing a request initiation process before presenting the offline payment target on the portable device, wherein the request initiation process comprises: routing a target request from the portable device to second management systems of the second service providers via the bridging system, to request respective offline payment targets or corresponding source target contents from the second management systems, wherein the presented offline payment target is one of the respective offline payment targets or generated from one of the source target contents.

16. The method according to claim 14, further comprising performing a request initiation process before presenting the offline payment target on the portable device, wherein the request initiation process comprises:32searching for a completed bridging transaction involving the first service provider, the selected second service provider and the bridging service provider by the portable device; and retrieving a used payment target or its source target content associated with the completed bridging transaction by the portable device, wherein the used payment target or the source target content is served as or used to generate the offline payment target, respectively.

17. The method according to claim 16, wherein the request initiation process is performed when the portable device is offline.

18. A bridging system for performing an offline bridging transaction, comprising a storage device and a processor configured to execute instructions stored in the storage device for performing the offline bridging transaction, wherein the bridging system is communicatively connected with a first management system of a first service provider and a second management system of a second service provider, and wherein performing the offline bridging transaction comprises: receiving a transaction request, wherein the transaction request includes a parsed target content obtained by reading an offline payment target presented on a portable device while the portable device is offline; sending the transaction request to the first management system, based on an identity of the first service provider associated with the offline payment target and stored in the bridging system, wherein the first service provider provides payment transfer service for a payer having the portable device, and the transaction request is provided to the first management system to request an offline payment; and upon receiving a transaction approval from the first management system, executing the offline payment and sending a transaction notice to the first management system.

19. The bridging system according to claim 18, wherein the bridging system sends the transaction request received from the second management system, which receives from a target reading system of a receiver as a user of the second service provider, and further sends the transaction notice to the second management system, and wherein the target reading system of the receiver does not recognize a payment target of the first service provider.

20. The bridging system according to claim 19, wherein performing the offline bridging transaction further comprises following steps before the offline payment target is presented on the portable device: receiving a target request and sending the target request to the second management system;33circulating the offline payment target or its source target content provided by the second management system to the first management system; and storing the offline payment target or the source target content, along with the identity of the first service provider.

21. The bridging system according to claim 19, wherein the offline payment target or its source target content is used in a previous bridging transaction performed through the first management system, the second management system and the bridging system, and is stored in the bridging system.

22. The bridging system according to claim 18, wherein performing the offline bridging transaction further comprises: receiving a transaction request link identifier (RLID) from the second management system, along with the transaction request; and circulating the transaction RLID to the first management system, wherein the transaction RLID links the transaction request to an identity of the payer and an identity of the receiver.

23. The bridging system according to claim 22, wherein the bridging system receives the transaction approval if the transaction request is authorized by the first management system based on a risk assessment comprising retrieving user score and / or risk level related to the payer according to the transaction RLID.

24. A method for performing an offline bridging transaction through a first management system of a first service provider providing payment transfer service for a payer, comprising: receiving a transaction request for an offline payment by the first management system, wherein the transaction request includes a parsed target content obtained by reading an offline payment target presented on a portable device while the portable device is offline, and an identity of the payer associated with the offline payment target is stored in the first management system before the offline payment target is presented on the portable device; and after execution of the offline payment and when the portable device is back online, sending a record of the completed offline payment to the portable device by the first management system.

25. The method according to claim 24, wherein a target reading system used by a receiver to read the offline payment target does not recognize a target of the first service provider.

26. The method according to claim 24, further comprising: performing a risk assessment by the first management system upon receiving the transaction request, to determine whether to authorize the transaction request.3427. The method according to claim 26, wherein the risk assessment performed by the first management system comprises: retrieving user score and / or risk level related to the payer according to the identity of the payer; determining an authorization threshold by taking account of the user score and / or risk level; and comparing transaction details of the offline payment with the authorization threshold.

28. The method according to claim 24, wherein the transaction request is routed to the first management system via a second management system of a second service provider providing payment transfer service for a receiver, and a target reading system used by the receiver to read the offline payment target does not recognize a payment target of the first service provider.

29. The method according to claim 28, wherein a bridging system is communicatively connected with the first management system and the second management system to execute the offline payment, and to send a transaction notice to the first management system and the second management system upon execution of the offline payment.

30. The method according to claim 24, wherein the transaction request is provided to the first management system by a second management system of a second service provider providing payment transfer service for a receiver, and the offline payment is executed by the first management system.

31. The method according to claim 30, further comprising: upon executing the offline payment, sending a transaction notice to the second management system by the first management system.

32. The method according to claim 24, wherein the transaction request is provided to the first management system via a second management system of a second service provider providing payment transfer service for a receiver, and the method further comprises performing a request initiation process to obtain the offline payment target or its source target content before presenting the offline payment target on the portable device, wherein the request initiation process comprises: routing a target request to the second management system by the first management system; and directing the offline payment target or the source target content provided by the second management system to the portable device by the first management system.3533. The method according to claim 24, wherein the transaction request is provided to the first management system via a second management system of a second service provider providing payment transfer service for a receiver, and the offline payment target or its source target content is used in a previous bridging transaction involving the first service provider and the second service provider.

34. A first management system of a first service provider providing payment transfer service for a payer, comprising a storage device and a processor configured to execute instructions stored in the storage device for performing an offline bridging transaction, comprising: receiving a transaction request for an offline payment, wherein the transaction request includes a parsed target content obtained by reading an offline payment target presented on a portable device while the portable device is offline, and an identity of the payer associated with the offline payment target is stored in the first management system before the offline payment target is presented on the portable device; and after execution of the offline payment and when the portable device is back online, sending a record of the completed offline payment to the portable device.

35. The first management system according to claim 34, wherein the offline payment is executed by a bridging system of a bridging service provider, and the bridging system is communicatively connected with the first management system of the first service provider and a second management system of a second service provider.

36. The first management system according to claim 35, wherein performing the offline bridging transaction further comprises: performing a risk assessment upon receiving the transaction request, to determine whether to authorize the transaction request; and if the transaction request is authorized, sending a transaction approval to the bridging system.

37. The first management system according to claim 34, wherein the offline payment is executed by the first management system.

38. The first management system according to claim 37, wherein performing the offline bridging transaction further comprises: performing a risk assessment upon receiving the transaction request, to determine whether to authorize the transaction request.

39. The first management system according to claim 34, wherein the transaction request is provided to the first management system via a second management system of a second36service provider providing payment transfer service for a receiver, and performing the offline bridging transaction further comprises performing a request initiation process to obtain the offline payment target or its source target content before presenting the offline payment target on the portable device, wherein the request initiation process comprises: routing a target request to the second management system by the first management system; and directing the offline payment target or the source target content provided by the second management system to the portable device by the first management system.

40. The first management system according to claim 34, wherein the transaction request is provided to the first management system via a second management system of a second service provider providing payment transfer service for a receiver, and the offline payment target or its source target content is used in a previous bridging transaction involving the first service provider and the second service provider.

41. A method for performing an offline bridging transaction through a second management system of a second service provider providing payment transfer service for a receiver, comprising: providing an offline payment target or its source target content to a portable device of a payer by the second management system; upon receiving a transaction request, directing the transaction request to a first management system of a first service provider via the second management system, to request an offline payment, wherein the first service provides payment transfer service for the payer, and the transaction request includes a parsed target content obtained by reading the offline payment target presented on the portable device while the portable device is offline; and upon execution of the offline payment, providing a payment confirmation to the receiver.

42. The method according to claim 41, further comprising: providing a transaction request link identifier (RLID) along with the transaction request to the first management system by the second management system, wherein the transaction RLID links the transaction request with an identity of the payer and an identity of the receiver.

43. The method according to claim 41, wherein the transaction request is provided to the first management system via the second management system and a bridging system of a bridging service provider.

44. The method according to claim 43, wherein the offline payment is executed by the bridging system after receiving a transaction approval from the first management system, and37the payment confirmation is provided after the second management system receives a transaction notice from the bridging system.

45. The method according to claim 44, wherein the second management system is stored with the offline payment target or the source target content and an identity of the first service provider associated with the offline payment target before receiving the transaction request.

46. The method according to claim 41, wherein the offline payment is executed by the second management system, after receiving a transaction approval from the first management system.

47. The method according to claim 41, wherein the offline payment target or the source target content has not been used in any transaction before the offline payment target is presented on the portable device.

48. The method according to claim 41, wherein the offline payment target or the source target content has been used in a previous bridging transaction involving the first service provider and the second service provider.

49. A second management system of a second service provider providing digital property transfer service for a receiver, comprising a storage device and a processor configured to execute instructions stored in the storage device for performing an offline bridging transaction, comprising: providing an offline payment target or its source target content to a portable device of a payer; upon receiving a transaction request, directing the transaction request to a first management system of a first service provider via the second management system, to request an offline payment, wherein the first service provides payment transfer service for the payer, and the transaction request includes a parsed target content obtained by reading the offline payment target presented on the portable device while the portable device is offline; and upon execution of the offline payment, providing a payment confirmation to the receiver.

50. The second management system according to claim 49, wherein performing the offline bridging transaction further comprises: providing a transaction request link identifier (RLID) along with the transaction request to the first management system, wherein the transaction RLID links the transaction request with an identity of the payer and an identity of the receiver.

51. The second management system according to claim 49, wherein the transaction request is provided to the first management system via the second management system and a bridging system of a bridging service provider.3852. The second management system according to claim 51, wherein the offline payment is executed by the bridging system after receiving a transaction approval from the first management system, and the payment confirmation is provided after the second management system receives a transaction notice from the bridging system.

53. The second management system according to claim 52, wherein the second management is stored with the offline payment target or the source target content and an identity of the first service provider associated with the offline payment target before receiving transaction request.

54. The second management system according to claim 53, wherein the offline payment is executed by the second management system, after receiving a transaction approval from the first management system.39

Images