DETAILED ACTION
This non-final office action is in response to claims 1-20 filed on 03/14/2025 for examination. Claims 1-20 are being examined and 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 .
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.
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(s) 1-20 is/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. Particularly:
The term “directly” in claim 1, line 11 is a relative term which renders the claim indefinite. The term “directly” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. I.e., what is close enough to be considered “directly”? Claims 8-9, 15, 18, and 20 recite a similar deficiency, and are rejected under like rational. Claims 2-7, 10-14, 16-17, and 19 incorporate the deficiency of their parent claim, and are rejected under like rationale.
Claim 19 recites “the method” in line 1. There is insufficient antecedent basis for this limitation in the claim.
Consideration Under 35 USC § 101
Note: the claims have been considered and analyzed by the Examiner under 35 USC § 101 with respect to statutory category and judicial exceptions, and appear to recite a form of subject matter statutorily compliant with § 101.
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)(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.
Claim(s) 1, 3, 7-8, 10, 13-15, and 18-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Doney et al. (US20210304200; hereinafter “Doney”).
Regarding claim 1, Doney teaches a computing system (abstract), comprising: a processing system comprising one or more processors ([0069-071] – system implemented via processors executing instructions stored in memory) configured to:
receive an input dataset corresponding to an entity, the input dataset comprising asset attributes, identity information, or event metadata ([0039-043] and [0055] – Personally Identifiable Information “PIO”, Know You Customer “KYC” data, wallet information, entity data, transaction information, etc. <i.e., input dataset corresponding to an entity comprising attributes/ID info/event metadata> is input into a VASP/Identity Information Exchange/distributed computing system <i.e., computing system receiving the input dataset>);
generate encrypted data by encrypting the received input dataset ([0054-055] and [0010-015] – PII/KYC data/D1/etc. <i.e., input dataset> is encrypted into encrypted PII/KYC data/D1* <i.e., encrypted data generated>);
partition the encrypted data into a plurality of encrypted segments, each encrypted segment having a unique segment identifier associated with the encrypted segment ([0050-051] – the encrypted data may be stored in a decentralized storage system, e.g., IPFS may be used. In IPFS/decentralized storage, the encrypted data is split into a plurality of encrypted parts <i.e., segments> and stored in distributed nodes. IPFS hashes are used to track/reassemble the encrypted parts <i.e., unique identifiers associated with the encrypted segments>);
distribute each of the encrypted segments to at least one decentralized storage node selected from a plurality of decentralized storage nodes, wherein each decentralized storage node is configured to store or synchronize the encrypted segments ([0050-051] – the encrypted data may be stored in a decentralized storage system. E.g., IPFS may be used. In IPFS the encrypted data is split into a plurality of encrypted parts <i.e., segments> and stored across participating distributed nodes for storage <i.e., distributed to selected IPFS system nodes>. IPFS hashes are used to track/reassemble the stored encrypted parts);
generate a cryptographic token directly associated with the input dataset ([0055], [0062], and [0015-016] – a WalletRegistry/AuthTokenRegistry smart contract generates an AuthToken <i.e.,cryptographic token> including DataID, AccessKey, Source, and Client Wallet Address/account identifier <i.e., associated with the input dataset>);
embed metadata within the cryptographic token, the metadata comprising references identifying the encrypted segments stored on the decentralized storage nodes, a data provenance identifier associated with the input dataset, or a timestamp indicating creation of the cryptographic token ([0055], [0062], and [0015-016] – AuthToken <i.e., cryptographic token> includes D1*ID/DataID <i.e., reference identifying the encrypted stored data, including IPFS-stored encrypted file parts tracked by hashes>, AccessKey, PolicyID, Source, and Client Wallet Address/account identifier <i.e., metadata embedded in the AuthToken>. Source/VASP wallet and Client Wallet Address/account identifier identify the owner/client wallet associated with the dataset <i.e., data provenance identifier associated with the input dataset>);
deploy a smart contract to a distributed ledger technology (DLT) network, the smart contract configured to mint the cryptographic token and cryptographically link the metadata embedded in the cryptographic token to the encrypted segments stored at the decentralized storage nodes ([0050-051], [0055], [0062], and [0067-068] – a WalletRegistry/ AuthTokenRegistry smart contract is added on a blockchain, and used to generate <i.e., mint> an AuthToken <i.e., cryptographic token>. DataID, AccessKey, PolicyID, VASP wallet, Client Wallet, Address/account identifier <i.e., metadata> is embedded into the AuthToken <i.e., cryptographic token> linking the AuthToken <i.e., cryptographic token> with the encrypted dataset/parts); and
provide, via the deployed smart contract, authorized access to the input dataset associated with the cryptographic token according to access permissions embedded in the smart contract ([0019-025] and [0063-064] – Access is requested to the PII/KYC/D1 dataset <i.e., input dataset> by a recipient. The recipient signs the access request using the AuthTokenID <i.e., request for authorized access to the dataset is associated with the cryptographic token>. The request goes into the WalletRegistry/AuthTokenRegistry smart contract, which checks AuthToken-holder status/permissions <i.e., deployed smart contract enforces access permissions>. If authorized, the data host retrieved the encrypted files for decryption <i.e., provides authorized access>).
Regarding claim 3, Doney teaches the computing system of claim 1, wherein the processing system is configured to generate the cryptographic token so that the metadata embedded within the cryptographic token includes an access control list specifying one or more authorized entities permitted to access the encrypted segments associated with the cryptographic token ([0055] and [0062-063] – AccessKey, PolicyID/access policy, recipient wallet, and AuthToken-holder status <i.e., access control list/authorization metadata specifying authorized entities> included in/associated with the AuthToken data structure <i.e., metadata embedded within the cryptographic token> to permit designated wallets <i.e., authorized entities> to access the encrypted PII/KYC data/D1 associated with the AuthToken <i.e., provides access control for the encrypted data associated with the cryptographic token>; [0050-051] – the encrypted PII/KYC data/D1 may be split and stored as multiple encrypted parts <i.e., segments>).
Regarding claim 7, Doney teaches the computing system of claim 1, wherein the processing system is further configured to generate a provenance record associated with the input dataset, the provenance record including: a historical log recording updates to the input dataset; entity identifiers associated with entities responsible for each update; and timestamps corresponding to each recorded update ([0037-043], [0055], and [0062-063] – attestation updates, transaction operation records, AuthToken metadata, and SessionID records including a historical log of updates go into the compliance oracle, HEX distributed ledger, and session registry <i.e., provenance record associated with the input dataset>. VASP identifiers, authorized personnel identities, wallet addresses, account identifiers <i.e., entity identifiers associated with updating entities> as included in the records. Similarly, TTL/expiration data and transaction details are included/stored in the records <i.e., updates comprise timestamps>).
Regarding claim 8, Doney teaches the computing system of claim 1, wherein the processing system is configured to provide authorized access to the input dataset by: retrieving encrypted segments referenced by the cryptographic token from the decentralized storage nodes ([0050-051], [0055], and [0063-064] – DataID/D1*ID in the AuthToken <i.e., reference associated with the cryptographic token> goes into data host’s retrieval of encrypted files from IPFS/decentralized storage <i.e., retrieving encrypted segments from decentralized storage nodes>);
decrypting the retrieved encrypted segments using a private cryptographic key, wherein the private cryptographic key is linked directly to the cryptographic token and provisioned according to the access permissions embedded in the deployed smart contract ([0015-023], [0055], and [0063-064] – encrypted data D1** and AccessKey/K1* <i.e., retrieved encrypted data and token-linked key material> go into recipient wallet private key decryption <i.e., decrypting using a private cryptographic key> to procude D1*/K1 for decrypting the encrypted data); and
assembling the decrypted segments to reconstruct the original input dataset ([0051], [0023], and [0064] – IPFS parts <i.e., encrypted segments> are assembled based on hash values and decrypted using key K/K1 <i.e., decryption key obtained through token/private key access flow> to reconstruction PII/KYC data/D1 <i.e., original input dataset>).
Regarding claim 10, Doney teaches the computing system of claim 1, wherein: the deployed smart contract is configured to mint the cryptographic token by embedding validation rules within the smart contract ([0016], [0025], [0055], and [0062-063] – access policy, PolicyID, policy engine conditions, AuthToken-holder checks, qualifying transaction requirements, TTL/expiration data, and rights data <i.e., validation rules> go into/are used by the WalletRegistry/AuthTokenRegistry smart contract in connection with issuing AuthTokens and validating authorizations sessions <i.e., minting the token by embedding the used within the token-contract framework>); and
the validation rules define specific conditions under which authorized entities may access or modify the input dataset ([0025], [0042], and [0063-064] – AuthToken-holder status, qualifying transaction conditions, sender/recipient/context attributes, TTL/expiration data, and rights data <i.e., validation rules defining specific conditions> control whether entities are authorized to access the encrypted PII/KYC/D1 data <i.e., input dataset>).
Regarding claim 13, Doney teaches the computing system of claim 1, wherein the DLT network comprises an Ethereum protocol or a layer-one or layer-two protocol compatible with Ethereum ([0050-051] – the distributed ledger platform may be, e.g., an Ethereum blockchain <i.e., comprises Ethereum protocol).
Regarding claim 14, Doney teaches the computing system of claim 1, wherein the deployed smart contract is configured to mint the cryptographic token by: verifying authenticity of the input dataset by comparing the data provenance identifier embedded within the cryptographic token to a stored provenance record corresponding to the input dataset ([0024], [0039-041], and [0055] – Source=VASP wallet and Client Wallet Address/account identifier are included in the AuthToken <i.e., data provenance identifier embedded in the token>, and Wallet Registry/compliance-oracle/attestation-registry records linking wallet address to PII/KYC status and certification information <i.e., stored provenance record corresponding to the input dataset> are queried to confirm that the wallet/entity associated with the PII/etc. data is registered, certified, and/or associated with the retrievable PII data <i.e., verifying authenticity of the input dataset>); and
enforcing predefined access permissions embedded within the metadata of the cryptographic token according to an access control policy associated with the input dataset ([0025], [0055], and [0063-064] – PolicyID, AccessKey, DataID, AuthTokenID, SessionID TTL/rights data, and AuthToken-holder status <i.e., predefined access permissions embedded within metadata of the cryptographic token> are enforced by the WalletRegistry smart contract and policy engine <i.e., smart contract enforces permissions according to policy> before the encrypted files are retrieved/accessed).
Regarding claim 15, Doney teaches A computer-implemented method for tokenizing entities performed by a processing system ([0069-071]) operating on a distributed ledger technology (DLT) network (abstract), the method comprising:
receiving an input dataset corresponding to an entity, the input dataset comprising asset attributes, identity information, or event metadata ([0039-043] and [0055] – Personally Identifiable Information “PIO”, Know You Customer “KYC” data, wallet information, entity data, transaction information, etc. <i.e., input dataset corresponding to an entity comprising attributes/ID info/event metadata> is input into a VASP/Identity Information Exchange/distributed computing system <i.e., computing system receiving the input dataset>);
generating encrypted data by encrypting the received input dataset ([0054-055] and [0010-015] – PII/KYC data/D1/etc. <i.e., input dataset> is encrypted into encrypted PII/KYC data/D1* <i.e., encrypted data generated>);
partitioning the encrypted data into a plurality of encrypted segments, each encrypted segment having a unique segment identifier associated with the encrypted segment ([0050-051] – the encrypted data may be stored in a decentralized storage system, e.g., IPFS may be used. In IPFS/decentralized storage, the encrypted data is split into a plurality of encrypted parts <i.e., segments> and stored in distributed nodes. IPFS hashes are used to track/reassemble the encrypted parts <i.e., unique identifiers associated with the encrypted segments>);
distributing each of the encrypted segments to at least one decentralized storage node selected from a plurality of decentralized storage nodes, wherein each decentralized storage node is configured to store or synchronize the encrypted segments ([0050-051] – the encrypted data may be stored in a decentralized storage system. E.g., IPFS may be used. In IPFS the encrypted data is split into a plurality of encrypted parts <i.e., segments> and stored across participating distributed nodes for storage <i.e., distributed to selected IPFS system nodes>. IPFS hashes are used to track/reassemble the stored encrypted parts);
generating a cryptographic token directly associated with the input dataset ([0055], [0062], and [0015-016] – a WalletRegistry/AuthTokenRegistry smart contract generates an AuthToken <i.e.,cryptographic token> including DataID, AccessKey, Source, and Client Wallet Address/account identifier <i.e., associated with the input dataset>);
embedding metadata within the cryptographic token, the metadata comprising references identifying the encrypted segments stored on the decentralized storage nodes, a data provenance identifier associated with the input dataset, or a timestamp indicating creation of the cryptographic token ([0055], [0062], and [0015-016] – AuthToken <i.e., cryptographic token> includes D1*ID/DataID <i.e., reference identifying the encrypted stored data, including IPFS-stored encrypted file parts tracked by hashes>, AccessKey, PolicyID, Source, and Client Wallet Address/account identifier <i.e., metadata embedded in the AuthToken>. Source/VASP wallet and Client Wallet Address/account identifier identify the owner/client wallet associated with the dataset <i.e., data provenance identifier associated with the input dataset>);
deploying a smart contract to the DLT network, the smart contract configured to mint the cryptographic token and cryptographically link the metadata embedded in the cryptographic token to the encrypted segments stored at the decentralized storage nodes ([0050-051], [0055], [0062], and [0067-068] – a WalletRegistry/ AuthTokenRegistry smart contract is added on a blockchain, and used to generate <i.e., mint> an AuthToken <i.e., cryptographic token>. DataID, AccessKey, PolicyID, VASP wallet, Client Wallet, Address/account identifier <i.e., metadata> is embedded into the AuthToken <i.e., cryptographic token> linking the AuthToken <i.e., cryptographic token> with the encrypted dataset/parts); and
providing, via the deployed smart contract, authorized access to the input dataset associated with the cryptographic token according to access permissions embedded in the smart contract ([0019-025] and [0063-064] – Access is requested to the PII/KYC/D1 dataset <i.e., input dataset> by a recipient. The recipient signs the access request using the AuthTokenID <i.e., request for authorized access to the dataset is associated with the cryptographic token>. The request goes into the WalletRegistry/AuthTokenRegistry smart contract, which checks AuthToken-holder status/permissions <i.e., deployed smart contract enforces access permissions>. If authorized, the data host retrieved the encrypted files for decryption <i.e., provides authorized access>).
Regarding claim 18, Doney teaches the method of claim 15, wherein providing authorized access to the input dataset comprises:
retrieving encrypted segments referenced by the cryptographic token from the decentralized storage nodes ([0050-051], [0055], and [0063-064] – DataID/D1*ID in the AuthToken <i.e., reference associated with the cryptographic token> goes into data host’s retrieval of encrypted files from IPFS/decentralized storage <i.e., retrieving encrypted segments from decentralized storage nodes>);
decrypting the retrieved encrypted segments using a private cryptographic key, wherein the private cryptographic key is linked directly to the cryptographic token and provisioned according to the access permissions embedded in the deployed smart contract ([0015-023], [0055], and [0063-064] – encrypted data D1** and AccessKey/K1* <i.e., retrieved encrypted data and token-linked key material> go into recipient wallet private key decryption <i.e., decrypting using a private cryptographic key> to procude D1*/K1 for decrypting the encrypted data); and
assembling the decrypted segments to reconstruct the original input dataset ([0051], [0023], and [0064] – IPFS parts <i.e., encrypted segments> are assembled based on hash values and decrypted using key K/K1 <i.e., decryption key obtained through token/private key access flow> to reconstruction PII/KYC data/D1 <i.e., original input dataset>).
Regarding claim 19, Doney teaches the method of claim 1, wherein the deployed smart contract is configured to mint the cryptographic token by: verifying authenticity of the input dataset by comparing the data provenance identifier embedded within the cryptographic token to a stored provenance record corresponding to the input dataset ([0024], [0039-041], and [0055] – Source=VASP wallet and Client Wallet Address/account identifier are included in the AuthToken <i.e., data provenance identifier embedded in the token>, and Wallet Registry/compliance-oracle/attestation-registry records linking wallet address to PII/KYC status and certification information <i.e., stored provenance record corresponding to the input dataset> are queried to confirm that the wallet/entity associated with the PII/etc. data is registered, certified, and/or associated with the retrievable PII data <i.e., verifying authenticity of the input dataset>); and
enforcing predefined access permissions embedded within the metadata of the cryptographic token according to an access control policy associated with the input dataset ([0025], [0055], and [0063-064] – PolicyID, AccessKey, DataID, AuthTokenID, SessionID TTL/rights data, and AuthToken-holder status <i.e., predefined access permissions embedded within metadata of the cryptographic token> are enforced by the WalletRegistry smart contract and policy engine <i.e., smart contract enforces permissions according to policy> before the encrypted files are retrieved/accessed).
Regarding claim 20, Doney teaches a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processing system in a computing device to perform operations ([0069-071] – implemented via processors executing instructions stored in memory) for tokenizing entities performed by a processing system operating on a distributed ledger technology (DLT) network (abstract, [0050-64]), the operations comprising:
receiving an input dataset corresponding to an entity, the input dataset comprising asset attributes, identity information, or event metadata ([0039-043] and [0055] – Personally Identifiable Information “PIO”, Know You Customer “KYC” data, wallet information, entity data, transaction information, etc. <i.e., input dataset corresponding to an entity comprising attributes/ID info/event metadata> is input into a VASP/Identity Information Exchange/distributed computing system <i.e., computing system receiving the input dataset>);
generating encrypted data by encrypting the received input dataset ([0054-055] and [0010-015] – PII/KYC data/D1/etc. <i.e., input dataset> is encrypted into encrypted PII/KYC data/D1* <i.e., encrypted data generated>);
partitioning the encrypted data into a plurality of encrypted segments, each encrypted segment having a unique segment identifier associated with the encrypted segment ([0050-051] – the encrypted data may be stored in a decentralized storage system, e.g., IPFS may be used. In IPFS/decentralized storage, the encrypted data is split into a plurality of encrypted parts <i.e., segments> and stored in distributed nodes. IPFS hashes are used to track/reassemble the encrypted parts <i.e., unique identifiers associated with the encrypted segments>);
distributing each of the encrypted segments to at least one decentralized storage node selected from a plurality of decentralized storage nodes, wherein each decentralized storage node is configured to store or synchronize the encrypted segments ([0050-051] – the encrypted data may be stored in a decentralized storage system. E.g., IPFS may be used. In IPFS the encrypted data is split into a plurality of encrypted parts <i.e., segments> and stored across participating distributed nodes for storage <i.e., distributed to selected IPFS system nodes>. IPFS hashes are used to track/reassemble the stored encrypted parts);
generating a cryptographic token directly associated with the input dataset ([0055], [0062], and [0015-016] – a WalletRegistry/AuthTokenRegistry smart contract generates an AuthToken <i.e.,cryptographic token> including DataID, AccessKey, Source, and Client Wallet Address/account identifier <i.e., associated with the input dataset>);
embedding metadata within the cryptographic token, the metadata comprising references identifying the encrypted segments stored on the decentralized storage nodes, a data provenance identifier associated with the input dataset, or a timestamp indicating creation of the cryptographic token ([0055], [0062], and [0015-016] – AuthToken <i.e., cryptographic token> includes D1*ID/DataID <i.e., reference identifying the encrypted stored data, including IPFS-stored encrypted file parts tracked by hashes>, AccessKey, PolicyID, Source, and Client Wallet Address/account identifier <i.e., metadata embedded in the AuthToken>. Source/VASP wallet and Client Wallet Address/account identifier identify the owner/client wallet associated with the dataset <i.e., data provenance identifier associated with the input dataset>);
deploying a smart contract to the DLT network, the smart contract configured to mint the cryptographic token and cryptographically link the metadata embedded in the cryptographic token to the encrypted segments stored at the decentralized storage nodes ([0050-051], [0055], [0062], and [0067-068] – a WalletRegistry/ AuthTokenRegistry smart contract is added on a blockchain, and used to generate <i.e., mint> an AuthToken <i.e., cryptographic token>. DataID, AccessKey, PolicyID, VASP wallet, Client Wallet, Address/account identifier <i.e., metadata> is embedded into the AuthToken <i.e., cryptographic token> linking the AuthToken <i.e., cryptographic token> with the encrypted dataset/parts); and
providing, via the deployed smart contract, authorized access to the input dataset associated with the cryptographic token according to access permissions embedded in the smart contract ([0019-025] and [0063-064] – Access is requested to the PII/KYC/D1 dataset <i.e., input dataset> by a recipient. The recipient signs the access request using the AuthTokenID <i.e., request for authorized access to the dataset is associated with the cryptographic token>. The request goes into the WalletRegistry/AuthTokenRegistry smart contract, which checks AuthToken-holder status/permissions <i.e., deployed smart contract enforces access permissions>. If authorized, the data host retrieved the encrypted files for decryption <i.e., provides authorized access>).
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.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Doney in view of Sangle-Ferriere (US20210165914; Hereinafter “Sangle-Ferriere”).
Regarding claim 2, Doney teaches the computing system of claim 1. Yet, Doney appears to fail to specifically disclose wherein the processing system is further configured to: verify integrity of the input dataset prior to encrypting the input dataset by: generating a cryptographic hash based on the input dataset; and comparing the generated cryptographic hash with a stored reference hash to confirm the integrity of the input dataset.
However, Sangle-Ferriere teaches a similar system for verifying integrity of a dataset, wherein the processing system is further configured to: verify integrity of the input dataset prior to encrypting the input dataset ([0011-014], [0106-0111], and [0190] – a file, dataset, message, or software package <i.e., input dataset> is checked to determine whether it has been modified. It is check by creating a hash of the present file/dataset/message/software package and comparing the generated hash against a first created/stored hash. If a match exists, integrity is verified) by: generating a cryptographic hash based on the input dataset ([0011-014], [0106-0111], and [0190] – a file, dataset, message, or software package <i.e., input dataset> is checked to determine whether it has been modified. It is check by creating a hash of the present file/dataset/message/software package and comparing the generated hash against a first created/stored hash. If a match exists, integrity is verified); and comparing the generated cryptographic hash with a stored reference hash to confirm the integrity of the input dataset ([0011-014], [0106-0111], and [0190] – a file, dataset, message, or software package <i.e., input dataset> is checked to determine whether it has been modified. It is check by creating a hash of the present file/dataset/message/software package and comparing the generated hash against a first created/stored hash. If a match exists, integrity is verified).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doney with the teachings of Sangle-Ferriere, wherein the processing system is further configured to: verify integrity of the input dataset prior to encrypting the input dataset by: generating a cryptographic hash based on the input dataset; and comparing the generated cryptographic hash with a stored reference hash to confirm the integrity of the input dataset, to ensure the input dataset has not been tampered (see, e.g., Sangle-Ferriere at [0011-014], [0106-0111], and [0190]).
Claim(s) 4 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Doney in view of Bestler et al. (US20160191508; Hereinafter “Bestler”).
Regarding claim 4, Doney teaches the computing system of claim 1, wherein the processing system is configured to distribute each of the encrypted segments to the decentralized storage nodes by: assigning a subset of the encrypted segments to a specific decentralized storage node ([0050-051] – the encrypted data may be stored in a decentralized storage system. E.g., IPFS may be used. In IPFS the encrypted data is split into a plurality of encrypted parts <i.e., segments> and stored across participating distributed nodes for storage <i.e., distributed to selected IPFS system nodes>. IPFS hashes are used to track/reassemble the stored encrypted parts). However, Doney appears to fail to specifically disclose wherein the processing system is configured to distribute each of the encrypted segments to the decentralized storage nodes by: assigning a subset of the encrypted segments to a specific decentralized storage node selected based upon an availability score associated with the specific decentralized storage node; and replicating the assigned subset of encrypted segments on at least one additional decentralized storage node to improve data redundancy or fault tolerance.
Yet, Bestler teaches wherein the processing system is configured to distribute each of the encrypted segments to the decentralized storage nodes by: assigning a subset of the [[encrypted]] segments to a specific decentralized storage node selected based upon an availability score associated with the specific decentralized storage node ([0108-0115] and [0711-0713] – capacity/backlog/congestion/workload metrics for nodes <i.e., availability score associated with a specific decentralized storage node> are used when selecting storage servers from a negotiating group for storing chunks <i.e., when assigning which storage nodes to use to store segments>); and
replicating the assigned subset of [[encrypted]] segments on at least one additional decentralized storage node to improve data redundancy or fault tolerance ([0179-0180], [0573-586], and [0883] – chunks <i.e., segments> may be replicated in additional servers/failure domain servers to provide efficient/reliable access to requestors <i.e., improving data redundancy/fault tolerance>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doney with the teachings of Bestler, wherein the processing system is configured to distribute each of the encrypted segments to the decentralized storage nodes by: assigning a subset of the encrypted segments to a specific decentralized storage node selected based upon an availability score associated with the specific decentralized storage node; and replicating the assigned subset of encrypted segments on at least one additional decentralized storage node to improve data redundancy or fault tolerance, to improve reliability of the system (see, e.g., Bestler at [0108-0115], [0179-0180], and [0883]).
Regarding claim 16, Doney teaches the method of claim 15, wherein distributing each of the encrypted segments to the decentralized storage nodes comprises:
assigning a subset of the encrypted segments to a specific decentralized storage node ([0050-051] – the encrypted data may be stored in a decentralized storage system. E.g., IPFS may be used. In IPFS the encrypted data is split into a plurality of encrypted parts <i.e., segments> and stored across participating distributed nodes for storage <i.e., distributed to selected IPFS system nodes>. IPFS hashes are used to track/reassemble the stored encrypted parts). However, Doney appears to fail to specifically disclose wherein the processing system is configured to distribute each of the encrypted segments to the decentralized storage nodes by: assigning a subset of the encrypted segments to a specific decentralized storage node selected based upon an availability score associated with the specific decentralized storage node; and replicating the assigned subset of encrypted segments on at least one additional decentralized storage node to improve data redundancy or fault tolerance.
Yet, Bestler teaches wherein the processing system is configured to distribute each of the encrypted segments to the decentralized storage nodes by: assigning a subset of the [[encrypted]] segments to a specific decentralized storage node selected based upon an availability score associated with the specific decentralized storage node ([0108-0115] and [0711-0713] – capacity/backlog/congestion/workload metrics for nodes <i.e., availability score associated with a specific decentralized storage node> are used when selecting storage servers from a negotiating group for storing chunks <i.e., when assigning which storage nodes to use to store segments>); and
replicating the assigned subset of [[encrypted]] segments on at least one additional decentralized storage node to improve data redundancy or fault tolerance ([0179-0180], [0573-586], and [0883] – chunks <i.e., segments> may be replicated in additional servers/failure domain servers to provide efficient/reliable access to requestors <i.e., improving data redundancy/fault tolerance>).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doney with the teachings of Bestler, wherein the processing system is configured to distribute each of the encrypted segments to the decentralized storage nodes by: assigning a subset of the encrypted segments to a specific decentralized storage node selected based upon an availability score associated with the specific decentralized storage node; and replicating the assigned subset of encrypted segments on at least one additional decentralized storage node to improve data redundancy or fault tolerance, to improve reliability of the system (see, e.g., Bestler at [0108-0115], [0179-0180], and [0883]).
Claim(s) 5 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Doney in view of Nemethi (US11880836; Hereinafter “Nemethi”).
Regarding claim 5, Doney teaches the computing system of claim 1, wherein the processing system is configured to: associate the cryptographic token with a unique identifier corresponding to an individual entity or an Internet-of-Things (IoT) device ([0055] and [0062-063] – AuthToken includes Source=VASP wallet and Client Wallet/Address account identifier <i.e., associated token with entity/device>). However, Doney appears to fail to specifically disclose wherein the cryptographic token comprises a soulbound token (SBT) and the processing system is configured to: and restrict transferability of the cryptographic token to preserve its association with the unique identifier.
However, Nemethi teaches a similar system for authenticating blockchain permissions (see, e.g., abstract), wherein the cryptographic token comprises a soulbound token (SBT) (column 7, lines 12-52 – verification proofs <i.e., tokens> may be, e.g., a soulbound non-fungible token stored in a ledger. The soulbound token is nontransferable) and the processing system is configured to: restrict transferability of the cryptographic token to preserve its association with the unique identifier (column 7, lines 12-52 – soulbound NFTs are non-transferable and are issued to different blockchain addresses whose corresponding accounts are verified <i.e., restricting transferability/preserving association with the verified address/account).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doney with the teachings of Nemethi, wherein the cryptographic token comprises a soulbound token (SBT) and the processing system is configured to: restrict transferability of the cryptographic token to preserve its association with the unique identifier, to prevent unauthorized transfers of access rights to sensitive data (see, e.g., Doney at [0055] and [0062-063]; with Nemethi at column 7, lines 12-52).
Regarding claim 17, Doney teaches the method of claim 15, wherein the method further comprises: associating the cryptographic token with a unique identifier corresponding to an individual entity or an Internet-of-Things (IoT) device ([0055] and [0062-063] – AuthToken includes Source=VASP wallet and Client Wallet/Address account identifier <i.e., associated token with entity/device>). However, Doney appears to fail to specifically disclose wherein the cryptographic token comprises a soulbound token (SBT) and the processing system is configured to: and restrict transferability of the cryptographic token to preserve its association with the unique identifier.
However, Nemethi teaches a similar system for authenticating blockchain permissions (see, e.g., abstract), wherein the cryptographic token comprises a soulbound token (SBT) (column 7, lines 12-52 – verification proofs <i.e., tokens> may be, e.g., a soulbound non-fungible token stored in a ledger. The soulbound token is nontransferable) and restricting transferability of the cryptographic token to preserve its association with the unique identifier (column 7, lines 12-52 – soulbound NFTs are non-transferable and are issued to different blockchain addresses whose corresponding accounts are verified <i.e., restricting transferability/preserving association with the verified address/account).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doney with the teachings of Nemethi, wherein the cryptographic token comprises a soulbound token (SBT) and the processing system is configured to: restrict transferability of the cryptographic token to preserve its association with the unique identifier, to prevent unauthorized transfers of access rights to sensitive data (see, e.g., Doney at [0055] and [0062-063]; with Nemethi at column 7, lines 12-52).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Doney in view of Sarker (US20200051186; Hereinafter “Sarker”).
Regarding claim 6, Doney teaches the computing system of claim 1. While Doney teaches using the cryptographic token (see, e.g., Doney at [0055] and [0062]), Doney appears to fail to specifically disclose wherein the processing system is further configured to associate renewable energy certificate information with the cryptographic token, the renewable energy certificate information including: energy generation attributes including a generation timestamp, generation location, or source identifier; environmental descriptors identifying a renewable energy source; and certification information verifying renewable characteristics associated with the energy source.
However, Sarker teaches a similar system comprising a distributed ledger for issuing and recording information on a blockchain (see, e.g., abstract, [0028-030]), wherein the processing system is further configured to associate renewable energy certificate information with the cryptographic token ([0028-029], [0039-049], and [0055-056] – real-time REC <i.e., renewable energy credits> attributes and signed REC transaction data go into the blockchain-recorded real-time REC transaction <i.e., cryptographic token/token associated record>), the renewable energy certificate information including:
energy generation attributes including a generation timestamp, generation location, or source identifier ([0028], [0036-037], and [0056] –production time/start and time/end, production location, GPS coodinates, supplier, and asset ID <i.e., energy generation attributes including a generation timestamp, generation location, or source identifier> go into the REC record);
environmental descriptors identifying a renewable energy source ([0028], [0036-037], and [0056] – power types such as solar, wind, hydro, etc. <i.e., renewable energy sources> go into the REC attributes); and
certification information verifying renewable characteristics associated with the energy source ([0003] and [0055-056] – REC unique ID number, certifying entity registration, supplier signature, and asset/type/location fields <i.e., certification information associated with the energy source> go into the REC attributes).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doney with the teachings of Sarker, wherein the processing system is further configured to associate renewable energy certificate information with the cryptographic token, the renewable energy certificate information including: energy generation attributes including a generation timestamp, generation location, or source identifier; environmental descriptors identifying a renewable energy source; and certification information verifying renewable characteristics associated with the energy source, to securely track and control access to renewable energy certificate information (see, e.g., Sarker at [0028-029], [0039-049], and [0055-056]).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Doney in view of Nair et al. (US20230205445; Hereinafter “Nair”).
Regarding claim 9, Doney teaches the computing system of claim 1, configured to receive access requests directed to the decentralized storage nodes storing the encrypted segments (see, e.g., Doney at [0050-051] and [0063-064] – distributed nodes accessed to re-assemble/decrypt the encrypted parts), as well as log each access request for auditing purposes (Doney at [0043], [0048], and [0063] – AuthTokenID, SessionID, TTL, rights data, and transaction/reporting details <i.e., access request/session information> go into the on-chain session registry and regulatory reporting dashboard <i.e., log for auding purposes>). Yet, Doney appears to fail to specifically disclose wherein the processing system is further configured to: monitor access requests directed to the decentralized storage nodes storing the encrypted segments; dynamically route the monitored access requests to at least one decentralized storage node selected based upon network performance metrics or node availability.
However, Nair teaches a similar system for managing a distributed storage system (see, e.g., abstract), wherein the processing system is further configured to: monitor access requests [[directed to the decentralized storage nodes storing the encrypted segments]] ([0034], [0040], and [0060] – read/write requests, node states, and storage-node load <i.e., access request and node-status information> go into the cluster manager/processor monitoring the workflow <i.e., monitoring access requests to the distributed storage nodes);
dynamically route the monitored access requests to at least one decentralized storage node selected based upon network performance metrics or node availability ([0009], [0056-058], and [0066-067] – read request <i.e., monitored access request> goes into processor/controller unit/cluster manager unit <i.e., dynamic routing logic> which selects a storage node from a plurality of storage nodes/DRG based on latency, load, flash factor, node state, and other performance metrics <i.e., network performance metrics or node availability information>. The selected node is used to serve the read request).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doney with the teachings of Nair, further configured to: monitor access requests directed to the decentralized storage nodes storing the encrypted segments; dynamically route the monitored access requests to at least one decentralized storage node selected based upon network performance metrics or node availability, to improve system reliability, efficiency, performance (see, e.g., Nair at [0009], [0056-058], and [0066-067]).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Doney in view of Udupi et al. (US20160349993; Hereinafter “Udupi”).
Regarding claim 11, Doney teaches the computing system of claim 1, as well as storing encrypted segments (see, e.g., Doney at [0050-051]). Yet, Udupi appears to fail to specifically disclose wherein: the processing system is further configured to generate a visual representation of encrypted segment distribution across the decentralized storage nodes; and the visual representation identifies: each active decentralized storage node storing encrypted segments; allocation details identifying specific encrypted segments assigned to each decentralized storage node; and status indicators representing synchronization state or availability of each decentralized storage node.
However, Udupi teaches a similar system for managing distributed storage (see, e.g., abstract), wherein: the processing system is further configured to generate a visual representation of [[encrypted]] segment distribution across the decentralized storage nodes ([0023], [0041-043], [0053], and [0058-059] – object distribution information <i.e., segment distribution information> goes into visualization generator <i.e., processing system configured to generate a visual representation> to generate a display of the distribution across the nodes); and
the visual representation identifies: each active decentralized storage node storing [[encrypted]] segments ([0026-028], [0042], and [0053] – OSD lead nodes <i.e., active decentralized storage nodes storing segments> go into the graphical hierarchical map/tree <i.e., visual representation identifying each active decentralized storage node>);
allocation details identifying specific [[encrypted]] segments assigned to each decentralized storage node ([0025-028], [0045], and [0058-059] – objects/replicas <i.e., specific segments> go into CRUSH-determined placement groups and primary/secondary/tertiary OSDs <i.e., allocation details identifying specific segments assigned to each node>, and the object distribution goes into graphical place group/OSD displays <i.e., visual representation produced of allocation details>); and
status indicators representing synchronization state or availability of each decentralized storage node ([0017], [0035], [0045], [0054-055], and [0065] – OSD state, capacity, latency, load, volume, requests, performance metrics, rebalancing information, etc. <i.e., status indicators representing synchronization state or availability of each node> go into the OSD graphic UI elements/heatmaps).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doney with the teachings of Udupi, wherein: the processing system is further configured to generate a visual representation of encrypted segment distribution across the decentralized storage nodes; and the visual representation identifies: each active decentralized storage node storing encrypted segments; allocation details identifying specific encrypted segments assigned to each decentralized storage node; and status indicators representing synchronization state or availability of each decentralized storage node, to help administrators efficiently manage/store the encrypted data segments (see, e.g., Doney at [0050-051]; with Udupi at [0023], [0041-043], [0053], and [0058-059]).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Doney in view of Knop et al. (NPL: “IMB Spectrum Scale Security”; September 18, 2018; Hereinafter “Knop”).
Regarding claim 12, Doney teaches the computing system of claim 1, as well as using a decentralized storage node system to store encrypted segments (see, e.g., Doney at [0050-051]). Yet Doney appears to fail to specifically disclose wherein the processing system is further configured to secure the decentralized storage nodes by: encrypting communications transmitted between decentralized storage nodes; applying role-based access permissions to restrict administrative-level access exclusively to authorized administrators of the decentralized storage nodes; and maintaining an audit log configured to record administrative activities performed on each decentralized storage node.
However, Knop teaches a system for secure communications in decentralized storage systems (see, e.g., § 1.1, 5.3, and 5.4.1), wherein the processing system is further configured to secure the [[decentralized]] storage nodes by: encrypting communications transmitted between [[decentralized]] storage nodes (§ 1.1 and 5 – clustered storage nodes can securely communicate. E.g., sending and receiving cluster node communications go into the “Cipher”-mode secure communication protocol <i.e., encrypting communications transmitted between the nodes>. In cipher mode, the communications may be encrypted/protected. E.g., using AES128-GCM-SHA256);
applying role-based access permissions to restrict administrative-level access exclusively to authorized administrators of the [[decentralized]] storage nodes (§ 5.3 and 5.4.1 – predefined administrative roles/user groups and RBAC-authenticated REST administration <i.e., role based access permissions> go into GUI/REST management of storage cluster functions such as filesets, snapshots, and quotas <i.e., administrative level access to the storage nodes/system>. The administrative operations are restricted to authenticated users having administrative roles); and
maintaining an audit log configured to record administrative activities performed on each [[decentralized]] storage node (§ 5.4.1 and 7.2-7.2.1 – administrator/user commands, tasks, and cluster configuration changes involving the clustered storage nodes are tracked in audit logs/syslog/GPFS logs).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Doney with the teachings of Knop, wherein the processing system is further configured to secure the decentralized storage nodes by: encrypting communications transmitted between decentralized storage nodes; applying role-based access permissions to restrict administrative-level access exclusively to authorized administrators of the decentralized storage nodes; and maintaining an audit log configured to record administrative activities performed on each decentralized storage node, to protect sensitive data from unauthorized manipulation or access (see, e.g., § 1.1, 5.3, and 7.2-7.2.1).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Struttmann et al. (US20180205552; Hereinafter “Struttmann”) teaches a system for receiving a file, dividing the file into parts, and storing the parts across decentralized nodes for subsequent assembly (see, e.g., Struttman at abstract, [0006-009]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA RAYMOND WHITE whose telephone number is (571)272-4365. The examiner can normally be reached Monday-Thursday, & Alternate Fridays.
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, Taghi Arani can be reached at 5712723787. 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.
/J.R.W./Examiner, Art Unit 2438 /TAGHI T ARANI/Supervisory Patent Examiner, Art Unit 2438
Prosecution Insights