Prosecution Insights
Last updated: April 19, 2026
Application No. 17/653,872

PROVIDING DATA PROVENANCE, PERMISSIONING, COMPLIANCE, AND ACCESS CONTROL FOR DATA STORAGE SYSTEMS USING AN IMMUTABLE LEDGER OVERLAY NETWORK

Final Rejection §101§103§112
Filed
Mar 08, 2022
Examiner
IMMANUEL, ILSE I
Art Unit
3699
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Dmg Blockchain Solutions Inc.
OA Round
4 (Final)
23%
Grant Probability
At Risk
5-6
OA Rounds
4y 7m
To Grant
50%
With Interview

Examiner Intelligence

Grants only 23% of cases
23%
Career Allow Rate
68 granted / 293 resolved
-28.8% vs TC avg
Strong +27% interview lift
Without
With
+27.1%
Interview Lift
resolved cases with interview
Typical timeline
4y 7m
Avg Prosecution
47 currently pending
Career history
340
Total Applications
across all art units

Statute-Specific Performance

§101
26.7%
-13.3% vs TC avg
§103
35.4%
-4.6% vs TC avg
§102
6.0%
-34.0% vs TC avg
§112
30.0%
-10.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 293 resolved cases

Office Action

§101 §103 §112
DETAILED ACTION Acknowledgements This office action is in response to the claims filed 12/10/2025. Claims 1-4 are cancelled. Claims 5, and 16 are amended. Claims 5-20 are pending. Claims 5-20 have been examined. Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Response to Arguments Applicant's arguments filed 12/10/2025 have been fully considered but they are not persuasive. 101 Applicant argues “The independent claims as amended recite that "the provenance record is encoded as a cryptographic event on the immutable cryptographic ledger that enables distributed verification across more than one ledger node and establishes an audit log indicating that data incorporated into the trained Al model originated from the data source entity." The distributed verification process involves multiple parties ensuring that the data on the blockchain is correct while the cryptographic event is propagated through the network and maintained across multiple ledger nodes ([0015], [0025]). A human with pen and paper cannot encode a provenance record as a cryptographic event, nor can a human enable distributed verification across multiple ledger nodes.” Examiner disagrees. First, the disclosure “([0015], [0025])”, makes no mention of “the provenance record is encoded as a cryptographic event on the immutable cryptographic ledger that enables distributed verification across more than one ledger node and establishes an audit log indicating that data incorporated into the trained Al model originated from the data source entity”. The disclosure(¶ 25) states “the blockchain contains an immutable audit log of all the activity. This component is significant in the system because unlike centralized data provenance solutions, the logs and execution of contracts in the blockchain do not require trusting any single party. Multiple untrusted parties are together ensuring that the data on the blockchain is correct…Authentication of a user is performed via the algorithm that the blockchain uses by cryptographic signatures using the user's key.”. There does not appear to be an “encoded” “provenance record”, there appears to be an audit log of the activity. And a human with pen and paper is capable of keeping an audit log of activities. The automation of this process does not negate the existence of an abstract idea. . Secondly, the limitation provides a description of the ledger “the immutable cryptographic ledger that enables distributed verification across more than one ledger node”. Applicant’s are not claiming the invention of a distributed network, just the use of one. The rejection is maintained. 112 Due to Applicant’s amendments, the prior 112 rejections are withdrawn. 103 Applicant argues “Neither reference teaches nor suggests generating a provenance record that indicates that an Al model includes data originating from a specific data source entity in a manner that enables distributed verification of the Al model's training integrity. The amended claims recite "generating a provenance record on the immutable cryptographic ledger that indicates that the Al model includes data originating from the data source entity, wherein the provenance record is encoded as a cryptographic event on the immutable cryptographic ledger that enables distributed verification across more than one ledger node and establishes an audit log indicating that data incorporated into the trained Al model originated from the data source entity… This limitation requires creating a13 verifiable relationship between the trained Al model and the specific training data sources that contributed to that model, enabling post-training verification through an audit log of which data sources were actually incorporated into the Al model.” Examiner disagrees. For the generated record on the block chain, Lowagie ( ¶ 24, 53) explains “The files are in this example made public via locations each comprising at least two location alternatives. All location alternatives relate to URLs. Each CLIENT component maintains a copy of the BLOCKCHAIN database composed of blocks, corresponding to said blockchain. Each block in the BLOCKCHAIN database comprises a list of location references, with for each of them a file hash and diverse location alternatives. Each block in the BLOCKCHAIN database further comprises the corresponding hash-related strings, and information about the user comprised in the user identity… public key" and "private key" refer to aspects of Public Key Infrastructure (PKI). PKI is used for recording the identity of a person or organization. PKI comprises the use of a key pair comprising two keys”. The immutable ledger keeps a record of the transactions and verification is performed. There does not appear to be support in either the claims of disclosure for Applicant’s arguments that “this limitation requires creating a verifiable relationship between the trained Al model and the specific training data sources that contributed to that model, enabling post-training verification through an audit log of which data sources were actually incorporated into the Al model.” First, Lowagie ( ¶ 33-40, 48) discloses “in response to determining that the application is associated with the data access control permission, determining, based on the data access control permission, a subset of the data set to transmit to the application, wherein determining the subset of the data set includes identifying data elements of a specific data type within the data set not encompassed by the data access control permission and removing the identified data elements of the specific data type prior to transmission” Lowagie – In another preferred embodiment, said location comprises a location alternative concerning a URL providing access to a visitor to the file if said visitor disposes of a permission to consult said file. Such an embodiment allows a user in an advantageous way to disclose the existence and the location of a file, without necessarily disclosing the whole content of the file …In a preferred embodiment, the file information is limited to some fields such as author, location, date of publication, and this is included in the location reference. In an alternative embodiment, the further file information is extended, with fields relating to for example several authors, biographies and source material. …Whether the content of the files is pubic, is a choice of the respective providers of the files. The URL of a file can for example directly give access to the content of the file, but it is also possible that only partial information about the file is displayed, and that an authentication should take place for full access, e.g. with a password and/or a captcha and/or a possibility to log in… ( ¶ 36, 53) Secondly, Lowagie discloses generating a provenance record on the immutable cryptographic ledger that indicates that the data recipient includes data originating from the data source entity, wherein the provenance record is encoded as a cryptographic event on the immutable cryptographic ledger that enables distributed verification across more than one ledger node and establishes an audit log indicating that data incorporated into the recipient originated from the data source entity ( ¶ 21-35, 50-63); Claim Interpretation – According to the disclosure(¶ 24, 55), “first the permissions are checked with the smart contract. If the permission exists, then the hash of the updated data and the source of the data (provenance) is written in the blockchain… The multi-entity system 40 provides clear data provenance for the AI models that were trained. The control nodes 24 generate transactions to the blockchain layer 24 that embed the audit logs for exactly whose data was provided to train the AI models. This process creates a virtual marketplace that allows AI/machine learning service and data sharing to be transacted in a secure and distributed environment among many parties.” A provenance record is geared towards the source or who the data belongs to, not what data an AI model includes. Claim Interpretation - According to the disclosure (¶ 20, 24, 32, 42, 55, 58, 61, 62), “The control node 24 enforces the permissions and access to the data in the data store 22 and creates the audit trail for data provenance, permission changes, and all app 30 (or user) actions. The audit trail and permissions are stored in the data store 22, and they are also stored or hashed into the blockchain layer 26 to prove the correctness of the audit trail and permissions…The multi-entity system 40 provides clear data provenance for the AI models that were trained. The control nodes 24 generate transactions to the blockchain layer 24 that embed the audit logs for exactly whose data was provided to train the AI models. This process creates a virtual marketplace that allows AI/machine learning service and data sharing to be transacted in a secure and distributed environment among many parties… The audit logs of recordable events are embedded within transactions on the first blockchain as each individually occurs.” Lowagie – The files are in this example made public via locations each comprising at least two location alternatives. All location alternatives relate to URLs. Each CLIENT component maintains a copy of the BLOCKCHAIN database composed of blocks, corresponding to said blockchain. Each block in the BLOCKCHAIN database comprises a list of location references, with for each of them a file hash and diverse location alternatives. Each block in the BLOCKCHAIN database further comprises the corresponding hash-related strings, and information about the user comprised in the user identity… public key" and "private key" refer to aspects of Public Key Infrastructure (PKI). PKI is used for recording the identity of a person or organization. PKI comprises the use of a key pair comprising two keys:… Before ID, Opub, L and HsO end up in a block of the blockchain, a request for verification is sent to one or more nodes in the blockchain. ( ¶ 24, 32, 53, 59) 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. Claims 5-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Subject Matter Eligibility Standard When considering subject matter eligibility under 35 U.S.C. § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter (101 Analysis: Step 1). Even if the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea) (101 Analysis: Step 2a(Prong 1), and if so, Identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether they integrate the exception into a practical application of the exception. (101 Analysis: Step 2a (Prong 2). If additional elements does not integrate the exception into a practical application of the exception, claim still requires an evaluation of whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception. If the claim as a whole amounts to significantly more than the exception itself (there is an inventive concept in the claim), the claim is eligible. If the claim as a whole does not amount to significantly more (there is no inventive concept in the claim), the claim is ineligible. (101 Analysis: Step 2b). The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter: a) Mathematical concepts b) Certain methods of organizing human activity and c) Mental processes Analysis In the instant case, claim 5 is directed to a method, and claim 16 is directed to an article of manufacture. Step 2a.1– Identifying an Abstract Idea The claims recite the steps of “receiving a request… determining… is associated with…permission… determining…relevant data… to transmit… transmitting the relevant data … and generating… record….” The recited limitations fall with mental processes, specifically, evaluating data, for example, receiving information determining what information to send out, sending the information and saving a record of the data sent. Accordingly, the claims recites an abstract idea. See MPEP 2106. Step 2a.2 – Identifying a Practical Application The claim does not currently recite any additional elements or combination of additional elements that integrate the judicial exception into a practical application. The recitation of a distributed ledger or blockchain or “application” does not preclude the claim from reciting an abstract idea as the blockchain recites functions of a generic computer component, such as storing a record or sending information to another entity. Mere instructions to apply the exception using generic computer components and limitations to a particular field of use or technological environment do not amount to practical applications. The claim in directed to an abstract idea. Step 2b The claim limitations recite “receiving… transmitting… generating…” are not additional elements and they amount to no more than mere instructions to apply the exception using a generic computer component. They recite insignificant-extra solution activity of a generic device. For the same reason these elements are not sufficient to provide an inventive concept. This is also determined to be well-understood, routine and conventional activity in the field. The Symantec, TLI, and OIP Techs, court decision cited in MPEP 2106.05(d)(II) indicates that mere receipt or transmission of data over a network is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here. Therefore, when considering the elements alone, and in combination, there is no inventive concept in the claim and thus the claim is not eligible. Viewed as a whole, instructions/method claims recite the concept of an evaluation as performed by a generic computer. The claims do not currently recite any additional elements or combination of additional elements that amount to significantly more than the judicial exception. The elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea in a network, and/or merely uses a network as a tool to perform an abstract idea and/or generally linking the use of the judicial exception to a particular environment. Dependent claims 6, 7, 9-11, 17, 18, and 20 discuss functions in more descriptive detail of the steps geared toward the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable. Claims 8 and 19 recite an evaluation process to fulfill a request, also geared toward the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable. Claims 13-15 provide more descriptive detail of the steps geared toward the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable. The claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field. Therefore, based on case law precedent, the claims are claiming subject matter similar to concepts already identified by the courts as dealing with abstract ideas. See Alice Corp. Pty. Ltd., 573 U.S. 208 (citing Bilski v. Kappos, 561, U.S. 593, 611 (2010)). The claims at issue amount to nothing significantly more than an instruction to apply the abstract idea using some unspecified, generic computer. See Alice Corp. Pty. Ltd., 573 U.S. 208. Mere instructions to apply the exception using a generic computer component and limitations to a particular field of use or technological environment cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible. Conclusion The claim as a whole, does not amount to significantly more than the abstract idea itself. This is because the claim does not affect an improvement to another technology or technical filed; the claim does not amount to an improvement to the functioning of a computer system itself; and the claim does not move beyond a general link of the use of an abstract idea to a particular technological environment. Accordingly, the Examiner concludes that there are no meaningful limitations in the claim that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself. Dependent claims do not resolve the deficiency of independent claims and accordingly stand rejected under 35 USC 101 based on the same rationale. Dependent claims 6-15 and 17-20 are also rejected. Claim Rejections - 35 USC § 112 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 5-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 5 and 16 recite “wherein the provenance record is encoded as a cryptographic event on the immutable cryptographic ledger that enables distributed verification across more than one ledger node and establishes an audit log indicating that data incorporated into the trained Al model originated from the data source entity.” According to the disclosure (¶ 20, 32, 42, 55, 58, 61, 62), “The control node 24 enforces the permissions and access to the data in the data store 22 and creates the audit trail for data provenance, permission changes, and all app 30 (or user) actions. The audit trail and permissions are stored in the data store 22, and they are also stored or hashed into the blockchain layer 26 to prove the correctness of the audit trail and permissions…The multi-entity system 40 provides clear data provenance for the AI models that were trained. The control nodes 24 generate transactions to the blockchain layer 24 that embed the audit logs for exactly whose data was provided to train the AI models. This process creates a virtual marketplace that allows AI/machine learning service and data sharing to be transacted in a secure and distributed environment among many parties… The audit logs of recordable events are embedded within transactions on the first blockchain as each individually occurs.” The disclosure makes no mention of a “provenance record” that is encoded as a cryptographic event on the immutable cryptographic ledger that enables distributed verification across more than one ledger node, and secondly, the disclosure does not provide support for the “provenance record” that “establishes an audit log indicating that data incorporated into the trained Al model originated from the data source entity.” There is no written description support for the recited limitations. Dependent claims 6-15 and 17-20 are also rejected. 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. Claims 5-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention. Claims 5 and 16 recite “wherein the provenance record is encoded as a cryptographic event on the immutable cryptographic ledger that enables distributed verification across more than one ledger node and establishes an audit log indicating that data incorporated into the trained Al model originated from the data source entity”. The claims are unclear and indefinite. The claims are unclear as to whether Applicant is explaining that an “immutable cryptographic ledger … enables distributed verification across more than one ledger node” or rather that when the “provenance record” is “encoded as a cryptographic event”, it then enables “distributed verification across more than one ledger node”. The claims are unclear and indefinite. Dependent claims 6-15 and 17-20 are also rejected. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 5-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lowagie (EP 3560136) (“Lowagie”), and further in view of Saxena et al (US 10,726,342) (“Saxena”). Regarding claims 5 and 16, Lowagie discloses receiving a request from an application via a node of an immutable cryptographic ledger, the request associated with transfer of a data set from a data store to the application ( ¶ 11, 19, 20, 47-63); Lowagie – In case of several URLs, a visitor desiring access to the file, for example is granted a faster access, or a more robust access. A faster access is for example obtained when the URLs correspond to several physical download locations spread all over the world, as a result of which it becomes possible, whether automatically or not, to choose the download location that is physically most nearby. A more robust access is obtained if one of the locations is inaccessible temporarily or permanently, for example because of problems relating to the network or a firewall blocking certain domains for certain visitors, but the other locations do remain accessible… The present invention has for example been described with reference to a separate blockchain destined for the recording of the location of a general file, but it will be clear that the invention can be applied with a blockchain that is acquainted with another use, such as for example the bitcoin blockchain. Diverse formats for the file are also mentioned, such as PDF-based files, but actually, any kind of file format can be used. ( ¶ 11, 63) determining whether the application is associated with a data access control permission stored on the immutable cryptographic ledger, the data access control permission encoded to a first cryptographic event on the immutable cryptographic ledger ( ¶ 20, 34, 44-47, 53); Lowagie – Here, it is about a URL that is available for visitors of said URL having the permissions to consult the file. In such an embodiment, certain credentials are for example necessary for having access to the file. Examples of credentials are: the combination of a user name and a password, a certificate. Also, the condition that one tries to make a connection with the URL via a particular intranet, can result in a kind of selective access… the recording of a location reference occurs in a blockchain provided that said user identity belongs to a plurality of user identities that have been registered in a web-of-trust or at a certificate authority; ( ¶ 20, 47) in response to determining that the application is associated with the data access control permission, determining, based on the data access control permission, a subset of the data set to transmit to the application, wherein determining the subset of the data set includes identifying data elements of a specific data type within the data set not encompassed by the data access control permission and removing the identified data elements of the specific data type prior to transmission ( ¶ 33-40, 48); Lowagie – In another preferred embodiment, said location comprises a location alternative concerning a URL providing access to a visitor to the file if said visitor disposes of a permission to consult said file. Such an embodiment allows a user in an advantageous way to disclose the existence and the location of a file, without necessarily disclosing the whole content of the file …In a preferred embodiment, the file information is limited to some fields such as author, location, date of publication, and this is included in the location reference. In an alternative embodiment, the further file information is extended, with fields relating to for example several authors, biographies and source material. …Whether the content of the files is pubic, is a choice of the respective providers of the files. The URL of a file can for example directly give access to the content of the file, but it is also possible that only partial information about the file is displayed, and that an authentication should take place for full access, e.g. with a password and/or a captcha and/or a possibility to log in… ( ¶ 36, 53) transmitting the subset of the training data set to the application; and ( ¶ 9, 36; claim 5); Lowagie – location comprises a location alternative concerning a URL providing access to a visitor to the file if said visitor disposes of a permission to consult said file. ( ¶ 36) generating a provenance record on the immutable cryptographic ledger that indicates that the data recipient includes data originating from the data source entity, wherein the provenance record is encoded as a cryptographic event on the immutable cryptographic ledger that enables distributed verification across more than one ledger node and establishes an audit log indicating that data incorporated into the recipient originated from the data source entity ( ¶ 21-35, 50-63); Claim Interpretation – According to the disclosure(¶ 24, 55), “first the permissions are checked with the smart contract. If the permission exists, then the hash of the updated data and the source of the data (provenance) is written in the blockchain… The multi-entity system 40 provides clear data provenance for the AI models that were trained. The control nodes 24 generate transactions to the blockchain layer 24 that embed the audit logs for exactly whose data was provided to train the AI models. This process creates a virtual marketplace that allows AI/machine learning service and data sharing to be transacted in a secure and distributed environment among many parties.” A provenance record is geared towards the source or who the data belongs to, not what data an AI model includes. Claim Interpretation - According to the disclosure (¶ 20, 24, 32, 42, 55, 58, 61, 62), “The control node 24 enforces the permissions and access to the data in the data store 22 and creates the audit trail for data provenance, permission changes, and all app 30 (or user) actions. The audit trail and permissions are stored in the data store 22, and they are also stored or hashed into the blockchain layer 26 to prove the correctness of the audit trail and permissions…The multi-entity system 40 provides clear data provenance for the AI models that were trained. The control nodes 24 generate transactions to the blockchain layer 24 that embed the audit logs for exactly whose data was provided to train the AI models. This process creates a virtual marketplace that allows AI/machine learning service and data sharing to be transacted in a secure and distributed environment among many parties… The audit logs of recordable events are embedded within transactions on the first blockchain as each individually occurs.” Lowagie – The files are in this example made public via locations each comprising at least two location alternatives. All location alternatives relate to URLs. Each CLIENT component maintains a copy of the BLOCKCHAIN database composed of blocks, corresponding to said blockchain. Each block in the BLOCKCHAIN database comprises a list of location references, with for each of them a file hash and diverse location alternatives. Each block in the BLOCKCHAIN database further comprises the corresponding hash-related strings, and information about the user comprised in the user identity… public key" and "private key" refer to aspects of Public Key Infrastructure (PKI). PKI is used for recording the identity of a person or organization. PKI comprises the use of a key pair comprising two keys:… Before ID, Opub, L and HsO end up in a block of the blockchain, a request for verification is sent to one or more nodes in the blockchain. ( ¶ 24, 32, 53, 59) Lowagie does not disclose a training data set from the data store to the application for training of an Al model, the training data set originating from a data source entity; a subset of the training data set to transmit to the application for training of the Al model; for training of the Al model. Saxena teaches a training data set from the data store to the application for training of an Al model, the training data set originating from a data source entity; a subset of the training data set to transmit to the application for training of the Al model; for training of the Al model (column 39, line 29-67, column 40, line 8-65, column 41, line 48-67, column 42, line 1-51, column 50, line 4-58); Saxena – the repositories of multi-structured data 1104 may include public 1106, proprietary 1108, social 1110, device 1112, and other types of data. Examples of such data include emails, social media feeds, news feeds, blogs, doctor's notes, transaction records, blockchain transactions, call logs, and device telemetry streams. In these embodiments, the repositories of multi-structured data 1104 may include unstructured data (e.g., a document), semi-structured data (e.g., a social media post), and structured data (e.g., a string, an integer, etc.), such as data stored in a relational database management system (RDBMS) or a blockchain. In various embodiments, such data may be stored in a data lake 1114, a data…The training data typically consists of a set of training examples, with each example consisting of an input object (e.g., a vector) and a desired output value (e.g., a supervisory signal). In various embodiments, the training data is data associated with a blockchain…the data sovereignty, security, lineage and traceability system 1128 is implemented to ensure that data ownership rights are observed, data privacy is safeguarded, and data integrity is not compromised. In certain embodiments, data sovereignty, security, lineage and traceability system 1128 is likewise implemented to provide a record of not only the source of the data throughout its lifecycle, but also how it has been used, by whom, and for what purpose. (column 40, line 8-65, column 41, line 48-67, column 42, line 1-51) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Lowagie and Saxena in order to process complex datasets, including learning systems data, through a blockchain (Saxena; column 1, line 17-66). Regarding claims 6 and 17, Lowagie discloses upon receiving instructions from a user of the data store, issuing the data access control permission by encoding hashed data to the first cryptographic event on the immutable cryptographic ledger ( ¶ 9, 23-25, 35-40, 48, 53-62; claim 4). Regarding claims 7 and 18, Lowagie discloses said determining the subset further Regarding claims 8 and 19, Lowagie discloses receiving, by a first user, a write request to write data to the data store; verifying an existence of a writing data access control permission Regarding claims 9 and 20, Lowagie discloses forwarding a first data item with write instructions to the data store from a first user; and generating a write record on the immutable cryptographic ledger, wherein the write record is encoded to a second cryptographic event on the immutable cryptographic ledger and includes a timestamp and identifying information for the first user ( ¶ 15, 27, 32, 35-49, 54, 60-62). Regarding claim 10, Lowagie discloses said facilitating further comprising: generating a read record on the immutable cryptographic ledger, wherein the read record is encoded to a second cryptographic event on the immutable cryptographic ledger and includes a timestamp and identifying information for the Regarding claim 11, Lowagie discloses recording on the immutable cryptographic ledger in a plurality of encoded events each read, write, and authorization status for the data store, each encoded event of the plurality of encoded events including a timestamp and identifying metadata for associated users ( ¶ 15, 27, 32, 53-63). Regarding claim 12, Lowagie discloses wherein each encoded event of the plurality of encoded events further comprises metadata describing any of: data read; data modified; or data created ( ¶ 48-54). Regarding claim 13, Saxena teaches wherein the immutable cryptographic ledger is a subchain immutable ledger, the method further comprising: periodically recording, to a public immutable cryptographic ledger, data included in each of the encoded events on the subchain immutable ledger occurring since a previous periodic recording, wherein the data is recorded into one batch-encoded event on the public immutable cryptographic ledger (Figure 9; column 26, line 41-64, column 29, line 11-63, column 30, line 14-65, column 32, line 3-67, column 32, line 1-67). Regarding claim 14, Lowagie discloses authenticating the application Regarding claim 15, Saxena teaches processing a payment by the application that is based on fulfillment of the request (column 8, line 44-67, column 9, line 1-35, column 26, line 1-40, column 37, line 59-67). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Vestemean et al., (US 20220094739) teaches AI programs and blockchains. Mahesh (US 10411897)- Secret sharing on blockchains Fisher(US 20160283920) – authentication and verification of digital data on a blockchain Barinov (US 10157295) – file authentication on a blockchain THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ILSE I IMMANUEL whose telephone number is (469)295-9094. The examiner can normally be reached Monday-Friday 9:00 am to 5:00pm. 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, NEHA H PATEL can be reached on (571) 270-1492. 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. /ILSE I IMMANUEL/Primary Examiner, Art Unit 3699
Read full office action

Prosecution Timeline

Mar 08, 2022
Application Filed
Sep 07, 2024
Non-Final Rejection — §101, §103, §112
Dec 26, 2024
Interview Requested
Jan 03, 2025
Examiner Interview Summary
Jan 03, 2025
Applicant Interview (Telephonic)
Jan 10, 2025
Response Filed
Apr 19, 2025
Final Rejection — §101, §103, §112
Jul 24, 2025
Request for Continued Examination
Jul 31, 2025
Response after Non-Final Action
Sep 06, 2025
Non-Final Rejection — §101, §103, §112
Dec 10, 2025
Response Filed
Mar 27, 2026
Final Rejection — §101, §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12586062
MULTI-BLOCKCHAIN TOKEN REBALANCER
2y 5m to grant Granted Mar 24, 2026
Patent 12555106
DIGITIZATION OF PAYMENT CARDS FOR WEB 3.0 AND METAVERSE TRANSACTIONS
2y 5m to grant Granted Feb 17, 2026
Patent 12555117
ARCHITECTURES, SYSTEMS, AND METHODS FOR CARD BASED TRANSACTIONS
2y 5m to grant Granted Feb 17, 2026
Patent 12443942
SYSTEMS AND METHODS OF BLOCKCHAIN TRANSACTION RECORDATION
2y 5m to grant Granted Oct 14, 2025
Patent 12430635
SYSTEMS AND METHODS FOR AN ACCOUNT ISSUER TO MANAGE A MOBILE WALLET
2y 5m to grant Granted Sep 30, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

5-6
Expected OA Rounds
23%
Grant Probability
50%
With Interview (+27.1%)
4y 7m
Median Time to Grant
High
PTA Risk
Based on 293 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month