DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the communications filed on 09/02/2025.
Claims 1, 2, and 8-11 have been amended and are hereby entered.
Claim 3 has been canceled.
Claims 1-2, 4, and 7-11 are currently pending and have been examined.
This action is made Final.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for future claim amendments to avoid U.S.C 112(a) issues that can arise. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-2, 4, and 7-11 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea of processing user registration, transactional, and transaction approval information without significantly more.
Claim 1 is directed to a system, which is one of the statutory categories of invention; Claim 10 is directed to a device, which is one of the statutory categories of invention; and Claim 11 is directed to a method, which is one of the statutory categories of invention. (Step 1: YES).
Claim 1 is directed to a system, comprising: a memory; a terminal associated with a user; a server configured to: provide an application associated with a specific service to the terminal of the user, wherein the terminal is configured to execute the application; receive, based on the execution of the application, first registration information from the terminal, wherein the first registration information is associated with the user; and control the memory to record the first registration information; and a processor executable on a first node of a plurality of nodes of a public blockchain, wherein the processor is configured to: access a memory area of the first node to determine first transaction data is recorded in the public blockchain, wherein the first transaction data includes: first identification information that includes an application identifier that identifies the specific service, and second registration information, and the public blockchain is a network that executes a smart contract; and receive an inquiry from the server to identify unapproved transaction data stored in the memory area, wherein the inquiry is received subsequent to the determination that the first transaction data is recorded in the public blockchain; access, based on the received inquiry, the memory area of the first node to identify the unapproved transaction data; identify the first transaction data as the unapproved transaction data; transmit the first transaction data to the server based on the identification of the first transaction data as the unapproved transaction data, wherein the server is further configured to: receive the first transaction data; specify, based on the received first transaction data, the first registration information in the memory; determine the second registration information matches the specified first registration information; call the smart contract from a second node of the plurality of nodes based on the determination that the second registration information matches the specified first registration information; and input, to the smart contract called from the second node, approval information for approval of the first transaction data, wherein the smart contract records second transaction data in the public blockchain based on the input of the approval information to the smart contract. These series of steps describe the abstract idea of processing user registration, transactional, and transaction approval information (with the exception of the italicized and bolded terms above), which is mitigating risk of incorrectly identifying, approving, and recording transaction data into a public blockchain; therefore, corresponding to a fundamental economic principle or practice (including mitigating risk). Hence, a fundamental economic principle or practice (mitigating risk) is a Certain Methods of Organizing Human Activity. The abstract idea is also the processing and approving transactional data to be inputted into contract, which is a commercial interaction. Therefore, a commercial interaction is also a Certain Methods of Organizing Human Activity. The system limitations, e.g., a memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract, do not necessarily restrict the claim from reciting an abstract idea. Thus, claim 1 recites an abstract idea (Step 2A-Prong 1: YES).
This judicial exception is not integrated into a practical application because the additional elements of a memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract, are no more than simply applying the abstract idea using generic computer elements. The additional elements listed above are all recited at a high level of generality and under their broadest reasonable interpretation comprises a generic computing arrangement. Specifically, the additional elements, a memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract, are all recited at a high level of generality and under their broadest reasonable interpretation comprises a generic computing arrangement. Merely invoking a memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract is similar to invoking software and software components. The presence of a generic computer arrangement is nothing more than to implement the claimed invention (MPEP 2106.05(f)). The computer network limitations are a field of use limitations (MPEP 2106.05(h)). Therefore, the recitations of additional elements do not meaningfully apply the abstract idea and hence do not integrate the abstract idea into a practical application. Thus, claim 1 does not integrate the abstract idea into a practical application (Step 2A-Prong 2: NO).
Claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements of a memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract, limitations are recited at a high level of generality in that it results in no more than simply applying the abstract idea using generic computer elements. The computer network limitations are a field of use limitations (MPEP 2106.05(h)). The additional elements when considered separately and as an ordered combination do not amount to add significantly more as these limitations provide nothing more than to simply apply the exception in a generic computer environment (Step 2B: NO). Thus, claim 1 is not patent eligible.
Dependent claims 2-4 and 7-9 are directed to a system that performs steps that describe the abstract idea of processing user registration, transactional, and transaction approval information, which is mitigating risk of incorrectly identifying, approving, and recording transaction data into a public blockchain; therefore, corresponding to a fundamental economic principle or practice (including mitigating risk). Hence, a fundamental economic principle or practice (mitigating risk) is a Certain Methods of Organizing Human Activity. The abstract idea is also the processing and approving transactional data to be inputted into contract, which is a commercial interaction. Therefore, a commercial interaction is also a Certain Methods of Organizing Human Activity. Thus, claims 2-4 and 7-9 recite an abstract idea. The additional elements of a memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract are no more than simply applying the abstract idea using generic computer elements. Specifically, the additional elements, a memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract, are all recited at a high level of generality and under their broadest reasonable interpretation comprises a generic computing arrangement. Merely invoking a memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract is similar to invoking software and software components. The presence of a generic computer arrangement is nothing more than to implement the claimed invention (MPEP 2106.05(f)). The computer network limitations are a field of use limitations (MPEP 2106.05(h)). Therefore, the recitations of additional elements do not meaningfully apply the abstract idea and hence do not integrate the abstract idea into a practical application. Furthermore, the additional elements: aa memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract, do not amount to add significantly more as these limitations provide nothing more than to simply apply the exception in a generic computer environment.
Claim 10 is directed to a device comprising: a memory; and a processor executable on a first node of a plurality of nodes of a public blockchain, wherein the processor is configured to: provide an application associated with a specific service to a terminal of a user; receive, based on execution of the application on the terminal, first registration information from the terminal, wherein the first registration information is associated with the user; control the memory to record the first registration information; control access to a memory area of the first node to determine first transaction data is recorded in the public blockchain, wherein the first transaction data includes: first identification information that includes an application identifier that identifies the specific service, and second registration information, and the public blockchain is a network that executes a smart contract; access, subsequent to the determination that the first transaction data is recorded in the public blockchain, the memory area of the first node to identify unapproved transaction data stored in the memory area; identify the first transaction data as the unapproved transaction data; specify the first registration information in the memory based on the identification of the first transaction data as the unapproved transaction data; determine the second registration information matches the specified first registration information; call the smart contract from a second node of the plurality of nodes based on the determination that the second registration information matches the specified first registration information; and input, to the smart contract called from the second node, approval information for approval of the first transaction data, wherein the smart contract records second transaction data in the public blockchain based on the input of the approval information to the smart contract. These series of steps describe the abstract idea of processing user registration, transactional, and transaction approval information (with the exception of the italicized and bolded terms above), which is mitigating risk of incorrectly identifying, approving, and recording transaction data into a public blockchain; therefore, corresponding to a fundamental economic principle or practice (including mitigating risk). Hence, a fundamental economic principle or practice (mitigating risk) is a Certain Methods of Organizing Human Activity. The abstract idea is also the processing and approving transactional data to be inputted into contract, which is a commercial interaction. Therefore, a commercial interaction is also a Certain Methods of Organizing Human Activity. The system limitations, e.g., a memory, processor, first node, second node, plurality of nodes, public blockchain, application, terminal, memory area, network, and smart contract, do not necessarily restrict the claim from reciting an abstract idea. Thus, claim 10 recites an abstract idea (Step 2A-Prong 1: YES).
This judicial exception is not integrated into a practical application because the additional elements of a memory, processor, first node, second node, plurality of nodes, public blockchain, application, terminal, memory area, network, and smart contract, are no more than simply applying the abstract idea using generic computer elements. The additional elements listed above are all recited at a high level of generality and under their broadest reasonable interpretation comprises a generic computing arrangement. Specifically, the additional elements, a memory, processor, first node, second node, plurality of nodes, public blockchain, application, terminal, memory area, network, and smart contract, are all recited at a high level of generality and under their broadest reasonable interpretation comprises a generic computing arrangement. Merely invoking a memory, processor, first node, second node, plurality of nodes, public blockchain, application, terminal, memory area, network, and smart contract is similar to invoking software and software components. The presence of a generic computer arrangement is nothing more than to implement the claimed invention (MPEP 2106.05(f)). The computer network limitations are a field of use limitations (MPEP 2106.05(h)). Therefore, the recitations of additional elements do not meaningfully apply the abstract idea and hence do not integrate the abstract idea into a practical application. Thus, claim 10 does not integrate the abstract idea into a practical application (Step 2A-Prong 2: NO).
Claim 10 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements of a memory, processor, first node, second node, plurality of nodes, public blockchain, application, terminal, memory area, network, and smart contract are recited at a high level of generality in that it results in no more than simply applying the abstract idea using generic computer elements. The computer network limitations are a field of use limitations (MPEP 2106.05(h)). The additional elements when considered separately and as an ordered combination do not amount to add significantly more as these limitations provide nothing more than to simply apply the exception in a generic computer environment (Step 2B: NO). Thus, claim 10 is not patent eligible.
Claim 11 is directed to a method, which recites a series of steps, e.g., in a service providing system that includes a server, a memory, a terminal associated with a user, and a processor: providing, by the server, an application associated with a specific service to the terminal of the user; and receiving, by the server, based on execution of the application, first registration information from the terminal, wherein the first registration information is associated with the user; controlling, by the server, the memory to record the first registration information; controlling execution of the processor on a first node of a plurality of nodes of a public blockchain; accessing, by the processor, a memory area of the first node to determine first transaction data is recorded in the public blockchain, wherein the first transaction data includes: first identification information that includes an application identifier that identifies the specific service, and second registration information, and the public blockchain is a network that executes a smart contract; receiving an inquiry from the server to identify unapproved transaction data stored in the memory area, wherein the inquiry is received subsequent to the determination that the first transaction data is recorded in the public blockchain; accessing, based on the received inquiry, the memory area of the first node to identify the unapproved transaction data; identifying the first transaction data as the unapproved transaction data; transmitting, by the processor, the first transaction data to the server based on the identification of the first transaction data as the unapproved transaction data; receiving, by the server, the first transaction data; specifying, by the server, the first registration information in the memory based on the received first transaction data; determining, by the server, the second registration information matches the specified first registration information; calling, by the server, the smart contract from a second node of the plurality of nodes based on the determination that the second registration information matches the specified first registration information; and inputting, by the server, to the smart contract called from the second node, approval information for approval of the first transaction data, wherein the smart contract records second transaction data in the public blockchain based on the input of the approval information to the smart contract. These series of steps describe the abstract idea of processing user registration, transactional, and transaction approval information (with the exception of the italicized and bolded terms above), which is mitigating risk of incorrectly identifying, approving, and recording transaction data into a public blockchain; therefore, corresponding to a fundamental economic principle or practice (including mitigating risk). Hence, a fundamental economic principle or practice (mitigating risk) is a Certain Methods of Organizing Human Activity. The abstract idea is also the processing and approving transactional data to be inputted into contract, which is a commercial interaction. Therefore, a commercial interaction is also a Certain Methods of Organizing Human Activity. The system limitations, e.g., a service providing system, memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract, do not necessarily restrict the claim from reciting an abstract idea. Thus, claim 11 recites an abstract idea (Step 2A-Prong 1: YES).
This judicial exception is not integrated into a practical application because the additional elements of a service providing system, memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract, are no more than simply applying the abstract idea using generic computer elements. The additional elements listed above are all recited at a high level of generality and under their broadest reasonable interpretation comprises a generic computing arrangement. Specifically, the additional elements, a service providing system, memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract, are all recited at a high level of generality and under their broadest reasonable interpretation comprises a generic computing arrangement. Merely invoking a service providing system, memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract is similar to invoking software and software components. The presence of a generic computer arrangement is nothing more than to implement the claimed invention (MPEP 2106.05(f)). The computer network limitations are a field of use limitations (MPEP 2106.05(h)). Therefore, the recitations of additional elements do not meaningfully apply the abstract idea and hence do not integrate the abstract idea into a practical application. Thus, claim 11 does not integrate the abstract idea into a practical application (Step 2A-Prong 2: NO).
Claim 11 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements of a service providing system, memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract, limitations are recited at a high level of generality in that it results in no more than simply applying the abstract idea using generic computer elements. The computer network limitations are a field of use limitations (MPEP 2106.05(h)). The additional elements when considered separately and as an ordered combination do not amount to add significantly more as these limitations provide nothing more than to simply apply the exception in a generic computer environment (Step 2B: NO). Thus, claim 11 is not patent eligible.
Dependent claims 2, 4, and 7-9 have further defined the abstract idea that is present in their respective independent claim: Claim 1, and thus correspond to Certain Methods of Organizing Human Activity, and hence are abstract in nature for the reason presented above. The dependent claims 2, 4, and 7-9 do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Therefore, claims 2, 4, and 7-9 are directed to an abstract idea without significantly more.
Thus, claims 1-2, 4, and 7-11 are not patent-eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4, and 7-11 are rejected under 35 U.S.C. 103 as being unpatentable over Balaraman (U.S. Patent Application Publication No. US 2019/0303942 A1; hereinafter “Balaraman”), in view of Arora (U.S. Patent Publication No. US 2020/0097924 A1; hereinafter “Arora”).
Regarding Claims 1 and 11:
Balaraman teaches:
An information processing system, comprising: a memory; a terminal associated with a user; [a server] configured to: (Balaraman, See, Para. 19, 20, 22-23, 50, 76; Abstract);
An information processing method, comprising: (Balaraman, See, Para. 19, 20, 22-23, 50, 76; Abstract);
provide an application associated with a specific service to the terminal of the user, wherein the terminal is configured to execute the application; (Balaraman, The system may also include applications deployed on user devices such as, for example, computers, tablets, smartphones, Internet of Things devices (“IoT” devices), etc. The applications may communicate with the blockchain (e.g., directly or via a blockchain node) to transmit and retrieve data. In various embodiments, a governing organization or consortium may control access to data stored on the blockchain. Registration with the managing organization(s) may enable participation in the blockchain network. (See, Para.19-20, 35; Abstract));
receive, based on the execution of the application, first registration information from the terminal, wherein the first registration information is associated with the user; and (Balaraman, User terminal 220 may transmit the registration request comprising identifying information (e.g., a merchant ID, existing login credentials, driver's license, etc.) and the public blockchain address to participant registration portal 260. ….. authenticate the registration request based the identifying information. For example, in response to the identifying information comprising a merchant ID (or similar merchant identifying information) (See, Para.19-20, 34-35, 40-42, 48-50; Abstract));
control the memory to record the first registration information; and (Balaraman, Blockchain wallet 225 may serve as a blockchain interface accessible by users and applications installed on user terminal 220. For example, blockchain wallet 225 may be configured to register user terminal 220 with the blockchain, request public key (e.g., blockchain address) and private key pairs from blockchain network 101, and/or otherwise access and interact with blockchain account information. (See, Para.19-20, 34-35, 40-42; Abstract); Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses (e.g., for fraud management access rights) (See, Para. 48-50, 60-61); Blockchain network 101 may comprise a fraud reporting smart contract 202. Fraud reporting smart contract 202 may be configured to control the end-to-end flow of fraud management, including fraud inquiries and fraud reporting. Fraud reporting smart contract 202 may be an executable that writes data to the blockchain, queries the blockchain in a predetermined format, and/or controls the application flow based on predetermined function parameters passed by an API call, or the like. (See, Para. 30, 107));
a processor executable on a first node of a plurality of nodes of a public blockchain, wherein the processor is configured to: access a memory area of the first node to determine first transaction data is recorded in the public blockchain, (Balaraman, Blockchain network 101 may comprise various blockchain nodes (e.g., consensus participants) in electronic communication with each other, as discussed further herein. Each blockchain node may comprise a computing device configured to write blocks to the blockchain and validate blocks of the blockchain. (See, Para. 22-24, 26, 29, 33-35, 39-45); Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register…public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses (e.g., for fraud management access rights). (See, Para. 47-50, 60-65));
wherein the first transaction data includes: first identification information that includes an application identifier that identifies the specific service, and second registration information, and the public blockchain is a network that executes a smart contract; and (Balaraman, User terminal 220 may transmit the registration request comprising identifying information (e.g., a merchant ID, existing login credentials, driver's license, etc.)…the public blockchain address to participant registration portal 260……in response to the identifying information comprising a merchant ID (or similar merchant identifying information)…. In that respect, in response to the merchant ID matching a stored merchant ID, the registration request may be authenticated. (See, Para. 40-55, 60-65); Blockchain network 101 may comprise a fraud reporting smart contract 202. …. Fraud reporting smart contract 202 may be an executable that writes data to the blockchain …. Fraud reporting smart contract 202 may also perform these functions based on the current value of parameters stored in the blockchain and the identity of the caller of fraud reporting smart contract 202 ….. Fraud reporting smart contract 202 may provide functions for inquiring on potential fraud (e.g., by locating a matching fraud record in the blockchain), reporting fraud, permissioning and/or revoking blockchain addresses belonging to a registered entity, confirming a fraud report (See, Para. 23-25, 30));
receive an inquiry from [the server] to identify unapproved transaction data stored in the memory area, wherein the inquiry is received subsequent to the determination that the first transaction data is recorded in the public blockchain; (Balaraman, Process 401 may comprise querying local blockchain database 235 based on the payment request hash (step 411). Blockchain node 230 may query local blockchain database 235 to determine whether the payment request hash matches any stored data (e.g., to determine whether the payment request has been previously reported as suspected and/or validated fraud)….. Blockchain node 230 may receive the query results from local blockchain database 235 (step 413). The query results may comprise data indicating whether the query in step 411 returned a match (e.g., “true” if a record existed, “false” if the record did not exist). In various embodiments, the query results may also comprise a fraud confidence level. (See, Para. 29-33, 47-50, 53-56, 60-65, 76; Fig. 1-3, 5A-B));
access, based on the received inquiry, the memory area of the first node to identify the unapproved transaction data; (Balaraman, Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register the public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses (e.g., for fraud management access rights). Fraud reporting smart contract 202 returns a fraud management access confirmation to participant registration portal 260 (step 315). (See, Para. 29-33, 47-50, 53-56, 60-65, 76; Fig. 1-3, 5A-B));
identify the first transaction data as the unapproved transaction data; (Balaraman, Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register the public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses (e.g., for fraud management access rights). Fraud reporting smart contract 202 returns a fraud management access confirmation to participant registration portal 260 (step 315). (See, Para. 29-33, 47-50, 53-56, 60-65, 76; Fig. 1-3, 5A-B));
transmit the first transaction data to [the server] based on the identification of the first transaction data as the unapproved transaction data, (Balaraman, User terminal 220 may transmit the registration request comprising identifying information (e.g., a merchant ID, existing login credentials, driver's license, etc.) and the public blockchain address to participant registration portal 260.….. authenticate the registration request based the identifying information. For example, in response to the identifying information comprising a merchant ID (or similar merchant identifying information); …… Blockchain network 101 may comprise various blockchain nodes (e.g., consensus participants) in electronic communication with each other, as discussed further herein. Each blockchain node may comprise a computing device configured to write blocks to the blockchain and validate blocks of the blockchain. (See, Para. 19-24, 26, 29, 33-35, 39-45); Fraud reporting smart contract 202 may also register the public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses (e.g., for fraud management access rights). Fraud reporting smart contract 202 returns a fraud management access confirmation to participant registration portal 260 (step 315); blockchain node 230 may transmit the query results to hashing module 245 (step 415). Hashing module 245 may transmit the query results to transaction account processing system 240 (step 417). (See, Para. 29-33, 47-50, 53-56, 60-65, 76; Fig. 1-3, 5A-B));
wherein [the server] is further configured to: receive the first transaction data; (Balaraman, User terminal 220 may transmit the registration request comprising identifying information (e.g., a merchant ID, existing login credentials, driver's license, etc.) and the public blockchain address to participant registration portal 260. ….. authenticate the registration request based the identifying information. For example, in response to the identifying information comprising a merchant ID (or similar merchant identifying information) (See, Para.19-23, 34-35, 40-42, 48-50, 60-65, 76));
specify, based on the received first transaction data, the first registration information in the memory; (Balaraman, Blockchain network 101 may comprise various blockchain nodes (e.g., consensus participants) in electronic communication with each other, as discussed further herein. Each blockchain node may comprise a computing device configured to write blocks to the blockchain and validate blocks of the blockchain. (See, Para. 22-24, 26, 29, 33-35, 39-45); Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register…public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses (e.g., for fraud management access rights)(See, Para. 19-23, 34-35, 47-50, 60-65));
determine the second registration information matches the specified first registration information; (Balaraman, User terminal 220 may transmit the registration request comprising identifying information (e.g., a merchant ID, existing login credentials, driver's license, etc.)…the public blockchain address to participant registration portal 260……in response to the identifying information comprising a merchant ID (or similar merchant identifying information)…. In that respect, in response to the merchant ID matching a stored merchant ID, the registration request may be authenticated. (See, Para. 40-55, 60-65));
call the smart contract from a second node of the plurality of nodes based on the determination that the second registration information matches the specified first registration information; and (Balaraman, Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register the public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses …. Fraud reporting smart contract 202 returns a fraud management access confirmation to participant registration portal 260 (step 315). …… process 501 may comprise invoking fraud reporting smart contract 202 (step 513). Blockchain node 230 may invoke fraud reporting smart contract 202 by passing the potential fraud report hash the public blockchain address. The call to fraud reporting smart contract 202 may be secured using the private key from the user. …. Process 501 may comprise validating user fraud management authorization (step 515). Fraud reporting smart contract 202 may validate that the public blockchain address associated with the user is authorized to access and/or perform writes to blockchain network 101 (e.g., fraud management access rights) by querying the blockchain to locate registration data (e.g., as added to the blockchain in process 301, with brief reference to FIGS. 3A and 3B). (See, Para. 49-65; Fig. 3A-B, 5));
input, to the smart contract called from the second node, approval information for approval of the first transaction data, (Balaraman, Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register the public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses …. Fraud reporting smart contract 202 returns a fraud management access confirmation to participant registration portal 260 (step 315). …… process 501 may comprise invoking fraud reporting smart contract 202 (step 513). Blockchain node 230 may invoke fraud reporting smart contract 202 by passing the potential fraud report hash the public blockchain address. The call to fraud reporting smart contract 202 may be secured using the private key from the user. …. Process 501 may comprise validating user fraud management authorization (step 515). Fraud reporting smart contract 202 may validate that the public blockchain address associated with the user is authorized to access and/or perform writes to blockchain network 101 (e.g., fraud management access rights) by querying the blockchain to locate registration data (e.g., as added to the blockchain in process 301, with brief reference to FIGS. 3A and 3B). (See, Para. 49-65));
wherein the smart contract records second transaction data in the public blockchain based on the input of the approval information to the smart contract. (Balaraman, Process 601 may comprise invoking fraud reporting smart contract 202 (step 609). Blockchain node 280 may invoke fraud reporting smart contract 202 by passing the validated fraud report hash and/or the public blockchain address. The call to fraud reporting smart contract 202 may be secured using the private key from the user. The public blockchain address included in the call may be digitally signed using a trusted certificate authority (e.g., VeriSign®, DigiCert®, etc.). Process 6501 may comprise validating user fraud management authorization (step 611). Fraud reporting smart contract 202 may validate that the public blockchain address associated with the user is authorized to access and/or perform validation writes to blockchain network 101 (e.g., fraud management access rights) by querying the blockchain to locate registration data (e.g., as added to the blockchain in process 301, with brief reference to FIGS. 3A and 3B). (See, Para. 23, 30, 33, 40-55, 60-65)).
Balaraman does not specifically teach a server. Balaraman discloses that the various system components discussed herein may include one or more of the following: a host server or other computing systems including a processor for processing digital data.
However, Arora further teaches the following limitations:
An information processing system, comprising: a memory; a terminal associated with a user; a [server] configured to: (Arora, processing server. (See, Para. 7, 9, 74; Claims 6 and 14 Abstract; Fig. 2, 5));
transmit the first transaction data to [the server] based on the determination that the first transaction data is recorded in the public blockchain. (Arora, system for processing a multi-account check includes: a receiver of a processing server configured to receive a first authorization request transmitted via payment rails, wherein the first authorization request is formatted according to one or more standards and includes a plurality of data elements configured to store transaction data… a processing device of the processing server configured to identify a blockchain associated with the account identifier, wherein the blockchain includes a plurality of blocks, each block includes a block header and one or more blockchain data values, and a blockchain data value included in one of the plurality of blocks …. a transmitter of the processing server configured to electronically transmit each of the two or more blockchain transaction requests to a node in a blockchain network associated with a separate blockchain. (See, Para. 7, 9, 74; Claims 6 and 14 Abstract; Fig. 2, 5));
wherein [the server] is further configured to: receive the first transaction data; (Arora, system for processing a multi-account check includes: a receiver of a processing server configured to receive a first authorization request transmitted via payment rails, wherein the first authorization request is formatted according to one or more standards and includes a plurality of data elements configured to store transaction data… a processing device of the processing server configured to identify a blockchain associated with the account identifier, wherein the blockchain includes a plurality of blocks, each block includes a block header and one or more blockchain data values, and a blockchain data value included in one of the plurality of blocks(See, Para. 7, 9, 74; Claims 6 and 14 Abstract; Fig. 2, 5)).
It would have been obvious to one of ordinary skill in the art before the effective filing of the claimed invention to have modified Balaraman with the features of Arora’s system because the “system for processing a multi-account check includes: a receiver of a processing server configured to receive a first authorization request transmitted via payment rails, wherein the first authorization request is formatted according to one or more standards and includes a plurality of data elements configured to store transaction data, the transaction data including at least a transaction amount, an account identifier, and a check number; a processing device of the processing server configured to identify a blockchain associated with the account identifier, wherein the blockchain includes a plurality of blocks, each block includes a block header and one or more blockchain data values, and a blockchain data value included in one of the plurality of blocks includes the check number, and generate two or more blockchain transaction requests, wherein each blockchain transaction request includes at least a recipient blockchain address, a funding blockchain address, and a payment amount, where the recipient blockchain address is generated using the same public key for each blockchain transaction request, and a total of the payment amount included in each of the blockchain transaction requests is based on the transaction amount; and a transmitter of the processing server configured to electronically transmit each of the two or more blockchain transaction requests to a node in a blockchain network associated with a separate blockchain.” (Arora, Para. 9).
Regarding Claim 2:
Balaraman teaches:
wherein the processor is further configured to: monitor third transaction data held by at least one node of the plurality of nodes in the public blockchain; and (Balaraman, User terminal 220 may transmit the registration request comprising identifying information (e.g., a merchant ID, existing login credentials, driver's license, etc.) and the public blockchain address to participant registration portal 260. ….. authenticate the registration request based the identifying information. For example, in response to the identifying information comprising a merchant ID (or similar merchant identifying information) (See, Para.19-20, 34-35, 40-42, 48-50; Abstract); Blockchain network 101 may comprise a fraud reporting smart contract 202. Fraud reporting smart contract 202 may be configured to control the end-to-end flow of fraud management, including fraud inquiries and fraud reporting. Fraud reporting smart contract 202 may be an executable that writes data to the blockchain, queries the blockchain in a predetermined format, and/or controls the application flow based on predetermined function parameters passed by an API call, or the like. Fraud reporting smart contract 202 may also perform these functions based on the current value of parameters stored in the blockchain and the identity of the caller of fraud reporting smart contract 202 (e.g., transaction account issuer 103, payment service provider 105, payment processing network 107, merchant 109, and/or third party fraud system 111). Fraud reporting smart contract 202 may provide functions for inquiring on potential fraud (e.g., by locating a matching fraud record in the blockchain), reporting fraud, permissioning and/or revoking blockchain addresses belonging to a registered entity, confirming a fraud report, and/or the like. (See, Para. 30, 107));
determine, based on the monitored third transaction data, the first transaction data is recorded in the public blockchain. (Balaraman, User terminal 220 may transmit the registration request comprising identifying information (e.g., a merchant ID, existing login credentials, driver's license, etc.) and the public blockchain address to participant registration portal 260.….. authenticate the registration request based the identifying information. For example, in response to the identifying information comprising a merchant ID (or similar merchant identifying information); …… Blockchain network 101 may comprise various blockchain nodes (e.g., consensus participants) in electronic communication with each other, as discussed further herein. Each blockchain node may comprise a computing device configured to write blocks to the blockchain and validate blocks of the blockchain. (See, Para. 19-24, 26, 29, 33-35, 39-45); Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register…public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses (e.g., for fraud management access rights) (See, Para. 47-50, 60-65, 76)).
Regarding Claim 3:
(Canceled).
Regarding Claim 4:
Balaraman teaches:
wherein the monitored third transaction data is broadcasted to the public blockchain and received by the at least one node. (Balaraman, The system may also increase the reliability of data transfers in a network environment having reliable and unreliable peers, as each node broadcasts messages to all connected peers, and, as each block comprises a link to a previous block, a node may quickly detect a missing block and propagate a request for the missing block to the other nodes in the blockchain network. Moreover, the system may also offer increased security of consumer data by performing cryptographic processes on consumer data prior to querying the blockchain or storing data on the blockchain. (See, Para. 19-21, 30, 34-35, 40-42, 48-50, 107)).
Regarding Claim 7:
Balaraman teaches:
wherein the smart contract is a Turing-complete type. (Balaraman, Fraud reporting smart contract 202 may include a program written in a programming language such as, for example, Solidity, or any other suitable programming language. The program may be configured to execute to perform the functions and tasks discussed herein. (See, Abstract; Para. 30, 76, 80, 106)).
Regarding Claim 8:
Balaraman teaches:
wherein [the server] is further configured to: notify the terminal of second identification information, wherein the second identification information specifies a recording position of the first registration information in the memory, and (Balaraman, The consensus participants may notify blockchain node 230 of a successful write to the blockchain by returning an update confirmation (step 519), or by blockchain node 230 locating the fraud data written on blockchain. Blockchain node 230 may transmit the update confirmation to hashing module 245 (step 521). Hashing module 245 may transmit the update confirmation to transaction account processing system 240 (step 523). (See, Para. 23, 30, 33, 40-55, 60-65));
the terminal associated with the user records the first transaction data including the second identification information in the public blockchain and the terminal associated with the user records the first transaction data based on the smart contract; and (Balaraman, Blockchain network 101 may comprise various blockchain nodes (e.g., consensus participants) in electronic communication with each other, as discussed further herein. Each blockchain node may comprise a computing device configured to write blocks to the blockchain and validate blocks of the blockchain. (See, Para. 22-24, 26, 29, 33-35, 39-45); Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register…public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain… public blockchain addresses (e.g., for fraud management access rights)(See, Para. 47-50));
specify the first registration information in the memory based on the second identification information. (Balaraman, Blockchain network 101 may comprise various blockchain nodes (e.g., consensus participants) in electronic communication with each other, as discussed further herein. Each blockchain node may comprise a computing device configured to write blocks to the blockchain and validate blocks of the blockchain. (See, Para. 22-24, 26, 29, 33-35, 39-45); Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register…public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses (e.g., for fraud management access rights)(See, Para. 47-50)).
Balaraman does not specifically teach a server. Balaraman discloses that the various system components discussed herein may include one or more of the following: a host server or other computing systems including a processor for processing digital data.
However, Arora further teaches the following limitation:
wherein [the server] is further configured to: notify the terminal associated with the user of second identification information. (Arora, a processing device of the processing server configured to identify a blockchain associated with the account identifier, wherein the blockchain includes a plurality of blocks, each block includes a block header and one or more blockchain data values, and a blockchain data value included in one of the plurality of blocks …. a transmitter of the processing server configured to electronically transmit each of the two or more blockchain transaction requests to a node in a blockchain network associated with a separate blockchain. (See, Para. 7, 9, 74; Claims 6 and 14 Abstract; Fig. 2, 5)).
It would have been obvious to one of ordinary skill in the art before the effective filing of the claimed invention to have modified Balaraman with the features of Arora’s system because the “system for processing a multi-account check includes: a receiver of a processing server configured to receive a first authorization request transmitted via payment rails, wherein the first authorization request is formatted according to one or more standards and includes a plurality of data elements configured to store transaction data, the transaction data including at least a transaction amount, an account identifier, and a check number; a processing device of the processing server configured to identify a blockchain associated with the account identifier, wherein the blockchain includes a plurality of blocks, each block includes a block header and one or more blockchain data values, and a blockchain data value included in one of the plurality of blocks includes the check number, and generate two or more blockchain transaction requests, wherein each blockchain transaction request includes at least a recipient blockchain address, a funding blockchain address, and a payment amount, where the recipient blockchain address is generated using the same public key for each blockchain transaction request, and a total of the payment amount included in each of the blockchain transaction requests is based on the transaction amount; and a transmitter of the processing server configured to electronically transmit each of the two or more blockchain transaction requests to a node in a blockchain network associated with a separate blockchain.” (Arora, Para. 9).
Regarding Claim 9:
Balaraman teaches:
wherein in a case where the first transaction data is approved based on the second transaction data, the smart contract issues information that certifies authenticity of the second registration information included in the first transaction data, and (Balaraman, User terminal 220 may transmit the registration request comprising identifying information (e.g., a merchant ID, existing login credentials, driver's license, etc.)…the public blockchain address to participant registration portal 260 …… in response to the identifying information comprising a merchant ID (or similar merchant identifying information)…. In that respect, in response to the merchant ID matching a stored merchant ID, the registration request may be authenticated. (See, Para. 40-55, 60-65));
the issuance of the information is based on the inquiry. (Balaraman, User terminal 220 may transmit the registration request comprising identifying information (e.g., a merchant ID, existing login credentials, driver's license, etc.)…the public blockchain address to participant registration portal 260……in response to the identifying information comprising a merchant ID (or similar merchant identifying information)…. In that respect, in response to the merchant ID matching a stored merchant ID, the registration request may be authenticated. (See, Para. 40-55, 60-65); Blockchain network 101 may comprise a fraud reporting smart contract 202. …. Fraud reporting smart contract 202 may be an executable that writes data to the blockchain …. Fraud reporting smart contract 202 may also perform these functions based on the current value of parameters stored in the blockchain and the identity of the caller of fraud reporting smart contract 202 ….. Fraud reporting smart contract 202 may provide functions for inquiring on potential fraud (e.g., by locating a matching fraud record in the blockchain), reporting fraud, permissioning and/or revoking blockchain addresses belonging to a registered entity, confirming a fraud report (See, Para. 23-25, 30)).
Regarding Claim 10:
Balaraman teaches:
An information processing device, comprising: a memory; and a processor executable on a first node of a plurality of nodes of a public blockchain, wherein the processor is configured to: (Balaraman, See, Para. 19, 20, 22-23, 50, 76; Abstract);
provide an application associated with a specific service to a terminal of a user; (Balaraman, The system may also include applications deployed on user devices such as, for example, computers, tablets, smartphones, Internet of Things devices (“IoT” devices), etc. The applications may communicate with the blockchain (e.g., directly or via a blockchain node) to transmit and retrieve data. In various embodiments, a governing organization or consortium may control access to data stored on the blockchain. Registration with the managing organization(s) may enable participation in the blockchain network. (See, Para.19-20, 35; Abstract));
receive, based on execution of the application on the terminal first registration information from the terminal , wherein the first registration information is associated with the user; (Balaraman, User terminal 220 may transmit the registration request comprising identifying information (e.g., a merchant ID, existing login credentials, driver's license, etc.) and the public blockchain address to participant registration portal 260. ….. authenticate the registration request based the identifying information. For example, in response to the identifying information comprising a merchant ID (or similar merchant identifying information) (See, Para.19-20, 34-35, 40-42, 48-50, ; Abstract));
control the memory to record the first registration information; (Balaraman, Blockchain wallet 225 may serve as a blockchain interface accessible by users and applications installed on user terminal 220. For example, blockchain wallet 225 may be configured to register user terminal 220 with the blockchain, request public key (e.g., blockchain address) and private key pairs from blockchain network 101, and/or otherwise access and interact with blockchain account information. (See, Para.19-20, 34-35, 40-42; Abstract); Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses (e.g., for fraud management access rights) (See, Para. 48-50, 60-61); Blockchain network 101 may comprise a fraud reporting smart contract 202. Fraud reporting smart contract 202 may be configured to control the end-to-end flow of fraud management, including fraud inquiries and fraud reporting. Fraud reporting smart contract 202 may be an executable that writes data to the blockchain, queries the blockchain in a predetermined format, and/or controls the application flow based on predetermined function parameters passed by an API call, or the like. Fraud reporting smart contract 202 may also perform these functions based on the current value of parameters stored in the blockchain and the identity of the caller of fraud reporting smart contract 202 (e.g., transaction account issuer 103, payment service provider 105, payment processing network 107, merchant 109, and/or third party fraud system 111).(See, Para. 30, 107));
control access to a memory area of the first node to determine first transaction data is recorded in the public blockchain, (Balaraman, Blockchain network 101 may comprise various blockchain nodes (e.g., consensus participants) in electronic communication with each other, as discussed further herein. Each blockchain node may comprise a computing device configured to write blocks to the blockchain and validate blocks of the blockchain. (See, Para. 22-24, 26, 29, 33-35, 39-45); Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register…public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses (e.g., for fraud management access rights)(See, Para. 47-50); Blockchain network 101 may comprise a fraud reporting smart contract 202. Fraud reporting smart contract 202 may be configured to control the end-to-end flow of fraud management, including fraud inquiries and fraud reporting. Fraud reporting smart contract 202 may be an executable that writes data to the blockchain, queries the blockchain in a predetermined format, and/or controls the application flow based on predetermined function parameters passed by an API call, or the like. Fraud reporting smart contract 202 may also perform these functions based on the current value of parameters stored in the blockchain and the identity of the caller of fraud reporting smart contract 202 (e.g., transaction account issuer 103, payment service provider 105, payment processing network 107, merchant 109, and/or third party fraud system 111). Fraud reporting smart contract 202 may provide functions for inquiring on potential fraud (e.g., by locating a matching fraud record in the blockchain), reporting fraud, permissioning and/or revoking blockchain addresses belonging to a registered entity, confirming a fraud report, and/or the like. (See, Para. 30, 107));
wherein the first transaction data includes: first identification information that includes an application identifier that identifies the specific service, and second registration information, and the public blockchain is a network that executes a smart contract; (Balaraman, User terminal 220 may transmit the registration request comprising identifying information (e.g., a merchant ID, existing login credentials, driver's license, etc.)…the public blockchain address to participant registration portal 260……in response to the identifying information comprising a merchant ID (or similar merchant identifying information)…. In that respect, in response to the merchant ID matching a stored merchant ID, the registration request may be authenticated. (See, Para. 40-55, 60-65); Blockchain network 101 may comprise a fraud reporting smart contract 202. …. Fraud reporting smart contract 202 may be an executable that writes data to the blockchain …. Fraud reporting smart contract 202 may also perform these functions based on the current value of parameters stored in the blockchain and the identity of the caller of fraud reporting smart contract 202 ….. Fraud reporting smart contract 202 may provide functions for inquiring on potential fraud (e.g., by locating a matching fraud record in the blockchain), reporting fraud, permissioning and/or revoking blockchain addresses belonging to a registered entity, confirming a fraud report (See, Para. 23-25, 30));
access, subsequent to the determination that the first transaction data is recorded in the public blockchain, the memory area of the first node to identify unapproved transaction data stored in the memory area; (Balaraman, Process 401 may comprise querying local blockchain database 235 based on the payment request hash (step 411). Blockchain node 230 may query local blockchain database 235 to determine whether the payment request hash matches any stored data (e.g., to determine whether the payment request has been previously reported as suspected and/or validated fraud)….. Blockchain node 230 may receive the query results from local blockchain database 235 (step 413). The query results may comprise data indicating whether the query in step 411 returned a match (e.g., “true” if a record existed, “false” if the record did not exist). In various embodiments, the query results may also comprise a fraud confidence level; Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register the public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses (e.g., for fraud management access rights). Fraud reporting smart contract 202 returns a fraud management access confirmation to participant registration portal 260 (step 315). (See, Para. 29-33, 47-50, 53-56, 60-65, 76; Fig. 1-3, 5A-B));
identify the first transaction data as the unapproved transaction data; (Balaraman, Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register the public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses (e.g., for fraud management access rights). Fraud reporting smart contract 202 returns a fraud management access confirmation to participant registration portal 260 (step 315). (See, Para. 29-33, 47-50, 53-56, 60-65, 76; Fig. 1-3, 5A-B));
specify the first registration information in the memory based on the identification of the first transaction data as the unapproved transaction data; (Balaraman, Blockchain network 101 may comprise various blockchain nodes (e.g., consensus participants) in electronic communication with each other, as discussed further herein. Each blockchain node may comprise a computing device configured to write blocks to the blockchain and validate blocks of the blockchain. (See, Para. 22-24, 26, 29, 33-35, 39-45); Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register…public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses (e.g., for fraud management access rights)(See, Para. 47-50);Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register the public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses (e.g., for fraud management access rights). Fraud reporting smart contract 202 returns a fraud management access confirmation to participant registration portal 260 (step 315). (See, Para. 29-33, 47-50, 53-56, 60-65, 76; Fig. 1-3, 5A-B));
determine the second registration information matches the specified first registration information; (Balaraman, User terminal 220 may transmit the registration request comprising identifying information (e.g., a merchant ID, existing login credentials, driver's license, etc.)…the public blockchain address to participant registration portal 260……in response to the identifying information comprising a merchant ID (or similar merchant identifying information)…. In that respect, in response to the merchant ID matching a stored merchant ID, the registration request may be authenticated. (See, Para. 40-55, 60-65));
call the smart contract from a second node of the plurality of nodes based on the determination that the second registration information matches the specified first registration information; and (Balaraman, Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register the public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses …. Fraud reporting smart contract 202 returns a fraud management access confirmation to participant registration portal 260 (step 315). …… process 501 may comprise invoking fraud reporting smart contract 202 (step 513). Blockchain node 230 may invoke fraud reporting smart contract 202 by passing the potential fraud report hash the public blockchain address. The call to fraud reporting smart contract 202 may be secured using the private key from the user. …. Process 501 may comprise validating user fraud management authorization (step 515). Fraud reporting smart contract 202 may validate that the public blockchain address associated with the user is authorized to access and/or perform writes to blockchain network 101 (e.g., fraud management access rights) by querying the blockchain to locate registration data (e.g., as added to the blockchain in process 301, with brief reference to FIGS. 3A and 3B). (See, Para. 49-65; Fig. 3A-B, 5));
input, to the smart contract called from the second node, approval information for approval of the first transaction data, (Balaraman, Process 301 may comprise invoking fraud reporting smart contract 202, via blockchain node 280, in blockchain network 101 to grant fraud management access (step 313). Fraud reporting smart contract 202 may write the registration data to the blockchain. Fraud reporting smart contract 202 may also register the public blockchain address into an internal data storage in fraud reporting smart contract 202 to track and maintain registered public blockchain addresses …. Fraud reporting smart contract 202 returns a fraud management access confirmation to participant registration portal 260 (step 315). …… process 501 may comprise invoking fraud reporting smart contract 202 (step 513). Blockchain node 230 may invoke fraud reporting smart contract 202 by passing the potential fraud report hash the public blockchain address. The call to fraud reporting smart contract 202 may be secured using the private key from the user. …. Process 501 may comprise validating user fraud management authorization (step 515). Fraud reporting smart contract 202 may validate that the public blockchain address associated with the user is authorized to access and/or perform writes to blockchain network 101 (e.g., fraud management access rights) by querying the blockchain to locate registration data (e.g., as added to the blockchain in process 301, with brief reference to FIGS. 3A and 3B). (See, Para. 49-65));
wherein the smart contract records second transaction data in the public blockchain based on the input of the approval information to the smart contract. (Balaraman, Process 601 may comprise invoking fraud reporting smart contract 202 (step 609). Blockchain node 280 may invoke fraud reporting smart contract 202 by passing the validated fraud report hash and/or the public blockchain address. The call to fraud reporting smart contract 202 may be secured using the private key from the user. The public blockchain address included in the call may be digitally signed using a trusted certificate authority (e.g., VeriSign®, DigiCert®, etc.). Process 6501 may comprise validating user fraud management authorization (step 611). Fraud reporting smart contract 202 may validate that the public blockchain address associated with the user is authorized to access and/or perform validation writes to blockchain network 101 (e.g., fraud management access rights) by querying the blockchain to locate registration data (e.g., as added to the blockchain in process 301, with brief reference to FIGS. 3A and 3B). (See, Para. 23, 30, 33, 40-55, 60-65)).
Response to Arguments
With respect to the objection of claims 1, 8, 10, and 11, the objection is withdrawn in view of Applicant’s arguments/remarks made in an amendment filed on 09/02/2025.
With respect to the 35 US.C. 112(a) rejection of claims 1-4 and 7-11, the rejection is withdrawn in view of Applicant’s arguments/remarks made in an amendment filed on 09/02/2025.
Applicant's arguments filed on 09/02/2025 have been fully considered, but are not persuasive due to the following reasons:
With respect to the rejection of claims 1-4 and 7-11 under 35 U.S.C. 101, Applicant arguments are moot in view of the grounds of rejections presented above in this office action. The arguments are addressed to the extent they apply to the amended claims.
Applicant argues that “contrary to the Office's assertion, the claimed invention is not directed to an abstract idea. The claims are directed to a specific technological solution that solves concrete technical problems inherent in blockchain networks. Specifically, the claimed system addresses the technical problem of efficiently identifying and processing unapproved transaction data in a distributed blockchain environment through a novel inquiry-based monitoring architecture. … Similar to Ancora, the claimed subject matter in amended independent claim 1 improves the technology related to registration information verification in computing environments to provide secure authenticity of the registration information….. Thus, the features of amended independent claim 1 describe a specific technological improvement to blockchain monitoring systems, and not an abstract concept, or a concept similar to those found by the Courts to be Abstract, such as a Certain Methods of Organizing Human Activity. ”
Examiner respectfully disagrees.
Under Step 2A: Prong 1, Examiner respectfully notes that independent claims 1, 10, and 11, as amended, are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea of processing user registration, transaction, and approval information; without significantly more. As previously discussed, the series of steps recited in claims 1, 10, and 11, as amended, describe the abstract idea of processing user registration, transaction, and approval information, which is mitigating risk of incorrectly identifying, approving, and recording transaction data into a public blockchain; therefore, corresponding to a fundamental economic principle or practice (including mitigating risk). Hence, a fundamental economic principle or practice (mitigating risk) is a Certain Methods of Organizing Human Activity. The abstract idea is also the processing and approving transactional data to be inputted into contract, which is a commercial interaction. Therefore, a commercial interaction is also a Certain Methods of Organizing Human Activity. Furthermore, the system limitations, e.g., a service providing system, memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract do not necessarily restrict the claim from reciting an abstract idea. Furthermore, Examiner respectfully notes that the claims are first analyzed in the absence of technology to determine if it recites an abstract idea. The additional limitations of technology are then considered to determine if it restricts the claim from reciting an abstract idea. Unlike the referenced case: Ancora Technologies, INC vs HTC America, INC., HTC Corporation, it is determined that the additional limitations of technology do not necessarily restrict the claim from reciting an abstract idea. Furthermore, Examiner respectfully notes that the recited features in the limitations (amended claim 11): “in a service providing system that includes a server, a memory, a terminal associated with a user, and a processor: providing, by the server, an application associated with a specific service to the terminal of the user; and receiving, by the server, based on execution of the application, first registration information from the terminal, wherein the first registration information is associated with the user; controlling, by the server, the memory to record the first registration information; controlling execution of the processor on a first node of a plurality of nodes of a public blockchain; accessing, by the processor, a memory area of the first node to determine first transaction data is recorded in the public blockchain, wherein the first transaction data includes: first identification information that includes an application identifier that identifies the specific service, and second registration information, and the public blockchain is a network that executes a smart contract; receiving an inquiry from the server to identify unapproved transaction data stored in the memory area, wherein the inquiry is received subsequent to the determination that the first transaction data is recorded in the public blockchain; accessing, based on the received inquiry, the memory area of the first node to identify the unapproved transaction data; identifying the first transaction data as the unapproved transaction data; transmitting, by the processor, the first transaction data to the server based on the identification of the first transaction data as the unapproved transaction data; receiving, by the server, the first transaction data; specifying, by the server, the first registration information in the memory based on the received first transaction data; determining, by the server, the second registration information matches the specified first registration information; calling, by the server, the smart contract from a second node of the plurality of nodes based on the determination that the second registration information matches the specified first registration information; and inputting, by the server, to the smart contract called from the second node, approval information for approval of the first transaction data, wherein the smart contract records second transaction data in the public blockchain based on the input of the approval information to the smart contract” are simply making use of a computer and the computer limitations do not necessarily restrict the claim from reciting an abstract idea as discussed above under Step 2A-Prong 1 of the 35 U.S.C. 101 rejection.
Thus, Examiner has also considered each and every arguments under Step 2A-Prong 1 and concludes that these arguments are not persuasive. For example, under Step 2A-Prong 1, Examiner considers each and every limitation to determine if the claim recites an abstract idea. In this case, it is determined that the claim recites an abstract idea and the additional limitations of a computer device does not necessarily restrict the claim from reciting an abstract idea. The recited steps, as amended, are abstract in nature as there are no technical/technology improvements as a result of these steps. Hence, the claim recites an abstract idea. Whether the claim integrates the abstract idea into a practical application by providing technical/technology improvements are considered under Step 2A-Prong 2.
Applicant argues that “regarding Prong Two of Step 2A of the 2019 Revised Patent Subject Matter Eligibility Guidance, even if one were to arrive at a conclusion satisfying the Prong One of such analysis, assuming arguendo, to which the Applicant does not concede, the Applicant submits the alleged abstract idea is integrated into a practical implementation….. Similar to Example 40, claim 1, the subject matter of amended independent claim 1 of the present application provides a specific and technical solution for verifying and approving registration information in a system. In the instant application, the claimed system determines that first transaction data is recorded in the public blockchain, receives an inquiry from the server to identify unapproved transaction data, accesses the memory area of the first node to identify the unapproved transaction data, and transmits it to the server. The server then verifies the registration information and calls a smart contract from a second node to input approval information, resulting in second transaction data being recorded in the blockchain. Accordingly, just as Example 40, claim 1 was found eligible because it integrated the abstract idea into a practical application by conditionally collecting and analyzing network data to improve monitoring. In particular, the present claims integrate the alleged judicial exception into a practical application by conditionally identifying and verifying transaction data before approval. By performing this process, the claimed system improves the authenticity and reliability of registration certificates in a peer-to-peer network, thereby providing a concrete and technological improvement over conventional blockchain data handling…. Therefore, the Applicant has shown a teaching in the Specification that describes a practical implementation and has thus established a clear nexus between the claim language and the practical implementation of the alleged judicial exception…. Accordingly, the Applicant respectfully requests that the rejections of claims 1, 2, 4, and 7-11 under 35 U.S.C. § 101 be withdrawn.”
Examiner respectfully disagrees.
Under Step 2A: Prong II, as previously discussed, Examiner respectfully notes that there is no improved technology in simply providing, executing, receiving, controlling, recording, accessing, determining, processing, identifying, transmitting, accessing, specifying, calling, registering, inputting, approving, and outputting data (i.e., service data, registration data, transactional data, identification information, approval data, smart contract data, and etc.). Unlike the referenced claim 1 of Example 40, the disclosed invention simply cannot be equated to improvement to technological practices or computers. There is no technical improvement at all. Instead, Applicant recites (claim 1) “a system, comprising: a memory; a terminal associated with a user; a server configured to: provide an application associated with a specific service to the terminal of the user, wherein the terminal is configured to execute the application; receive, based on the execution of the application, first registration information from the terminal, wherein the first registration information is associated with the user; and control the memory to record the first registration information; and a processor executable on a first node of a plurality of nodes of a public blockchain, wherein the processor is configured to: access a memory area of the first node to determine first transaction data is recorded in the public blockchain, wherein the first transaction data includes: first identification information that includes an application identifier that identifies the specific service, and second registration information, and the public blockchain is a network that executes a smart contract; and receive an inquiry from the server to identify unapproved transaction data stored in the memory area, wherein the inquiry is received subsequent to the determination that the first transaction data is recorded in the public blockchain; access, based on the received inquiry, the memory area of the first node to identify the unapproved transaction data; identify the first transaction data as the unapproved transaction data; transmit the first transaction data to the server based on the identification of the first transaction data as the unapproved transaction data, wherein the server is further configured to: receive the first transaction data; specify, based on the received first transaction data, the first registration information in the memory; determine the second registration information matches the specified first registration information; call the smart contract from a second node of the plurality of nodes based on the determination that the second registration information matches the specified first registration information; and input, to the smart contract called from the second node, approval information for approval of the first transaction data, wherein the smart contract records second transaction data in the public blockchain based on the input of the approval information to the smart contract.” The recited features in the limitations, as amended, do not result in computer functionality or technical improvement. Examiner respectfully notes that Applicant is simply using a computer to input, process, and output data. The recited features in the limitations does not disclose a technical solution to technical problem, but simply a business solution. Specifically, the recited steps, as amended, are merely managing/processing data (MPEP 2106.05(d)(II)) and does not result in computer functionality or technical improvement. Thus, Applicant has simply provided a business method practice of processing data (processing user registration, transaction, and approval information), and no technical solution or improvement has been disclosed.
Moreover, unlike the referenced claim 1 of Example 40, there is no technology/technical improvement as a result of implementing the abstract idea. The recited limitations in the pending claims simply amount to the abstract idea of service data, registration data, transactional data, identification information, approval data, smart contract data, and etc. There is no computer functionality improvement or technology improvement. The claim does not provide a technical solution to a technical problem. If there is an improvement, it is to the abstract idea and not to technology. Additionally, Examiner notes that it is important to keep in mind that an improvement in the judicial exception itself (e.g., recited fundamental economic principle or practice and/or commercial interaction) is not an improvement in technology (See, MPEP 2106.05(a)(II)). Additionally, claims 1, 10, and 11, as amended, recites steps at a high level of generality.. In addition, all uses of the recited judicial exceptions require such data gathering and outputting, and, as such, these limitations do not impose any meaningful limits on the claim. These limitations amount to necessary data gathering and output. See MPEP 2106.05. The claim simply makes use of a computer as a tool to apply the abstract idea without transforming the abstract idea into a patent eligible subject matter. Thus, the claim does not integrate the abstract idea into a practical application; and these arguments are not persuasive.
Additionally, these steps, as amended, are recited as being performed by the additional elements: a service providing system, memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract. The additional elements: a service providing system, memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract are recited at a high level of generality, and are used as a tool to perform the generic computer function of receiving, processing, and outputting data. See MPEP 2106.05(f). The claims 1, 10, and 11, as amended, recite a service providing system, memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract, which are simply used to perform an abstract idea, as discussed above in Step 2A, Prong 1, such that it amounts to no more than mere instructions to apply the exception using a generic computer. See MPEP 2106.05(f). Specifically, the recitation of “a service providing system, memory, terminal, server, application, processor, first node, second node, plurality of nodes, public blockchain, memory area, network, and smart contract” in the limitations merely indicates a field of use or technological environment in which the judicial exception is performed. The claims, as amended, merely confines the use of the abstract idea to a particular technological environment; and thus fails to add an inventive concept to the claims. See MPEP 2106.05(h). Even when viewed in combination, these additional elements do not integrate the recited judicial exception into a practical application, and the claim is directed to the judicial exception. Hence, Claims 1, 10, and 11, as amended, do not integrate the abstract idea into a practical application. Thus, these arguments are not persuasive.
Hence, Examiner respectfully declines Applicant’s request to withdraw the 35 U.S.C. 101 rejection of claims 1-2, 4 and 7-11.
With respect to the rejection of claims 1-4 and 7-11 under 35 U.S.C. 103, Applicant arguments are moot in view of newly cited language recited in previously used prior art, as presented above in this office action.
Applicant argues that “the combination of Balaraman and Arora does not teach, suggest or render obvious at least, for example, the newly presented features of "receive an inquiry from the server to identify unapproved transaction data stored in the memory area, wherein the inquiry is received subsequent to the determination that the first transaction data is recorded in the public blockchain; access, based on the received inquiry, the memory area of the first node to identify the unapproved transaction data; identify the first transaction data as the unapproved transaction data, transmit the first transaction data to the server based on the identification of the first transaction data as the unapproved transaction data," as recited in amended independent claim 1….. The Applicant submits that amended independent claims 10 and 11 are also not taught, suggested, or rendered obvious over the references cited in the Office Action at least for the reasons stated above with regard to amended independent claim 1…. Furthermore, each of dependent claims 2, 4, and 7-9 separately recites subject matter not described or suggested by any of the cited references, whether taken individually or in combination. ”
Examiner respectfully disagrees.
Examiner respectfully notes that Applicant's arguments are moot in view of new grounds of rejection presented above based on newly cited portions of paragraphs 29-33 and 53-55, and Figures 2, 3, 5A, and 5B of the disclosed prior art Balaraman, which reads on the amended language.
Hence, Examiner respectfully declines Applicant’s request to withdraw the 35 U.S.C. 103 rejection of claims 1-13.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure are the following:
Madisetti (U.S. Patent Application Publication No. US-2020/0005290-A1) “System and method for processing payments in fiat currency using blockchain and tethered tokens”
Uhr (U.S. Patent Application Publication No. US-2018/0294977-A1) “System for issuing public certificate on basis of block chain, and method for issuing public certificate on basis of block chain by using same”
Uhr (U.S. Patent Application Publication No. US-2019/0296920-A1) “Method and service-providing server for secure transmission of user-authenticating information”
Liu (U.S. Patent Application Publication No. US-2021/0004791-A1) “Guaranteeing server and method for transaction on blockchain”
Yu (U.S. Patent Application Publication No. US-2020/0034356-A1) “Method, apparatus, device and storage medium for implementing application based on blockchain network”
Roennow (U.S. Patent Application Publication No. US-2020/0021446-A1) “Secure de-centralized domain name system”
Sharma (U.S. Patent Application Publication No. US-2020/0213128-A1) “Method and system for two factor authentication for blockchain transactions”
Safak (U.S. Patent Application Publication No. US-2020/0235911-A1) “Method and system for state associated device identification for digital payments using blockchain technology”
Shier (U.S. Patent Application Publication No. US-2020/0074552-A1) “Systems and methods for short and long tokens”
Leddy (U.S. Patent No. US-10,862,671-B2) “Global ownership registry”
Song (K.R. Patent Publication No. KR-101849912-B1) “Method for providing certificate service based on smart contract and server using the same”
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMED H MUSTAFA whose telephone number is (571) 270-7978. The examiner can normally be reached M-F 8:00 - 5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, MICHAEL W. ANDERSON can be reached on 571-270-0508. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MOHAMMED H MUSTAFA/Examiner, Art Unit 3693
/BRUCE I EBERSMAN/Primary Examiner, Art Unit 3693
Prosecution Insights