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 .
Response to Amendments
The action is responsive to the Applicant’s Amendment filed on 5/11/2026. Claims 1-5, 7-12, 14-18, and 20 are pending in the application. Claims 1, 7, 8, 14, and 20 are amended. Claim 6, 13, and 19 are canceled.
Response to Arguments
Applicant’s arguments with respect to the rejections of claims 1-5, 7-12, 14-18, and 20 have been fully considered but they are not persuasive. In view of the claim amendments, the rejections are being updated accordingly.
In regards to independent claim 1, Applicant argued that, “Arevalillo does not teach or suggest… (1) creating a block representing the interaction to be placed in a distributed register, wherein the block comprises at least information associated with a previous block of the distributed register and information associated with the interaction.” However, Arevalillo explicitly teaches, “The SEQ number may for example be equal the hash of the chosen reception certificate of the previously validated round.” A block representing the interaction to be placed in a distributed register indicates intended use and is not given weight when it simply expresses the intended result of a process step positively recited. Also, the limitation of “wherein the block comprises at least information associated with a previous block of the distributed register and information associated with the interaction” is nonfunctional descriptive material, which merely describe different types of information elements that are not functionally involved in the steps recited. None of the claimed steps are depending on any of the information being described. All steps in the claims would be performed the same to achieve a same outcome regardless of the information because none of it is being used in a way that could impact the outcome of the claimed steps.
In addition, the Applicant argues that Arevalillo does not teach, “(2) in response to receiving the block representing the interaction, validating the block based on generating a hash for the block based on difficulty requirements associated with the block, wherein the difficulty requirements associated with the block are based on number of nodes in the distributed register, number of blocks, and number of users.” However, Arevalillo explicitly teaches validating the block based on generating a hash for the block as outlined in the Office Action below. The difficulty requirements are nonfunctional descriptive material, which merely describe different types of information elements that are not functionally involved in the steps recited. None of the claimed steps are depending on the difficulty requirements being described. All steps in the claims would be performed the same to achieve a same outcome regardless of the difficulty requirements because none of them is being used in a way that could impact the outcome of the claimed steps.
Thus, for at least the reasons as set forth above, it is submitted that the amended limitations are properly addressed by cited reference Arevalillo.
In regards to independent claims 8 and 14, the emphasized limitations that the Applicant argues in claims 8, and 14 are similar to the emphasized limitations of claim 1, which have been addressed above. See the response of claim 1 above for explanation.
Further, regarding the new limitations recited in claims 1, 7, 8, 14, and 20, it is submitted that they are properly addressed by the new ground of rejection.
Furthermore, it is also submitted that all limitations in pending claims, including those not specifically argued, are properly addressed. The reason is set forth in the rejections. See claim analysis below for details.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-5, 7-12, 14-18, and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by de la Rocha Gómez-Arevalillo (US 20210126800 A1).
Regarding Claim 1, de la Rocha Gómez-Arevalillo discloses a computer system for validating one or more blocks of a distributed register ([0078]: FIG. 1 shows a schematic diagram of a possible system architecture; Fig. 5b; [0133]-[0138]: nodes may use a classical register where they store the state… They may choose to validate all of its data through the quantum ring, or… they may prefer to only use the quantum ring for the validation of certain blocks; [0002]: The present invention relates to DLT (Distributed Ledger Technology)… offered in DLT networks (for example, in networks using blockchain technology), comprising:
a classical computer apparatus comprising: a processor; a memory (Fig. 1; [0084]: Each DLT network comprises one or more (usually many of them) nodes (computing nodes); the computing nodes are electronic devices of any type (for example, servers) including databases storage capacity (memory) and processing capacity (processor)); and
a validation application that is stored in the memory and executable by the processor ([0004]: Consensus algorithms are one of the core components of blockchain systems (and generally speaking of DLT systems). It is the piece responsible for the orchestration of transactions, and the synchronization and validation of data in the network);
a quantum optimizer in communication with the classical computer apparatus (Fig. 1; [0084]: The present invention purposes the implementation of a quantum network layer (called from now on, quantum trust ring) between different nodes underlaying different DLT (e.g. blockchain) networks, consensus algorithms, and distributed systems),
the quantum optimizer comprising: a quantum processor; and a quantum memory (Fig. 1; [0063] A processor configured to validate the b computing node data bits using the quantum error correction scheme based on the entangled data qubits from one or more other computing nodes of the group; [0086]: The quantum trust ring employs quantum error correction algorithms to enforce the trust of data between networks; [0114]: the quantum trust ring is designed to be used as an auxiliary independent security layer for isolated blockchain platforms, DLT systems, or quantum consensus, or a group of them);
wherein the validation application is configured for:
receiving an interaction (Fig. 4; [0121]-[0123]: Whenever a node wants to start a validation round, it sends a message using the classical channel… The beginning of a new validation round is notified to the rest of nodes);
authenticating the interaction ([0126]-[0130]: Upon reception of a certificate, the node verifies its integrity and authenticity (through the certificate signature); [0003]: security is accomplished through cryptographic keys and signatures);
creating a block representing the interaction to be placed in a distributed register (Fig. 4; [0119]: DATA is the specific validation data… This data may be a block proposal (with the specific format of the overlaying blockchain platform; [0126]-[0131]: When a node has received the data from all its entangled counterparts… it builds a reception certificate… If everything is correct, the validation proposal… is the one selected to update the ledger and the state of the distributed network… The identifier for the block, or network state update stored, may be the hash of the reception certificate of the winner node),
wherein the block comprises at least information associated with a previous block of the distributed register and information associated with the interaction ([0057]: The SEQ number may for example be equal the hash of the chosen reception certificate of the previously validated round; [0114]: This SEQ number may equal the hash of the previously validated round);
transmitting the block representing the interaction to the quantum optimizer ([0087]: In the 3-qubit scheme presented in FIG. 2 the quantum state to be transmitted (first block, “Data”) is coded using two additional redundant qubits; [0114]: This datagram structure is the one sent on through the data qubits of the quantum scheme; [0128]: Every node shares its reception certificate signed… Hence, every node would send the following data structure signed with their private key);
wherein the quantum optimizer is configured for: in response to receiving the block representing the interaction, validating the block based on generating a hash for the block based on difficulty requirements associated with the block ([0119]: This SEQ number may equal the hash of the previously validated round… DATA is the specific validation data… the data to which the consensus algorithm is to be applied. This data may be a block proposal (with the specific format of the overlaying blockchain platform; Fig. 2; [0130]: After receiving every reception certificate, it validates using the ancilla and redundancy bits that no data was forged in the validation round),
wherein the difficulty requirements associated with the block are based on number of nodes in the distributed register, number of blocks, and number of users ([0138]: Multiple networks (FIG. 5b): In this configuration, each network may be using his own consensus algorithm. They may choose to validate all of its data through the quantum ring, or if they only have a limited number of quantum nodes connected to the trust ring, they may prefer to only use the quantum ring for the validation of certain blocks [This is nonfunctional descriptive material. None of the steps in the claim are depending on this information.]); and
transmitting the validated block to the validation application ([0130]: If everything is correct, the validation proposal from, for example, the node that resulted in the measurement of the smaller random number is the one selected to update the ledger and the state of the distributed network).
Regarding Claim 2, de la Rocha Gómez-Arevalillo discloses the computer system of claim 1, wherein the validation application is configured for updating the distributed register with the validated block ([0051]: In an embodiment, the method further comprises: [0052]: If all the validations are positive, selecting in each computing node one of the validated data to update a corresponding ledger; [0132]: Once reception certificates have been validated, every node may use the data with the smaller random number to update the ledger and run the pertinent executions).
Regarding Claim 3, de la Rocha Gómez-Arevalillo discloses the computer system of claim 1, wherein the quantum optimizer is a node in a distributed register network associated with the distributed register ([0133]-[0134]: The quantum trust ring may be designed as an independent auxiliary network layer that may be implemented as a specific distributed network where the nodes of the quantum trust ring is formed by the nodes of the distributed network it gives service to (FIG. 5a, single network)).
Regarding Claim 4, de la Rocha Gómez-Arevalillo discloses the computer system of claim 1, wherein the classical computer apparatus is a node in a distributed register network associated with the distributed register (Fig. 5a; [0025]: In every block/data validation round in a distributed network (a DLT network), there is a pass of data messages between nodes… For its operation, the proposed embodiments may use a combination of quantum transmission channels (based on the entanglement between qubits of different nodes), and a classical channel like any other computational communication system; [0133]-[0134]: For their operation, nodes may use a classical register where they store the state).
Regarding Claim 5, de la Rocha Gómez-Arevalillo discloses the computer system of claim 1, wherein the block comprises more than one interactions (Fig. 4; [0121]-[0132]: Every node shares its reception certificate signed (to ensure its integrity) through the corresponding classical network transport layer. Hence, every node would send the following data structure signed with their private key).
Regarding Claim 7, de la Rocha Gómez-Arevalillo discloses the computer system of claim 6, wherein the hash for the block meets a difficulty level defined in the block ([0091]-[0113]: A basic Byzantine Fault Tolerant level of security is to be offered, i.e. the proposed embodiment must withstand at least one third of the nodes being faulty, compromised or malicious).
Regarding Claim 8, de la Rocha Gómez-Arevalillo discloses a computer program product for validating one or more blocks of a distributed register, comprising a non-transitory computer-readable storage medium having computer-executable instructions for causing a classical computer apparatus comprising to ([0070]: A digital data storage medium is also provided for storing a computer program comprising instructions, causing a computer executing the program to perform all steps of the disclosed methods when the program is run on a computer; Fig. 5b; [0133]-[0138]: nodes may use a classical register where they store the state… They may choose to validate all of its data through the quantum ring):
receiving an interaction (Fig. 4; [0121]-[0123]: Whenever a node wants to start a validation round, it sends a message using the classical channel… The beginning of a new validation round is notified to the rest of nodes);
authenticating the interaction ([0126]-[0130]: Upon reception of a certificate, the node verifies its integrity and authenticity (through the certificate signature) [0003]: security is accomplished through cryptographic keys and signatures);
creating a block representing the interaction to be placed in a distributed register (Fig. 4; [0119]: DATA is the specific validation data… This data may be a block proposal (with the specific format of the overlaying blockchain platform; [0126]-[0131]: When a node has received the data from all its entangled counterparts… it builds a reception certificate… If everything is correct, the validation proposal… is the one selected to update the ledger and the state of the distributed network… The identifier for the block, or network state update stored, may be the hash of the reception certificate of the winner node);
wherein the block comprises at least information associated with a previous block of the distributed register and information associated with the interaction ([0057]: The SEQ number may for example be equal the hash of the chosen reception certificate of the previously validated round; [0114]: This SEQ number may equal the hash of the previously validated round);
transmitting the block representing the interaction to a quantum optimizer ([0087]: In the 3-qubit scheme presented in FIG. 2 the quantum state to be transmitted (first block, “Data”) is coded using two additional redundant qubits; [0114]: This datagram structure is the one sent on through the data qubits of the quantum scheme; [0128]: Every node shares its reception certificate signed… Hence, every node would send the following data structure signed with their private key);
wherein the quantum optimizer is configured for: in response to receiving the block representing the interaction, validating the block (Fig. 2; [0130]: After receiving every reception certificate, it validates using the ancilla and redundancy bits that no data was forged in the validation round… If everything is correct, the validation proposal from, for example, the node that resulted in the measurement of the smaller random number is the one selected to update the ledger and the state of the distributed network); and
transmitting the validated block to a validation application in the classical computer apparatus (Fig. 4; [0138]: The quantum ring would perform the validation process and return the validated block to the network).
Regarding Claim 9, de la Rocha Gómez-Arevalillo discloses the computer program product of claim 8, wherein the validation application is configured for updating the distributed register with the validated block ([0051]: In an embodiment, the method further comprises: [0052]: If all the validations are positive, selecting in each computing node one of the validated data to update a corresponding ledger; [0132]: Once reception certificates have been validated, every node may use the data with the smaller random number to update the ledger and run the pertinent executions).
Regarding Claim 10, de la Rocha Gómez-Arevalillo discloses the computer program product of claim 8, wherein the quantum optimizer is a node in a distributed register network associated with the distributed register ([0133]-[0134]: The quantum trust ring may be designed as an independent auxiliary network layer that may be implemented as a specific distributed network where the nodes of the quantum trust ring is formed by the nodes of the distributed network it gives service to (FIG. 5a, single network)).
Regarding Claim 11, de la Rocha Gómez-Arevalillo discloses the computer program product of claim 8, wherein the classical computer apparatus is a node in a distributed register network associated with the distributed register (Fig. 5a; [0025]: In every block/data validation round in a distributed network (a DLT network), there is a pass of data messages between nodes… For its operation, the proposed embodiments may use a combination of quantum transmission channels (based on the entanglement between qubits of different nodes), and a classical channel like any other computational communication system; [0133]-[0134]: For their operation, nodes may use a classical register where they store the state).
Regarding Claim 12, de la Rocha Gómez-Arevalillo discloses the computer program product of claim 8, wherein the block comprises more than one interactions (Fig. 4; [0121]-[0132]: Every node shares its reception certificate signed (to ensure its integrity) through the corresponding classical network transport layer. Hence, every node would send the following data structure signed with their private key).
Regarding Claim 14, de la Rocha Gómez-Arevalillo discloses a method for validating one or more blocks of a distributed register ([Abstract]: Method and system which provides an increase in the basic security, performance, and trust of consensus algorithms in distributed systems based on the use of quantum technology (quantum computing mechanisms)), comprising:
receiving, via a classical computer apparatus, an interaction (Fig. 4; [0121]-[0123]: Whenever a node wants to start a validation round, it sends a message using the classical channel… The beginning of a new validation round is notified to the rest of nodes);
authenticating, via a classical computer apparatus, the interaction ([0126]-[0130]: Upon reception of a certificate, the node verifies its integrity and authenticity (through the certificate signature); [0003]: security is accomplished through cryptographic keys and signatures);
creating, via a classical computer apparatus, a block representing the interaction to be placed in a distributed register (Fig. 4; [0119]: DATA is the specific validation data… This data may be a block proposal (with the specific format of the overlaying blockchain platform; [0126]-[0131]: When a node has received the data from all its entangled counterparts… it builds a reception certificate… If everything is correct, the validation proposal… is the one selected to update the ledger and the state of the distributed network… The identifier for the block, or network state update stored, may be the hash of the reception certificate of the winner node);
wherein the block comprises at least information associated with a previous block of the distributed register and information associated with the interaction ([0057]: The SEQ number may for example be equal the hash of the chosen reception certificate of the previously validated round; [0114]: This SEQ number may equal the hash of the previously validated round);
transmitting, via a classical computer apparatus, the block representing the interaction to a quantum optimizer ([0087]: In the 3-qubit scheme presented in FIG. 2 the quantum state to be transmitted (first block, “Data”) is coded using two additional redundant qubits; [0114]: This datagram structure is the one sent on through the data qubits of the quantum scheme; [0128]: Every node shares its reception certificate signed… Hence, every node would send the following data structure signed with their private key);;
in response to receiving the block representing the interaction, validating, via the quantum optimizer(Fig. 2; [0130]: After receiving every reception certificate, it validates using the ancilla and redundancy bits that no data was forged in the validation round… If everything is correct, the validation proposal from, for example, the node that resulted in the measurement of the smaller random number is the one selected to update the ledger and the state of the distributed network),
the block based on generating a hash for the block based on difficulty requirements associated with the block, wherein the difficulty requirements associated with the block are based on number of nodes in the distributed register, number of blocks, and number of users (([0138]: Multiple networks (FIG. 5b): In this configuration, each network may be using his own consensus algorithm. They may choose to validate all of its data through the quantum ring, or if they only have a limited number of quantum nodes connected to the trust ring, they may prefer to only use the quantum ring for the validation of certain blocks [This is nonfunctional descriptive material. None of the steps in the claim are depending on this information.])
transmitting, via the quantum optimizer, the validated block to a validation application in the classical computer apparatus (Fig. 4; [0138]: The quantum ring would perform the validation process and return the validated block to the network).
Regarding Claim 15, de la Rocha Gómez-Arevalillo discloses the method of claim 14, wherein the validation application is configured for updating the distributed register with the validated block ([0051]: In an embodiment, the method further comprises: [0052]: If all the validations are positive, selecting in each computing node one of the validated data to update a corresponding ledger; [0132]: Once reception certificates have been validated, every node may use the data with the smaller random number to update the ledger and run the pertinent executions).
Regarding Claim 16, de la Rocha Gómez-Arevalillo discloses the method of claim 14, wherein the quantum optimizer is a node in a distributed register network associated with the distributed register ([0133]-[0134]: The quantum trust ring may be designed as an independent auxiliary network layer that may be implemented as a specific distributed network where the nodes of the quantum trust ring is formed by the nodes of the distributed network it gives service to (FIG. 5a, single network)).
Regarding Claim 17, de la Rocha Gómez-Arevalillo discloses the method of claim 14, wherein the classical computer apparatus is a node in a distributed register network associated with the distributed register (Fig. 5a; [0025]: In every block/data validation round in a distributed network (a DLT network), there is a pass of data messages between nodes… For its operation, the proposed embodiments may use a combination of quantum transmission channels (based on the entanglement between qubits of different nodes), and a classical channel like any other computational communication system; [0133]-[0134]: For their operation, nodes may use a classical register where they store the state).
Regarding Claim 18, de la Rocha Gómez-Arevalillo discloses the method of claim 14, wherein the block comprises more than one interactions (Fig. 4; [0121]-[0132]: Every node shares its reception certificate signed (to ensure its integrity) through the corresponding classical network transport layer. Hence, every node would send the following data structure signed with their private key).
Regarding Claim 20, de la Rocha Gómez-Arevalillo discloses the method of claim 19, wherein the hash for the block meets a difficulty level defined in the block, wherein the difficulty requirements are associated with the difficulty level defined in the block ([0086]: The quantum trust ring employs quantum error correction algorithms to enforce the trust of data between networks; [0091]-[0113]: A basic Byzantine Fault Tolerant level of security is to be offered, i.e. the proposed embodiment must withstand at least one third of the nodes being faulty, compromised or malicious).
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 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIRLEY D. HICKS whose telephone number is (571)272-3304. The examiner can normally be reached Mon - Fri 7:30 - 4: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, Charles Rones can be reached on (571) 272-4085. 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.
/S D H/Examiner, Art Unit 2168
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168
Prosecution Insights