DETAILED ACTION
This is office action on the merits in response to the application filed on 05/29/2026.
Claims 1-20 have been filed by the applicant.
Claims 1-5, 7-12, 14-18 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 .
Response to Argument
Rejection under 101:
The applicant traverses 101 rejections and states that the application addresses the technical problem of blockchain by protect privacy while preserving the integrity of data. The examiner respectfully disagrees. The claims recites a series steps involving determining whether or not a database possesses data and requesting the data from others if not, which is abstract idea of mental processes. The claims do not recite how blockchain is implemented in a non-conventional manner or how it improves computer or network functionality. Instead, blockchain is used for its expected purpose of storing data, which constitutes generally link the use of the judicial exception to a particular technological environment. Therefore, 101 is maintained.
Rejection under 103:
The applicant argues that the cited prior arts do not teach the amended feature of utilizing “key value” to look for data. Applicant' s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 4 and 11 rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claim 1 and 9 recite “the third block node comprising the full ledger and a second database”. However, dependent claims 4 and 11 further recite “second database does not store the data values associated with the transactions in the blockchain network” which is contradict with the independent claims. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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, a first database, and instructions, the partial ledger comprising a part of a full ledger regarding the blockchain network, wherein the full ledger comprises a plurality of blocks connected in parallel, and the first database stores at least one key value, and its corresponding at least one data value changed by execution of at least one transaction involving the first block node; 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:
receive, from a user, a request of a first transaction involving a first key value,
determine whether the first data value corresponding to the first key value necessary for executing a first smart contract in response to the request of the first transaction is stored in the first database of the first block node,
based on determining that the first data value corresponding to the first key value is not stored in the first database of the first block node, acquire, by the first block node, first hash information corresponding to the first key value, and first node information regarding at least one block node that stores the first data value corresponding to the first key value, through the communication circuitry from the third block node comprising the full ledger and a second database, wherein the second database stores key values associated with transactions in the blockchain network, node information regarding which node stores each of data values corresponding to each of the key values associated with the transactions in the blockchain network, and hash information corresponding to each of the data values associated with the transactions in the blockchain network,
acquire, at the first block node, the first data value corresponding to the first key value from the second block node among the at least one block node based on the first node information through the communication circuitry,
verify the acquired first data value based on the acquired first hash information, and
execute, when the acquired first data value is verified, the first smart contract based on the verified first data value
Limitations C through D under the broadest reasonable interpretation covers steps or functions that can be reasonably performed in the human mind as to determine whether or not data exist. 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 C through D recite an abstract idea, as highlighted above, that is consistent with the observation, evaluation, and judgment aspects of a mental process.
Furthermore, limitation B and E-G recites “receive transaction request, acquire information regarding data and acquire the data and execute contract,” which is equivalent to following rules or instruction. Limitation B and E-G 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, a first database, and instructions, the partial ledger comprising a part of a full ledger regarding the blockchain network, wherein the full ledger comprises a plurality of blocks connected in parallel, and the first database stores at least one key value, and its corresponding at least one data value changed by execution of at least one transaction involving the first block node; 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:
receive, from a user, a request of a first transaction involving a first key value,
determine whether the first data value corresponding to the first key value necessary for executing a first smart contract in response to the request of the first transaction is stored in the first database of the first block node,
based on determining that the first data value corresponding to the first key value is not stored in the first database of the first block node, acquire, by the first block node, first hash information corresponding to the first key value, and first node information regarding at least one block node that stores the first data value corresponding to the first key value, through the communication circuitry from the third block node comprising the full ledger and a second database, wherein the second database stores key values associated with transactions in the blockchain network, node information regarding which node stores each of data values corresponding to each of the key values associated with the transactions in the blockchain network, and hash information corresponding to each of the data values associated with the transactions in the blockchain network,
acquire, at the first block node, the first data value corresponding to the first key value from the second block node among the at least one block node based on the first node information through the communication circuitry,
verify the acquired first data value based on the acquired first hash information, and
execute, when the acquired first data value is verified, the first smart contract based on the verified first data value
The additional element(s) in limitation A and communication circuit in limitation D merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). The “blockchain”, “smart contract”, “nodes” and “hash information” recited in limitation C through G 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 consensus. 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)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 3 further recite first database stores data related to transaction which further recites the abstract idea. The limitation recites a generic computer to implement the abstract idea (MPEP § 2106.05(f)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 4 and 11 further recite second database storing data. 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. The additional elements fail to recite a practical application nor significantly more than the abstract idea.
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)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
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)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
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. The additional elements fail to recite a practical application nor significantly more than the abstract idea.
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. The additional elements fail to recite a practical application nor significantly more than the abstract idea.
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)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
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)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
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) and Novotny (US 20210149775 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, a first database, and instructions, the […] ledger comprising […] ledger regarding the blockchain network,[…]; 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])
receive, from a user, a request of a first transaction involving a first […] value, determine whether the first data value […] necessary for executing a first smart contract in response to the request of the first transaction 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 data value […] is not stored in the first database of the first block node, acquire, by the first block node, […], and first node information regarding at least one block node that stores the first data value […], 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 value […] from the second block node among the at least one block node based on the first node information through the communication circuitry. (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])
execute, […], the first smart contract […]. (The enterprise 106 (e In block 514, the blockchain network may label the data transaction as successful and update each node in the blockchain network with the block. [0091])
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 and a 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 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])
its corresponding at least one data value changed by execution of at least one transaction involving the first block node. (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].
Sekar in view of Yang and Anderson does not specifically teach the following limitations. However,
Novotny teaches (in italic):
the first database stores at least one key value; a request of a first transaction involving a first key value; first data value corresponding to the first key value. (The world state database may include a key-value store storing key-value pairs of data objects on the blockchain For example, the snapshot may be retrieved from an off-chain storage using an identifier of the snapshot such as a timestamp. [0086])
first hash information corresponding to the first key value. (In 514, the method may include retrieving a hash of the snapshot from a blockchain associated with the world state database. [0086])
wherein the second database stores key values associated with transactions in the blockchain network, node information regarding which node stores each of data values corresponding to each of the key values associated with the transactions in the blockchain network, and hash information corresponding to each of the data values associated with the transactions in the blockchain network. (The world state database may include a key-value store storing key-value pairs of data objects on the blockchain For example, the snapshot may be retrieved from an off-chain storage using an identifier of the snapshot such as a timestamp. [0086])
verify the acquired first data value based on the acquired first hash information; execute, when the acquired first data value is verified, […] on the verified first data value. (The chaincode receives a hash and retrieves from the blockchain a hash associated with the data template created by use of a previously stored feature extractor. If the hashes of the hash identifier and the hash created from the stored identifier template data match, then the chaincode sends an authorization key to the requested service.[0053])
Sekar in view of Yang and Anderson discloses a system for retrieving data from corresponding database. Novotny discloses a system for retrieving data from database based on identifier (i.e., key value) of each data.
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 utilizing a key value for retrieving data with the technique as disclosed by Novotny to access data efficiently and reliably as Novotny suggested [0044].
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 the at least one transaction...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 a consensus process. (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 first database stores the at least one key value and the at least one data value associated with the at least one transaction in which the first block node participates in a consensus process, and does not store other key values and their corresponding data values associated with other transactions in which the first block node does not participate in a consensus process. (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 second database does not store the data values associated with the transactions in 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])
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", "Anderson" and "Novotny" 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 first transaction to the second block node, wherein the first data set comprises the first data value, the first hash information, and the first node information, receive, from the second block node, an […] result comprises a second data set generated based on the […] request, and the first data set; 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 first 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])
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 and Novotny 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 and Novotny 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 first 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, the node information, and block order information which is 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 first transaction, based on the first data set and the second data set, with the endorsement result being validated. (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 the first hash information, the first node information and block order information which is stored in a memory of the third electronic device, and generate and confirm a block based on the block generation request and 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
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
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
Prosecution Insights