DETAILED ACTION
This is office action on the merits in response to the application filed on 01/13/2026.
Claims 1-20 have been filed by the applicant.
Claims 1, 9 and 16 are currently amended.
Claims 1-20 are currently pending and have been examined.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 01/13/2026 has been entered.
Response to Argument
Rejection under 101:
The applicant traverses 101 rejections and states that the application defines a problem and provides a solution. The examiner respectfully disagrees. The claims recites a series steps involving determining whether or not possesses data and requesting the data from others if not possesses the data which is abstract idea of mental processes. The recitation of blockchain technology is generally linking the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)). Therefore, 101 is maintained.
Rejection under 103:
The applicant argues that Sekar does not teach the claimed limitations because Sekar discloses enterprises 106, 108 and 110 for performing the claimed limitations instead of “end-user device”. The applicant also makes end user device 102 of Sekar equivalent to the “end user devices” as recited in the claims. The examiner respectfully disagrees. The claims recite an electronic device configured as a first block node for performing the recited steps. The claims further recite that the block nodes are implemented by “end user devices”. Sekar discloses enterprises 106, 108 and 110 for performing the recited functions, Sekar also discloses that these enterprises 106, 108 and 110 are nodes of blockchain system [0038 0049]. Therefore, enterprises 106, 108 and 110 are block nodes and also being end user device of the blockchain system. It is mistake to simply equal end user device 110 of Sekar to “end user devices” as recited in the claims.
The applicant further argues that Anderson teaches away because basic node of Anderson maintain a validated state based on the full node blockchain record. The examiner respectfully disagrees. Anderson clearly discloses that T1 maintains full blockchain, whereas each T2 is unique in that it manages only a subset of outgoing transactions, and nodes for a given TN will not overlap with Nodes for a different TN.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-8 are directed to an electronic device comprising a memory and a processor, claims 9-15 are directed to a method, and claims 16-20 are directed to a system. Therefore, these claims fall within the four statutory categories of invention.
The limitations of independent claim 1, which is representative of independent claims 9 and 16, have been denoted with letters by the Examiner for easy reference. The judicial exceptions recited in claim 1 are identified in bold below:
An electronic device configured as a first block node included in a blockchain network, the electronic device comprising: communication circuitry configured to transmit or receive a signal to or from a second block node or a third block node included in the blockchain network; memory storing a partial ledger and instructions, the partial ledger comprising a part of a full ledger regarding the blockchain network, and a first database, wherein the full ledger comprises a plurality of blocks connected in parallel, and the first database comprises state data changed by execution of a transaction; and at least one processor communicatively coupled with the communication circuitry and the memory, wherein the instructions, when executed by the at least one processor individually or collectively, cause the electronic device to:
determine whether first state data necessary for executing a first smart contract regarding a transaction requested to be performed is stored in the first database of the first block node,
based on determining that the first state data is not stored in the first database of the first block node, acquire, by the first block node, node information comprising information regarding at least one block node that stores the first state data from the third block node comprising the full ledger through the communication circuitry, and
acquire, at the first block node, the first state data from the second block node among the at least one block node, or the third block node, based on the node information through the communication circuitry, and execute the first smart contract based on the acquired first state data, and wherein the first block node and the at least one block node are implemented by end user devices including the electronic device
Limitations B through C under the broadest reasonable interpretation covers steps or functions that can be reasonably performed in the human mind. Other than reciting generic computer hardware in limitation A and “smart contract” and a series of “block nodes” that are generally linking the use of the judicial exception to a particular technological environment, nothing in the claim element differentiates the limitation from processes that a person can reasonably perform in the mind. For example, the claim establishes the context of determining whether data exists for a contract (i.e., observation, evaluation), based on determination… (i.e., judgement, opinion). Therefore, limitations B through C recite an abstract idea, as highlighted above, that is consistent with the observation, evaluation, and judgment aspects of a mental process.
Furthermore, limitation C and D recites “acquire information regarding data and acquire the data and execute contract,” which is equivalent to following rules or instruction. Limitation C and D therefore recites managing personal interactions that following instructions based on judgment made by mental process, fits squarely within the “certain methods of organizing human activity” grouping of abstract ideas.
Accordingly, claim 1, and by analogy similar claims 9 and 16, recite at least two abstract ideas and the analysis proceed to Step 2A.2.
The judicial exception is not integrated into a practical application. In particular, claim 1 recites the additional elements in bold below:
An electronic device configured as a first block node included in a blockchain network, the electronic device comprising: communication circuitry configured to transmit or receive a signal to or from a second block node or a third block node included in the blockchain network; memory storing a partial ledger and instructions, the partial ledger comprising a part of a full ledger regarding the blockchain network, and a first database, wherein the full ledger comprises a plurality of blocks connected in parallel, and the first database comprises state data changed by execution of a transaction; and at least one processor communicatively coupled with the communication circuitry and the memory, wherein the instructions, when executed by the at least one processor individually or collectively, cause the electronic device to:
determine whether first state data necessary for executing a first smart contract regarding a transaction requested to be performed is stored in the first database of the first block node,
based on determining that the first state data is not stored in the first database of the first block node, acquire, by the first block node, acquire node information comprising information regarding at least one block node that stores the first state data from the third block node comprising the full ledger through the communication circuitry, and
acquire, at the first block node, the first state data from the second block node among the at least one block node, or the third block node, based on the node information through the communication circuitry, and execute the first smart contract based on the acquired first state data, and wherein the first block node and the at least one block node are implemented by end user devices including the electronic device
The additional element(s) in limitation A and communication circuit in limitation C merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). The “smart contract”, and “notes” recited in limitation B through D generally link the use of the judicial exception to a particular technological environment(MPEP § 2106.05(h)). Accordingly, the additional element(s) do not integrate the abstract idea into a practical application because they do not recite any additional elements indicative of integration into a practical application. Rather, the claim as whole generally links the judicial exception to a technological environment defined by high level recitations of a computer and the Internet. Therefore, the claim is directed to an abstract idea and the analysis proceeds to Step 2B.
The additional elements, both individually and as an ordered combination, do not amount to significantly more than the judicial exception because the outcome of the considerations at Step 2B will be the same when the considerations from Step 2A.2 are reevaluated. As discussed under Step 2A.2, the additional element(s) amount to no more than generally link the abstract idea to a technological environment performed by a generic computer. This is not enough to provide an inventive concept. Therefore, claims 1, 9, and 16 are not patent eligible.
Dependent claims 2 and 10 further recite partial ledger comprises block, the block comprises block hash and the electronic device participates in an agreement. The limitation recited general function of a blockchain, therefore, the limitation generally link the use of the judicial exception to a particular technological environment(MPEP § 2106.05(h)).
Dependent claims 3 further recite first database stores state data related to transaction. The limitation recites a generic computer to implement the abstract idea (MPEP § 2106.05(f)).
Dependent claims 4 and 11 further recite third node comprises full ledger stores all data regarding blockchain which is generally link the use of the judicial exception to a particular technological environment(MPEP § 2106.05(h)). The limitation of the processor acquires the data from the third block node which is use generic computer to perform abstract idea of acquiring data.
Dependent claims 5, 12 and 17 further recite acquire node information, transmit data and request to second node, receive result and validate the result. The steps further correspond to abstract idea of following instructions. The additional element of hash corresponds to abstract idea of mathematical concept.
Dependent claims 6 and 13 further recite generation of data by node which is using generic computer to implement the abstract idea (MPEP § 2106.05(f)).
Dependent claims 7 and 14 further recite a series step of generating transaction data, transmit block generation request, receive ledger update request and update ledger. These steps recite general process on a blockchain which is generally link the use of the judicial exception to a particular technological environment(MPEP § 2106.05(h)).
Dependent claims 8 and 15 further recite a generation of an update request using certain data which further recites the abstract idea of following instructions by using generic computer.
Dependent claims 18 further recite generating transaction data, transmitting a request, comparing data sets and confirm comparing result, which further recites the abstract idea of following instructions by using generic computer.
Dependent claims 19 further recite requesting to update blockchain block, which further recites the abstract idea of following instructions by using generic computer. The blockchain generally link the use of the judicial exception to a particular technological environment(MPEP § 2106.05(h)).
Dependent claims 20 further recite full ledger of blockchain system which is general construction of blockchain. The limitation generally link the use of the judicial exception to a particular technological environment(MPEP § 2106.05(h)).
In summary, the dependent claims considered both individually and as an ordered combination do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself. The claims do not recite an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or provide meaningful limitations beyond generally linking an abstract idea to a particular technological environment. Therefore, the claims are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
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 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.
Claim(s) 1-4, 9-11, 16 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sekar et al. (US 20220094524 A1), and further in view of Yang (US 20200294140 A1) and Anderson (US 20200211011 A1).
With respect to claim 1, 9 and 16:
Sekar teaches (in italic):
An electronic device configured as a first block node included in a blockchain network, the electronic device comprising. (blockchain infrastructure includes an end user device 102, a network 104, an enterprise 106, an enterprise 108, and an enterprise 110. Additionally, in the illustrative embodiment, each of the enterprises 106, 108, 110 is included in or otherwise associated with an enterprise system 112. Further, in the illustrative embodiment, the enterprise 106 includes a contact center system 114, the enterprise 108 includes a contact center system 116, and the enterprise 110 includes a contact center system 118. the enterprises of the enterprise system 112 are described herein as being associated with one another (e.g., as nodes in a private system associated with a permissioned blockchain infrastructure) [0038 0049])
communication circuitry configured to transmit or receive a signal to or from a second block node or a third block node included in the blockchain network; memory storing a […] ledger and instructions, […] ledger regarding the blockchain network, and a first database,[…]; at least one processor communicatively coupled with the communication circuitry and the memory, wherein the instructions, when executed by the at least one processor individually or collectively, cause the electronic device to. (It should be appreciated that each of the end user device 102, network 104, enterprises 106, 108, 110, enterprise system 112, and contact center systems 114, 116, 118 may be embodied as (or include) one or more computing devices similar to the computing device 300 described below in reference to. FIG. 3. contact center systems 114, 116, 118 may include a processing device 302 and a memory 306 having stored thereon operating logic 308 (e.g., a plurality of instructions) for execution by the processing device 302 for operation of the corresponding device.[0068])
determine whether first […] data necessary for executing a first smart contract regarding a transaction requested to be performed is stored in the first database of the first block node. (the contact center system 114 of the enterprise 106) may receive the request for data from the end user device...In block 404, the enterprise 106 (e.g., via the contact center system 114) may analyze the request for data and may determine that the enterprise 106 does not possess the requested data. the blockchains described herein may include smart contracts, which the system 100 may leverage to self-execute and perform various functions (e.g., automated transact across enterprise devices in the system 100). [0078-0079 0100 Fig. 4])
based on determining that the first state data is not stored in the first database of the first block node, acquire, by the first block node, node information comprising information regarding at least one block node that stores the first […] data […] through the communication circuitry. (In response to determining that the enterprise 106 does not possess the requested data, the enterprise 106 (e.g., via the contact center system 114) may utilize a technological platform to determine which enterprise (e.g., the enterprises 106, 108, 110) in the enterprise system 112 possesses the requested data. After determining which enterprise in the enterprise system 112 possesses the requested data, the technological platform may communicate to the enterprise 106 information regarding the enterprise possessing the requested data (e.g., the enterprise 108). For example, the technological platform may determine that enterprise 108 possesses the solution to address the issue with the end user's cable internet service. [0079])
acquire, at the first block node, the first […] data from the second block node among the at least one block node, or the third block node, based on the node information through the communication circuitry, and execute the first smart contract based on the acquired first […] data. (The enterprise 106 (e.g., via the contact center system 114) may then transmit the request for data to the enterprise 108. In block 408, the system 100 (e.g., via the enterprise 106) may transmit the requested data received from the enterprise 108 to the end user device 102 (e.g., via the application 120 or, more particularly, the personal bot system). For example, the enterprise 106 may share with the end user device 102 the solution to address the issue with the end user's cable internet service. [0079 0086])
wherein the first block node and the at least one block node are implemented by end user devices including the electronic device. (the enterprises of the enterprise system 112 are described herein as being associated with one another (e.g., as nodes in a private system associated with a permissioned blockchain infrastructure). each of the enterprises 106, 108, 110 is included in or otherwise associated with an enterprise system 112. Further, in the illustrative embodiment, the enterprise 106 includes a contact center system 114, the enterprise 108 includes a contact center system 116, and the enterprise 110 includes a contact center system 118. It should be appreciated that each of the end user device 102, network 104, enterprises 106, 108, 110, enterprise system 112, and contact center systems 114, 116, 118 may be embodied as (or include) one or more computing devices similar to the computing device 300 described below in reference to FIG. 3. [0038 0049 0068])
Sekar does not specifically teach the following limitations. However,
Yang teaches:
a partial ledger, the partial ledger comprising a part of a full ledger. (The “light node” described in the implementations provided in the present specification refers to a node that can selectively back up block data or delegate its own consensus authority to other representative nodes (e.g., core nodes) to complete consensus and recording of block data. [0035])
third block node comprising the full ledger. (The light node can retain the recent data writing and query function locally, and can initiate data query to the full node when there is a historical data query need. [0035])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Sekar to set up node with partial ledger with the technique as disclosed by Yang to ease computer load by selectively perform blockchain transaction while also achieve consensus with other nodes as Yang suggested [0035].
Sekar in view of Yang does not specifically teach the following limitations. However,
Anderson teaches:
wherein the full ledger comprise a plurality of blocks connected in parallel. (Embodiments of the present invention provide a scalable architecture with easy to use oracles for creating custom blockchain solutions. Oracles can be composed into a Directed Acyclic Graph (DAG) to easily produce a use-case specific implementation. Upon receiving a proposed block, Validators simply validate this block in parallel by checking the validity of transactions, including their balances and signatures, and then updating its internal chain state. If parallel block pairs are proposed, where both are final with respect to parallel blocks, then the final block-pair from the Validator highest on the Validator list will have the highest priority. [0090 0117 0121])
the [..] database comprises state data changed by execution of transaction; first state data. (T1 manages the full state of the blockchain itself as well as which portions of the blockchain T2s manage. All transactions are still recorded, however, given the summary of transactions in the T2 blocks, which can be represented as a chain state vector. Basic nodes contain a working copy of the current state of ownership. Basic nodes implement validation and consensus, and maintain a validated state based on the full node blockchain record. Full and basic nodes can exist on both T1 and T2. Upon receiving a proposed block, Validators simply validate this block in parallel by checking the validity of transactions, including their balances and signatures, and then updating its internal chain state. . [0117 0135 0140-0141])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Sekar in view of Yang to set a parallel blocks structure with the technique as disclosed by Anderson to enables massive scaling and high performance as Anderson suggested [0035].
Claim 9, a method with the same scope as claim 1, is rejected.
Claim 16, a system with the same scope as claim 1, is rejected.
With respect to claim 2 and 10:
Yang further teaches:
wherein the partial ledger comprises at least one block corresponding to at least one transection...wherein the at least one block comprises a block hash comprising previous block information in the full ledger and previous block information in the partial ledger, and block data. (The “light node” described in the implementations provided in the present specification refers to a node that can selectively back up block data or delegate its own consensus authority to other representative nodes (e.g., core nodes) to complete consensus and recording of block data. [0035])
on which the electronic device participates in an agreement. (Full data of all or some nodes is backed up based on a specific consensus mechanism [0032])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Sekar to set up node with partial ledger with the technique as disclosed by Yang to store block information and participants in agreement to prevent tampering as Yang suggested [0032].
Claim 10, a method with the same scope as claim 2, is rejected.
With respect to claim 3:
Sekar further teaches:
wherein the state data of the first database is related to the transaction. (It should be appreciated that the transactions of the blockchain 600 (e.g., the transactions 608, 612, 616, etc.) may record various interactions and/or events occurring within the system 100. For example, such interactions/events may include interactions between an end user (or other person) and an enterprise 106, 108, 110, interactions between the various enterprises 106, 108, 110 within the system, events occurring within a particular enterprise 106, 108, 110, and/or other relevant interactions/events within the system 100 [0095 Fig. 6-7])
With respect to claim 4 and 11:
Yang further teaches:
wherein the full ledger comprises a second database, wherein the second database is configured to store all state data regarding the blockchain network. (The full node is a node that has a complete blockchain ledger, and the full node can independently verify all transactions on the blockchain and update data in real time or asynchronously. [0034])
wherein the instruction, when executed by the at least one processor individually or collectively. Further cause the electronic device to acquire the first state data from the third block node when the first state data is stored in the second database. (The light node can retain the recent data writing and query function locally, and can initiate data query to the full node when there is a historical data query need. [0035])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Sekar to set up node with partial ledger with the technique as disclosed by Yang to store full ledger in a block node for assuring data security and anti-tampering as Yang suggested [0032].
Claim 11, a method with the same scope as claim 4, is rejected.
With respect to claim 20:
Sekar further teaches wherein the full ledger of the blockchain system comprises at least one block corresponding to at least one transaction regarding the blockchain system, respectively, wherein the at least one block comprises a block hash comprising previous block information in the full ledger and previous block information in the partial ledger, and wherein the at least one block is connected in a directed acyclic graph (DAG) structure. (Each of the blocks in the illustrative blockchain 600 includes a transaction and a hash of the previous block's header (e.g., previous block to be added to the blockchain 600 chronologically). [0093-0099] Fig. 6-7)
Claim(s) 5-8, 12-15 and 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over " Sekar", "Yang" and "Anderson" as applied to claim 1, 9 and 16 above, and further in view of McKendree et al. (US 20250124159 A1).
With respect to claim 5, 12 and 17:
Sekar further teaches:
transmit a first data set and an […] request comprising the transaction to the second block node, receive an […] result comprising a second data set generated based on the […] request, and the first data set, from the second block node; wherein the first data set comprises state data required to execute the first smart contract, and wherein the second data set comprises state data to be stored in the first database, based on execution of the first smart contract. (The enterprise 106 (e.g., via the contact center system 114) may then transmit the request for data to the enterprise 108. In block 408, the system 100 (e.g., via the enterprise 106) may transmit the requested data received from the enterprise 108 to the end user device 102 (e.g., via the application 120 or, more particularly, the personal bot system). For example, the enterprise 106 may share with the end user device 102 the solution to address the issue with the end user's cable internet service. [0079 0086])
validate the […] result based on the hash information. (In block 508, each node in the blockchain network may verify whether the data transaction is valid or not (i.e., validate the data transaction). When the block is added to the blockchain, the block may link itself to the previous block in the blockchain. When the next new block arrives at the blockchain network, the next new block will cryptographically link itself to the block added Each of the blocks in the illustrative blockchain 600 includes a transaction and a hash of the previous block's header (e.g., previous block to be added to the blockchain 600 chronologically). [0091 0094])
Yang further teaches:
acquire hash information regarding the state data from the third block node through the communication circuitry, along with the node information. (The light node can retain the recent data writing and query function locally, and can initiate data query to the full node when there is a historical data query need. The account receivable information included in the target transaction can be …. a transaction digest value (Tx Hash) of the raw information of the account receivable that is published to the blockchain. [0035-0036])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system to acquire hash information with the technique as disclosed by Yang to store full ledger in a block node for assuring data security and anti-tampering as Yang suggested [0032].
Sekar in view of Yang and Anderson does not specifically teach endorsement. However,
McKendree teaches endorsement. (Other peer nodes in blockchain network 102 may verify the party attempting to update the student's ledger using the signer's public key to decrypt the hash. If the decrypted hash matches a hash of the same data generated by the peer node, then the endorsing peer node may verify the request. [0050])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Sekar in view of Yang and Anderson to endorse the requested data with the technique as disclosed by McKendree to prevent unauthorized tamping of the ledger contents [0050].
Claim 12, a method with the same scope as claim 5, is rejected.
Claim 17, a system with the same scope as claim 5, is rejected.
With respect to claim 6 and 13:
Sekar further teaches wherein the second data set is generated by the second block node executing a second smart contract based on the first data set. (The enterprise 106 (e.g., via the contact center system 114) may then transmit the request for data to the enterprise 108. In block 408, the system 100 (e.g., via the enterprise 106) may transmit the requested data received from the enterprise 108 to the end user device 102 (e.g., via the application 120 or, more particularly, the personal bot system). For example, the enterprise 106 may share with the end user device 102 the solution to address the issue with the end user's cable internet service. [0079 0086])
Claim 13, a method with the same scope as claim 6, is rejected.
With respect to claim 7 and 14:
Sekar further teaches:
generate transaction data regarding the transaction, based on the first data set and the second data set, with the endorsement result being validated; transmit a block generation request comprising the first data set, the second data set, and the transaction data to the third block node. (In block 510, the blockchain network may determine whether consensus has been reached among the nodes in the blockchain network. If the blockchain network determines that consensus has been reached among the nodes in the blockchain network, the method 500 may advance to block 512 in which the blockchain network may add the block to the blockchain. [0091])
receive an update request regarding the partial ledger and the first database, which is generated based on the block generation request, from the third block node, and update the partial ledger and the first database based on the update request. (In block 514, the blockchain network may label the data transaction as successful and update each node in the blockchain network with the block (e.g., the requested data may be provided to the enterprise 106 by the enterprise 108). [0091])
Claim 14, a method with the same scope as claim 7, is rejected.
With respect to claim 8 and 15:
Anderson further teaches wherein the update request is generated based on a result of comparing the first data set and the second data set with at least one of the hash information, block order information, a node list which are stored in the third block node. (The T1 blockchain does not independently validate all transactions. Instead, it validates T2 blocks as its inputs, which are assured to be valid since they are coming from full blockchain implementations. T2 networks package data in their blocks so that T1 can include and validate it more efficiently, putting more of the validation load on the T2 networks. For example, T1 nodes can reference a hash of entire T2 blocks that include a simplified representation of wallet balance updates. [0141])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system to compare hashes with the technique as disclosed by Anderson to enables massive scaling and high performance as Anderson suggested [0035].
Claim 15, a method with the same scope as claim 8, is rejected.
With respect to claim 18:
Sekar further teaches:
wherein the first electronic device is configured to generate transaction data corresponding to the transaction, based on the first data set and the second data set, based on the endorsement result. (The enterprise 106 (e.g., via the contact center system 114) may then transmit the request for data to the enterprise 108. In block 408, the system 100 (e.g., via the enterprise 106) may transmit the requested data received from the enterprise 108 to the end user device 102 (e.g., via the application 120 or, more particularly, the personal bot system). For example, the enterprise 106 may share with the end user device 102 the solution to address the issue with the end user's cable internet service. A node may initiate a data transaction and may sign the data transaction with its private key. In block 504, a block representing the data transaction may be created in the blockchain network. [0079 0086 0090-0091])
wherein the first electronic device is configured to transmit a block generation request comprising the first data set, the second data set, and the transaction data to the third electronic device. (the data transaction may be published to each node in the blockchain network. In block 508, each node in the blockchain network may verify whether the data transaction is valid or not (i.e., validate the data transaction). In some embodiments, the nodes in the blockchain network may use one or more consensus algorithms to validate the transaction. [0091])
Anderson further teaches wherein the third electronic device is configured to: compare the first data set and the second data set with at least one of hash information of the first state data, block order information, and a node list regarding the data which are stored in a memory of the third electronic device, and confirm the block based on a result of the comparing. (The T1 blockchain does not independently validate all transactions. Instead, it validates T2 blocks as its inputs, which are assured to be valid since they are coming from full blockchain implementations. T2 networks package data in their blocks so that T1 can include and validate it more efficiently, putting more of the validation load on the T2 networks. For example, T1 nodes can reference a hash of entire T2 blocks that include a simplified representation of wallet balance updates. [0141])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system to compare hashes with the technique as disclosed by Anderson to enables massive scaling and high performance as Anderson suggested [0035].
With respect to claim 19:
Sekar further teaches wherein, in response to the block being confirmed, the third electronic device is configured to request electronic devices related to the transaction to update according to the confirmed block, among at least one electronic device included in the blockchain system as a blockchain node. (If the blockchain network determines that consensus has been reached among the nodes in the blockchain network, the method 500 may advance to block 512 in which the blockchain network may add the block to the blockchain. the blockchain network may label the data transaction as successful and update each node in the blockchain network with the block. [0091])
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZESHENG XIAO whose telephone number is (571)272-6627. The examiner can normally be reached 10:00am-4:30pm M-F.
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, Patrick McAtee can be reached on (571) 272-7575. 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.
/Z.X./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698