Target analysis method and system

Abstract

A method and system for resolving targets using a two-stage target resolution is disclosed. A local resolution node resolves targets as a first stage. If the target resolution fails at the first stage, the local resolution node sends target-related data to at least one remote resolution node for a second stage of target resolution, and returns a resolvable result indicating that the target can be resolved to a corresponding type of identifier. To avoid traffic congestion caused by indiscriminately sending target-related data to the at least one remote resolution node, a mechanism cache and a hint service are used. The target-related data can be sent simultaneously or sequentially depending on the current traffic condition. Thus, the method and system can reliably resolve known or unknown targets in two stages without compromising the efficiency of target resolution.

Description

Technical Field

[0001] The present invention relates to a method and system for parsing targets, and more particularly to a method for parsing targets from raw target data into at least one identifier corresponding to a target parsing type, wherein such target parsing type is associated with a transaction. Background Technology

[0002] The global village has undoubtedly fostered an increasing number of international tourism activities, both business and leisure. These activities generate numerous payments for goods and services purchased abroad, and credit cards have been a popular choice for such cross-border payments for many years.

[0003] Using personal mobile devices for contactless payments may be a new model, but it's common in many countries and regions, such as Taiwan and countless Asian and African nations. Consumers in other areas still prefer credit cards, cash, bank transfers, or checks. Hygiene concerns, such as the recent pandemic, have made keypad use less convenient. Contactless transactions using Quick Response codes and Near-Field Communication (NFC) technologies are becoming increasingly important and widespread than ever before.

[0004] However, the original target information in matrix codes or NFC tags generated by customer or commercial devices through different payment services (such as SoftBank's Pay, Alibaba's Alipay, etc.) is converted into transaction targets. Because their data formats or addressing mechanisms are not standardized, these matrix codes or NFC tags vary depending on the payment service. For example, for Taiwanese merchants who only accept matrix codes generated by Taiwanese payment services, matrix codes generated by devices using SoftBank's payment services cannot be recognized and parsed into corresponding payment targets. In this case, a target parsing service is needed that can identify the addressing mechanism of the customer's or merchant's original target information and parse the target within that information. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for parsing targets, with an emphasis on providing reliable and effective target parsing for subsequent transactions.

[0006] To achieve the above objectives, this invention discloses a method for parsing a target, the method comprising:

[0007] (a) The local resolution node receives the target and the target resolution type from the user connected to the local resolution node;

[0008] (b) The local resolver node determines whether the target can be resolved to at least one identifier corresponding to the target's resolution type;

[0009] (c) When the target is unresolvable, the local resolver transmits the target resolution type and the target to at least one remote resolver, wherein the local resolver and the at least one remote resolver are part of a plurality of resolvers that communicate with a cross-node transaction network; and; and

[0010] (d) The local resolver determines whether the target is resolvable based on the number of at least one resolvable result returned from the at least one remote resolver.

[0011] In one embodiment, the local parsing node stores a blacklist that is updated every Time to Live (TTL), and the blacklist records at least one of the parsing nodes that are aware of the mechanism.

[0012] In another embodiment, in step (c), the local parsing node transmits the target parsing type and the target to the at least one remote parsing node, each of which is different from the parsing nodes retrieved from the blacklist using the mechanism.

[0013] In another embodiment, in step (c), the local parsing node transmits the target parsing type, the mechanism, and the target to the at least one remote parsing node, each of which is the same as one of the parsing nodes in the whitelist and different from at least one of the parsing nodes retrieved from the blacklist using the mechanism.

[0014] In another embodiment, both the whitelist and the blacklist are generated based on one of the factors: merchant location and customer location.

[0015] In another embodiment, in step (c), the local resolver may choose to transmit the target resolver type, the addressing mechanism, and the target to the at least one remote resolver simultaneously or sequentially.

[0016] To achieve the above objectives, the system for parsing the target includes:

[0017] The system for parsing the target includes a cross-node transaction network, user devices, and several parsing nodes.

[0018] These resolver nodes communicate with a cross-node transaction network containing a subset of resolver nodes, including at least one remote resolver node and a local resolver node.

[0019] The local resolution node communicates with the user device, receives the target and the target resolution type from the user device, determines whether the target can be resolved into at least one identifier corresponding to the target resolution type, and if the target cannot be resolved, the local resolution node transmits the target resolution type and the target to the at least one remote resolution node, and determines whether the target can be resolved based on the count of at least one resolvable result returned from the at least one remote resolution node.

[0020] In the two-stage target parsing scenario, if a local parsing node fails to parse the target in the first stage for any reason, at least one remote parsing node will provide a more comprehensive parsing service in the second stage. This eliminates situations where the local node is unaware of the original target information or is aware of the mechanism but unable to parse the target, thus significantly improving the reliability of target parsing. Simultaneously, a mechanism caching method is used to block the transmission of target information to parsing nodes in the blacklist that are unaware of the mechanism, and a prompting service is used to narrow the target transmission range to parsing nodes in the whitelist that can parse the target. Compared to indiscriminately transmitting target information to the second stage, these two methods can reasonably reduce the traffic generated by message transmission between the first-stage target parsing and the second-stage target analysis, thereby making target parsing faster and more efficient. Therefore, the method and system of this invention are superior to traditional technologies in providing more reliable and faster target parsing.

[0021] Other objects, advantages and novel technical features of the present invention are further described below. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating an embodiment of the method for analyzing the target of the present invention;

[0023] Figure 2A and 2B A flowchart relating to another embodiment of the method for analyzing the target of the present invention;

[0024] Figure 3 This is a flowchart of the mark return procedure in Figure 2;

[0025] Figure 4 To display a flowchart of the procedure for obtaining raw target information, the procedure is supplemented. Figure 1 And the method shown in Figure 2;

[0026] Figure 5 is a flowchart illustrating an embodiment of a transaction payment procedure using the target parsing of the present invention;

[0027] Figure 6 This is a schematic diagram illustrating an embodiment of the network structure of the system for parsing a target according to the present invention; and

[0028] Figure 7 This is a schematic diagram illustrating another embodiment of the network structure of the system for parsing a target according to the present invention. Detailed Implementation

[0029] The terminology used herein is intended to describe details in specific embodiments of the invention, and all terms should be interpreted in the broadest possible sense. Certain terms will be specifically highlighted below; any limiting terms will be defined by the specific embodiments.

[0030] The embodiments described below can be implemented via software and / or firmware programmed or configured programmable circuitry, or entirely via special function circuitry, or a combination thereof. The special function circuitry (if present) can be implemented in the following forms, such as: one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), etc.

[0031] The embodiments described herein relate to methods and systems for parsing targets when a target supplier provides raw target information to a user, the targets which may be used in subsequent transactions. Generally, raw target information can be provided in various ways, as long as it can be used to generate a mechanism and the resulting target. The mechanism described herein refers to the data format of the raw target data. Depending on the nature of the transaction, either the target supplier or the user can provide raw target information, and the other party can obtain the target from the raw target information in the transaction. The target parsing type is typically determined by the nature of the transaction. In one embodiment, the target parsing type is specified by the user. The target can be information embedded in the raw target information and parsed as an identifier. In one embodiment, there are three identifiers related to mobile transactions: MSN (Mobile User Number), MSID (Merchant Service Universal Unique Identifier), and MSU (MSN and MSID), each corresponding to a target parsing type. The key to this method or system is the two-stage target parsing, one performed by a local parsing node and the other by at least one remote parsing node. Both the local parsing node and the at least one remote parsing node are part of a group of parsing nodes in this system. To avoid network congestion caused by indiscriminately transmitting the target and its resolution type to other resolution nodes, a caching mechanism and a hint service are used to reduce the number of queries required for target resolution by other resolution nodes, thus resolving the network congestion problem. For the network structure of the target resolution system, a cross-node transaction network is used to connect several resolution nodes, including local resolution nodes and at least one remote resolution node. The implementation of this method and system will be described below.

[0032] As previously mentioned, in one embodiment, the target resolution method can be used to facilitate transactions between users and target suppliers. Considering the trend of using mobile wallets for transactions, Figure 1 The target resolution method described herein focuses on resolving the target into specific identifiers related to mobile transaction services, namely the customer's MSN, the merchant's MSID, and the store card's MSU, where the MSU contains the customer's and merchant's identification codes. Transactions described herein include, but are not limited to, payment transactions.

[0033] The target provider offers its original target information and communicates this information, along with its mechanism, to the user. The user then extracts the target from the original target information and communicates the mechanism, the target, and the target resolution type to the local resolution node. The original target information and the mechanism for the target resolution type can be predetermined by the system. Therefore, it may not be necessary to communicate the original target information and the mechanism for the target resolution type from the target provider to the user and further to the local resolution node. The original target information is defined as the source information of the target, stored in data form, including but not limited to a QR code, a near-field communication (NFC) tag, a voice signature, and a fingerprint. The mechanism of the original target information is a proprietary data format supported by the payment service provider and, in one embodiment, can be provided to the user by the target provider. These mechanisms include, but are not limited to, QR code mechanisms, NFC mechanisms, voice mechanisms, and fingerprint mechanisms, all of which can be supported by the payment service provider. For example, PayPal, as a payment service provider, can generate raw target information using various mechanisms (such as matrix barcodes, near-field communication, voice, and fingerprint mechanisms). The target itself is information obtained by extracting features from the raw target information. For instance, features can be extracted and the target derived from the raw target information by scanning a matrix barcode, sensing an NFC tag, retrieving a voice signature from a voice record, or scanning a fingerprint. The target can be in the format of a string.

[0034] From a transaction perspective, the user might be a merchant, and the target supplier might be a customer. In this case, assuming the matrix code serves as the mechanism for the original target information, the customer presents the matrix code via a portable / mobile device (e.g., a mobile phone), and the merchant or their POS machine scans the customer's matrix code to obtain the target, i.e., the matrix code string. Alternatively, the user might be a customer, and the target supplier might be a merchant. In this case, assuming the matrix code still serves as the mechanism for the original target information, the merchant presents the matrix code, and the customer's mobile device scans the merchant's matrix code to obtain the matrix code string.

[0035] A target resolution type is an identifier that a target has been resolved into. In one embodiment, it can be an MSN, an MSID, or an MSU, corresponding to a target that can be resolved into MSN, MSID, or MSN plus MSID, respectively. MSN is used when at least one identifier resolved from the target is related to a customer. MSID is used when at least one identifier resolved from the target is related to a merchant. MSU is used when at least one identifier resolved from the target is related to both a customer and a merchant. For example, the use of MSN, MSID, and MSU involves transactions using the customer's original target information, the merchant's original target information, and the store card's original target information, respectively. The store card stores the credit limit given to the customer by the merchant. In one embodiment, after obtaining the target from the original target information, the customer or merchant provides the target resolution type to the local resolution node. Any statement in this invention that "the target is resolved into at least one identifier corresponding to the target resolution type" means that at least one identifier resolved from the target can be identified by the local resolution node performing the target resolution. Regarding the hardware architecture disclosed in this invention, the local resolver node and at least one remote resolver node are part of a plurality of resolver nodes communicatively connected to a cross-node transaction network. The local resolver node service receives the target directly from the user, while none of the other remote resolver nodes receive it.

[0036] The method for parsing the target includes the following steps:

[0037] Step S110: The local resolution node receives the target and target resolution type from the user. Prior to this step, in the preprocessing stage, the user obtains the target and target resolution type, for example, by scanning a matrix code or transmitting an NFC tag. In one embodiment, the target resolution type is predetermined by the system, which may be an application installed on the customer's mobile device or software installed on the merchant's POS machine or server. In this step, the local resolution node receives the target and target resolution type from the user to perform the subsequent first-stage target resolution.

[0038] Step S120: The local resolution node determines whether the target can be resolved to at least one identifier corresponding to the target resolution type. This step is for the first stage of target resolution, attempting to resolve the target to at least one identifier. If the target is resolvable, the at least one identifier is MSN when the target resolution type is MSN, MSID when the target resolution type is MSID, or MSN plus MSID when the target resolution type is MSU. In one embodiment, the MSD identifies a globally unique mobile phone number associated with a globally unique customer; the MSID identifies a globally unique merchant ID associated with a globally unique merchant; and the MSU identifies a globally unique store card associated with a credit limit granted to the customer by the merchant. When the local resolution node determines that the target cannot be resolved without encountering any internal errors during target resolution, step S130 is executed. Otherwise, a notification of successful target resolution is reported, and steps S130 and S140 are not executed.

[0039] Step S130: The local resolver transmits the target resolution type and the target to at least one remote resolver. This step is the transmission phase. The at least one remote resolver can be one or more remote resolver nodes. As mentioned earlier, when the local resolver broadcasts the target resolution type and the target to the remaining or all remote resolver nodes without filtering or randomly, network congestion will occur, thus slowing down the resolution of the target. As suggested earlier, the following will describe the notification service method used to resolve this network congestion problem.

[0040] Step 140: The local resolver determines whether the target is resolvable based on the number of at least one resolvable result returned by the at least one remote resolver. This step is the second phase of target resolution. When each of the at least one remote resolver determines that the target is resolvable, the remote resolver returns a resolvable result to the local resolver. When the remote resolver determines that the target is unresolvable, it does not return a resolvable result. The number of resolvable results returned to the local resolver is a criterion for the local resolver to determine whether the target is resolvable. Through this two-phase target resolution, as long as the target is resolved in either the first or second phase, all parties involved in the transaction based on this instruction will be allowed to proceed with the transaction.

[0041] exist Figure 1 Based on the method shown, Figure 2A and Figure 2BThe method for parsing the target shown is a detailed version of the aforementioned method. The difference lies in that step S110' replaces step S110, steps S121 to S124 are derived from the confirmation result of step S120, and steps S141 to S144 replace step S140. To avoid repetition, only the following descriptions will be provided. Figure 2A and Figure 2B Mid-heel Figure 1 The methods differ and there are additional steps.

[0042] The following steps replace S110' Figure 1 Step S110 in the process.

[0043] Step S110': The local resolution node receives the target, mechanism, and target resolution type from the user. The difference between this step and the original step S110 is that the user additionally transmits the mechanism to the local resolution node for the first stage of target resolution. In one embodiment, the target resolution system is implemented to generate and receive matrix code mechanisms and NFC tag mechanisms, and the user needs to provide this mechanism to the local resolution node.

[0044] like Figure 2A As stated, the next steps S121 to S124 are from Figure 1 The result of the determination in step S120.

[0045] Step S121: When the local parsing node understands the mechanism in step S120 and parses the target as the at least one identifier, the local parsing node confirms that the target is parseable and skips steps S130 and S140 to S144. When the local parsing node understands the mechanism and parses the target as the at least one identifier, this step concludes that the target can be parsed as the at least one identifier and does not require a second-stage target parsing.

[0046] Within the same high-level mechanism, such as matrix code mechanisms and NFC tag mechanisms, each high-level mechanism can further include several low-level mechanisms (data formats). Taking the matrix code mechanism as an example, if the target is a 13-digit matrix code string and the target resolution type is MSN (which can serve as a globally unique mobile phone number), then the low-level mechanisms could be country code (3 digits), area code (3 digits), and local phone number (7 digits). The term "mechanism" can refer to a high-level mechanism, a low-level mechanism, or both, depending on the context. Each resolution node has a preset list containing at least one preset mechanism that the resolution node can understand. Therefore, if the mechanism of the original target information is the same as at least one of the preset mechanisms in the local resolution node's preset list, the mechanism of the original target information will be considered understandable by the local resolution node. In one embodiment, the preset list of the local resolution node may be partially different from or completely different from the preset list of at least one remote resolution node (which is part of such resolution nodes). If the preset list of the at least one remote resolution node is completely identical to that of the local resolution node, the second-stage target resolution is not very helpful.

[0047] Step S122: When the local parsing node encounters any internal error while parsing the target in step S120, the local parsing node determines that the target is unresolvable and skips steps S130 and S140 to S144. Unlike step S121, when the local parsing node receives an internal error while parsing the target, regardless of whether it is due to hardware or software problems, this step concludes that the target cannot be resolved into at least one identifier and that a second-stage target parsing is not required.

[0048] Step S123: If the local parsing node cannot understand the mechanism in step S120, or understands the mechanism but cannot resolve the target into the at least one identifier, the local parsing node will determine that the target is unresolvable. This step aims to determine that the target cannot be resolved in the first stage and prepare for the target resolution in the second stage. Two conditions are required to initiate the second stage of resolution. First, if the mechanism is not in the local parsing node's preset list, the mechanism is considered unknown to the local parsing node. Second, if the mechanism is in the local parsing node's preset list, but the local parsing node cannot find the at least one identifier resolved from the target. When either of these two conditions is met, the target is determined to be unresolvable into the at least one identifier, and the second stage of target resolution should be performed.

[0049] Step S124: When the local resolver node receives a whitelist including some other resolvers capable of resolving the target in step S120 and receives a suggestion from its own hint service in step S120, the local resolver node considers the target unresolvable. While this step determines the target is unresolvable upon receiving the whitelist, it does not skip the remaining steps. This whitelist is a spontaneous response, and not every resolver node provides this hint service to itself or other resolvers every time. Nevertheless, when the whitelist is feasible, the local resolver node only needs to request a portion, not all, of the other resolvers on the whitelist to resolve the target—that is, a finite number of nodes—thereby resolving the fan-out problem.

[0050] like Figure 2B As shown, the following steps S141 to S144 replace Figure 1 Step S140 in the process.

[0051] Step S141: Each of the at least one remote resolution nodes determines whether it understands the mechanism and can resolve the target into at least one identifier corresponding to the target resolution type. This step aims to determine whether each of the at least one remote resolution nodes understands the mechanism and can resolve the target in the second stage of target resolution. A similar description of understanding the mechanism can be found in step S121, and will not be repeated here. When the remote resolution node understands the mechanism and resolves the target into the at least one identifier, step S142 is executed. When any internal error occurs, the remote resolution node does not understand the mechanism, the remote resolution node understands the mechanism but cannot resolve the target into the at least one identifier, or the remote resolution node returns a portion including information from other resolution nodes that can resolve the target and a whitelist prompted by the prompting service of the remote resolution node to the local resolution node, step S143 is executed.

[0052] Step S142: The remote resolution target will send back a token that corresponds to the at least one identifier and indicates that the target can be resolved by the local resolution node. Here, the token refers to the resolvable result in step S140, and in order to hide the at least one identifier from the local resolution node that initiated the target resolution, the token can be encrypted data. Since the token corresponds to the at least one identifier, it can be used to map back to the at least one identifier when using the token for transactions.

[0053] Step S143: The remote resolution node does not return a flag. When the second-stage target resolution detects an internal error, is unable to understand the mechanism, understands the mechanism but cannot resolve the target, or the whitelist exists, the remote resolution node does not return a flag. It is important to note that the whitelist provided by the second-stage target resolution is meaningless for the second-stage target resolution and will be discarded.

[0054] Step S144: When the number of at least one tag received from the at least one remote resolution node is one, the local resolution node confirms that the target is resolvable; or when the number of tags is zero or greater than one, it confirms that the target is unresolvable. This step aims to conclude that the target is resolvable when the number of at least one tag received from the at least one remote resolution node is one. When the number of tags is zero or greater than one, the local resolution node determines that the target cannot be resolved to the at least one identifier.

[0055] according to Figure 3 Step S142 further includes the following steps.

[0056] Step S1421: The remote resolution node confirms the target resolution type. If the target resolution type is MSN or MSU, proceed to step S1422. If the target resolution type is MSID, proceed to step S1423.

[0057] Step S1422: The remote resolver obtains a user ID, which identifies the target provider through a KYC (Know-Your-Customer) query service on the remote resolver or another server connected to the cross-node transaction network. The target provider has an MSN with at least one identifier. Next, the remote resolver replaces the MSN in the at least one identifier with the user ID, generating a tag that corresponds to the at least one identifier, and sends the tag back to the local resolver. Although the target provider may have more than one MSN, the user ID is the unique identifier for the target provider. The primary consideration for sending back the tag, i.e., encrypted information, instead of the MSN, is to keep the user ID confidential from the local resolver, as the local resolver may have no business or service relationship with the remote resolver. Also, the MSN is not a unique identifier compared to the user ID. In the case of an MSN-type target resolver, the tag is used to map back to a corresponding MSN; in the case of an MSU-type target resolver, the tag is used to map back to the corresponding MSN and MSID.

[0058] Step S1423: The remote resolution node generates a tag that corresponds to the at least one identifier and sends the tag back to the local resolution node. When the target resolution type is an MSID, a KYC query service is not required because the MSID itself is a unique identifier. Therefore, the remote resolution node generates a tag that corresponds only to the MSID.

[0059] In addition to providing a whitelist-based notification service, providing a blacklist-based mechanism caching method is another countermeasure to address the fan-out problem. Unlike a whitelist, a blacklist includes at least one mechanism and at least one node among all parsing nodes that is unaware of and cannot be mapped to any mechanism in the blacklist. Each parsing node has its own blacklist, which is updated every Time-to-Live (TTL), which is considered the self-destruct time. The local parsing node in step S123 and the remote parsing nodes that are unaware of the mechanism in step S143 will be recorded in the blacklist of the local parsing node during the next update. In the target information transmission phase of step S130, the notification service method and the mechanism caching method can be used individually or together. When the whitelist exists in the local parsing node and the notification service method is used alone, the local parsing node transmits the mechanism, the target, and the target parsing type to the at least one remote parsing node, which can be mapped to the mechanism in the whitelist. When the mechanism caching method is used alone, the local resolution node transmits the mechanism, the target, and the target resolution type to at least one remote resolution node. Each of these remote resolution nodes is different from at least one node in the blacklist corresponding to this mechanism. When the prompt service method and the mechanism caching method are used together, the local resolution node transmits the mechanism, the target, and the target resolution type to the at least one remote resolution node. Each of these remote resolution nodes is one of several resolution nodes in the whitelist corresponding to this mechanism and is different from at least one node in the blacklist corresponding to this mechanism. Regarding the transmission method, the local resolution node can transmit the mechanism, the target, and the original target information to at least one remote resolution node simultaneously or sequentially. Generally, whitelists and blacklists can be generated based on at least one factor: merchant location and customer location.

[0060] Figure 1 The method shown in Figure 2 includes the following steps, such as Figure 4 As shown, this step is used to generate and obtain the original target information.

[0061] Step S410: The user requests the target information sending service of the resolution node to obtain the original target information and the target resolution type. The resolution node is then authorized to send the original target information to the user. This target information sending service is provided by a backend server, which shares the same address as the resolution node that acts as the payment service provider.

[0062] Step S420: The parsing node that has the target information sending service generates a target token and transmits the token to one of the parsing nodes. The target token is encrypted information.

[0063] Step S430: The parsing node receives the target tag, maps the tag to at least one identifier related to the target parsing type, and records the target tag in the parsing node's corresponding list. This step aims to establish the mapping relationship between the target tag and the user-related identifier. When the original target information is used for target parsing, the target tag can be used to map back to the at least one identifier.

[0064] Step S440: After receiving confirmation from the parsing node that the target tag has been added to the corresponding list, the parsing node generates the original target information containing the target tag and transmits the original target information to the user. The target tag is encrypted information contained in the original target information, and the target tag can be obtained by retrieving and decoding the content of the original target information.

[0065] According to Figure 5, the following steps employ a program that uses target resolution technology to resolve the target provider's target as MSN before a payment transaction is made between the user (the merchant's POS machine) and the target provider (the customer's mobile device).

[0066] Step S510: A mechanism by which the user receives the original target information from the target provider and can selectively parse the original target information to obtain the original target information.

[0067] Step S520: The user sends the price information, including amount, currency, original target information, optional mechanism, and optional invoice ID, to the user's backend server.

[0068] Step S530: After the user receives the original target information, the user's backend server will do three things: first, parse the original target information and determine the mechanism if the mechanism is not provided to the user in step S510; second, selectively generate the invoice ID if the user does not provide the invoice ID in step S520; and third, determine the price information if the user does not provide the price information in step S520.

[0069] Step S540: The user's backend server sends the mechanism, target, amount, currency, optional invoice ID, user's MSID, and user information (e.g., merchant name, address, etc.) to the host node to request a payment operation. This host node is communicatively connected to the cross-node transaction network and is able to execute cross-node transactions for the user and the target supplier. The user and the target supplier are also communicatively connected to the cross-node transaction network.

[0070] Step S550: The host node checks whether the local resolver connected to the cross-node transaction network has successfully resolved the target into an MSN containing the target and the mechanism. If the local resolver cannot resolve the target, proceed to step S560. Otherwise, proceed to step S580.

[0071] Step S560: The host node broadcasts the target and the mechanism to at least one remote node connected to the cross-node transaction network, and checks whether the at least one remote resolving node can resolve the target into an MSN with the target and the mechanism. If the at least one remote node cannot resolve the target, proceed to step S570. Otherwise, proceed to step S580.

[0072] Step S570: The host node confirms that the transaction was not completed and reports an error in the payment request of step S540.

[0073] Step S580: The host node notifies the user that the payment request has been successfully sent and responds to the user's backend server request. Simultaneously, the remote resolution node notifies the target provider's backend server of the payment request, which includes the amount, currency, user information (if provided by the user's backend server in step S540), invoice ID (if provided by the user's backend server in step S540), and the resolved user ID.

[0074] Step S590: The target provider's backend server sends a notification to the target provider, requesting permission for the payment request required for the transaction.

[0075] As can be seen from the above, the method for achieving this analytical goal is backed by a system. (Refer to...) Figure 6 and Figure 7 The system for resolving target 70 includes: a cross-node transaction network 71, a user device 72, and several resolving nodes 73. Before proceeding with a detailed description of this system, it is important to note that this system uses all the definitions, concepts, and embodiments of terms used in the above-described methods.

[0076] In one embodiment, the cross-user transaction network 71 is implemented using distributed ledger technology. The user's device 72 obtains the original target information, mechanism, and target resolution type from a target provider (not shown in the figure). In one embodiment, the mechanism and target resolution type may be system-preset, thus the target provider does not need to provide this information. When the owner is a customer, the user device 72 may be a mobile device, including but not limited to a mobile phone, tablet, or laptop. When the owner is a merchant, the user device 72 may be a POS machine. The resolution nodes 73 are communicatively connected to the cross-node transaction network 71 and include a local resolution node 73a and at least one remote resolution node 73b, 73c, and 73d, all of which are part of the resolution nodes 73. Figure 6 and Figure 7 These are embodiments of a single remote resolution node 73b and several remote resolution nodes 73b, 73c, and 73d. In one embodiment, each of these resolution nodes 73 is a node operated by a telecommunications operator, and these nodes can manage transactions of digital assets (such as digital currencies, digital securities, digital bonds, digital futures, and digital precious metal currencies). The local resolution node 73 is communicatively connected to the user device 72 and the user's transaction service provider, while the at least one remote resolution node 73b, 73c, and 73d does not communicate directly with the user device 72 (not its own communication service provider). The local resolution node 73a receives the target, mechanism (optional), and target resolution type from the user device 72, determines whether the target can be resolved to at least one identifier corresponding to the target resolution type, and then, if no internal error occurs and the target cannot be resolved, transmits the target resolution type and the target to the at least one remote resolution node 73b, 73c, 73d, and determines whether the target can be resolved based on the number of at least one resolvable result returned by the at least one remote resolution node 73b, 73c, 73d.

[0077] Because this suggestion service method involves a whitelist, when the local resolver 73a receives the whitelist, it transmits the target resolution type, the mechanism, and the target to at least one remote resolver 73b, 73c, and 73d. The whitelist contains a portion of these resolver nodes 73b, and each node in that portion can resolve the target. This whitelist is suggested by the local resolver's suggestion service. On the other hand, the mechanism caching method involves a blacklist. The local resolver 73a stores a blacklist that maps the mechanism to the parts of the resolver nodes that are unaware of the mechanism, and this blacklist is updated every Time-to-Live (TTL). Only when the blacklist is active does the local resolver 73a transmit the target, the mechanism, and the target resolution type to the at least one remote resolver 73b, 73c, and 73d. Each of these remote resolver nodes will be different from at least one of the resolver nodes retrieved from the blacklist using this mechanism. When only the whitelist is active, the local resolution node 73a transmits the target, the mechanism, and the target resolution type to at least one remote resolution node 73b, 73c, or 73d. Each of these at least one remote resolution node is one of the resolution nodes retrieved from the whitelist using this mechanism. When both the whitelist and blacklist are active, the local resolution node 73a transmits the target, the mechanism, and the target resolution type to at least one remote resolution node 73b, 73c, or 73d. Each of these at least one remote resolution node is one of the resolution nodes 73 in the whitelist and is different from at least one of the resolution nodes 73 retrieved from the blacklist using this mechanism. Besides the mechanism caching method and the notification service method, the transmission method by which the local resolution node 73a transmits the target, the mechanism, and the target resolution type to the at least one remote resolution node 73b, 73c, or 73d can be determined based on the traffic conditions of system 70, and can be executed sequentially or simultaneously.

[0078] The system 70 further includes a target sending node 73e, which is one of the resolving nodes and is authorized to send the original target information to the user device 72. This target sending node is communicatively connected to the cross-node transaction network 71. The resolving node may co-locate with a backend server operated by the payment service provider and sending the original target information. To obtain the original target information, the user device 72 first requests the original target information and the target resolution type from the target sending node 73e. Upon receiving the request and the target resolution type, the target sending node 73e generates a target tag and transmits the target tag to one of the other resolving nodes 73. The other resolving node 73 receives the target tag, maps it to at least one identifier corresponding to the target resolution type, and adds the target tag to its corresponding list. After receiving confirmation that the target tag has been added to the corresponding list of the other resolving node 73, the target sending node 73e generates original target information containing the target tag and transmits the original target information to the user device 72. When the target resolution type is either MSN or MSU, the remote resolution nodes 73b, 73c, and 73d perform the following steps: First, obtain the user ID through the remote node's KYC query system or an external KYC query system. This user ID identifies the target provider through the MSN in at least one identifier. Second, replace the MSN in the at least one identifier with the user ID. Third, generate a tag that corresponds to the at least one identifier. Finally, return the tag to the local resolution node 73a. When the target resolution type is MSID, the remote resolution nodes 73b, 73c, and 73d generate a tag that corresponds to the at least one identifier and return the tag to the local resolution node 73a.

[0079] While the foregoing has described many technical features and advantages of the present invention, the disclosed functions and detailed structures are illustrative only. Without departing from the spirit of the invention, the scope of the claims is broadly interpreted to cover any modifications to the shape, size, and component configuration of the invention based on the teachings of this specification.

Claims

1. A method for parsing a target, the method comprising: (a) The local resolution node receives the target and target resolution type from the user with whom it has a direct communication connection, wherein the user is a customer or merchant involved in the transaction and selects to specify the target resolution type as an identifier associated with at least one of the customer and the merchant involved in the transaction, and the target is information used to pay the transaction and can be resolved to be related to the target resolution type; (b) The local parsing node determines whether the target can be resolved to at least one identifier corresponding to the target's parsing type; (c) When the target is unresolvable, the local resolver transmits the target resolution type and the target to at least one remote resolver, wherein the local resolver and the at least one remote resolver are part of a plurality of resolvers that are communicatively connected to a cross-node transaction network; and (d) The local resolver determines whether the target is resolvable based on the number of at least one resolvable results returned from the at least one remote resolver, wherein the target is identified as unresolvable when the number is greater than one.

2. The method according to claim 1, wherein in step (a), the local parsing node further receives a mechanism for original target information, wherein the original target information is source information for extracting the target, the mechanism is a proprietary data format for generating the original target information, the original target information and the mechanism are provided to the user by a target provider connected to the user, and the user parses the target according to the characteristics of the original target information and conveys the mechanism, the target and the target parsing type to the local parsing node.

3. The method of claim 2, wherein the user is a merchant and the target provider is a customer, or the user is a customer and the target provider is a merchant.

4. The method according to claim 2, wherein the mechanism is one of a matrix code mechanism, a near-field wireless communication mechanism, a voice mechanism, and a fingerprint mechanism.

5. The method of claim 2, wherein the user obtains the target from the target provider by scanning a matrix code from the original target information, sensing an NFC tag, extracting a voice signature, or scanning a fingerprint.

6. The method according to claim 1, wherein the target resolution type is one of the following: Mobile User Number (MSN), Merchant Service Unique Identifier (MSID), and Mobile User Number and Merchant Service Unique Identifier (MSU).

7. The method of claim 6, wherein when the target resolution type is the MSN, the MSID, or the MSU type, the local resolution target resolves the target to include at least one identifier comprising the MSN, the MSID, or the MSN and the MSID, the at least one identifier corresponding to the target resolution type being the MSN, the MSID, or the MSU type.

8. The method of claim 2, wherein step (b) further comprises: (b1) When the local parsing node understands the mechanism and resolves the target into at least one identifier, the local parsing node confirms that the target is resolvable and skips steps (c) and (d); (b2) If there is any internal error when resolving the target, the local resolver node determines that the target is unresolvable and skips steps (c) and (d); (b3) When the local resolution target is unaware of the mechanism or is unaware of the mechanism but cannot resolve the target to the at least one identifier, the local resolution target determines that the target is unresolvable; and (b4) Upon receiving a whitelist that includes a subset of several parsing nodes capable of resolving the target and a suggestion service provided by the local parsing node, the local parsing node confirms that the target is unresolvable, wherein the whitelist is a spontaneous response from each of the several parsing nodes and the suggestion service is provided by each of the several parsing nodes.

9. The method of claim 8, wherein step (d) further comprises: (d1) Each of the at least one remote resolution node confirms whether the remote resolution node is aware of the mechanism and can resolve the target to at least one identifier corresponding to the target resolution type; (d2) When the remote parsing node understands the mechanism and parses the target as the at least one identifier, the remote parsing node returns a tag that corresponds to the at least one identifier and indicates that the target can be parsed by the local parsing node, wherein the tag is the parsable result; (d3) When an internal error occurs, the remote parser node is unaware of the mechanism, the remote parser node is unaware of the mechanism but is unable to parse the target, or the remote parser node returns the part of the plurality of parser nodes that can parse the target and the whitelist suggested by the prompting service of the local parser node, the remote parser node will not return the tag. as well as (d4) When the number of the at least one tag returned from the at least one remote resolution node is one, the local resolution node confirms that the target is resolvable; when the number is zero, the local resolution node considers the target to be unresolvable.

10. The method of claim 9, wherein the local parsing node stores a blacklist that is updated every time it has a lifespan, and the blacklist records at least one of the plurality of parsing nodes that are unaware of the mechanism.

11. The method of claim 10, wherein in steps (b3) and (d3), the local resolution node and the at least one remote resolution node that is unaware of the mechanism are recorded in the blacklist and associated with the mechanism during the next blacklist update.

12. The method of claim 10, wherein in step (c), the local parsing node transmits the target parsing type and the target to the at least one remote parsing node, each of the at least one remote parsing node being different from the plurality of parsing nodes retrieved from the blacklist using the mechanism.

13. The method of claim 10, wherein in step (c), the local parsing node transmits the target parsing type, the mechanism, and the target to the at least one remote parsing node, each of the at least one remote parsing node being identical to one of the plurality of parsing nodes in the whitelist and different from at least one of the plurality of parsing nodes retrieved from the blacklist using the mechanism.

14. The method of claim 13, wherein the whitelist and the blacklist are generated based on one of the factors of merchant location and customer location.

15. The method of claim 2, wherein in step (c), the local resolver simultaneously or sequentially transmits the target resolver type, the mechanism, and the target to the at least one remote resolver.

16. The method of claim 9, wherein step (d2) further comprises: The remote resolution node determines the target resolution type; When the target resolution type is either MSN or MSU (Mobile User Number and Merchant Service Unique Identifier), the remote resolution node obtains the user ID through its own KYC query system or an external KYC query system. The user ID identifies the target provider through the MSN in the at least one identifier. Then, the MSN in the at least one identifier is replaced with the user ID. Next, a tag that can be mapped to the at least one identifier is generated, and finally, the tag is sent back to the local resolution node. as well as When the target resolution type is Merchant Service Universal Unique Identifier (MSID), the remote resolution node generates a tag that corresponds to at least one identifier and sends the tag back to the local resolution node.

17. The method of claim 9, further comprising: The user requests the original target information containing the target parsing type from the target sending node, which is one of the several parsing nodes and is authorized to send the original target information to the user; The target sending node generates a target marker and transmits the target marker to one of the plurality of parsing nodes, wherein the target marker is encrypted data; When a parsing node receives a target tag, it maps the target tag to at least one identifier that corresponds to the target parsing type and adds the target tag to the corresponding list of the parsing node. as well as After receiving confirmation that the target tag has been added to the corresponding list of the parsing node, the target sending node generates the original target information containing the target tag and transmits the original target information to the user.

18. The method of claim 1, wherein the local resolver node is bound to the user service and the at least one remote resolver node is not bound to the user service.

19. The method of claim 1, wherein the cross-node transaction network is a distributed ledger capable of cross-node transactions and each of the plurality of parsing nodes is a node communicatively connected to the cross-node transaction network and operated by a telecommunications operator capable of managing digital property transactions.

20. A system for analyzing a target, the system comprising: Cross-node transaction network; User equipment; as well as Several parsing nodes are communicatively connected to the cross-node transaction network, and a portion of these parsing nodes include: At least one remote resolution node; as well as A local resolution node, which is directly connected to the user device, receives a target and a target resolution type from the user device, determines whether the target can be resolved to at least one identifier corresponding to the target resolution type, and when the target is unresolvable, transmits the target resolution type and the target to the at least one remote resolution node. It also determines whether the target is resolvable based on the number of at least one resolvable results returned from the at least one remote resolution node, wherein the user device is a device of a customer or merchant involved in a transaction and selects to specify the target resolution type as being associated with at least one customer or merchant involved in the transaction, the target is information used to pay the transaction and can be resolved to be related to the target resolution type, and when the number is greater than one, the target is determined to be unresolvable.

21. The system according to claim 20, wherein the original target information and the mechanism of the original target information are provided by a target providing device communicatively connected to the user device, and the user device parses the target according to the characteristics of the original target information and transmits the mechanism, the target, and the target parsing type to the local parsing node, wherein the original target information is the source information for extracting the target, and the mechanism is a proprietary data format for generating the original target information, which can be classified into the following mechanisms: matrix code mechanism, short-range wireless communication mechanism, voice mechanism, and fingerprint mechanism.

22. The system of claim 21, wherein the user device obtains the target from the target provider by scanning a matrix code from the original target information, sensing a proximity wireless communication tag, extracting a voice signature from a voice, or scanning a fingerprint.

23. The system of claim 21, wherein the target resolution type is one of Mobile User Number (MSN), Merchant Service Unique Identifier (MSID), and Mobile User Number and Merchant Service Unique Identifier (MSU).

24. The system of claim 23, wherein when the target resolution type is one of the MSN, the MSID, or the MSU, the local resolution node resolves the target to the at least one identifier, and corresponding to the target resolution type being the MSN, the MSID, or the MSU, the at least one identifier includes the MSN, the MSID, or the MSN plus the MSID.

25. The system of claim 21, wherein upon receiving a whitelist suggested by a prompting service from a subset of the plurality of parsing nodes capable of parsing the target, the local parsing node transmits the target parsing type, the mechanism, and the target to at least one remote parsing node, each of the at least one remote parsing node being identical to one of the subsets of the plurality of parsing nodes in the whitelist, wherein the whitelist is a spontaneous response from each of the plurality of parsing nodes and the prompting service is provided by each of the plurality of parsing nodes.

26. The system of claim 21, wherein when each of the at least one remote resolution node understands the mechanism and resolves the target as the at least one identifier, the remote resolution node returns a tag that corresponds to the at least one identifier and indicates that the target can be resolved by the local resolution node; when the number of the at least one tag returned from the at least one remote resolution node is one, the local resolution node confirms that the target is resolvable; when the number is zero, the local resolution node considers the target unresolvable, wherein the tag is the result of being resolvable.

27. The system of claim 25, wherein the local parsing node stores a blacklist that maps the mechanism to a portion of at least one of the plurality of parsing nodes that does not understand the mechanism, and the blacklist is updated once every time its lifetime expires.

28. The system of claim 27, wherein the local resolution node and the at least one remote resolution node that is unaware of the mechanism are recorded in the blacklist during the next blacklist update, and can be mapped to the mechanism and retrieved through the mechanism.

29. The system of claim 27, wherein the local parsing node transmits the target parsing type and the target to at least one remote parsing node, each of the at least one remote parsing node being different from at least one of the plurality of parsing nodes retrieved from a blacklist using the mechanism.

30. The system of claim 27, wherein the local parsing node transmits the target parsing type, the mechanism, and the target to the at least one remote parsing node, each of the at least one remote parsing node being identical to one of the plurality of parsing nodes in the whitelist and different from at least one of the plurality of parsing nodes retrieved from the blacklist using the mechanism.

31. The system of claim 27, wherein the whitelist and the blacklist are generated based on one of the factors of merchant location and customer location.

32. The system of claim 21, wherein the local parsing node transmits the target parsing type, the mechanism, and the target to the at least one remote parsing node simultaneously or sequentially.

33. The system of claim 26, wherein when the target resolution type is a Mobile User Number (MSN) or a Mobile User Number and Merchant Service Unique Identifier (MSU), the remote resolution node obtains the user ID through its own KYC query system or an external KYC query system. The user ID identifies the target provider using the Mobile User Number (MSN) of the at least one identifier. Then, the MSN in the at least one identifier is replaced with the user ID. Next, a tag corresponding to the at least one identifier is generated, and finally, the tag is sent back to the local resolution node; and When the target resolution type is Merchant Service Universal Unique Identifier (MSID), the remote resolution node generates a tag that corresponds to the at least one identifier and sends the tag back to the local resolution node.

34. The system of claim 21, wherein the plurality of parsing nodes further includes a target sending node, which is communicatively connected to the cross-node transaction network and authorized to send the original target information to the user device, wherein After receiving a request from the user device regarding the original target information and the target parsing type, the target sending node generates a target tag and transmits the target tag to one of the plurality of parsing nodes. The parsing node then adds the target tag, which corresponds to at least one identifier of the target parsing type, to its corresponding list. After receiving confirmation from the parsing node that the target tag has been added to the corresponding list, the target sending node generates the original target information containing the target tag and transmits the original target information to the user device. The target tag is encrypted data.

35. The system of claim 20, wherein the local resolution node is bound to the user device and the at least one remote resolution node is not bound to the user device.

36. The system of claim 20, wherein the cross-node transaction network is a distributed ledger network capable of cross-node transactions, and each of the plurality of resolution nodes is a node communicatively connected to the cross-node transaction network and operated by a telecommunications operator that can manage digital property transactions.

Images