DETAILED ACTION
The present Office Action is in response to an application filed on 09/05/2024 wherein claims 1-20 are pending and ready for examination.
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 .
Priority
Applicant’s claim for the benefit of a prior-filed provisional application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/07/2025 is being considered by the examiner.
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-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,192,364. Although the claims at issue are not identical, they are not patentably distinct from each other because all elements of claims 1-20 of the instant application correspond to elements of claims 1-20 of the referenced U.S. Patent as indicated below:
Claim No.
Instant Application
Claim No.
US 12,192,364 B1
1, 11, 20
4, 14
2, 12
1, 11, 20
3, 13
2, 12
4, 14
3, 13
5, 15
5, 15
6, 16
6, 16
7, 17
7, 17
8, 18
8, 18
9, 19
9, 19
10
10
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 19 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.
Claim 19 recites the limitation "in response to receiving the at least one access data structure…" in line 4, and “in response to generating the at least one access data structure…” in line 8. There is insufficient antecedent basis for this limitation in the claim. Examiner suggests amending claim 19 to depend upon claim 18 instead of claim 11.
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-4, 8-14 and 18-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Gilchrist et al. (US 20250293882 A1), hereinafter Gilchrist.
Regarding claim 1, Gilchrist discloses a method for controlling access to cyber resilience data using cyber resilience identities and associated metadata (a method of securely memorializing events using SBTs cryptographically linked to immutable event records – see FIG. 15A, [0393-0403]), the method comprising:
receiving, by one or more processing circuits from an entity computing system of an entity corresponding to a cyber resilience identity or from an authorized entity computing system corresponding to an authorized entity of a plurality of authorized entities, an access request for the cyber resilience identity, the access request comprising at least one access data structure compatible with a control structure for restricting one or more updates and redemptions of a metadata object corresponding with the cyber resilience identity (referring to FIG. 15A, steps 1502 through 1510: the method receives a data input associated with an event, including event metadata (e.g., timestamp, identifier, and event-specific information) from an entity – see [0394]; a cryptographic hash is generated and, based on classification rules, data may be stored off-chain or on-chain, in which case the processing system may create a standardized token metadata record including the cryptographic hash, timestamp, origin identifier, and event-specific information formatted according to blockchain standards – see [0395-0397]; step 1514 creates a non-transferable token (e.g., SBT) representing the event, including the token metadata structure cryptographically bound to an identity key associated with the decentralized identifier (a unique decentralized identifier (DID) represents an entity or event, see [0004]) by executing blockchain-based smart contracts – see [0399]; the non-transferable token is stored on a DLT ledger in step 1516 – see [0400]; examiner’s note: this non-transferable token (e.g., SBT) is being considered by the examiner as the cyber resilience identity; in 1518, secure query [i.e., access request] of the token is allowed by authenticating a querying entity based on an identity key [i.e., access data structure] linked to the decentralized identifier and verifying access permissions encoded in the token metadata structure; the processing system may verify access permissions embedded in smart contract [i.e., control structure] rules governing token metadata and token querying – see [0401]);
verifying, by the one or more processing circuits using the control structure, the at least one access data structure (in 1518, secure query [i.e., access request] of the token is allowed by authenticating a querying entity based on an identity key [i.e., access data structure] linked to the decentralized identifier and verifying access permissions encoded in the token metadata structure; the processing system may verify access permissions embedded in smart contract [i.e., control structure] rules governing token metadata and token querying – see [0401]);
granting, by the one or more processing circuits, access to the metadata object and a performance event dataset of the cyber resilience identity to the entity or the authorized entity (in step 1518, the processing system may authenticate querying entities by verifying cryptographic signatures generated using private identity keys stored within entity-controlled digital wallets; may verify access permissions embedded in smart contract rules governing token metadata and token querying – see [0401]; in 1520, the processing system may retrieve data associated with the token – see [0402]; examiner’s note: by authenticating the querying entity and retrieving data associated with the token, it is understood that access has been granted; in terms of the data input associated with an event, including event metadata (e.g., timestamp, identifier, and event-specific information) from an entity that was tokenized in step 1514, “event data” refers to information about occurrences in a computing environment, such as user actions, system events, or security incidents (i.e., performance event dataset), and may include timestamps, origin identifiers, event types, and contextual details describing the occurrence – see [0053]; and, the input dataset corresponding to an entity may include asset attributes, identity information, or event metadata – see [0005]);
decrypting, by the one or more processing circuits, the metadata object (in 1520, the processing system may retrieve data associated with the token, including off-chain data referenced by the storage pointer, and reconstruct an event record including event metadata and associated data; the processing system may securely retrieve encrypted data shards from decentralized storage locations referenced by storage pointers and decrypt them using cryptographic keys derived from the DID, reconstructing a complete event record – see [0402]); and
providing, by the one or more processing circuits, the access to the metadata object and the performance event dataset by facilitating retrieval using a secure interface between the one or more processing circuits and the entity computing system or the authorized entity computing system (in 1522, the processing system may provide the event record to the querying entity in a human-readable format; the processing system may convert the reconstructed event record from encoded blockchain or storage formats into standardized, readable outputs such as PDF documents or structured JSON records displayed through secure user interfaces – see [0403]).
Regarding claim 2, Gilchrist discloses all the claimed subject matter recited in claim 1 above.
Furthermore, Gilchrist discloses the method, wherein the metadata object comprises metadata of cyber resilience data, wherein the cyber resilience identity comprises at least a link with the metadata object, a unique identifier (UID), and the performance event dataset, wherein at least a portion of the cyber resilience data is encrypted, wherein the cyber resilience identity is encapsulated in a control structure, and wherein the cyber resilience identity is broadcasted to a ledger or a distributed ledger (referring to FIG. 15A, steps 1502 through 1510: the method receives a data input associated with an event, including event metadata (e.g., timestamp, identifier, and event-specific information) from an entity – see [0394]; a cryptographic hash is generated and, based on classification rules, data may be stored off-chain or on-chain, in which case the processing system may create a standardized token metadata record including the cryptographic hash, timestamp, origin identifier, and event-specific information formatted according to blockchain standards – see [0395-0397]; in 1512, the processing system may generate a storage pointer referencing an off-chain storage location and incorporate the storage pointer into the token metadata structure in response to determining the data input may be stored off-chain; may generate a secure Uniform Resource Identifier (URI) linking to an off-chain storage repository on a decentralized storage network – see [0398]; in step 1514 creates a non-transferable token (e.g., SBT) representing the event, including the token metadata structure cryptographically bound to an identity key associated with the decentralized identifier (a decentralized identifier (DID) is a unique cryptographic identifier associated with the entity stored on a distributed ledger, see [0350] and [0410]) by executing blockchain-based smart contracts – see [0399]; the non-transferable token is stored on a distributed ledger in step 1516 – see [0400]).
Regarding claim 3, Gilchrist discloses all the claimed subject matter recited in claim 2 above.
Furthermore, Gilchrist discloses the method, wherein the control structure comprises a verification function to restrict the one or more updates and redemptions of the metadata object, the verification function executable by the control structure to validate one or more of the one or more updates and redemptions of the metadata object by verifying one or more cryptographic proofs of authorization of the plurality of authorized entities prior to updating the cyber resilience identity (the processing system may execute blockchain-based smart contracts [i.e., control structure] deployed on DLT networks such as Ethereum to mint identity-linked, SBTs [non-transferable tokens]; may create tokens by encoding non-transferability rules explicitly into the smart contract logic controlling token minting; may cryptographically bind tokens to the decentralized identifier by signing token metadata structures using the private identity key associated with the DID – see [0399]; the processing system may authenticate querying entities by verifying cryptographic signatures generated using private identity keys stored within entity-controlled digital wallets; may verify access permissions embedded in smart contract rules governing token metadata and token querying – see [0401]; see also [0410-0412]; the processing system may invoke blockchain-based smart contracts deployed on DLT networks, performing operations such as updating metadata content, retiring the token, or modifying metadata records – see [0445]).
Regarding claim 4, Gilchrist discloses all the claimed subject matter recited in claim 3 above.
Furthermore, Gilchrist discloses the method, further comprising:
receiving or identifying, by the one or more processing circuits, additional cyber resilience data of the entity corresponding to the cyber resilience identity (referring to FIG. 15B, in 1554, the processing system may electronically apply modifications to the original dataset, such as correcting inaccuracies, adding supplementary information, or removing sensitive entries – see [0406]);
receiving, by the one or more processing circuits, at least one cryptographic proof of provenance of the additional cyber resilience data (an authorized entity, such as a data steward or system administrator, electronically signs the child record using digital signature techniques (e.g., ECDSA signatures); the processing system electronically appends this verified child record to the ledger, ensuring traceability and authorized modification – see [0406]; in 1556, the processing system may electronically create additional child branches referencing the same parent record to establish a hierarchical, tree-like data provenance structure – see [0407]);
verifying, by the one or more processing circuits using the verification function of the control structure, the at least one cryptographic proof of provenance (in 1558, the processing system may electronically validate the integrity and consistency of the entire hierarchical lineage structure; the processing system may electronically perform a sequential recalculation of cryptographic hashes beginning from each child record, verifying each hash reference backward through all preceding parent records; and confirms that computed hashes match previously recorded ledger entries – see [0408]);
updating, by the one or more processing circuits using the control structure, the cyber resilience identity by updating the metadata object or appending the additional cyber resilience data to the performance event dataset (the processing system electronically links the child record by embedding a reference to the unique identifier or cryptographic hash of the parent record – see [0406]; each separate modification results in an electronically generated child record, each uniquely identified by a distinct cryptographic hash; the processing system electronically embeds references to the same parent identifier in each of these child records; as the processing system electronically appends each branch to the distributed ledger, the system develops a structured, hierarchical representation of divergent yet traceable data modifications – see [0407]; examiner’s note; when creating and managing non-transferable tokens linked to immutable event records which may include receiving an input from an entity including a DID uniquely associated with the entity, the system invokes a smart contract [i.e., control structure] deployed on a distributed ledger to mint an identity-based token linked to the DID, as discussed in [0410] and [0153]); and
broadcasting, by the one or more processing circuits using the control structure, the updated the cyber resilience identity to the ledger or the distributed ledger (the processing system may electronically create a parent record that represents an initial state of a dataset or digital asset; the processing system electronically stores this parent record within a distributed ledger system, such as a blockchain or permissioned ledger, establishing the baseline for data lineage tracking – see [0405]; the processing system may electronically insert a child record directly referencing the previously created parent record; the processing system electronically appends this verified child record to the ledger, ensuring traceability and authorized modification – see [0406]).
Regarding claim 8, Gilchrist discloses all the claimed subject matter recited in claim 1 above.
Furthermore, Gilchrist discloses the method, further comprising:
generating, by the one or more processing circuits, the at least one access data structure for at least one of the entity computing system of the entity corresponding to the cyber resilience identity or the authorized entity computing system corresponding to the authorized entity of the plurality of authorized entities; or receiving, by the one or more processing circuits from at least one of the entity computing system or the authorized entity computing system, the at least one access data structure (the processing system may receive the data input through a secure interface accessed by entities using digital wallets associated with decentralized identifiers (DIDs); the processing system may authenticate the received data input by verifying cryptographic signatures generated using private keys linked to the DID – see [0394]; in 1518, secure query [i.e., access request] of the token is allowed by authenticating a querying entity based on an identity key [i.e., access data structure] linked to the decentralized identifier and verifying access permissions encoded in the token metadata structure; the processing system may verify access permissions embedded in smart contract [i.e., control structure] rules governing token metadata and token querying – see [0401]; examiner’s note: the entity’s identity is linked to a decentralized identifier (DID), which is a unique cryptographic identifier stored on a distributed ledger, as discussed in [0350]).
Regarding claim 9, Gilchrist discloses all the claimed subject matter recited in claim 8 above.
Furthermore, Gilchrist discloses the method, wherein the least one access data structure comprises a token, key, certificate, or access mechanism (“identity key”), and wherein determining the at least one access data structure being compatible with the control structure comprises:
in response to receiving the at least one access data structure, configuring the at least one access data structure by updating the control structure to enforce restricting the one or more updates and redemptions of the metadata object, wherein updating the control structure comprises updating one or more access parameters of the control structure; or in response to generating the at least one access data structure, providing, by the one or more processing circuits to the entity computing system or the authorized entity computing system, the at least one access data structure (in 1514, the processing system may create a SBT representing the event, including the token metadata structure cryptographically bound to an identity key associated with the decentralized identifier; the processing system may execute blockchain-based smart contracts deployed on DLT networks such as Ethereum to mint identity-linked, SBTs; and, may create tokens by encoding non-transferability rules explicitly into the smart contract logic controlling token minting; the processing system may cryptographically bind tokens to the decentralized identifier by signing token metadata structures using the private identity key associated with the DID – see [0399]; the processing system may authenticate querying entities by verifying cryptographic signatures generated using private identity keys stored within entity-controlled digital wallets; the processing system may verify access permissions embedded in smart contract rules governing token metadata and token querying – see [0401]; invoking the smart contract may further include specifying rules for restricting access to the identity-based token based on predefined conditions associated with the entity – see [0411]).
Regarding claim 10, Gilchrist discloses all the claimed subject matter recited in claim 1 above.
Furthermore, Gilchrist discloses the method, wherein the cyber resilience data comprises at least one of firmographics data, safeguard data, performance data, policy data, incident data, or claims data (the method receives a data input associated with an event, including event metadata (e.g., timestamp, identifier, and event-specific information) from an entity – see [0394]; a cryptographic hash is generated and, based on classification rules, data may be stored off-chain or on-chain, in which case the processing system may create a standardized token metadata record including the cryptographic hash, timestamp, origin identifier, and event-specific information formatted according to blockchain standards – see [0395-0397]; “event data” refers to information about occurrences in a computing environment, such as user actions, system events, or security incidents, and may include timestamps, origin identifiers, event types, and contextual details describing the occurrence), and wherein the control structure comprises a smart contract – see [0053]).
Regarding claim 11, all limitations correspond to the system performing the method of claim 1. Therefore, claim 11 is being rejected on the same basis as claim 1.
Furthermore, Gilchrist discloses the system comprising one or more processing circuits (the various illustrative logical blocks, modules, circuits, and algorithmic steps described in connection with the aspects disclosed herein may be implemented as electronic hardware, computer software, or combinations of both – [0661]; the hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may include or be performed by a general-purpose processor… - see [0662]; see FIG. 1).
Regarding claim 12, all limitations correspond to the system performing the method of claim 2. Therefore, claim 12 is being rejected on the same basis as claim 2.
Regarding claim 13, all limitations correspond to the system performing the method of claim 3. Therefore, claim 13 is being rejected on the same basis as claim 3.
Regarding claim 14, all limitations correspond to the system performing the method of claim 4. Therefore, claim 14 is being rejected on the same basis as claim 4.
Regarding claim 18, all limitations correspond to the system performing the method of claim 8. Therefore, claim 18 is being rejected on the same basis as claim 8.
Regarding claim 19, all limitations correspond to the system performing the method of claim 9. Therefore, claim 19 is being rejected on the same basis as claim 9.
Regarding claim 20, all limitations correspond to the non-transitory computer-readable medium (CRM) comprising one or more instructions stored thereon and executable by one or more processors performing the method of claim 1. Therefore, claim 20 is being rejected on the same basis as claim 1.
Furthermore, Gilchrist discloses the non-transitory computer-readable medium (CRM) comprising one or more instructions stored thereon and executable by one or more processors (the functions described may be implemented in hardware, software, firmware, or any combination thereof; if implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable medium or non-transitory processor-readable medium – see [0663]).
Allowable Subject Matter
Claims 5-7 and 15-17 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Patent Documents
Luedtke et al. (US 20220156249 A1) - CORRELATING DIFFERENT TYPES OF DATA OF A DISTRIBUTED LEDGER SYSTEM
Manamohan et al. (US 20240256525 A1) - DECENTRALIZED POLICY-BASED TRANSACTIONAL OBJECT MANAGEMENT FOR FEDERATED WORKFLOWS
Miller et al. (US 20190377712 A1) - DISTRIBUTED WORK DATA MANAGEMENT
Murdoch et al. (US 20200401734 A1) - ENCRYPTING DATA ASSOCIATED WITH DECENTRALIZED IDENTIFIER
Quintas et al. (US 20170374067 A1) - DETERMINING A DEVICE POSTURE USING A DEVICE POSTURE TOKEN
Siegel et al. (US 20250267146 A1) - SYSTEMS AND METHODS FOR WEB 3.0 AND BEYOND-ENABLED MULTI-SYSTEM, MULTI-CLIENT, CYBER-RESILIENT DATA EXCHANGE PLATFORM LEVERAGING PERMISSION BLOCKCHAIN, EDGE COMPUTING, AND FEDERATED LEARNING TECHNOLOGY
Non-Patent Literature
Dai et al. (2023) - Blockchain-enabled cyber-resilience enhancement framework of microgrid distributed secondary control against false data injection attacks
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DORIANNE ALVARADO DAVID whose telephone number is (571)272-4228. The examiner can normally be reached 9:00am-5:00pm ET.
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, Philip Chea can be reached at (571) 272-3951. 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.
/DORIANNE ALVARADO DAVID/Examiner, Art Unit 2499 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499