DETAILED ACTION
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 2/20/2026 has been entered.
-Claims 1 and 11 are amended.
-Claim 2 is cancelled.
-Claims 1 and 3-20 are pending.
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 Arguments
Applicant’s Remarks filed on 2/20/2026 have been fulling considered.
The double patenting rejecting is maintained until the final scope of the claims has been determined.
The arguments are mainly directed to the amended feature and therefore they are moot in view of the new grounds of rejection necessitated by the claim amendments.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1 and 3-10 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No.11,496,518. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in the issued patent in view of Liberman render obvious the claims in the current application. The motivation to modify with Liberman is that it may provide for tamper protection and detection of the substrate or the entries contained therein [Liberman, para.0107].
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1 and 3-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 11 recite the terms “the policy blockchain” which lack antecedent basis. For the purpose of examination, the claims are interpreted as reciting “the blockchain”.
The dependent claims inherit this rejection. Additionally, claims 3, 5-6 and 9 recite “a policy blockchain” and it is not clear whether these recitations are referring to the same “policy blockchain” recited in their respective parent claims.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1, 3-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The amended features recite “wherein the proposed policy is prevented from being committed to the policy blockchain if the external security posture information indicates a compromised, anomalous, or non-trusted operational state, even if the proposed policy satisfies the policy information stored in the policy blockchain”, however the specification does not appear to provide support for this feature. In the specification, [0058] states that if an external system determines an access request is suspicious, the request is denied even if it is supported by a policy. It does not describe preventing the proposed policy from being committed. Note that ,in that case, the policy would already be on the blockchain since it’s supported by the policy. On the other hand, [0076] of the specification describes preventing commitment only after consensus is reached. As such, the two embodiments are different and incompatible. As such, there no sufficient support for this amended feature.
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.
Claims 1 and 3-20 are rejected under 35 U.S.C. 103 as being unpatentable over Liberman et al (US Pub. No. 2023/0063172).
Re Claim 1. Liberman discloses: method, comprising: receiving, at a control plane of a zero trust (ZT) architecture (i.e. There are several base assumptions and requirements for such a system, when the environment is an open and public network, in which anyone may participate and no implicit trust is possible) [Liberman, paa.0048], a request to implement a proposed policy; forwarding the request to multiple policy engines of a blockchain policy engine (i.e. A participant broadcasts an entry which creates an anchoring point on the substrate. Each substrate participant receives the broadcasted entry and determines their interest. If interested, they apply consensus protocol of the current substrate in order to derive the validation substrate definition) [Liberman, para.0127-0128], (i.e. communicating a proposed transaction record 1310 comprising data indicative of a consensus and/or data validation rule to another participant via the electronic communications network 1316) [Liberman, para.0216-0217]; executing, by the policy engines, a consensus algorithm that decides whether or not the proposed policy will be implemented, wherein, as part of execution of the consensus algorithm, each of the policy engines performs a respective validation process with respect to the proposed policy (i.e. they apply consensus protocol of the current substrate in order to derive the validation substrate definition………………..Once all participants have confirmed their joining, they are expected to broadcast their decision on the entry validity onto validation substrate) [Liberman, para.0128, 0131]; and when a consensus is reached by the policy engines, either implementing the proposed policy (i.e. An Entry is a transaction envelope, container or wrapper that contains the data, e.g. event, transaction, assertion, or other payload, etc. on which consensus is sought. The data may further comprise data to be interpreted or executed by an application coupled with the disclosed consensus system. The data may also comprise one or more proposed data validation rules, which once these rules are themselves are validated, are used to validate subsequently received entries) [Liberman, para.0078, see also para.0311], (i.e. receiving and recording the validations of the entries, i.e. the consensus decisions/votes, of other participants, concluding when consensus has been reached and the entry has been validated, and storing the validated entry in the substrate or an anchoring substrate) [Liberman, para.0083], or preventing implementation of the proposed policy, as dictated by the consensus (i.e. A distributed consensus, as will be described, may then be applied to make sure that each record has confirmations from all participants to a transaction regarding authenticity of data, and serving as a legally binding agreement to its contents. For example, a requested change to data, which does not have all authorizing cryptographic signatures may not be allowed, or otherwise considered, to be stored in the system, that is the record may exist in the data structure but it may be regarded as incomplete, unenforceable) [Liberman, para.0292, see also para.0312]; wherein each of the validation processes is performed based on execution of an immutable smart contract (i.e. Once a transaction has been confirmed on the ledger it cannot be revoked even by mutual agreement in any way other than submitting a new transaction, which reverses the effects of the transaction in question. This property is achieved in blockchain through immutability and irrefutability) [Liberman, para.0055], which is saved in every policy engine (i.e. in one implementation, the party and the counter-party participant were each maintaining their own copy of the data,……………………each of the ledger devices 502A, 502B, 502C, 502n may include all the necessary hardware and software components to implement the Bilateral Distributed Ledger (BDL) system) [Liberman, para.0253, 0322], to determine whether or not to commit the proposed policy to a blockchain in each policy engine (i.e. as the broadcast makes the transaction/entry known to other participants and therefore cannot be concealed or denied by the participant who broadcast it. Each receiving participant may record the broadcasted entry/transaction and rely upon it as proof of commitment of the participant who broadcast it) [Liberman, para.0108];
Lieberman further discloses: and wherein the validation process determines eligibility of the proposed policy for commitment to the blockchain based on (i) policy information stored in the policy blockchain (i.e. In the case of a request data transaction message, the operation of the system includes processing of a request data transaction message (block 906). The operation of the system further includes identifying a participant to validate modifications to data (block 908); and modifying a portion of a shared data structure 320 according to the identified participant (block 910). The operation of the system 700 further includes generating a notification data transaction message (block 912) and transmitting the notification data transaction message (block 914). The operation of the system 700 further includes receiving, in response to the notification data transaction message, a validation data transaction message (block 916). The operation of the system 700 also includes determining if all, or a requisite subset of, e.g. as specified by a consensus protocol of a substrate definition (described in more detail below), identified participants have validated the request to modify data (918) and, if all, or alternatively, a requisite subset, of, the identified participants have validated the request to modify data, the operation of the system 700 includes generating a response data transaction message (block 920), transmitting the response data transaction message (block 922), and modifying the data stored in the portion of the shared data structure 320, or electronic ledger 732, (block 924)) [Liberman, para.0326, Fig. 9A, 9B] and (ii) dynamically received external security posture information obtained from at least one system external to the blockchain policy engine (i.e. validating the request to modify data (block 934). In particular, the request may be validated by communicating it, e.g. automatically upon receipt, via the user interface 712 or otherwise, to an external reviewer and/or to external business logic/business rules 718 which evaluate the request to determine whether it is valid or not, and indication of which is then communicated back to the system 700. The external business logic/business rules 718 may comprise ……………. a different entity such as a regulatory or oversight entity) [Liberman, para.0327, Fig. 9A, 9C], wherein the proposed policy is prevented from being committed to the policy blockchain if the external security posture information indicates a compromised, anomalous, or non-trusted operational state, even if the proposed policy satisfies the policy information stored in the policy blockchain (i.e. If the data request has not been approved, the operation of the system 700 further includes removing the data stored in the shared data structure 320 according to the request (block 946)) [Liberman, para.0327, Fig. 9C block 946 shows abandoning the proposed transaction which implies it is prevented from being stored on the blockchain. Note that, in this embodiment, the decision of the external system, which in this example is a regulatory or oversight entity, supersedes regardless of consensus or of a policy stored on the blockchain], (i.e. evaluate the change according to business logic or business rules which, as described above, may be previously agreed upon rules stored in a substrate, such as via an external program or external review process, to determine whether the change is acceptable/valid …………………. The business logic/business rules may further define, where the proposed value differs from the recalculated value, an acceptable range by which those values may differ. Other business rules/business logic may validate an assertion of fact against an independent source for that fact to confirm the veracity of the assertion. Still other business rules/business logic may define subjective or objective thresholds, value ranges, or sets of values, such as for measures of risk) [Liberman, para.0251, Note: measure of risk teaches compromise therefore the determination of whether to accept or reject is based on whether there is risk/compromise].
Liberman does not disclose all the above limitations in the same embodiment, however it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the different embodiments of Liberman because such a combination is suggested by Liberman: features that are described in this specification in the context of separate embodiments may also be implemented in combination in a single embodiment [Liberman, para.00449]. This motivation applies to the dependent claims.
Re Claim 3. Liberman discloses the method as recited in claim 1, wherein when the consensus indicates the proposed policy will be implemented, the proposed policy is committed to a respective policy blockchain that is included in each of the policy engines (i.e. the party and the counter-party participant were each maintaining their own copy of the data, the counter-party may reliably update this copy based on its response, i.e. be assured that its copy reflects the same state as the copy of the data structure maintained by the party) [Liberman, para.0253], (i.e. Only validated entries can be transmitted to the commitment fabric as accepted for commitment to the local ledger data store. Followers can validate leader's commitments by executing the same validation algorithm) [Liberman, para.0073], (i.e. as the broadcast makes the transaction/entry known to other participants and therefore cannot be concealed or denied by the participant who broadcast it. Each receiving participant may record the broadcasted entry/transaction and rely upon it as proof of commitment of the participant who broadcast it) [Liberman, para.0108].
Re Claim 4. Liberman discloses the method as recited in claim 1, wherein the validation process is configured to receive additional data from different system components (i.e. a validation substrate may be used which stores the consensus validation rules and the entry pending validation as well as the consensus decisions/votes, rendered, based on validation rules, of each validation substrate participant. Once consensus is reaches, e.g. all of the affirming decisions of the participants have been received, delegation rules are applied to determine what result is to be stored in an anchoring substrate) [Liberman, para.0110, 0113].
Re Claim 5. Liberman discloses the method as recited in claim 1, wherein when the proposed policy is malicious, commitment of the proposed policy to a policy blockchain is prevented after the consensus is reached (i.e. a user may use a computer to access a web site whereby the computer makes an assertion to a certifying authority, e.g. a Certificate Authority, that it is accessing the true web site and not a fraudulent web site. The assertion may include a copy of the web site's digital certificate. The validation of the assertion by the certifying authority then signals to the computer that it is safe to allow the user the access the web site. The validated assertion is maintained by the computer to authorize future accesses. Should the Certificate Authority later determine that the web site is fraudulent, it may assert a revocation which the computer then validates as an acknowledgement of the revocation) [Liberman, para.0277].
Re Claim 6. Liberman discloses the method as recited in claim 1, wherein each of the policy engines has a respective copy of a policy blockchain that stores (i.e. In a BDL implementation of a substrate for the implementation of the BAM, as will be described, the data structure may be subdivided into portions, each of which is maintained by one of the participants to store copies of data in which they have an interest, i.e. selectively replicated. As can be seen, in the BDL implementation of the BAM, where the counter-party participant may maintain their own copy of the data in which they have an interest, the counter-party participant, upon approving of the request can immediately update any copy of the data that they have in accordance with the requested change) [Liberman, para.0279] one or more policies (i.e. A data store definition may consist of multiple independent partitions, containers or layers, referred to as “substrates,” each of which include a set of consensus validation rules, a specification of a network transmission protocol paired with data representation specification (referred to herein as a “commitment fabric”), may additionally include a validation script, used to validate a proposed entry, e.g. transaction, and may further include one or more delegation rules which define interaction between a substrate and another substrate) [Liberman, para.0063].
Re Claim 7. Liberman discloses the method as recited in claim 1, wherein the policy engines are elements of a policy decision point that resides in the control plane (i.e. each substrate may include one or more consensus validation rules, optionally one or more delegation rules as well as one or more entries, described in more detail below, that have been validated. As will be described, substrate participants join the substrate using invitations, i.e. sent by a “leader,” and are then able to participate in consensus decisions, i.e. application of consensus validation rules to establish consensus as to storage/commitment of an entry to a substrate and data validation rules, regarding transactions, also referred to as entries or events, which reference those participants or submit new entries into the system) [Liberman, para.0066], (i.e. Upon collecting all required decisions and successful execution of validation logic, validation leader broadcasts the completed entry onto the substrate) [Liberman, para.0132].
Re Claim 8. Liberman discloses the method as recited in claim 1, wherein each of the policy engines is associated with a respective policy administrator (i.e. Each substrate participant receives the broadcasted entry and determines their interest. If interested, they apply consensus protocol of the current substrate in order to derive the validation substrate definition) [Liberman, para.0128], by way of which that policy engine is able to communicate with a byzantine fault tolerant enforcement point of a data plane (i.e. Once all participants have confirmed their joining, they are expected to broadcast their decision on the entry validity onto validation substrate) [Liberman, para.0131], (i.e. Consensus protocols may be implemented in the disclosed embodiments via various mechanisms, such as: Practical Byzantine Fault Tolerance (“PBFT”)) [Liberman, para.0192-0193].
Re Claim 9. Liberman discloses the method as recited in claim 1, wherein the proposed policy cannot be implemented unless, or until, the proposed policy is committed to a policy blockchain (i.e. Only validated entries can be transmitted to the commitment fabric as accepted for commitment …………………… The data may also comprise one or more proposed data validation rules, which once these rules are themselves are validated, are used to validate subsequently received entries) [Liberman, para.0073, 0078].
Re Claim 10. The method as recited in claim 1, wherein the proposed policy concerns access to a system resource (i.e. Rules which may be specified by a transaction record 1310 include rules defining participation, e.g. invitation rules, and permissions such as to control access to the portions of the memory 1304 by different subsets of the participants) [Liberman, para.0218].
Re Claim 11. Liberman discloses a method, comprising: receiving, at a data plane of a zero trust (ZT) architecture (i.e. There are several base assumptions and requirements for such a system, when the environment is an open and public network, in which anyone may participate and no implicit trust is possible) [Liberman, paa.0048], a request to access a system resource; forwarding the request to multiple policy enforcement points (i.e. receiving, from a user via a user interface 1312 or from another participant via the electronic communications network 1302/1316, a proposed transaction record 1310 for storage in the memory 1304 (Block 1404) and validating the proposed transaction record 1310 in accordance with each of the set of core rules 1308……………………… at least one of the set of core rules 1308 includes a rule for communicating a proposed transaction record 1310 comprising data indicative of a consensus and/or data validation rule to another participant via the electronic communications network 1316 and determining whether the other participant has accepted or rejected the rule, a rule for receiving a proposed transaction record comprising data indicative of a consensus and/or data validation rule from another participant and determining whether to accept or reject the rule) [Liberman, para.0228, 0216]; executing, by the policy enforcement points, a first consensus algorithm, and providing a resulting consensus to a policy decision point of a control plane (i.e. at least one of the set of core rules 1308 includes a rule for validating a proposed transaction record 1310 for storage in the memory 1304, i.e. a consensus validation rule for determining agreement to the storage of the proposed transaction record 1310 and/or a data validation rule……………. a proposed transaction record 1310 must be validated, e.g. agreed upon according to the consensus validation rules as described. Validated transaction records 1310 are then stored in the memory 1304 as described herein. It will be appreciated that proposed transaction records 1310 may also be stored in the memory 1304 temporarily as they undergo validation. To be validated, the proposed transaction record 1310 and/or the data contained therein, are assessed against the core set of rules 1308 and/or at least a subset of rules of previously validated and stored transaction records 1310. In this manner, the set of rules by which transaction records 1310 are validated may evolve to, as described herein, form complex transactional processes which implement a given transaction processing system as described
…………………….Once all participants have confirmed their joining, they are expected to broadcast their decision on the entry validity onto validation substrate) [Liberman, para.00216-0217,0131]; executing, by policy engines of the policy decision point, a second consensus algorithm (i.e. For the purposes of negotiating the consensus on the operation of transaction processing system overall, or with respect to a specific transaction/entry, a validation substrate may be used. Such a substrate can be either ephemeral or durable. In one embodiment, it will only include those participants relevant to a particular data entry that is the subject of the consensus/validation decision. If an entry contains sub-records, then a new validation substrate may be used for each of them thus forming a hierarchy of substrates which commit the consensus decisions to the parent using delegation rules within each substrate) [Liberman, para.0104, Note: it is interpreted that a first consensus algorithm may be performed for a specific transaction and a second consensus algorithm may be performed with respect to the operation of the transaction processing system] that decides whether or not a proposed policy will be implemented, wherein, as part of execution of the second consensus algorithm, each of the policy engines performs a respective validation process with respect to the proposed policy (i.e. they apply consensus protocol of the current substrate in order to derive the validation substrate definition………………..Once all participants have confirmed their joining, they are expected to broadcast their decision on the entry validity onto validation substrate…………………..generating a notification data transaction message for each identified participant, the notification data transaction message comprising data indicative of the request to modify the data in the portion of the shared data structure. The method may comprise transmitting each of the generated notification data transaction messages to the associated one of the identified at least one other participants……………receiving a validation data transaction message from each of the identified at least one other participants, each of the received validation data transaction messages comprising data indicative of a response to the request to modify data stored in the portion of the shared data structure, e.g. as indicated in the notification data transaction message. The method may comprise determining, based on the received validation data transaction messages, whether all, or at least a requisite subset, of the identified other participants have validated the request to modify the data) [Liberman, para.0128, 0131, 0280-0281], (i.e. communicating a proposed transaction record 1310 comprising data indicative of a consensus and/or data validation rule to another participant via the electronic communications network 1316) [Liberman, para.0216-0217]; receiving, by each of the policy enforcement points, a response from the policy decision point (i.e. If all, or at least the requisite subset, of the identified other participants have validated the request to modify the data in the portion of the shared data structure, the method may comprise generating a response data transaction message to the requesting participant, or, alternatively or in addition thereto, for each of the identified at least one other participants, comprising data indicative of a confirmation of the modification to the data in the portion of the shared data structure, transmit the response data transaction message to the requesting participant and/or each of the identified at least one other participants,) [Liberman, para.0282]; and applying, by one of the policy enforcement points, the proposed policy to the request (i.e. and modify the data stored in the portion of the shared data structure according to the request to modify the data) [Liberman, para.0282] wherein each of the validation processes is performed based on execution of an immutable smart contract(i.e. Once a transaction has been confirmed on the ledger it cannot be revoked even by mutual agreement in any way other than submitting a new transaction, which reverses the effects of the transaction in question. This property is achieved in blockchain through immutability and irrefutability) [Liberman, para.0055], which is saved in every policy engine (i.e. in one implementation, the party and the counter-party participant were each maintaining their own copy of the data,……………………each of the ledger devices 502A, 502B, 502C, 502n may include all the necessary hardware and software components to implement the Bilateral Distributed Ledger (BDL) system) [Liberman, para.0253, 0322], to determine whether or not to commit the proposed policy to a blockchain in each policy engine (i.e. as the broadcast makes the transaction/entry known to other participants and therefore cannot be concealed or denied by the participant who broadcast it. Each receiving participant may record the broadcasted entry/transaction and rely upon it as proof of commitment of the participant who broadcast it) [Liberman, para.0108].
In a manner similar to the rejection of the similar features in claim 1, Lieberman discloses: and wherein the validation process determines eligibility of the proposed policy for commitment and enforcement based on (i) policy information stored in the policy blockchain and (ii) dynamically received external security posture information obtained from at least one system external to the policy decision point, wherein the proposed policy is not committed to the policy blockchain and is not applied to the request if the external security posture information indicates a compromised or non-trusted state of the control plane, even if the proposed policy satisfies the policy information stored in the policy blockchain.
Liberman does not disclose all the above limitations in the same embodiment, however it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the different embodiments of Liberman because such a combination is suggested by Liberman: features that are described in this specification in the context of separate embodiments may also be implemented in combination in a single embodiment [Liberman, para.00449]. This motivation applies to the dependent claims.
Re Claim 12. Liberman discloses the method as recited in claim 11, wherein the policy enforcement points are implemented in a byzantine fault tolerant enforcement point in the data plane (i.e. the rule for validating a proposed transaction record 1310 comprises a proof of work, a federated agreement, a Practical Byzantine Fault Tolerance protocol, a Raft protocol or a combination thereof. In one embodiment, the rule for validating a proposed transaction record 1310 comprises solicitation of approval from at least a subset of the plurality of participants) [Liberman, para.0247].
Re Claim 13. Liberman discloses the method as recited in claim 11, wherein the response from the policy decision point is received at the policy enforcement points by way of policy administrators associated with the policy decision point (i.e. A substrate is a container responsible for writing results of consensus onto the commitment fabric. As described herein, a substrate includes consensus rules which are used to validate, i.e. reach consensus, on whether to store an entry or not. Furthermore, the substrate manages the process of soliciting, receiving and recording the validations of the entries, i.e. the consensus decisions/votes, of other participants, concluding when consensus has been reached and the entry has been validated, and storing the validated entry in the substrate or an anchoring substrate) [Liberman, para.0083].
Re Claim 14. Liberman discloses the method as recited in claim 11, wherein fPEP is a number of faulty policy enforcement points that can be accommodated (i.e. Each participant will broadcast their vote on the data and will be listening for other votes. Once the number of positive votes reaches the threshold, the entry is considered valid. The formula for the necessary number of participants is 3f+1, where f is the number of permitted faults) [Liberman, para.0198], while avoiding an overload of a validation process performed by the policy decision point (i.e. as data is only replicated selectively, i.e., only among the sub-divided portions of the data structure belonging to the participants which have an interest in that data, unnecessary data transmissions and replication are avoided and, as will be seen, the security of the data is thereby improved) [Liberman, para.0279].
Re Claim 15. Liberman discloses the method as recited in claim 11, wherein the first consensus algorithm comprises a byzantine fault tolerant protocol (i.e. Consensus protocols may be implemented in the disclosed embodiments via various mechanisms, such as: Practical Byzantine Fault Tolerance (“PBFT”)) [Liberman, para.0192-0193].
Re Claim 16. Liberman discloses the method as recited in claim 11, wherein the policy decision point begins a validation process concerning the request only after fPEP +1 responses are received by the policy decision point from the policy enforcement points (i.e. Co-signed assertion (Leader+n co-signers) wherein transactions require signatures from both the leader and one or more other parties, but can only be submitted by the leader) [Liberman, para.0113, Note: fPEP has not been defined in this claim and therefore any number n teaches fPEP], (i.e. the rule for validating a proposed transaction record comprises solicitation of approval from at least a subset of the plurality of participants) [Liberman, para.0227].
Re Claim 17. Liberman discloses the method as recited in claim 11, wherein when the response from the policy decision point comprises fPDP +1 policy decision point responses, the policy decision point that applies the policy to the request is a first policy decision point to receive the fPDP +1 responses (i.e. Each participant will broadcast their vote on the data and will be listening for other votes. Once the number of positive votes reaches the threshold, the entry is considered valid. The formula for the necessary number of participants is 3f+1, where f is the number of permitted faults) [Liberman, para.0198, Note that 3f+1 responses comprise f+1 responses; also note that the policy decision point in Liberman is the leader and since the leader is the first to determine the consensus decision, it follows that it would be the first to determine what the agreed upon policy is, namely whether to approve or reject the request].
Re Claim 18. Liberman discloses the method as recited in claim 17, wherein fPDP is a number of faulty policy decisions points (i.e. where f is the number of permitted faults) [Liberman, para.0198].
Re Claim 19. Liberman discloses the method as recited in claim 11, wherein the request is received at one of the policy enforcement points (i.e. data indicative of a request by the participant to modify data) [Liberman, para.0280], (i.e. processing one or more electronic data transaction messages among a plurality of participants/users) [Liberman, para.0214, Note: implies that the request is received from the user/participant at the participant’s device].
Re Claim 20. Liberman discloses the method as recited in claim 11, wherein the consensus confirms that the request is valid (i.e. receiving and recording the validations of the entries, i.e. the consensus decisions/votes, of other participants, concluding when consensus has been reached and the entry has been validated, and storing the validated entry in the substrate or an anchoring substrate) [Liberman, para.0083].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NOURA ZOUBAIR whose telephone number is (571)270-7285. The examiner can normally be reached Monday - Friday.
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, Ali Shayanfar can be reached at 571-270-1050. 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.
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434