DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1-18 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 1/7/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a token-generation module configured to generate” and “a metadata module configured to generate” in claim 1.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 limitations “a token-generation module configured to generate” and “a metadata module configured to generate” invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification makes clear that the claimed “modules" are software modules, and therefore not necessarily structural elements. Therefore, claims 1-10 are indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
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.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
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 of carrying out his invention.
Claims 1-10 are rejected under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, 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 pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention. As described above, the disclosure does not provide adequate structure to perform the claimed functions of “a token-generation module configured to generate a non-fungible token (NFT)” and “a metadata module configured to generate a metadata file”. The specification does not demonstrate that applicant has made an invention that achieves the claimed function because the invention is not described with sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention. None of claims 2-10 fix this and are therefore rejected for the same reasons.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 11 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claim recites a system which includes no physical elements. Claim 11 recites a system, comprising “a computer-readable data file”, “a non-fungible token”, “a metadata file”, and “a server for communicating”. However, the first three elements are merely data, and “a server” is software per se. Therefore, the claim recites neither a process, machine, manufacture, or composition of matter, and is ineligible under 35 U.S.C. 101.
Claims 12-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s) the concept of receiving data, by an entity, and using that data to access files in a data storage system, which is a mental process. This judicial exception is not integrated into a practical application because the method merely comprises steps for getting access to information of indeterminate use. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the only non-data elements, a data storage system, is merely used to store and retrieve information, a well-understood, routine, conventional computer function. None of claims 13-18 fix this and are therefore rejected for the same reasons.
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(s) 1-3, 6-8, 11-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang et al (PGPUB 2023/0108366), and further in view of Khan et al (PGPUB 2024/0396752).
Regarding Claim 1:
Tang teaches a system for data transfer between entities, said system comprising:
a server for communicating with a data storage system, said data storage system being accessible to each of said entities, and said server comprising ([abstract] systems and methods for encryption using blockchain distributed ledgers include a memory, one or more processors in communication with the memory, and program instructions executable, via the memory, by the one or more processors):
- a token-generation module configured to generate a non-fungible token (NFT) for recording in a blockchain ledger ([abstract] systems and methods for encryption using blockchain distributed ledgers include a memory, one or more processors in communication with the memory, and program instructions executable, via the memory, by the one or more processors; [0032] execution of the program instructions executes a mint function to create the single NFT on a blockchain); and
- a metadata module configured to generate a metadata file uniquely associated with said NFT, said metadata file containing a pointer to a computer-readable data [object] ([abstract] systems and methods for encryption using blockchain distributed ledgers include a memory, one or more processors in communication with the memory, and program instructions executable, via the memory, by the one or more processors; [0055] the example data file 400 is a non-limiting example that includes a metadata.json file that is a metadata file that is utilized for Ethereal NFT contracts that is modified to include a portfolio array object 494), said computer-readable data [object] containing access details for data in said data storage system ([0055] the example data file 400 is a non-limiting example that includes a metadata.json file that is a metadata file that is utilized for Ethereal NFT contracts that is modified to include a portfolio array object 494; the portfolio array object 494 enables standard Ethereum NFT contracts to include multiple related documents that can be transferred from one wallet to another in a single transaction via a single NFT 490; according to one embodiment, each portfolio array object 494 may include a document name, a description, a direct uniform resource locator (URL) link to the encrypted document(s), and an external URL to access the document webpage; an example document webpage may enable a user to log-in/register (with invite) to access the full unencrypted document(s)), said data only being accessible by way of said access details ([0055] an example document webpage may enable a user to log-in/register (with invite) to access the full unencrypted document(s)),
wherein said NFT immutably links to said metadata file ([0032] the single NFT includes a link (i.e., a tokenURL) to the generated data file; [0061] the NFT is minted to the user's wallet on the desired blockchain, and also stored therein is a tokenURL link set to the data file (e.g., a link to the metadata.json URL that is on the file sharing network)),
wherein said access details are retrievable from said computer-readable data [object] ([0055] according to one embodiment, each portfolio array object 494 may include a document name, a description, a direct uniform resource locator (URL) link to the encrypted document(s), and an external URL to access the document webpage; an example document webpage may enable a user to log-in/register (with invite) to access the full unencrypted document(s)), and
wherein said data is added to said data storage system by one of said entities and a different one of said entities receives said NFT ([0039] a minter/owner transfers the portfolio NFT to another individual, the encrypted symmetric key stored at the document gateway is no longer valid; the document gateway looks up the encrypted symmetric key in the computer readable medium and identifies that the NFT owner address stored with the key is no longer the same as the current owner address; the document gateway communicates with the NFT management module which communicates with the blockchain to verify a transfer occurred for the NFT and that the current owner address is registered to the current logged in user; …allowing the new owner to access and view the NFT documents, and disallowing the previous owner from doing so), such that said different one of said entities is able to retrieve said data by way of said metadata file, said computer-readable data [object], and said access details, thereby enabling data transfer between said entities ([0039] a minter/owner transfers the portfolio NFT to another individual; …allowing the new owner to access and view the NFT documents, and disallowing the previous owner from doing so; [0086] FIG. 12 depicts a flowchart of an example method 1200 for authorization of encrypted documents using blockchain distributed ledgers, according to an implementation of the present disclosure; at step 1202, a request is received to view an NFT that includes a link to access a portfolio data file that includes a portfolio array of links to, in part, multiple encrypted documents; at step 1204, based on receiving the request, the system determines whether the received request is authenticated; at step 1206, the system accesses a file system network that includes (i) the multiple encrypted documents, and (ii) unencrypted versions of the multiple encrypted documents, wherein the unencrypted versions are variations of the multiple encrypted documents; at step 1208, based on determining that the request received is authenticated, the system decrypts an encrypted symmetric key to access the multiple encrypted documents; at step 1210, the system decrypts, using the decrypted symmetric key, the multiple encrypted documents).
Tang does not explicitly teach wherein the computer-readable data [object] is a computer-readable data file; and
wherein said metadata file is amendable.
However, Khan teaches the concept wherein a computer-readable data [object] is a computer-readable data file ([0016] NFTs (e.g., as recorded to one or more distributed ledgers 101) may further be associated with attributes, metadata, etc., such as attributes of an asset represented by a given NFT, a Uniform Resource Locator (“URL”) or other link to one or more resources that include attribute information for the asset (herein “metadata”), or the like; in an example where a particular NFT represents a vehicle, asset attributes (e.g., as indicated by the NFT) may include a make, model, color, year, service history, or other attributes of the vehicle; additionally, or alternatively, the asset attributes may include a URL or other type of reference to a network-accessible resource (e.g., a webpage, an online spreadsheet, etc.), i.e. “file”); and
wherein a metadata file is amendable ([0042] client 201 may record the modifications to distributed ledger 101, such that distributed ledger 101 may maintain the metadata, provenance, attribute history, and other information associated with asset token 309, while also maintaining the updated attributes of the underlying asset (i.e. “metadata”, as above).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the data file and amendable metadata teachings of Khan with the NFT data transfer teachings of Tang, in order to format data using the abstraction of “files”, thereby improving user experience and efficiency by incorporating the improved human understanding of file-based concepts to maintain data organization. Further, incorporating amendable metadata allows for improved accountability and reliability for tracking assets which may change over time, such as physical assets tied to a blockchain NFT, ensuring that the condition of an asset does not deviate from the NFT metadata far enough to become unrecognizable.
Regarding Claim 2:
Tang in view of Khan teaches the system according to claim 1. In addition, Tang teaches wherein said server further comprises an encryption module for encrypting said access details to thereby produce encrypted access details and wherein said computer-readable data [object] comprises said encrypted access details ([0056] key_hash 491 property, which is the hash of a symmetric key that is used to encrypt the documents of the newly minted NFT 490; as contemplated herein, the key_hash 491 would not the symmetric key, but would rather be a SHA256 hash or similar of the symmetric key that would be used to verify that the symmetric key that is supplied for a future decryption process matches what was used to encrypt the documents of the newly minted NFT); and
Khan teaches the wherein a computer-readable data [object] is a computer-readable data file ([0016] as above).
The rationale to combine Tang and Khan is the same as provided in claim 1 due to the overlapping subject matter between claims 1 and 2.
Regarding Claim 3:
Tang in view of Khan teaches the system according to claim 2. In addition, Tang teaches wherein said encryption module also generates a private key for decrypting said access details ([0039] document gateway loads the old private document key stored in the computer readable medium associated with the NFT, derives the public document key from the private key, decrypts the symmetric key, and re-encrypts the symmetric key by using the private document key for the new owner; this new encrypted symmetric key for the new owner overwrites the old encrypted symmetric key on the computer readable medium, allowing the new owner to access and view the NFT documents, and disallowing the previous owner from doing so; EXAMINER’S NOTE: the document gateway has access to both the public and private keys; in this way, the public key can be seen as the private key and vice versa).
Regarding Claim 6:
Tang in view of Khan teaches the system according to claim 3. In addition, Tang teaches wherein said private key and said NFT are shared with a third party to enable said third party to retrieve said access details and to thereby access said data ([0067] at step 770A, a user module 712 may receive a request from a user device 702 to register a new user, and based thereon the user module 712 may create a new user account record on a computer-readable storage medium and register the user's existing wallets and/or generate new wallets for the requested blockchains 752, 754; at step 770B, the user module 712 may store private keys for the user wallets and generate a private document key for the user).
Regarding Claim 7:
Tang in view of Khan teaches the system according to claim 6. In addition, Tang teaches wherein said third party stores said access details in a third-party blockchain ledger, said third-party blockchain ledger being maintained by said third party ([0037] the user interacts with the NFT management module via a website user interface to transfer NFTs into and out of a user wallet; further, the NFT management module can be used to mint new portfolio NFTs as well as regular NFTs on any supported blockchain; these portfolio NFTs are minted, by the NFT management module, via smart contracts that the management module has deployed on the blockchains; further, the NFT management module communicates with a document gateway to store the documents associated with the NFT, and instructs the document gateway to create a symmetric encryption key used to encrypt all documents of the portfolio NFT).
Regarding Claim 8:
Tang in view of Khan teaches the system according to claim 1. In addition, Tang teaches wherein said data storage system is a distributed file storage system ([0043] first host computer system 120 may also connect to the file system network 155 such as, for example, InterPlanetary File System (IPFS), to store encrypted document files and NFT metadata; the file system network 155 may, according to various embodiments, be any protocol, hypermedia and file sharing peer-to-peer network for storing and sharing data in a distributed file system).
Regarding Claim 11:
Tang teaches a system for data transfer between entities, said system comprising:
a computer-readable data [object] containing access details for data in a data storage system, said data storage system being accessible to each of said entities and said data only being accessible by way of said access details ([0055] the example data file 400 is a non-limiting example that includes a metadata.json file that is a metadata file that is utilized for Ethereal NFT contracts that is modified to include a portfolio array object 494; the portfolio array object 494 enables standard Ethereum NFT contracts to include multiple related documents that can be transferred from one wallet to another in a single transaction via a single NFT 490; according to one embodiment, each portfolio array object 494 may include a document name, a description, a direct uniform resource locator (URL) link to the encrypted document(s), and an external URL to access the document webpage; an example document webpage may enable a user to log-in/register (with invite) to access the full unencrypted document(s));
a non-fungible token (NFT) recorded in a blockchain ledger ([0032] execution of the program instructions executes a mint function to create the single NFT on a blockchain; [abstract] blockchain distributed ledgers);
a metadata file uniquely associated with said NFT, said metadata file containing a pointer to said computer-readable data [object] ([0055] the example data file 400 is a non-limiting example that includes a metadata.json file that is a metadata file that is utilized for Ethereal NFT contracts that is modified to include a portfolio array object 494); and
a server for communicating with said data storage system and said blockchain ledger and for generating and editing said metadata file ([abstract] systems and methods for encryption using blockchain distributed ledgers include a memory, one or more processors in communication with the memory, and program instructions executable, via the memory, by the one or more processors),
wherein said NFT immutably links to said metadata file ([0032] the single NFT includes a link (i.e., a tokenURL) to the generated data file; [0061] the NFT is minted to the user's wallet on the desired blockchain, and also stored therein is a tokenURL link set to the data file (e.g., a link to the metadata.json URL that is on the file sharing network)),
wherein said computer-readable data [object] is encrypted ([0056] key_hash 491 property, which is the hash of a symmetric key that is used to encrypt the documents of the newly minted NFT 490; as contemplated herein, the key_hash 491 would not the symmetric key, but would rather be a SHA256 hash or similar of the symmetric key that would be used to verify that the symmetric key that is supplied for a future decryption process matches what was used to encrypt the documents of the newly minted NFT),
wherein said access details are retrievable from said computer-readable data [object] ([0055] according to one embodiment, each portfolio array object 494 may include a document name, a description, a direct uniform resource locator (URL) link to the encrypted document(s), and an external URL to access the document webpage; an example document webpage may enable a user to log-in/register (with invite) to access the full unencrypted document(s)),
and wherein said data is added to said data storage system by one of said entities and a different one of said entities receives said NFT, such that said different one of said entities is able to retrieve said data by way of said metadata file, said computer-readable data [object], and said access details, thereby enabling data transfer between said entities ([0039] a minter/owner transfers the portfolio NFT to another individual; …allowing the new owner to access and view the NFT documents, and disallowing the previous owner from doing so; [0086] FIG. 12 depicts a flowchart of an example method 1200 for authorization of encrypted documents using blockchain distributed ledgers, according to an implementation of the present disclosure; at step 1202, a request is received to view an NFT that includes a link to access a portfolio data file that includes a portfolio array of links to, in part, multiple encrypted documents; at step 1204, based on receiving the request, the system determines whether the received request is authenticated; at step 1206, the system accesses a file system network that includes (i) the multiple encrypted documents, and (ii) unencrypted versions of the multiple encrypted documents, wherein the unencrypted versions are variations of the multiple encrypted documents; at step 1208, based on determining that the request received is authenticated, the system decrypts an encrypted symmetric key to access the multiple encrypted documents; at step 1210, the system decrypts, using the decrypted symmetric key, the multiple encrypted documents).
Tang does not explicitly teach wherein the computer-readable data [object] is a computer-readable data file.
However, Khan teaches the concept wherein a computer-readable data [object] is a computer-readable data file ([0016] NFTs (e.g., as recorded to one or more distributed ledgers 101) may further be associated with attributes, metadata, etc., such as attributes of an asset represented by a given NFT, a Uniform Resource Locator (“URL”) or other link to one or more resources that include attribute information for the asset (herein “metadata”), or the like; in an example where a particular NFT represents a vehicle, asset attributes (e.g., as indicated by the NFT) may include a make, model, color, year, service history, or other attributes of the vehicle; additionally, or alternatively, the asset attributes may include a URL or other type of reference to a network-accessible resource (e.g., a webpage, an online spreadsheet, etc.), i.e. “file”).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the data file teachings of Khan with the NFT data transfer teachings of Tang, in order to format data using the abstraction of “files”, thereby improving user experience and efficiency by incorporating the improved human understanding of file-based concepts to maintain data organization.
Regarding Claim 12:
Tang teaches a method for transferring data between entities, said method comprising:
- receiving a non-fungible token (NFT) ([0039] a minter/owner transfers the portfolio NFT to another individual, the encrypted symmetric key stored at the document gateway is no longer valid; the document gateway looks up the encrypted symmetric key in the computer readable medium and identifies that the NFT owner address stored with the key is no longer the same as the current owner address; the document gateway communicates with the NFT management module which communicates with the blockchain to verify a transfer occurred for the NFT and that the current owner address is registered to the current logged in user; …allowing the new owner to access and view the NFT documents, and disallowing the previous owner from doing so);
- accessing a metadata file uniquely associated with said NFT, said metadata file containing a pointer to a computer-readable data [object] ([0055] the example data file 400 is a non-limiting example that includes a metadata.json file that is a metadata file that is utilized for Ethereal NFT contracts that is modified to include a portfolio array object 494; the portfolio array object 494 enables standard Ethereum NFT contracts to include multiple related documents that can be transferred from one wallet to another in a single transaction via a single NFT 490; according to one embodiment, each portfolio array object 494 may include a document name, a description, a direct uniform resource locator (URL) link to the encrypted document(s), and an external URL to access the document webpage; an example document webpage may enable a user to log-in/register (with invite) to access the full unencrypted document(s));
- accessing said computer-readable data [object] using said pointer, said computer-readable data [object] containing access details for data in a data storage system, said data only being accessible by way of said access details ([0055] an example document webpage may enable a user to log-in/register (with invite) to access the full unencrypted document(s)); and
- accessing said data by way of said access details ([0055] an example document webpage may enable a user to log-in/register (with invite) to access the full unencrypted document(s)),
wherein said data is added to said data storage system by one of said entities and said method is practiced by a different one of said entities, thereby enabling data transfer between said entities ([0039] a minter/owner transfers the portfolio NFT to another individual; …allowing the new owner to access and view the NFT documents, and disallowing the previous owner from doing so; [0086] FIG. 12 depicts a flowchart of an example method 1200 for authorization of encrypted documents using blockchain distributed ledgers, according to an implementation of the present disclosure; at step 1202, a request is received to view an NFT that includes a link to access a portfolio data file that includes a portfolio array of links to, in part, multiple encrypted documents; at step 1204, based on receiving the request, the system determines whether the received request is authenticated; at step 1206, the system accesses a file system network that includes (i) the multiple encrypted documents, and (ii) unencrypted versions of the multiple encrypted documents, wherein the unencrypted versions are variations of the multiple encrypted documents; at step 1208, based on determining that the request received is authenticated, the system decrypts an encrypted symmetric key to access the multiple encrypted documents; at step 1210, the system decrypts, using the decrypted symmetric key, the multiple encrypted documents).
Tang does not explicitly teach wherein the computer-readable data [object] is a computer-readable data file.
However, Khan teaches the concept wherein a computer-readable data [object] is a computer-readable data file ([0016] NFTs (e.g., as recorded to one or more distributed ledgers 101) may further be associated with attributes, metadata, etc., such as attributes of an asset represented by a given NFT, a Uniform Resource Locator (“URL”) or other link to one or more resources that include attribute information for the asset (herein “metadata”), or the like; in an example where a particular NFT represents a vehicle, asset attributes (e.g., as indicated by the NFT) may include a make, model, color, year, service history, or other attributes of the vehicle; additionally, or alternatively, the asset attributes may include a URL or other type of reference to a network-accessible resource (e.g., a webpage, an online spreadsheet, etc.), i.e. “file”).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the data file teachings of Khan with the NFT data transfer teachings of Tang, in order to format data using the abstraction of “files”, thereby improving user experience and efficiency by incorporating the improved human understanding of file-based concepts to maintain data organization.
Regarding Claim 13:
Tang in view of Khan teaches the method according to claim 12. In addition, Tang teaches wherein said access details contained in said computer-readable data [object] are encrypted and said method further comprises decrypting said access details after accessing said computer-readable data [object] ([0056] key_hash 491 property, which is the hash of a symmetric key that is used to encrypt the documents of the newly minted NFT 490; as contemplated herein, the key_hash 491 would not the symmetric key, but would rather be a SHA256 hash or similar of the symmetric key that would be used to verify that the symmetric key that is supplied for a future decryption process matches what was used to encrypt the documents of the newly minted NFT); and
Khan teaches the wherein a computer-readable data [object] is a computer-readable data file ([0016] as above).
The rationale to combine Tang and Khan is the same as provided in claim 12 due to the overlapping subject matter between claims 12 and 13.
Regarding Claim 14:
Tang in view of Khan teaches the method according to claim 13. In addition, Khan teaches wherein said computer-readable data file is an image file ([0016] NFTs (e.g., as recorded to one or more distributed ledgers 101) may further be associated with attributes, metadata, etc., such as attributes of an asset represented by a given NFT, a Uniform Resource Locator (“URL”) or other link to one or more resources that include attribute information for the asset (herein “metadata”), or the like; in an example where a particular NFT represents a vehicle, asset attributes (e.g., as indicated by the NFT) may include a make, model, color, year, service history, or other attributes of the vehicle; additionally, or alternatively, the asset attributes may include a URL or other type of reference to a network-accessible resource (e.g., a webpage, an online spreadsheet, etc.), i.e. “file”; the asset attributes may include an image of the vehicle, and/or a URL or other type of reference to an image of the vehicle).
The rationale to combine Tang and Khan is the same as provided in claim 12 due to the overlapping subject matter between claims 12 and 14.
Regarding Claim 15:
Tang in view of Khan teaches the method according to claim 12. In addition, Tang teaches wherein said computer-readable data [object] is stored in said data storage system ([0043] first host computer system 120 may also connect to the file system network 155 such as, for example, InterPlanetary File System (IPFS), to store encrypted document files and NFT metadata; the file system network 155 may, according to various embodiments, be any protocol, hypermedia and file sharing peer-to-peer network for storing and sharing data in a distributed file system); and
Khan teaches the wherein a computer-readable data [object] is a computer-readable data file ([0016] as above).
The rationale to combine Tang and Khan is the same as provided in claim 12 due to the overlapping subject matter between claims 12 and 15.
Regarding Claim 16:
Tang in view of Khan teaches the method according to claim 12. In addition, Tang teaches wherein said metadata file is stored in said data storage system ([0043] first host computer system 120 may also connect to the file system network 155 such as, for example, InterPlanetary File System (IPFS), to store encrypted document files and NFT metadata; the file system network 155 may, according to various embodiments, be any protocol, hypermedia and file sharing peer-to-peer network for storing and sharing data in a distributed file system).
Regarding Claim 17:
Tang in view of Khan teaches the method according to claim 12. In addition, Tang teaches wherein said data storage system is a distributed file storage system ([0043] first host computer system 120 may also connect to the file system network 155 such as, for example, InterPlanetary File System (IPFS), to store encrypted document files and NFT metadata; the file system network 155 may, according to various embodiments, be any protocol, hypermedia and file sharing peer-to-peer network for storing and sharing data in a distributed file system).
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang in view of Khan, and further in view of Bieber (EP 4366228).
Regarding Claim 4:
Tang in view of Khan teaches the system according to claim 2.
Neither Tang nor Khan explicitly teaches wherein said encryption module applies a steganography technique to embed said access details in said computer-readable data file.
However, Bieber teaches the concept wherein an encryption module applies a steganography technique to embed access details in a computer-readable data file ([0002] the NFT is not the digital file itself, but rather a token which serves as a representation of the digital file; more specifically, the NFT may include a URI which provides the location of a metadata file (in the form of a JSON file) which is stored at some location; that metadata file then contains information about the digital asset including, crucially, the storage location of that digital asset; [0034] rather than or in addition to the NFT ID being stored in the metadata related to the data relating to the digital asset, the NFT ID may be embedded into the data representing the digital asset; when the NFT ID is embedded into the data representing the digital asset itself, there is no separate e.g. field which comprises the NFT ID after it is stored: the combination of the digital asset and the NFT ID is represented by a unitary set of data; techniques for embedding data into digital assets in this manner are well-known, and include e.g. steganography and watermarking; [0081] once the NFT is minted as described above, there is a clear chain of connected features, as illustrated in Fig. 5; the metadata file 500 stored on IPFS contains a reference to the URL or other storage address of the modified digital asset 502 which is also stored on IPFS; the modified digital asset 502 contains an NFT ID 504 which refers uniquely to the address 506 of the smart contract 508 which minted the NFT, and the token ID 510 within the smart contract).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the steganography teachings of Bieber with the NFT data transfer teachings of Tang in view of Khan, in order to cryptographically encode an identifier in the computer-readable data file which inextricably links the data file back to the NFT, thereby improving security through use of a steganographic tag which provides a measurement of integrity and non-repudiation.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang in view of Khan, and further in view of Weigold et al (PGPUB 2025/0069094).
Regarding Claim 5:
Tang in view of Khan teaches the system according to claim 2.
Neither Tang nor Khan teaches wherein said computer-readable data file is an encrypted image file.
However, Weigold teaches the concept wherein a computer-readable data file is an encrypted image file ([0031]-[0040] creation or minting of an NFT linked to a unique physical item, using an integrated hardware and software device (referred to as a LaserMinter device), that executes the following steps: a) Creates a graphical 2D square information code or QR code called QR1 for the physical environment format; b) Laser engraves the QR1 code onto the physical asset or item (or attachable label); c) Creates a second different graphical information code or QR code called QR2 for the digital environment format; d) Stores the digital file for the QR2 code online using a cloud storage provider, preferably on a decentralized file storage platform for improved data security; e) Creates or mints a new NFT digital identifier using an appropriate blockchain network protocol and its linkage to the QR2 code via incorporation into the NFT smart contract of the metadata, internet address or URL for the QR2 code that is stored online as per step (1e); f) Creates a third different graphical information code or QR code called QR3 by applying either a standard or proprietary mathematical hash transformation, such as an irreversible hash algorithm that combines the data from QR1 and QR2 to produce a new unique combination QR code or proprietary data code QR3 for that specific NFT, that will be used in future for the verification of ownership of both the NFT and physical item via process (2) below; g) Uploads the QR3 code used for verification purposes to an online library, table, account ledger or blockchain network that permanently stores every QR3 code for every NFT ever created or minted by a LaserMinter device).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the QR code teachings of Weigold with the NFT data transfer teachings of Tang in view of Khan, in order to utilize a visual data file which can be used to encode both digital and physical assets, and using cryptographic techniques such as hashing to secure the codes and prevent copying for the purposes of counterfeiting.
Claim(s) 9, 10, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tang in view of Khan, and further in view of Ghosh et al (US 12,333,602).
Regarding Claim 9:
Tang in view of Khan teaches the system according to claim 1. In addition, Khan teaches, wherein, when said data in said data storage system is updated, said metadata file is amended ([0042] client 201 may record the modifications to distributed ledger 101, such that distributed ledger 101 may maintain the metadata, provenance, attribute history, and other information associated with asset token 309, while also maintaining the updated attributes of the underlying asset (i.e. “metadata”, as above).
The rationale to combine Tang and Khan is the same as provided in claim 1 due to the overlapping subject matter between claims 1 and 9.
Neither Tang nor Khan explicitly teaches wherein, when said data in said data storage system is updated, said access details, and said computer-readable data file are amended.
However, Ghosh teaches the concept wherein, when data in a data storage system is updated, access details, and a computer-readable data file are amended ([col 15 line 18-49] each NFT can include a linked metadata object and the metadata object may include protected and unprotected data; in various arrangements, the data processing system 102 can analyze, based on accessing the link of the NFT, the metadata object to determine if any protected data is present; that is, when protected data is present, the cold storage processor 180 may update the metadata object by extracting the protected data and storing the protected data in a newly generated cold storage object; [col 32 line 50-col 33 line 2] the NFT generator 370 can modify and delete tokens linked with primary NFTs or parent smart contract control structures, to update control of a partial transfer of metadata object control; for example, the NFT generator 370 can create a token controlling 25% of shares of a physical or digital asset, and modify a token originally controlling 100% of the physical asset to link with a smart contract control structure controlling 75% of the physical asset).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the amending access data teachings of Ghosh with the NFT data transfer teachings of Tang in view of Khan, in order to allow for improved accountability and reliability for tracking assets which may change over time, such as protected data tied to NFT metadata, ensuring that the condition of an asset does not deviate from the NFT metadata or smart contract far enough to become inaccessible.
Regarding Claim 10:
Tang in view of Khan teaches the system according to claim 1.
Neither Tang nor Khan explicitly teaches wherein said data is medical data relating to a patient.
However, Ghosh teaches the concept wherein data is medical data relating to a patient ([col 15 line 18-49] each NFT can include a linked metadata object and the metadata object may include protected and unprotected data; as used herein, “protected data” can include sensitive data such as, but not limited to, social security numbers (SSN), passport number, deoxyribonucleic acid (DNA), financial account number, other personal identifying information, biometric information, geolocation data indicating one or more locations of a person, photographs of people, criminal records, credit and/or payment card numbers, health data, and so on).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the protected sensitive data teachings of Ghosh with the NFT data transfer teachings of Tang in view of Khan, in order to allow for secure storage and access to sensitive data such as medical data using secure cryptographic techniques like NFTs tied to smart contracts, thereby preventing leakage of sensitive data and improving the security environment.
Regarding Claim 18:
Tang in view of Khan teaches the method according to claim 12.
Neither Tang nor Khan explicitly teaches wherein said data is medical data relating to a patient.
However, Ghosh teaches the concept wherein data is medical data relating to a patient ([col 15 line 18-49] each NFT can include a linked metadata object and the metadata object may include protected and unprotected data; as used herein, “protected data” can include sensitive data such as, but not limited to, social security numbers (SSN), passport number, deoxyribonucleic acid (DNA), financial account number, other personal identifying information, biometric information, geolocation data indicating one or more locations of a person, photographs of people, criminal records, credit and/or payment card numbers, health data, and so on).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the protected sensitive data teachings of Ghosh with the NFT data transfer teachings of Tang in view of Khan, in order to allow for secure storage and access to sensitive data such as medical data using secure cryptographic techniques like NFTs tied to smart contracts, thereby preventing leakage of sensitive data and improving the security environment.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FORREST L CAREY whose telephone number is (571)270-7814. The examiner can normally be reached 9:00AM-5:30PM M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, William Korzuch can be reached at (571) 272-7589. 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.
/FORREST L CAREY/Examiner, Art Unit 2491
/WILLIAM R KORZUCH/Supervisory Patent Examiner, Art Unit 2491