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 .
Response to Arguments
Applicant’s arguments, see pg. 11-13, filed 03 December 2025, with respect to the restriction requirement applied to claims 49-54 have been fully considered and are persuasive. The restriction requirement of claims 49-54 has been withdrawn.
Applicant’s arguments, see pg. 14-23, filed 12/03/2025, with respect to the rejection(s) of claim(s) 1-2, 4-8, 10, 12-15, 17-21, 23, 25-26 and 42-48 under 35 U.S.C. § 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of prior art.
In light of these findings, this office action is made NON-FINAL.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract of the disclosure is objected to because the abstract should avoid using phrases which can be implied such as “Disclosed is a method…”; and the abstract is objected to because the abstract exceeds 150 words. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Drawings
The drawings are objected to because the rectangular boxes shown in Figure 3 should be provided with descriptive text labels. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
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.
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) 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: "an audit module configured to ... monitor executed operations for deviation from schema rules, and ... automatically generate a trace log comprising schema identifier, version, executed operation, and TEE instance identifier" in claim 51.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f), 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) , applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) (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).
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 1, 2, 4-8, 10-15, 17-21, 23-26, and 42-54 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding claim 1:
Applying the Alice1/Mayo2 test (see also MPEP § 2106):
Step 1: Is the claim to a process, machine, manufacture or composition of matter?
Finding: Yes, The claim(s) recite(s) “method” which falls under ‘process’.
Because this stage of the inquiry resolves to “yes”, the inquiry progresses to step 2.
Step 2A, Prong One: Is the claim directed to a law of nature, a natural phenomenon (product of nature), or an abstract idea?
Finding: Yes. The claim(s) recite(s) the following abstract idea:
A method of performing a transaction in relation to an identity centric dataset—abstract because it is a method that can be done with pen and paper (as illustrated below);
establishing … a set of permitted data operations … using a plurality of privacy schemas — abstract because it is creating and organizing rules about what actions are allowed under different policy categories (“privacy schemas”). A human can do this mentally or with pen and paper by writing a table: for each schema (e.g., “employee”, “customer”, “research”), list which operations are permitted (e.g. “view,” “mask,” “encrypt,” “share”). No computing device is required to conceive or perform the act of defining rules.
receiving … a transaction request to perform the transaction in relation to the identity centric dataset associated with a data owner—abstract because it is receiving and recognizing a request relating to a person’s record. A human can receive a request verbally, by mail, or on a paper form, and can note that it concerns a particular data owner’s dataset. “Receiving” and “associating with” are routine information-handling steps that can be performed with pen and paper by reading the request and writing down the data owner name/identifier;
identifying … based on the transaction request, a privacy schema from the plurality of privacy schema from the plurality of privacy schemas for use in performing the transaction—abstract because it is selecting an applicable policy based on request details. A human can do this by reading the request and then choosing which privacy schema applies—e.g., “This request is from Recipient X, with Consent Y, for Context Z, so apply Schema #3.” That is the same kind of decision a person makes when choosing which rule or policy governs a situation, and it can be done with a printed policy manual and a pen;
performing the transaction … one or more data operations from the set of permitted data operations upon the identity centric dataset of the data owner as permitted by the identified privacy schema thereby generating a manipulated dataset and transaction metadata—abstract because applying the selected rules to information and producing an updated output plus a record of what was done. A person can do this manually: take a paper file (the data set), apply permitted operation such as redacting fields (masking), copying selected parts, annotating, or formatting, and then create (i) the “manipulated dataset” (the modified copy) and (ii) “transaction metadata” (notes describing what was done, which rules were applied, who requested it, and when). This is consistent with ordinary manually record-processing and compliance handling;
recording the transaction metadata—abstract because it is recordkeeping—storing descriptive information about an action. A human can record the metadata by writing it into a logbook, filing it in a folder, or entering it on a paper format. The act of “recording” does not require any technology beyond writing and storage of information; and
transferring the manipulated dataset to a data receiver indicated by the transaction request—abstract because it is communicating or delivering information to an identified recipient. A human can do this by handing over the modified document, mailing it or otherwise providing it to the named recipient. The selection of the recipient is determined from the request; the transfer is a fundamental information-sharing act that can be performed without a computer.
Taken together, these limitations describe: (1) defining rule sets, (2) receiving a request, (3) selecting a rule set, (4) applying permitted operations to information and documenting what was done, (5) recording the documentation, and (6) providing the result to a recipient. Each of these steps can be performed by a person using only mental judgment and pen-and-paper recording handling, which is why they are appropriately characterized as abstract for Step 2A, Prong One.
Because this stage of the inquiry resolves to “yes”, the inquiry progresses to Step 2A Prong Two.
Step 2A, Prong Two: Does the claim recite additional elements that integrate the judicial exception into a practical application?
Claim 1 recites the additional, non-abstract, elements:
a consortium network (BRI: a generic network of computing devices);
a service network (BRI: a generic network of computing devices);
a trusted execution environment of the service network (BRI: a generic processor-based execution context); and
a distributed ledger of the service network (BRI: a generic software construct implemented on a network of computing devices).
No, the claim does not recite additional elements that integrate the judicial exception into a practical application because the additional elements recited in the claim do not meaningfully limit the abstract idea. Under the broadest reasonable interpretation, the consortium network and service network are generic networks of computing devices that merely provide a conventional computing environment in which the abstract steps of defining rules, selecting policies, authorizing actions, processing data, and disseminating information are carried out. The claims address a business and regulatory compliance problem—namely, enforcing privacy and consent policies and maintaining audit record for identity-centric data transaction—rather than a problem arising from the functioning of computer technology itself. The trusted execution environment is recited only as a generic processor-based execution context used for its expected purpose of executing instructions in an isolated manner, without any claim limitation directed to an improvement in processor operation, execution isolation, or security mechanisms themselves. The distributed ledger is recited as a software-implemented data structure maintained by networked computing devices and is used only to record transaction metadata, functioning as a conventional recordkeeping mechanism. The claims do not recite any specific technological improvement to computer functionality, network operation, execution environments, or ledger technology, nor do they reflect any improvement described in the specification that would be apparent to one of ordinary skill in the art. Instead, the claim as a whole merely implements the abstract idea using generic computing components as tools.
Because this stage of the inquiry resolves to “no”, the inquiry progresses to the final Step 2B.
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements, whether considered individually or as an ordered combination, merely recite generic computing components performing their conventional functions of networking, execution, storage and recordkeeping. The claims do not include any element or combination of elements that adds an inventive concept, such as a specific technological solution to a technical problem, a particular machine configuration that improves computer operation, or an unconventional arrangement of components beyond generic computer implementation. Accordingly, the claim(s) amount to not more than the abstract idea implemented on generic computing infrastructure.
Accordingly, claim 1 is directed to an abstract idea and is not patent eligible at the conclusion of this inquiry and properly rejected under 35 U.S.C. §101.
Regarding claims 2 and 15:
Claims 2/15 further recite that “the privacy schema is identified from the plurality of privacy schemas based on at least one of the data owner and the data receiver as indicated by the transaction request.” The additional, non-abstract aspect of this limitation is that the rule-selection step (choosing which privacy schema applies) is performed by a computer using specific input fields—namely, electronic identifiers of the data owner and/or data receiver included in the transaction request. This merely narrows the decision criteria for the same abstract policy-selection step already present in claims 1/14: instead of choosing a schema based on any transaction information, the system chooses it based on particular parties. A human could perform the same reasoning with pen and paper by reading a request, noting who the data owner and recipient are, and selecting the appropriate policy manual section accordingly. Thus, claims 2/15 simply refines which data are considered in the abstract decision-making process and amounts to insignificant extra-solution activity (selecting and using particular input data) and instructions to apply the abstract idea, without reciting any specific improvement to computer technology, data structures, or network operation. Accordingly, claims 2/15 do not integrate the judicial exception into a practical application or add significantly more than the abstract idea and, like its base claim, are ineligible under 35 U.S.C. 101.
Regarding claims 4 and 17:
Claims 4/17 further specify that “the one or more data operations comprise at least one of: a data transformation operation; a data encryption operation; a data privacy preservation operation; a data anonymization operation; a data pseudo-anonymization operation; a data tokenization operation; a data enrichment operation; a data label assignment operation; a data classification label assignment operation; and a data dissemination marker assignment operation.” The non-abstract portions of this limitation are generic software operations that manipulate or annotate electronic data in memory—e.g., transformation, encryption, anonymization, tokenization, and labeling—which are standard, well-understood data-processing and security functions that conventional computer systems are known to perform. The claim recites these operations only at a high, black-box functional level, without any particular algorithmic or architectural improvement, and they merely implement the same abstract privacy-policy management concept by specifying the types of actions that may be taken on the data. Accordingly, claims 4/17 simply add routine computer data-processing functions as tools for implementing the abstract idea and do not integrate the judicial exception into a practical application or supply an inventive concept under Step 2B. Therefore, the claims are ineligible under 35 U.S.C. 101.
Regarding claim 5 and 18:
Claims 5/18 recite that “the transaction metadata is indicative of: one or more identity attribute identifiers; a transaction context; consent of the data owner; an identifier of the data owner; an identifier of the data receiver; and an identifier of each of the one or more data operations.” The additional non-abstract aspect is that the system’s metadata record includes specific informational fields describing what data was processed, in what context, under what consent, by whom, and which operations were applied. This is nothing more than specifying the content and layout of an electronic log or record, i.e., routine data structuring and recordkeeping, which constitutes classic insignificant extra-solution activity and well-understood, routine, conventional computer functionality. It does not improve how computers store data or logs; it merely dictates what information to include in the log for the abstract consent/transaction-tracking idea. Accordingly, claims 5/18 do not integrate the abstract idea into a practical application or add significantly more than the judicial exception and are ineligible under 35 U.S.C. 101.
Regarding claims 6 and 19:
Claims 6/19 add that “the transaction request is indicative of the consent of the data owner and the transaction context.” The non-abstract feature is that the electronic request message includes particular fields (consent and context), i.e., additional pieces of data included in a computer message. Including these fields simply defines the informational content of the request and amounts to generic data gathering/transmission over a network—well-understood, routine, conventional computer communication. It refines what information the abstract process operates on but does not change the nature of the underlying idea (policy-based handling of identity-centric transactions) or improve any underlying technology. Therefore, claims 6/19 do not integrate the judicial exception into a practical application or add significantly more than the abstract idea, and are ineligible under 35 U.S.C. 101.
Regarding claims 7 and 20:
Claims 7/20 recite that “the privacy schema is identified from the plurality of privacy schemas based on at least one of the consent of the data owner and the transaction context.” The additional non-abstract portion is a computer using specific input fields (consent and context) when selecting which policy/schema to apply. This is simply an automated decision using particular data fields to choose among rule sets—the same kind of mental step a human would perform when deciding which privacy policy applies given consent and context. It thus represents selecting and applying particular input data in an abstract decision-making process, which is insignificant extra-solution activity and routine computer logic, not an improvement to computer technology. As such, claims 7/20 do not integrate the abstract idea into a practical application or provide significantly more than the judicial exception and are ineligible under 35 U.S.C. 101.
Regarding claims 8 and 21:
Claims 8/21 recite that “the manipulated dataset comprises one or more transaction data records and the transaction metadata.” The non-abstract aspect is defining the composition of the output data structure stored by the system (i.e., the processed transaction records together with the corresponding metadata). Structuring an electronic output record in this way is routine computer recordkeeping—merely specifying how the abstract result is formatted and stored—and is treated as post-solution activity that is well-understood, routine, and conventional. It does not improve how the computer stores data, nor does it alter the abstract nature of the overall method of policy-based record processing and logging. Accordingly, claims 8/21 do not integrate the abstract idea into a practical application or add significantly more than the judicial exception and are ineligible under 35 U.S.C. 101.
Regarding claims 10/23:
Claims 10/23 recite that “the service network includes a service application programming interface (API), wherein the transaction request is received from a data owner device via the service API.” The additional non-abstract elements are a generic service API and a data owner device communicating an electronic request over a network. Receiving a request via an API is a standard, well-understood pattern for client/server communication in computer systems and amounts to routine data input over a network. This limitation merely specifies the conventional way the abstract request-handling step is implemented (through an API) without changing the underlying abstract idea or improving the technology. Therefore, claims 10/23 do not integrate the judicial exception into a practical application or add significantly more than the abstract idea and are ineligible under 35 U.S.C. 101.
Regarding claims 11 and 24:
Claims 11/24 recite that some of the manipulated dataset is encrypted, and that the consortium network is configured to: receive a data access request via the service API; determine whether the data receiver is permitted to decrypt; if permitted, generate and transfer a decryption key to enable decryption; and record further transaction metadata to the distributed ledger. The non-abstract elements here are conventional access-control and cryptographic key-distribution functions performed by generic networked computer systems: receiving access requests, performing an authorization decision, issuing keys when authorized, and logging the event. These are standard, well-understood, routine, conventional security and logging operations that merely automate the abstract idea of checking if a requester is allowed to access protected data and recording that decision. They do not improve cryptography itself, access-control algorithms, or ledger technology, but instead use known techniques as tools within the abstract privacy-management workflow. Accordingly, claims 11/24 do not integrate the abstract idea into a practical application or provide significantly more and are ineligible under 35 U.S.C. 101.
Regarding claims 12 and 25:
Claims 12/25 recite that “the one or more processing systems configure the service network by initializing one or more system nodes based on a plurality of smart contracts and the plurality of privacy schemas distributed via a further distributed ledger, wherein the plurality of smart contracts encode the plurality of data operations.” The non-abstract elements are generic processing systems (nodes), smart contracts, and a distributed ledger, used in a conventional way: nodes load contracts and configuration (schemas) from a ledger and are thereby initialized to perform certain operations. This is a standard blockchain deployment pattern where code and policies are distributed via a ledger and nodes are configured accordingly; the claim does not recite any improvement to how smart contracts execute, how consensus is reached, or how nodes function internally. The limitation simply describes how the generic computer environment is set up to implement the same abstract privacy-policy management and recordkeeping idea. As such, claims 12/25 do not integrate the judicial exception into a practical application or add significantly more than the abstract idea and are ineligible under 35 U.S.C. 101.
Regarding claims 13 and 26:
Claims 13/26 recite that “the consortium network includes a plurality of system nodes, wherein the one or more processing systems are configured to establish the service network, wherein the one or more system nodes are part of the plurality of system nodes.” The additional non-abstract elements are the definition of a particular network topology: a consortium network with multiple nodes and a service network formed from a subset of those nodes. Selecting a subset of nodes in a distributed system to form a logical service network is a routine deployment and configuration practice in distributed computing and networking. This merely specifies an arrangement of generic nodes for implementing the same abstract privacy-policy and recordkeeping scheme and does not improve the functioning of the computer, network protocols, or any underlying technology. Accordingly, claims 13/26 do not integrate the judicial exception into a practical application or provide significantly more than the abstract idea and are likewise ineligible under 35 U.S.C. 101.
Regarding claim 14:
Applying the Alice3/Mayo4 test (see also MPEP § 2106):
Step 1: Is the claim to a process, machine, manufacture or composition of matter?
Finding: Yes. The claim recites “a system” comprising “one or more processing systems,” which falls under “machine.”
Because this stage of the inquiry resolves to “yes”, the inquiry progresses to Step 2.
Step 2A, Prong One: Is the claim directed to a law of nature, a natural phenomenon (product of nature), or an abstract idea?
Finding: Yes. The claim recites the following abstract idea:
A system of performing a transaction in relation to an identity centric dataset—abstract because it mirrors the method of claim 1 and ultimately implements a series of information-handling steps (rule definition, request handling, policy selection, data manipulation, logging, and delivery) that can be performed by a human with pen and paper managing paper records and policy documents, differing only in that they are here implemented by generic “processing systems.”
“establish [ing] a set of permitted data operations for a service network using a plurality of privacy schemas”—abstract because it is creating and organizing rules about what actions are allowed under different policy categories (“privacy schemas”). A human can do this mentally or on paper by writing, for each schema (e.g., “employee,” “customer,” “research”), which operations (view, redact, encrypt, share) are permitted. No special machine is required to conceive or perform this rule-definition activity; the claim simply attributes it to “one or more processing systems.”
“receiv[ing] a transaction request to perform the transaction in relation to the identity centric dataset associated with a data owner”—abstract because it is receiving and recognizing a request relating to a person’s record. A person can receive such a request verbally or by paper form and note that it concerns a particular individual’s file; substituting an electronic request handled by a generic processing system does not change the fundamental informational nature of the step.
“identify[ing] … based on the transaction request, a privacy schema from the plurality of privacy schemas for use in performing the transaction”—abstract because it is selecting an applicable policy based on request details, akin to a human reading a request and choosing which rule set applies given the parties and context (e.g., “apply Schema #3 because this is Recipient X with Consent Y in Context Z”), something that can be done mentally or with a printed policy manual.
“perform[ing] the transaction by executing, in a trusted execution environment of the service network, one or more data operations from the set of permitted data operations upon the identity centric dataset of the data owner as permitted by the identified privacy schema thereby generating a manipulated dataset and transaction metadata”—abstract because, at its core, it is applying selected rules to information and producing (i) an updated version of that information and (ii) a record of what was done. A human can manually modify a paper file according to permitted operations (redacting fields, copying allowed fields, annotating) and create a note describing what was done, which rules were applied, and by whom, using ordinary mental judgment and pen-and-paper record-processing. The recited “processing systems” and TEE merely automate this human-executable logic.
“record[ing] the transaction metadata to a distributed ledger of the service network”—abstract because it is recordkeeping: storing descriptive information about an action. A human can write the metadata into a logbook, file it in a folder, or maintain it in a register; the fact that claim 14 uses a generic “distributed ledger” data structure on networked processing systems to store the metadata does not change this fundamental nature of recording information about what was done.
“transfer[ring] the manipulated dataset to a data receiver indicated by the transaction request”—abstract because it is communicating or delivering information to an identified recipient. A human can hand over, mail, or otherwise provide an updated document to a designated recipient; assigning this task to a computer system transmitting data to a receiver device simply automates the same basic information-sharing step.
Taken together, these limitations describe: (1) defining rule sets, (2) receiving a request, (3) selecting a rule set, (4) applying permitted operations to information and documenting what was done, (5) recording the documentation, and (6) providing the result to a recipient. Each of these steps can be performed by a person using only mental judgment and pen-and-paper record handling, with the “system” merely implementing them on generic processing systems. Accordingly, claim 14 is appropriately characterized as being directed to an abstract idea for Step 2A, Prong One.
Because this stage of the inquiry resolves to “yes,” the inquiry progresses to Step 2A, Prong Two.
Step 2A, Prong Two: Does the claim recite additional elements that integrate the judicial exception into a practical application?
Claim 14 recites the additional, non-abstract, elements:
“one or more processing systems” (BRI: generic computer hardware executing software);
“a service network” (BRI: a generic network of such processing systems);
“a trusted execution environment of the service network” (BRI: a conventional processor-based secure execution context); and
“a distributed ledger of the service network” (BRI: a generic software-implemented data structure replicated across networked nodes).
No, the claim does not recite additional elements that integrate the judicial exception into a practical application, because these additional elements do not meaningfully limit the abstract idea. Under the broadest reasonable interpretation, the “one or more processing systems,” service network, TEE, and distributed ledger are generic computer and network components providing a conventional computing environment in which the abstract steps of defining rules, selecting policies, processing data according to those policies, recording metadata, and disseminating information are carried out. The claim addresses a business/compliance problem—managing privacy, consent, and auditability for identity-centric transactions—rather than a problem specifically arising in the functioning of computer technology itself. The trusted execution environment is recited only as a generic isolated execution context used for its expected purpose, with no limitation directed to an improvement in how TEEs operate. The distributed ledger is recited as a conventional replicated data store used simply to record transaction metadata, i.e., as a particular recordkeeping mechanism. The specification does not describe, and the claim does not recite, any specific technological improvement to computer functionality, network operation, TEE architecture, or ledger technology. Instead, claim 14 as a whole merely implements the abstract privacy-policy management idea using generic computing components as tools.
Because this stage of the inquiry resolves to “no,” the inquiry progresses to the final Step 2B.
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. The “one or more processing systems,” service network, TEE, and distributed ledger, whether considered individually or as an ordered combination, merely recite generic computer and network components performing their conventional functions of computation, communication, isolated execution, data storage, and recordkeeping. The claim does not include any element or combination of elements that adds an inventive concept, such as a specific technological solution to a technical problem, a particular machine configuration that improves computer operation, or an unconventional arrangement of components beyond generic computer implementation of the abstract privacy-management and logging workflow. Accordingly, claim 14 amounts to no more than the abstract idea implemented on generic computing infrastructure and is not patent-eligible under 35 U.S.C. 101.
Regarding claims 42 and 46:
Claims 42/46 further recite “a plurality of processing systems, each configured as a system node within a consortium network, the consortium network comprising multiple system nodes, and wherein each system node is configured to establish a set of permitted data operations for a service network using a plurality of privacy schemas, with system nodes initialized through privacy contracts distributed via the consortium’s distributed ledger.” The additional non-abstract elements are generic processing systems acting as nodes in a consortium network, and a conventional distributed-ledger arrangement in which “privacy contracts” are distributed via the ledger and used to initialize nodes. This merely describes a standard blockchain-style deployment pattern—multiple computer nodes, with contracts/configurations on a ledger that each node loads to establish permitted operations—i.e., using known distributed-ledger components as an environment for the same abstract privacy-policy management concept. The claim does not recite any improvement in how distributed ledgers operate, how nodes achieve consensus, or how contracts are executed; it simply automates rule initialization across nodes using generic technology. Accordingly, the additional limitations in claims 42/46 amount to well-understood, routine, conventional computer networking and ledger usage and do not integrate the judicial exception into a practical application or add significantly more than the abstract idea. Claims 42/46 are therefore ineligible under 35 U.S.C. 101.
Regarding claims 43 and 47:
Claims 43 and 47 further recite “a plurality of processing systems configured to receive a transaction request to perform the transaction in relation to the identity-centric dataset associated with a data owner, and to identify, based on parameters including data owner consent, transaction type, and data recipient identity, a suitable privacy schema from the plurality of privacy schemas for use in performing the transaction.” The non-abstract features are multiple processing systems receiving an electronic transaction request and using particular input parameters (consent, transaction type, recipient identity) to select an appropriate privacy schema. This is simply an automated implementation of the same abstract mental process a human could perform when reading a request and deciding which policy applies based on who is involved, what type of transaction it is, and what consent has been given. Choosing a rule set based on specific data fields is routine decision logic and constitutes insignificant extra-solution activity (selection and use of input data) using generic computing components. It does not recite a technological improvement in how computers process requests or manage policies. Accordingly, claims 43/47 do not integrate the abstract idea into a practical application or add significantly more than the judicial exception and are ineligible under 35 U.S.C. 101.
Regarding claim 44:
Claim 44 depends from claim 14 and further recites “smart contracts that encode data operations and enforce predefined data-processing rules aligned with the identified privacy schema.” The additional non-abstract element is the use of smart contracts in their expected role to encode and enforce rules. This limitation amounts to implementing the same abstract privacy-policy-driven processing using conventional smart-contract logic, without any recited improvement to smart-contract execution, ledger operation, or underlying computer functionality. It merely specifies a particular technological setting in which the abstract idea is carried out, which under MPEP § 2106.05(a), (b), and (h) is the use of generic technology as a tool rather than integrating the exception into a practical application or providing an inventive concept. Accordingly, claim 44 does not add significantly more than the judicial exception and is ineligible under 35 U.S.C. 101.
Regarding claim 45:
Claim 45 depends from claim 14 and further recites “execution of data operations within a Trusted Execution Environment (TEE) of the service network, the TEE providing cryptographic isolation and secure processing as permitted by the identified privacy schema.” The additional non-abstract element is a TEE used in its expected role to provide isolated execution. This limitation amounts to carrying out the same abstract privacy-policy-driven processing inside a conventional secure execution context, without any recited improvement to TEE architecture or computer functionality. It merely specifies a particular technological setting in which the abstract idea is carried out, which under MPEP § 2106.05(a), (b), and (h) is the use of generic technology as a tool rather than integrating the exception into a practical application or providing an inventive concept. Accordingly, claim 45 does not add significantly more than the judicial exception and is ineligible under 35 U.S.C. 101.
Regarding claim 48:
Claim 48 depends from claim 14 and further recites “a plurality of processing systems configured to execute the transaction within a Trusted Execution Environment (TEE), utilizing smart contracts that encode data processing rules aligned with the identified privacy schema, thereby ensuring secure, isolated execution of one or more data operations from the set of permitted data operations upon the identity-centric dataset of the data owner.” The additional non-abstract elements are a TEE and smart contracts, both known technologies, used in their expected roles: the TEE provides secure, isolated execution of code; the smart contracts encode and enforce data-processing rules. This limitation amounts to implementing the same abstract privacy-policy-driven data processing inside a conventional secure execution environment and under the control of conventional smart-contract logic, without any recited improvement to TEE architecture, smart-contract execution, or underlying computer/network functionality. It merely specifies a particular technological setting in which the abstract idea is carried out, which is treated under MPEP § 2106.05(a), (b), and (h) as using generic technology as a tool rather than integrating the exception into a practical application or providing an inventive concept. Accordingly, claim 48 does not add significantly more than the judicial exception and is ineligible under 35 U.S.C. 101.
Regarding claim 49:
Claim 49 depends from claim 1 and further recites “a service network that stores a version history of privacy schemas, detects nonconformance of a requested operation with a current schema version, and executes a rollback to a prior schema version associated with the data subject’s consent.” The additional non-abstract elements are routine configuration-management and policy-enforcement functions used in their expected roles. This limitation amounts to implementing the same abstract privacy-management idea using conventional versioning, conformance checking, and rollback operations, without any recited improvement to computer functionality or data management systems. It merely specifies administrative data handling as the technological setting, which under MPEP § 2106.05(a), (d), and (h) is generic technology use rather than an integration into a practical application or an inventive concept. Accordingly, claim 49 does not add significantly more than the judicial exception and is ineligible under 35 U.S.C. 101.
Regarding claim 50:
Claim 50 depends from claim 1 and further recites “transaction metadata that includes at least two digital signatures: a signature from the data owner indicating consent to the identified schema and a signature from the consortium network attesting to schema compliance and permitted operations.” The additional non-abstract elements are digital signatures used in their expected roles for authenticity and integrity. This limitation amounts to applying conventional cryptographic annotations to the same abstract consent/compliance record, without any recited improvement to cryptographic algorithms or system functionality. It merely specifies a routine security mechanism as the technological setting, which under MPEP § 2106.05(a), (d), and (h) is generic technology use rather than an integration or inventive concept. Accordingly, claim 50 does not add significantly more than the judicial exception and is ineligible under 35 U.S.C. 101.
Regarding claim 51:
Claim 51 depends from claim 14 and further recites “an audit module configured to monitor executed operations for deviation from schema rules and automatically generate a trace log comprising schema identifier, version, executed operation, and TEE instance identifier.” The additional non-abstract elements are monitoring and logging functions used in their expected roles. This limitation amounts to implementing the same abstract compliance-tracking idea with conventional auditing and log generation, without any recited improvement to auditing techniques, log structures, or system operation. It merely specifies ordinary monitoring/logging as the technological setting, which under MPEP § 2106.05(a), (d), and (h) is generic technology use rather than an integration or inventive concept. Accordingly, claim 51 does not add significantly more than the judicial exception and is ineligible under 35 U.S.C. 101.
Regarding claim 52:
Claim 52 depends from claim 1 and further recites “instantiating the trusted execution environment by retrieving a hardware-bound attestation key from a secure element associated with the processing node and validating TEE integrity via a challenge-response protocol involving the consortium ledger.” The additional non-abstract elements are attestation and secure-element operations used in their expected roles. This limitation amounts to applying conventional TEE attestation prior to executing the same abstract privacy-controlled processing, without any recited improvement to attestation protocols, secure elements, or ledger operation. It merely specifies standard security setup as the technological setting, which under MPEP § 2106.05(a), (d), and (h) is generic technology use rather than an integration or inventive concept. Accordingly, claim 52 does not add significantly more than the judicial exception and is ineligible under 35 U.S.C. 101.
Regarding claim 53:
Claim 53 depends from claim 14 and further recites “the decryption key for the manipulated dataset is split into multiple key fragments using a threshold scheme and delivered separately via distinct communication paths to the data receiver, with reassembly occurring only upon authenticated access within a TEE.” The additional non-abstract elements are threshold key splitting, multi-path delivery, and TEE-based reassembly used in their expected roles. This limitation amounts to employing conventional key-management and secure-execution techniques within the same abstract privacy-controlled workflow, without any recited improvement to cryptography, networking, or TEE operation. It merely specifies routine security mechanisms as the technological setting, which under MPEP § 2106.05(a), (d), and (h) is generic technology use rather than an integration or inventive concept. Accordingly, claim 53 does not add significantly more than the judicial exception and is ineligible under 35 U.S.C. 101.
Regarding claim 54:
Claim 54 depends from claim 1 and further recites “masking a subset of identity attributes based on schema rules prior to encryption, wherein masking is governed by attribute sensitivity levels defined in the schema.” The additional non-abstract element is data masking used in its expected role as routine preprocessing. This limitation amounts to applying conventional field-level masking within the same abstract privacy-management workflow, without any recited improvement to data structures, algorithms, or computer functionality. It merely specifies standard data manipulation as the technological setting, which under MPEP § 2106.05(a), (d), and (h) is generic technology use rather than an integration or inventive concept. Accordingly, claim 54 does not add significantly more than the judicial exception and is ineligible under 35 U.S.C. 101.
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.
Claims 1-2, 4-8, 10-15, 17-21, 23-26 and 42-54 are rejected under 35 U.S.C. 112(a) 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 at the time the application was filed, had possession of the claimed invention.
Claims 1 and 14 are rejected under 35 U.S.C. 112(a) for failure to comply with the written description requirement with respect to the limitation “establishing, by a consortium network, a set of permitted data operations for a service network using a plurality of privacy schemas.” The specification describes in general terms that a consortium network comprises system nodes 310, that privacy schemas 523 define mappings between identity attributes and data-processing methods, and that privacy contracts 524 may encode executable instructions distributable via a ledger and loadable into nodes. However, the specification does not disclose what concrete structural construct constitutes the claimed “set of permitted data operations” (for example, no configuration object, record format, schema language, or exemplar representation is provided), nor does it describe specific acts or protocols by which the consortium network “establishes” such a set for a service network (for example, no message formats, contract deployment sequence, node initialization procedure, or ledger transactions are shown). A POSITA would struggle to determine whether the applicant was in possession of how a network of nodes, the so-called “consortium network”, would arrive at choosing or selecting permitted data operation for a service network. The claims, by contrast, are drafted broadly enough to encompass any mechanism by which a consortium network might define, configure, or otherwise provide permitted operations for a service network based on multiple schemas, including mechanisms not described in the application. Under these circumstances, the specification does not reasonably convey to those skilled in the art that the inventor possessed the full scope of the claimed limitation at the time of filing. Accordingly, claims 1 and 14 fail to satisfy the written description requirement of 35 U.S.C. 112(a) with respect to this limitation.
Claims 1 and 14 recite the limitation “identifying, by the service network from the plurality of schemas and based on the transaction request, a privacy schema from the plurality of privacy schemas for use in performing the transaction.” The specification states in general terms that a transaction request includes information such as data owner identity, data receiver identity, consent, transaction context, and transaction type, and that a privacy and consent broker component “identifies” an appropriate privacy schema based on such information. However, the written description does not disclose any specific structural implementation of this identification functionality in the context of the “service network,” such as which node or nodes in the distributed network perform the decision, how those nodes coordinate to select a schema, what data structures (if any) store mappings from request parameters to schemas, or what algorithm, rule engine, or decision procedure is used to select a particular schema from the plurality. Nor does the specification define any finite class of schema-selection structures or mechanisms that are encompassed by “identifying, by the service network … a privacy schema … based on the transaction request.” Instead, the claim language broadly covers any mechanism by which a multi-node service network might inspect request fields and choose a schema, including structural arrangements and selection techniques that are not described in the application. As a result, the specification does not reasonably convey to those skilled in the art that the inventor was in possession, at the time of filing, of the full scope of the “identifying, by the service network … a privacy schema … based on the transaction request” limitation as recited. Accordingly, claims 1 and 14, and the dependent claims reciting this limitation, do not satisfy the written description requirement of 35 U.S.C. 112(a) with respect to this element.
Claim 49 recites that “the service network stores a version history of privacy schemas and is configured to: (a) detect nonconformance of a requested operation with a current schema version, and (b) execute a rollback to a prior schema version associated with the data subject’s consent at the time of data collection.” The specification generally describes that configuration state and policies may be stored in a ledger and that privacy schemas 523 can be defined and updated, but it does not disclose any specific structural implementation of a “version history of privacy schemas” (for example, particular record formats, index structures, or data models that maintain prior schema versions), nor does it describe a concrete mechanism by which the service network “executes a rollback” to a prior schema version associated with a given consent state (for example, specific procedures or data structures for mapping operations to schema versions and restoring prior configurations). The claim language, by contrast, is broad enough to encompass any versioning and rollback architecture for privacy schemas, including architectures and data structures not described in the application. As a result, the written description does not reasonably convey to those skilled in the art that the inventor was in possession, at the time of filing, of the full scope of the “version history” and “rollback” functionality as recited in claim 49. Accordingly, claim 49 fails to satisfy the written description requirement of 35 U.S.C. 112(a) with respect to this limitation.
Claim 50 recites that “the transaction metadata includes at least two digital signatures: (i) a signature from the data owner indicating consent to the identified schema, and (ii) a signature from the consortium network attesting to schema compliance and permitted operations.” The specification discusses that transactions and policies may be recorded on a distributed ledger and references cryptographic keys and attestation concepts in connection with TEEs and ledger entries, but it does not describe any specific transaction-metadata structure that includes both (a) a data owner signature explicitly indicating consent to a particular identified schema and (b) a separate consortium-network signature explicitly attesting both to schema compliance and to permitted operations. Nor does the specification present an example record, field layout, or concrete ledger entry in which such dual signatures are stored in the metadata in the manner claimed. Instead, claim 50 is drafted broadly to cover any transaction-metadata structure incorporating these two distinct signatures and their asserted semantics, without the written description showing that such a dual-signature arrangement was actually possessed by the inventor at the time of filing. Accordingly, claim 50 does not satisfy the written description requirement of 35 U.S.C. 112(a) with respect to this limitation.
Claim 51 recites that “the service network comprises an audit module configured to (a) monitor executed operations for deviation from schema rules, and (b) automatically generate a trace log comprising schema identifier, version, executed operation, and TEE instance identifier.” The specification generally describes that transactions and configuration information may be recorded in a distributed ledger and that these records can be used for verification or audit of system behavior, but it does not describe any particular “audit module” structure or finite class of structures that is configured to perform the full set of claimed functions, nor does it identify any concrete “trace log” data structure distinct from generic ledger entries. In particular, the written description does not disclose a specific software component, process, or combination of data structures that continuously monitors executed operations for “deviation from schema rules” and, upon such monitoring, “automatically generates” a trace log containing at least the recited fields. Instead, the claim language broadly covers any auditing and logging architecture capable of implementing these behaviors. As a result, the specification does not reasonably convey to those skilled in the art that the inventor had possession, at the time of filing, of the full scope of the “audit module” and “trace log” as functionally claimed in claim 51. Furthermore, in the absence of disclosure of specific auditing and trace-logging structures or algorithms, a person of ordinary skill in the art would be required to design and select among numerous possible monitoring mechanisms, logging formats, and trigger conditions without guidance, amounting to undue experimentation to implement the claimed “audit module” and “trace log” across their full breadth. Accordingly, claim 51 does not satisfy the written description requirements of 35 U.S.C. 112(a).
Claim 53 recites that “the decryption key for the manipulated dataset is (a) split into multiple key fragments using a threshold scheme and (b) delivered separately via distinct communication paths to the data receiver, wherein reassembly occurs only upon authenticated access within a TEE.” The specification describes use of a trusted execution environment 211, cryptographic protection of data, and remote attestation, but it does not disclose any threshold or secret-sharing scheme for splitting a decryption key into multiple fragments, any particular representation or data structure for such “key fragments,” any mechanism for selecting or implementing “distinct communication paths” for fragment delivery, or any protocol or structural arrangement for reassembling fragmented keys “only upon authenticated access within a TEE.” The claim language, however, is broad enough to encompass any threshold key-splitting approach, any fragment structure, and any multi-path delivery and reassembly process integrated with a TEE. In the absence of any description of these threshold-scheme and multi-path key-handling features in the specification, the written description does not reasonably convey to those skilled in the art that the inventor was in possession, at the time of filing, of the specific key-fragmentation and distribution configuration recited in claim 53. Accordingly, claim 53 does not satisfy the written description requirement of 35 U.S.C. 112(a) with respect to this limitation.
Claims 50-54 are also rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s), added 26 June 2026, contains new subject matter which was not described and supported 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, at the time the application was filed, had possession of the claimed invention.
Claim 50 discloses transaction metadata having two digital signatures, signature from the data owner and signature from the consortium network. These limitations added 26 June 2026, are not supported in the originally disclosure; therefore, these limitations are new matter.
Claim 51 discloses transaction metadata having an audit module and generating a trace log comprising schema identifier, version, executed operation, and TEE instance identifier . These limitations added 26 June 2026, are not supported in the originally disclosure; therefore, these limitations are new matter.
Claim 52 discloses a hardware-bound attestation key from a secure element and validating the integrity of the TEE based on a challenge-response protocol involving the consortium ledger. These limitations added 26 June 2026, are not supported in the originally disclosure; therefore, these limitations are new matter.
Claim 53 discloses splitting the decryption key into multiple key fragments using a threshold scheme and delivering separately via distinct communication paths to the data receiver and reassembly occurs only upon authenticated access within the TSS. These limitations added 26 June 2026, are not supported in the originally disclosure; therefore, these limitations are new matter.
Claim 54 discloses masking a subset of the identity attributes based on schema rules prior to encryption and wherein the masking is governed by attribute sensitivity levels defined in the schema. These limitations added 26 June 2026, are not supported in the originally disclosure; therefore, these limitations are new matter.
It is requested for Applicant to pinpoint in the original disclosure support for the limitations recited in claims 50-54.
Claims 2, 4-8, 10-13, 15, 17-21, 23-26, 42-45 are rejected as being dependent on, and failing to cure the deficiencies of, rejected independent claim 1
Claims 15, 17-21, 23-26, 46-48 are rejected to because said claims depend upon rejected claim 14.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1 and 14 recite processing “an identity centric dataset associated with a data owner.” The term “identity centric dataset” is a coined expression whose scope is not defined in the specification with reasonably certain boundaries. The disclosure repeatedly uses the phrase in functional context (e.g., ¶¶[0099]–[0105], [0120], [0183]) but does not identify any particular data structure or finite class of structures that constitutes the “identity centric dataset.” There is no definition section, no record layout, table schema, object model, or exemplar serialized format designated as the “identity centric dataset.” The figures likewise do not anchor the term to structure: the “identity ledger” (Fig. 6; ¶¶[0127]–[0129]) is a consortium configuration store, not the claimed dataset; the “privacy-preserved dataset” (Fig. 11; ¶[0184]) is a different construct produced after processing and is not equated to the “identity centric dataset.” Although the text mentions “identity attributes,” “consent,” and “context” (e.g., ¶¶[0132]–[0134], [0185]–[0191]), it does not specify that any minimum set of fields or relationships is required for the “identity centric dataset,” nor how such data is organized. Absent such structural anchoring, and given the generic nature of “dataset,” a person of ordinary skill in the art would not be reasonably apprised of which structural implementations fall within the scope of an “identity centric dataset” and which do not. Accordingly, the scope of this term, and of the claims that depend upon it, is not reasonably certain, and the claims are indefinite under 35 U.S.C. 112(b).
Claims 1 and 14 further recite “a plurality of privacy schemas” and the selection of “a privacy schema” for use in performing the claimed transaction. The term “privacy schema” is a coined expression whose scope is not defined with reasonable certainty in the specification. Although the specification refers to “privacy schemas 523” (see, e.g., Figs. 5, 6; ¶¶[0120]–[0134]) and describes them generally as defining data processing rules, mapping identity attributes to processing methods, or providing a policy enforcement mechanism, it does not identify any particular data structure, schema language, or finite class of structures that constitute a “privacy schema.” There is no definition, record format, table layout, configuration file, or exemplar schema provided, nor is the term expressly limited to block 523 or any enumerated structural implementations. The distinction between a “privacy schema” and related concepts such as “privacy contract 524” is also not structurally delineated. In the absence of structural anchoring, a person of ordinary skill in the art would not be reasonably apprised of which implementations fall within the scope of a “privacy schema” and which do not. Accordingly, the scope of this term, and of the claims that depend upon it, is not reasonably certain, and the claims are indefinite under 35 U.S.C. 112(b).
Claims 1 and 14 recite “establishing, by a consortium network, a set of permitted data operations for a service network using a plurality of privacy schemas,” and executing “one or more data operations from the set of permitted data operations,” but the phrase “set of permitted data operations” is likewise not clearly defined in structural terms. The specification lists example operation types (such as data transformation, data encryption, data anonymization, data pseudo-anonymization, data tokenization, data enrichment, data label assignment, data classification label assignment, and data dissemination marker assignment) and states that privacy schemas 523 and privacy contracts 524 define and implement such operations. However, the written description does not identify any particular data structure or finite class of data structures that constitute the claimed “set of permitted data operations” (for example, no specific list, table, record type, configuration object, or other data construct is designated as the “set of permitted data operations,” nor is the term explicitly equated to privacy schemas 523, privacy contracts 524, or any other specific structure). The root term “set” is itself generic and does not connote any particular structural representation to a person of ordinary skill in the art. In the absence of such structural anchoring, and given the generic nature of “set” as used here, one of ordinary skill in the art would not be reasonably apprised of which structural implementations fall within the scope of a “set of permitted data operations” and which do not. Accordingly, the scope of this term, and of the claims that depend upon it, is not reasonably certain, rendering these claims indefinite under 35 U.S.C. 112(b).
Claims 1 and 14 recite, in relevant part, “a transaction request to perform the transaction in relation to the identity centric dataset associated with a data owner” or similar language. The phrase “in relation to” is a broad, relational expression that does not, on its face, specify what kind of technical interaction with the “identity centric dataset” is required (e.g., reading data from the dataset, writing or updating data, transforming the dataset, deriving new data from it, or merely referencing it). The specification repeats this wording in describing method 400 and system 300, stating that a transaction request is received “to perform the transaction in relation to an identity centric dataset associated with a data owner,” and later explains that certain data operations are executed “upon the identity centric dataset,” but it does not define “in relation to” or limit it to any particular type of operation or finite class of operations involving the dataset. As a result, a person of ordinary skill in the art cannot determine with reasonable certainty whether a transaction that merely references or concerns the dataset, without actually accessing or modifying it, falls within the scope of the claims, or whether some more specific interaction is required. In the absence of a clear structural or behavioral definition of what it means for a transaction to be “in relation to” the identity centric dataset, the metes and bounds of this claim language are not reasonably certain. Accordingly, the above-identified claims are indefinite under 35 U.S.C. 112(b).
Claims 4 and 17 recite that the “one or more data operations” comprise at least one of “a data transformation operation, a data encryption operation, a data privacy preservation operation, a data anonymization operation, a data pseudo-anonymization / pseudo-anonymization operation, a data tokenization operation, a data enrichment operation, a data label assignment operation, a data classification label assignment operation, and a data dissemination marker assignment operation.” Although the specification lists these phrases as examples of operation types, it does not identify any particular data structure, software module, or finite class of structures corresponding to each of these “operations.” Instead, the terms function as high-level functional labels for unspecified processing behaviors. In the absence of structural anchoring or explicit limitation to the particular operation implementations disclosed, a person of ordinary skill in the art would not be reasonably apprised of which structural implementations fall within the scope of “data privacy preservation operation,” “data enrichment operation,” “data label assignment operation,” “data classification label assignment operation,” and “data dissemination marker assignment operation,” and which do not. Accordingly, claims 4 and 17 are indefinite under 35 U.S.C. 112(b).
Claims 46-48 depend from claim 14, which is directed to a system. However, claims 46-48 are drafted in method form and refer to “the method of claim 14.” Claim 14 does not recite a method, and a method claim cannot properly depend from a system claim. The inconsistency in statutory class renders the scope of claims 46-48 unclear, as it is not reasonably certain whether the claims are intended to further limit the system of claim 14 or instead recite a separate method.
Claim 49 recites that “the service network stores a version history of privacy schemas and is configured to (a) detect nonconformance of a requested operation with a current schema version, and (b) execute a rollback to a prior schema version associated with the data subject’s consent at the time of data collection.” While the specification generally describes that configuration state and policies may be stored in a ledger and that privacy schemas 523 can be updated, it does not define any particular “version history” data structure or finite class of data structures for storing such history, nor does it describe a specific structural mechanism for “rollback” to prior schema versions (e.g., specific record types, indexes, or algorithms designated as the version-history/rollback mechanism). The phrases “version history of privacy schemas” and “rollback to a prior schema version” therefore operate as high-level behavioral descriptions without structural delimitation. In the absence of structural anchoring, a person of ordinary skill in the art would not be reasonably apprised of which structural implementations fall within the scope of these elements and which do not. Accordingly, claim 49 is indefinite under 35 U.S.C. 112(b).
Claim 50 recites that “the transaction metadata includes at least two digital signatures: (i) a signature from the data owner indicating consent to the identified schema, and (ii) a signature from the consortium network attesting to schema compliance and permitted operations.” The specification references the use of cryptographic keys and distributed ledger entries but does not define any particular data structure or finite class of data structures that constitute these “digital signatures” as part of the transaction metadata (e.g., specific signature fields, formats, or storage structures in the ledger). Nor does it identify a specific structural mechanism by which the “consortium network” signature “attests to schema compliance and permitted operations.” In the absence of structural delimitation, the term “digital signatures” as used in claim 50 is broad enough to encompass any cryptographic or non-cryptographic attestation constructs, and a person of ordinary skill in the art would not be reasonably apprised of the structural boundaries of this claim element. Accordingly, claim 50 is indefinite under 35 U.S.C. 112(b).
Claim 51 recites that “the service network comprises an audit module” configured to “(a) monitor executed operations for deviation from schema rules, and (b) automatically generate a trace log comprising schema identifier, version, executed operation, and TEE instance identifier.” The specification describes that ledger records and metadata can be used to verify or audit transactions, but it does not identify any particular structural implementation of an “audit module” (e.g., a defined software component, process, or data structure) or any specific “trace log” data structure or finite class of such structures, distinct from generic ledger entries. As used, “audit module” and “trace log” function as broad functional labels for unspecified monitoring and logging facilities rather than structurally delimited elements. In the absence of structural anchoring, one of ordinary skill in the art would not be reasonably apprised of which structural implementations constitute the recited “audit module” and “trace log.” Accordingly, claim 51 is indefinite under 35 U.S.C. 112(b).
Claim 52 recites that “instantiating the trusted execution environment comprises retrieving a hardware-bound attestation key from a secure element associated with the processing node and validating the integrity of the TEE based on a challenge-response protocol involving the consortium ledger.” The specification describes TEEs and mentions remote attestation in general terms but does not define the structural nature of a “hardware-bound attestation key” (e.g., specific key format, storage structure, or hardware location) or the specific structural implementation of a “challenge-response protocol involving the consortium ledger” (e.g., particular message formats, ledger entries, or verification records). Without structural definition or limitation to particular known attestation protocols, these phrases function as high-level descriptions of unspecified attestation mechanisms, and a person of ordinary skill in the art would not be reasonably apprised of the structural boundaries of the claimed attestation scheme. Accordingly, claim 52 is indefinite under 35 U.S.C. 112(b).
Claim 53 recites that “the decryption key for the manipulated dataset is (a) split into multiple key fragments using a threshold scheme and (b) delivered separately via distinct communication paths to the data receiver, wherein reassembly occurs only upon authenticated access within a TEE.” The specification does not disclose any threshold or secret-sharing scheme, any structural representation of “key fragments,” any definition of “distinct communication paths” in this context, or any specific mechanism for “reassembly” of such fragments within a TEE. These terms therefore operate as broad cryptographic and networking labels without being tied to particular data structures, protocols, or finite sets of structural implementations. In the absence of such structural anchoring, a person of ordinary skill in the art would not be reasonably apprised of which threshold key-splitting and multi-path delivery arrangements fall within the scope of claim 53 and which do not. Accordingly, claim 53 is indefinite under 35 U.S.C. 112(b).
Claim 54 recites “masking a subset of identity attributes based on schema rules prior to encryption, wherein the masking is governed by attribute sensitivity levels defined in the schema.” Although the specification discusses anonymization/pseudo-anonymization and that privacy schemas may define how attributes can be used or disclosed, it does not define any particular data structure or finite class of data structures representing “attribute sensitivity levels,” nor does it describe a specific masking mechanism or mask representation governed by such levels. The term “attribute sensitivity levels” thus functions as a high-level policy concept rather than a structurally delimited claim element, and the claimed masking operation is not structurally anchored. In the absence of such structural definition, one of ordinary skill in the art would not be reasonably apprised of the structural scope of “attribute sensitivity levels” and schema-governed masking as recited in claim 54. Accordingly, claim 54 is indefinite under 35 U.S.C. 112(b).
Claims 2, 4-8, 10-13, 15, 17-21, 23-26 and 42-54 depend, directly or indirectly, from independent claims 1 and/or 14 and therefore include the limitations that are found to be indefinite in the parent claims. Because the dependent claims do not add any limitations that clarify, structurally define, or otherwise resolve the indefiniteness of these terms, they inherit the same 35 U.S.C. 112(b) deficiencies discussed above for claims 1 and 14. Accordingly, claims 2, 4–8, 10–13, 15, 17–21, 23–26, and 42–54 are likewise rejected under 35 U.S.C. 112(b) on the same grounds as their respective independent claims, in addition to any additional rejections mentioned above.
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-2, 4-8, 10-15, 17-21, 23-26, and 42-50 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bohrer et al US 20030088520 (hereinafter Bohrer) in view of Shadmon et al US 20190158594 (hereinafter Shadmon).
As to claim 1, Bohrer teaches a method of performing a transaction in relation to an identity centric dataset (abstract discloses a method to enforce privacy preferences on exchanges/transaction of personal data in relation to data subject (identity centric) rules having one or more subject constraints on one or more private data releases. Paragraph 12 reveals different business transactions that include requested information), wherein the method comprises:
establishing, by a consortium network, a set of permitted data operations for a service network using a plurality of privacy schemas (paragraph 33 discloses establishing authorization rules and data privacy policies/controls for requested data and requestors. The system provides functionalities of define authorization rules and privacy controls, send and handle requests for data, authenticate requesters, authorize release of data based on authorization rules and privacy policy matching and release data. Paragraph 16 and Claim 1 disclose the system comprises one or more computers connected to one or more networks providing service of enforcing privacy preferences on exchanges of personal data that is owned by the subject itself or held/owned by third parties such as enterprises. Thus the system utilizes a consortium/service enterprise network. Paragraph 49 further discloses permitted set of data operations for requested data such as specifying privacy preference rule for data requestors in the access list to access the data in the authorization dataset. The Privacy Preference Rule in an Authorization Rule contains two declarations: data subject's privacy preferences and access actions allowed by the data subject. The Privacy Preference also specifies why and how the data can be accessed in terms of the P3P standards. The privacy preferences rules, the access list and the authorization rules are the plurality of privacy schemas);
receiving, by the service network, a transaction request to perform the transaction in relation to the identity centric dataset associated with a data owner (paragraphs 32-33 disclose a data requestor uses a web browser of the system/service network or some other computer programs to send requests/transaction for data from a data subject. Each request for data is also accompanied by the data requestor’s privacy policies describing the intended usages of the requested data. Paragraphs 33, 79-80 and 82 reveal the request is in relation to the data of the data subject, thus it is identity centric dataset. Paragraph 12 reveals different business transactions include requestion information. See also paragraphs 21, 33, 44-45, 78-82);
identifying, by the service network from the plurality of schemas and based on the transaction request, a privacy schema from the plurality of privacy schemas for use in performing the transaction (paragraph 42 discloses the request is handled by the Profile Responder of the system/service network which uses the Authentication engine to verify the identity of the requester and the Policy Authorization engine to identify/check the authority of the requester to access the requested data by using/identifying authorization rules and privacy policies (plurality of privacy schemas). See also paragraphs 44-49, 82, and 84);
performing the transaction … using one or more data operations from the set of permitted data operations upon the identity centric dataset of the data owner as permitted by the identified privacy schema thereby generating a manipulated dataset and transaction metadata (Figure 7 discloses the steps involves in performing the transaction of the requested data. Paragraph 82, 84-88 further describe performing the transaction using one or more privacy level/identified schema from the permitted authorization rules of the data subject. Paragraph 86 reveals the different privacy levels/data label assignment operations that is performed in performing the data transaction request. Paragraph 87 further discloses checking the corresponding Boolean tag (generated transaction metadata) of a specific action in the preference settings (paragraph 77 discloses Boolean values are used to represent the access requirement flag). Paragraph 88 provides additional details of the data operation of filtering the data based on the privacy policies and authorization rules of the data subject. The filtered data is a manipulated dataset. Paragraph 9 also discloses manipulating data by transforming data so that it is no longer personally identifiable or to operate on data and produce results that are not personally identifiable);
recording the transaction metadata (paragraph 91 discloses storing the data subject privacy preferences governing the data owned/stored by the enterprise (paragraph 77 reveals the privacy preferences includes the action permissions such as the Boolean values (transaction metadata) ). Paragraph 38 also discloses actions are stored in the form of rules or explicit action types which are recorded); and
transferring the manipulated dataset to a data receiver indicated by the transaction request (paragraph 88 discloses sending the filtered data/manipulated data result to the data requestor as indicated in the transaction request).
Bohrer does not teach, but Shadmon teaches performing the transaction by executing, in a trusted execution environment of the service network (paragraph 418 discloses processing queries/requests via trusted execution environment), one or more data operations from the set of permitted data operations…as permitted by the identified privacy schema thereby generating a manipulated dataset and transaction metadata (paragraphs 414 and 418-419 disclose processing queries/requests via trusted execution environment on confidential data to obtain a result. A catalog is used in the process, therefore, when a query is processed, the catalog provides the information on the log files that needs to be considered to satisfy the query. The said catalog contains the metadata information such that when a query is processed the metadata provides the list of log files to consider and where each file is stored. The results are aggregated/manipulated to obtain the unified result. Paragraphs 413-414 reveal the data is distributed based on the level of data protection and on the policies regarding access permissions for data consumer/requestor); recording the transaction metadata to a distributed ledger of the service network (paragraph 271 discloses the metadata is maintained by a blockchain. The metadata may be represented by Accounts and Transactions on the blockchain and the meta information becomes available to a query process as the blockchain data is available. Paragraph 16 further discloses data is organized in log files which are stored on a network of machine (paragraph 18 discloses the service network) and paragraph 49 discloses that the plurality of log files are stored on the distributed server/ledgers).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Bohrer’s system performing the transaction and recording the transaction metadata with Shadmon’s teachings of processing the queries in the trusted execution environment and recording the transaction metadata to a distributed ledger to ensure that submitted queries/requests/transactions do not reveal information the data consumer is not authorized to access and that the query results only rely on authenticated data (paragraph 418 of Shadmon).
As to claim 2, the combination of Bohrer in view of Shadmon teaches wherein the privacy schema is identified from the plurality of privacy schemas based on at least one of the data owner and the data receiver as indicated by the transaction request (Bohrer: Figure 2 and paragraphs 44-47 disclose privacy schema (authorization rule) is identified from plurality of privacy schemas such as authorization dataset, privacy preference rule, access list, or authorization actions that are based on the data receiver and set by the data owner/subject. Paragraph 42 discloses the request/transaction for data describe the data desired along with privacy policies describing the intended usage).
As to claim 4, the combination of Bohrer in view of Shadmon teaches wherein the one or more data operations comprise at least one of: a data transformation operation; a data encryption operation; a data privacy preservation operation; a data anonymization operation; a data pseudo-anonymization operation; a data tokenization operation; a data enrichment operation; a data label assignment operation; a data classification label assignment operation; and a data dissemination marker assignment operation (Bohrer: paragraph 9 discloses enterprise Privacy-enhancing Data Manipulation tools and technologies are used to eliminate privacy issues by transforming data so it is no longer personally identifiable, or to operate on data and produce results that are not personally identifiable. Paragraph 87 reveals providing data classification label/Boolean tag of a specific action. Shadmon: paragraph 414 reveals data operation may involves anonymity requirements). Motivation similar to the motivation presented in claim 1.
As to claim 5, the combination of Bohrer in view of Shadmon teaches wherein the transaction metadata is indicative of one or more identity attribute identifiers (Bohrer: paragraph 87 reveals providing data classification label/Boolean tag of a specific action) ; a transaction context (Shadmon: paragraph 16 discloses metadata provides context to the data); consent of the data owner (Shadmon: paragraph 28 discloses the metadata determines the permissions, by the data owner provided to the user); an identifier of the data owner (Shadmon: paragraph 26 discloses the metadata determines the list of members registered to service data. Paragraph 76 reveals the metadata include the list of authorized users and their permissions); an identifier of the data receiver (Shadmon: paragraph 26 discloses the metadata determines the list of members registered to service data); and an identifier of each identifiers of the one or more data operations (Shadmon: paragraph 21 reveals the metadata determine which members maintain the log files that are needed to be considered in order to satisfy the query. Paragraph 45 discloses when data is distributed to the contractors, the identifiers of the data and the distribution of the data are registered using a registry. The node can maintain a local copy of the metadata/identifiers). Motivation similar to the motivation presented in claim 1.
As to claim 6, the combination of Bohrer in view of Shadmon teaches wherein the transaction request is indicative of the consent of the data owner and the transaction context (Bohrer: paragraphs 47 and 82 disclose the request involves identifying the authorization rules /consent of the data subject/owner and the access list/transaction context. Paragraph 12 discloses the context of the request allows the data subject/owner to allow access to different sets of data with different polices on usage and sharing).
As to claim 7, the combination of Bohrer in view of Shadmon teaches wherein the privacy schema is identified from the plurality of privacy schemas based on at least one of the consent of the data owner and the transaction context (Bohrer: Figure 2 and paragraphs 44-47 disclose privacy schema (authorization rule) is identified from plurality of privacy schemas such as authorization dataset (consent), privacy preference rule (consent), access list, or authorization actions that are based/set by the data owner/subject. Paragraph 42 discloses the request/transaction for data describe the data desired along with privacy policies describing the intended usage. Paragraph 12 discloses the context of the request allows the data subject/owner to allow access to different sets of data with different polices on usage and sharing).
As to claim 8, the combination of Bohrer in view of Shadmon teaches wherein the manipulated dataset comprises one or more transaction data records and the transaction metadata (Bohrer: paragraph 88 provides additional details of the data operation of filtering the data that was gathered from databases/data record (paragraphs 3, 17, and 91 reveal data subject stores their record in a data repository) based on the privacy policies and authorization rules of the data subject. The filtered data is a manipulated dataset. Paragraph 9 also discloses manipulating data by transforming data so that it is no longer personally identifiable or to operate on data and produce results that are not personally identifiable).
As to claim 10, the combination of Bohrer in view of Shadmon teaches wherein the service network includes a service application programming interface (API), wherein the transaction request is received from a data owner device via the service API (Bohrer: abstract discloses system receives a request from a data requester over a network interface. Claim 1 discloses the system further comprising receiving process that receives a request message from a data-requester over the network interfaces. Shadmon: paragraphs 22-23 reveal query is sent to a computer from an application using a REST API. Paragraph 395 reveals parties (which can include other data owners) can request data).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify the network interface in Bohrer’s system performing the transaction and recording the transaction metadata with Shadmon’s teachings of utilizing REST API such that data owners can provide access to third parties in a simple/convenient manner (paragraph 65 of Shadmon).
As to claim 11, the combination of Bohrer in view of Shadmon teaches wherein at least some of the manipulated dataset is encrypted by the service network based on the one or more data operations (Shadmon: paragraph 341-342 and 418 reveal the data is encrypted and processed in the TEE) , wherein the method further comprises: receiving, via the service API, a data access request (Bohrer: abstract discloses system receives a request from a data requester over a network interface. Claim 1 discloses the system further comprising receiving process that receives a request message from a data-requester over the network interfaces. Shadmon: paragraphs 22-23 reveal query is sent to a computer from an application using a REST API); determining, based on the data access request, if the data receiver is permitted to perform decryption of the at least some of the manipulated dataset (Shadmon: paragraph 418 reveals that only within the TEE can the encrypted data be decrypted for further processes. Paragraph 428 also disclose that within the TEE and the access permission (permitting the data receiver to obtain the data) the data is decrypted); and if the data receiver is determined to be permitted: generating and transferring, to the data receiver, a decryption key to enable the data receiver to decrypt the at least some of the manipulated dataset (Shadmon: paragraphs 49 and 51 reveal the decryption key is sent for the data from the servers to the permitted clients (thus data receiver is enable to receive the data); and recording, by the service network, further transaction metadata to the distributed ledger (Shadmon: paragraph 271 discloses the metadata is maintained by a blockchain. The metadata may be represented by Accounts and Transactions on the blockchain and the meta information becomes available to a query process as the blockchain data is available. Paragraph 16 further discloses data is organized in log files which are stored on a network of machine (paragraph 18 discloses the service network) and paragraph 49 discloses that the plurality of log files are stored on the distributed server/ledgers).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Bohrer’s system performing the transaction and recording the transaction metadata with Shadmon’s teachings of processing the queries in the trusted execution environment and recording the transaction metadata to a distributed ledger to ensure that submitted queries/requests/transactions do not reveal information the data consumer is not authorized to access and that the query results only rely on authenticated data (paragraph 418 of Shadmon).
As to claim 12, the combination of Bohrer in view of Shadmon teaches wherein the method further comprises configuring the service network by initializing one or more system nodes based on a plurality of smart contracts (Shadmon: paragraph 65 reveals the smart contracts document enforce the agreements that are made between peers (nodes) of the network, see also paragraph 120-122 which reveal a smart contract manages payments to the contractor, when the query is issued, the query is provided to a Coordinator node and processed by the Coordinator Node). Paragraph 355 discloses penalty would be enforced by a smart contract that would validate the integrity of the data maintained on the node or the node's response to a query by comparing the data or the query result to a different node that maintains the same data or process the same query over the same data. Or, if the node is not responsive, the smart contract can provide a time from which the penalty is triggered if the node remains unresponsive) and the plurality of privacy schemas distributed via a further distributed ledger (Shadmon: paragraphs 305 reveals the smart contract is stored in the block chain (paragraph 415 disclose the smart contract encodes a decentralized protocol for updating schema and security policies)), wherein the plurality of smart contracts encode the plurality of data operations (Shadmon: paragraph 415 disclose the smart contract encodes a decentralized protocol for updating schema and security policies).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Bohrer’s system performing the transaction and recording the transaction metadata with Shadmon’s teachings of processing smart contracts to validate the integrity of the data maintained on the node or the node's response to a query (paragraph 355 of Shadmon).
As to claim 13, the combination of Bohrer in view of Shadmon teaches wherein the consortium network includes a plurality of system nodes (Bohrer: paragraph 16 and Claim 1 disclose the system comprises one or more computers connected to one or more networks providing service of enforcing privacy preferences on exchanges of personal data that is owned by the subject itself or held/owned by third parties such as enterprises. Thus the system utilizes a consortium/service enterprise network. Shadmon: paragraph 30 discloses members of the network are nodes on a blockchain network) , wherein the method further comprises: establishing the service network, wherein the one or more system nodes are part of the plurality of system nodes (Bohrer: paragraph 16 and Claim 1 disclose the system comprises one or more computers connected to one or more networks providing service of enforcing privacy preferences on exchanges of personal data that is owned by the subject itself or held/owned by third parties such as enterprises. Thus the system utilizes a consortium/service enterprise network. Shadmon: paragraph 30 discloses members of the network are nodes on a blockchain network).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify the systems computers in a network Bohrer’s system performing the transaction and recording the transaction metadata with Shadmon’s teachings of nodes on a blockchain network to facilitate the improved functionalities provided by the members of the network (paragraph 30 of Shadmon).
As to claim 14, Bohrer teaches a system of performing a transaction in relation to an identity centric dataset (abstract discloses system and method to enforce privacy preferences on exchanges/transaction of personal data in relation to data subject (identity centric) rules having one or more subject constraints on one or more private data releases. Paragraph 12 reveals different business transactions include requestion information), wherein the system comprises one or more processing systems (abstract, paragraph 29, claim 38 disclose the system utilizes one or more computers in a computer network) configured to:
establish a set of permitted data operations for a service network using a plurality of privacy schemas (paragraph 33 discloses establishing authorization rules and data privacy policies/controls for requested data and requestors. The system provides functionalities of define authorization rules and privacy controls, send and handle requests for data, authenticate requesters, authorize release of data based on authorization rules and privacy policy matching and release data. Paragraph 16 and Claim 1 disclose the system comprises one or more computers connected to one or more networks providing service of enforcing privacy preferences on exchanges of personal data that is owned by the subject itself or held/owned by third parties such as enterprises. Thus the system utilizes a consortium/service enterprise network. Paragraph 49 further discloses permitted set of data operations for requested data such as specifying privacy preference rule for data requestors in the access list to access the data in the authorization dataset. The Privacy Preference Rule in an Authorization Rule contains two declarations: data subject's privacy preferences and access actions allowed by the data subject. The Privacy Preference also specifies why and how the data can be accessed in terms of the P3P standards. The privacy preferences rules, the access list and the authorization rules are the plurality of privacy schemas);
receive a transaction request to perform the transaction in relation to the identity centric dataset associated with a data owner (paragraphs 32-33 disclose a data requestor uses a web browser of the system/service network or some other computer programs to send requests/transaction for data from a data subject. Each request for data is also accompanied by the data requestor’s privacy policies describing the intended usages of the requested data. Paragraphs 33, 79-80 and 82 reveal the request is in relation to the data of the data subject, thus it is identity centric dataset. Paragraph 12 reveals different business transactions include requestion information. See also paragraphs 21, 33, 44-45, 78-82);
identify, from the plurality of schemas and based on the transaction request, a privacy schema from the plurality of privacy schemas for use in performing the transaction (paragraph 42 discloses the request is handled by the Profile Responder of the system/service network which uses the Authentication engine to verify the identity of the requester and the Policy Authorization engine to check the authority of the requester to access the requested data by using authorization rules and privacy policies (plurality of privacy schemas). See also paragraphs 44-49, 82, and 84);
perform the transaction … one or more data operations from the set of permitted data operations upon the identity centric dataset of the data owner as permitted by the identified privacy schema thereby generating a manipulated dataset and transaction metadata (Figure 7 discloses the steps involves in performing the transaction/requested data. Paragraph 82, 84-88 further describe performing the transaction using one or more privacy level/identified schema from the permitted authorization rules of the data subject. Paragraph 86 reveals the different privacy levels/data label assignment operations that is performed in performing the data transaction request. Paragraph 87 further discloses checking the corresponding Boolean tag (generated transaction metadata) of a specific action in the preference settings (paragraph 77 discloses Boolean values are used to represent the access requirement flag). Paragraph 88 provides additional details of the data operation of filtering the data based on the privacy policies and authorization rules of the data subject. The filtered data is a manipulated dataset. Paragraph 9 also discloses manipulating data by transforming data so that it is no longer personally identifiable or to operate on data and produce results that are not personally identifiable);
record the transaction metadata (paragraph 91 discloses storing the data subject privacy preferences governing the data owned/stored by the enterprise (paragraph 77 reveals the privacy preferences includes the action permissions such as the Boolean values (transaction metadata) ). Paragraph 38 also discloses actions that were intercepted and is stored in the form of rules or explicit action types which are recorded); and
transfer the manipulated dataset to a data receiver indicated by the transaction request (paragraph 88 discloses sending the filtered data result to the data requestor as indicated int eh transaction request).
Bohrer does not teach, but Shadmon teaches perform the transaction by executing, in a trusted execution environment of the service network (paragraph 418 discloses processing queries/requests via trusted execution environment), one or more data operations from the set of permitted data operations…as permitted by the identified privacy schema thereby generating a manipulated dataset and transaction metadata (paragraphs 414 and 418-419 disclose processing queries/requests as disclosed in the publication via trusted execution environment on confidential data to obtain a result. A catalog is used in the process, therefore, when a query is processed, the catalog provides the information on the log files that needs to be considered to satisfy the query and the contractor that maintains each log file. The said catalog contains the metadata information such that when a query is processed the metadata provides the list of log files to consider and where each file is stored. The results are aggregated/manipulated to obtain the unified result. Paragraphs 413-414 reveal the data is distributed based on the level of data protection and on the policies regarding access permissions for data consumer/requestor); record the transaction metadata to a distributed ledger of the service network (paragraph 271 discloses the metadata is maintained by a blockchain. The metadata may be represented by Accounts and Transactions on the blockchain and the meta information becomes available to a query process as the blockchain data is available. Paragraph 16 further discloses data is organized in log files which are stored on a network of machine (paragraph 18 discloses the service network) and paragraph 49 discloses that the plurality of log files are stored on the distributed server/ledgers).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Bohrer’s system performing the transaction and recording the transaction metadata with Shadmon’s teachings of processing the queries in the trusted execution environment and recording the transaction metadata to a distributed ledger to ensure that submitted queries/requests/transactions do not reveal information the data consumer is not authorized to access and that the query results only rely on authenticated data (paragraph 418 of Shadmon).
As to claim 15, the combination of Bohrer in view of Shadmon teaches wherein the privacy schema is identified from the plurality of privacy schemas based on at least one of the data owner and the data receiver as indicated by the transaction request (Bohrer: Figure 2 and paragraphs 44-47 disclose privacy schema (authorization rule) is identified from plurality of privacy schemas such as authorization dataset, privacy preference rule, access list, or authorization actions that are based on the data receiver and set by the data owner/subject. Paragraph 42 discloses the request/transaction for data describe the data desired along with privacy policies describing the intended usage).
As to claim 17, the combination of Bohrer in view of Shadmon teaches wherein the one or more data operations comprise at least one of: a data transformation operation; a data encryption operation; a data privacy preservation operation; a data anonymization operation; a data pseudo-anonymization operation; a data tokenization operation; a data enrichment operation; a data label assignment operation; a data classification label assignment operation; and a data dissemination marker assignment operation (Bohrer: paragraph 9 discloses enterprise Privacy-enhancing Data Manipulation tools and technologies are used to eliminate privacy issues by transforming data so it is no longer personally identifiable, or to operate on data and produce results that are not personally identifiable. Paragraph 87 reveals providing data classification label/Boolean tag of a specific action. Shadmon: paragraph 414 reveals data operation may involves anonymity requirements). Motivation similar to the motivation presented in claim 14.
As to claim 18, the combination of Bohrer in view of Shadmon teaches wherein the transaction metadata is indicative of one or more identity attribute identifiers (Bohrer: paragraph 87 reveals providing data classification label/Boolean tag of a specific action) ; a transaction context (Shadmon: paragraph 16 discloses metadata provides context to the data); consent of the data owner (Shadmon: paragraph 28 discloses the metadata determines the permissions, by the data owner provided to the user); an identifier of the data owner (Shadmon: paragraph 26 discloses the metadata determines the list of members registered to service data. Paragraph 76 reveals the metadata include the list of authorized users and their permissions); an identifier of the data receiver (Shadmon: paragraph 26 discloses the metadata determines the list of members registered to service data); and an identifier of each identifiers of the one or more data operations (Shadmon: paragraph 21 reveals the metadata determine which members maintain the log files that are needed to be considered in order to satisfy the query. Paragraph 45 discloses when data is distributed to the contractors, the identifiers of the data and the distribution of the data are registered using a registry. The node can maintain a local copy of the metadata/identifiers). Motivation similar to the motivation presented in claim 14.
As to claim 19, the combination of Bohrer in view of Shadmon teaches wherein the transaction request is indicative of the consent of the data owner and the transaction context (Bohrer: paragraphs 47 and 82 disclose the request involves identifying the authorization rules /consent of the data subject/owner and the access list/transaction context. Paragraph 12 discloses the context of the request allows the data subject/owner to allow access to different sets of data with different polices on usage and sharing).
As to claim 20, the combination of Bohrer in view of Shadmon teaches wherein the privacy schema is identified from the plurality of privacy schemas based on at least one of the consent of the data owner and the transaction context (Bohrer: Figure 2 and paragraphs 44-47 disclose privacy schema (authorization rule) is identified from plurality of privacy schemas such as authorization dataset (consent), privacy preference rule (consent), access list, or authorization actions that are based/set by the data owner/subject. Paragraph 42 discloses the request/transaction for data describe the data desired along with privacy policies describing the intended usage. Paragraph 12 discloses the context of the request allows the data subject/owner to allow access to different sets of data with different polices on usage and sharing).
As to claim 21, the combination of Bohrer in view of Shadmon teaches wherein the manipulated dataset comprises one or more transaction data records and the transaction metadata (Bohrer: paragraph 88 provides additional details of the data operation of filtering the data that was gathered from databases/data record (paragraphs 3, 17, and 91 reveal data subject stores their record in a data repository) based on the privacy policies and authorization rules of the data subject. The filtered data is a manipulated dataset. Paragraph 9 also discloses manipulating data by transforming data so that it is no longer personally identifiable or to operate on data and produce results that are not personally identifiable).
As to claim 23, the combination of Bohrer in view of Shadmon teaches wherein the service network includes a service application programming interface (API), wherein the transaction request is received from a data owner device via the service API (Bohrer: abstract discloses system receives a request from a data requester over a network interface. Claim 1 discloses the system further comprising receiving process that receives a request message from a data-requester over the network interfaces. Shadmon: paragraphs 22-23 reveal query is sent to a computer from an application using a REST API. Paragraph 395 reveals parties (which can include other data owners) can request data).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify the network interface in Bohrer’s system performing the transaction and recording the transaction metadata with Shadmon’s teachings of utilizing REST API such that data owners can provide access to third parties in a simple/convenient way (paragraph 65 of Shadmon).
As to claim 24, the combination of Bohrer in view of Shadmon teaches wherein at least some of the manipulated dataset is encrypted by the service network based on the one or more data operations (Shadmon: paragraph 341-342 and 418 reveal the data is encrypted and processed in the TEE) , wherein the consortium network is further configured to: receive, via the service API, a data access request (Bohrer: abstract discloses system receives a request from a data requester over a network interface. Claim 1 discloses the system further comprising receiving process that receives a request message from a data-requester over the network interfaces. Shadmon: paragraphs 22-23 reveal query is sent to a computer from an application using a REST API); determine, based on the data access request, if the data receiver is permitted to perform decryption of the at least some of the manipulated dataset (Shadmon: paragraph 418 reveals that only within the TEE can the encrypted data be decrypted for further processes. Paragraph 428 also disclose that within the TEE and the access permission (permitting the data receiver to obtain the data) the data is decrypted); and if the data receiver is determined to be permitted: generate and transfer, to the data receiver, a decryption key to enable the data receiver to decrypt the at least some of the manipulated dataset (Shadmon: paragraphs 49 and 51 reveal the decryption key is sent for the data from the servers to the permitted clients (thus data receiver is enable to receive the data); and record, by the service network, further transaction metadata to the distributed ledger (Shadmon: paragraph 271 discloses the metadata is maintained by a blockchain. The metadata may be represented by Accounts and Transactions on the blockchain and the meta information becomes available to a query process as the blockchain data is available. Paragraph 16 further discloses data is organized in log files which are stored on a network of machine (paragraph 18 discloses the service network) and paragraph 49 discloses that the plurality of log files are stored on the distributed server/ledgers).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Bohrer’s system performing the transaction and recording the transaction metadata with Shadmon’s teachings of processing the queries in the trusted execution environment and recording the transaction metadata to a distributed ledger to ensure that submitted queries/requests/transactions do not reveal information the data consumer is not authorized to access and that the query results only rely on authenticated data (paragraph 418 of Shadmon).
As to claim 25, the combination of Bohrer in view of Shadmon teaches wherein the one or more processing systems configure the service network by initializing one or more system nodes based on a plurality of smart contracts (Shadmon: paragraph 65 reveals the smart contracts document enforce the agreements that are made between peers (nodes) of the network, see also paragraph 120-122 which reveal a smart contract manages payments to the contractor, when the query is issued, the query is provided to a Coordinator node and processed by the Coordinator Node). Paragraph 355 discloses penalty would be enforced by a smart contract that would validate the integrity of the data maintained on the node or the node's response to a query by comparing the data or the query result to a different node that maintains the same data or process the same query over the same data. Or, if the node is not responsive, the smart contract can provide a time from which the penalty is triggered if the node remains unresponsive) and the plurality of privacy schemas distributed via a further distributed ledger (Shadmon :paragraphs 305 reveals the smart contract is stored in the block chain (paragraph 415 disclose the smart contract encodes a decentralized protocol for updating schema and security policies)), wherein the plurality of smart contracts encode the plurality of data operations (Shadmon: paragraph 415 disclose the smart contract encodes a decentralized protocol for updating schema and security policies).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Bohrer’s system performing the transaction and recording the transaction metadata with Shadmon’s teachings of processing smart contracts to validate the integrity of the data maintained on the node or the node's response to a query (paragraph 355 of Shadmon).
As to claim 26, the combination of Bohrer in view of Shadmon teaches wherein the consortium network includes a plurality of system nodes (Bohrer: paragraph 16 and Claim 1 disclose the system comprises one or more computers connected to one or more networks providing service of enforcing privacy preferences on exchanges of personal data that is owned by the subject itself or held/owned by third parties such as enterprises. Thus the system utilizes a consortium/service enterprise network. Shadmon: paragraph 30 discloses members of the network are nodes on a blockchain network) , wherein the method further comprises: establishing the service network, wherein the one or more system nodes are part of the plurality of system nodes (Bohrer: paragraph 16 and Claim 1 disclose the system comprises one or more computers connected to one or more networks providing service of enforcing privacy preferences on exchanges of personal data that is owned by the subject itself or held/owned by third parties such as enterprises. Thus the system utilizes a consortium/service enterprise network. Shadmon: paragraph 30 discloses members of the network are nodes on a blockchain network).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify the systems computers in a network Bohrer’s system performing the transaction and recording the transaction metadata with Shadmon’s teachings of nodes on a blockchain network to facilitate the improved functionalities provided by the members of the network (paragraph 30 of Shadmon).
As to claim 42, the combination of Bohrer in view of Shadmon teaches wherein establishing, by a consortium network, a set of permitted data operations for a service network using a plurality of privacy schemas includes establishing, by a consortium network composed of multiple system nodes, a set of permitted data operations for a service network using a plurality of privacy schemas (Bohrer: paragraph 33 discloses establishing authorization rules and data privacy policies/controls for requested data and requestors. The system provides functionalities of define authorization rules and privacy controls, send and handle requests for data, authenticate requesters, authorize release of data based on authorization rules and privacy policy matching and release data. Paragraph 16 and Claim 1 disclose the system comprises one or more computers connected to one or more networks providing service of enforcing privacy preferences on exchanges of personal data that is owned by the subject itself or held/owned by third parties such as enterprises. Thus the system utilizes a consortium/service enterprise network. Paragraph 49 further discloses permitted set of data operations for requested data such as specifying privacy preference rule for data requestors in the access list to access the data in the authorization dataset. The Privacy Preference Rule in an Authorization Rule contains two declarations: data subject's privacy preferences and access actions allowed by the data subject. The Privacy Preference also specifies why and how the data can be accessed in terms of the P3P standards. The privacy preferences rules, the access list and the authorization rules are the plurality of privacy schemas. Shadmon: paragraph 65 reveals the smart contracts document enforce the agreements that are made between peers (nodes) of the network, see also paragraph 120-122 which reveal a smart contract manages payments to the contractor, when the query is issued, the query is provided to a Coordinator node and processed by the Coordinator Node). Paragraph 355 discloses penalty would be enforced by a smart contract that would validate the integrity of the data maintained on the node or the node's response to a query by comparing the data or the query result to a different node that maintains the same data or process the same query over the same data. Or, if the node is not responsive, the smart contract can provide a time from which the penalty is triggered if the node remains unresponsive), wherein each system node is initialized based on a privacy contract distributed via a distributed ledger (Shadmon: paragraph 65 reveals the smart contracts document enforce the agreements that are made between peers (nodes) of the network; paragraphs 305 reveals the smart contract is stored in the block chain (paragraph 415 disclose the smart contract encodes a decentralized protocol for updating schema and security policies)).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Bohrer’s system performing the transaction and recording the transaction metadata with Shadmon’s teachings of processing smart/privacy contracts to validate the integrity of the data maintained on the node or the node's response to a query (paragraph 355 of Shadmon).
As to claim 43, the combination of Bohrer in view of Shadmon teaches further comprising: dynamically identifying, by the service network from the plurality of schemas and based on the transaction request, a privacy schema from the plurality of privacy schemas for use in performing the transaction, wherein the selection is based on factors including data owner consent, transaction type, and data recipient identity (Bohrer: paragraph 42 discloses the request is handled by the Profile Responder of the system/service network which uses the Authentication engine to verify the identity of the requester (based on the data recipient identity) and the Policy Authorization engine to check the authority of the requester to access the requested data by using authorization rules and privacy policies (plurality of privacy schemas- data owner consent). Paragraph 46 also disclose the selection is based on access list which involves rules who can access the specified data. Each access less contains one or more authorized party, these types are user, group, token, and all. See also paragraphs 44-49, 82, and 84).
As to claim 44, the combination of Bohrer in view of Shadmon teaches further comprising: configuring the service network by encoding data operations within smart contracts, wherein the smart contracts enforce predefined data processing rules aligned with the identified privacy schema (Shadmon: paragraph 65 reveals the smart contracts document enforce the agreements that are made between peers (nodes) of the network, see also paragraph 120-122 Paragraph 355 discloses penalty would be enforced by a smart contract that would validate the integrity of the data maintained on the node or the node's response to a query by comparing the data or the query result to a different node that maintains the same data or process the same query over the same data. Or, if the node is not responsive, the smart contract can provide a time from which the penalty is triggered if the node remains unresponsive. Paragraph 415 disclose the smart contract encodes a decentralized protocol for updating schema and security policies).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Bohrer’s system performing the transaction and recording the transaction metadata with Shadmon’s teachings of processing smart contracts to validate the integrity of the data maintained on the node or the node's response to a query (paragraph 355 of Shadmon).
As to claim 45, the combination of Bohrer in view of Shadmon teaches further comprising: performing the transaction by executing, in a Trusted Execution Environment (TEE) of the service network, one or more data operations from the set of permitted data operations upon the identity-centric dataset of the data owner (Bohrer: Figure 7 discloses the steps involves in performing the transaction/requested data. Paragraph 82, 84-88 further describe performing the transaction using one or more privacy level/identified schema from the permitted authorization rules of the data subject. Paragraph 86 reveals the different privacy levels/data label assignment operations that is performed in performing the data transaction request. Paragraph 87 further discloses checking the corresponding Boolean tag (generated transaction metadata) of a specific action in the preference settings (paragraph 77 discloses Boolean values are used to represent the access requirement flag). Paragraph 88 provides additional details of the data operation of filtering the data based on the privacy policies and authorization rules of the data subject. The filtered data is a manipulated dataset. Paragraph 9 also discloses manipulating data by transforming data so that it is no longer personally identifiable or to operate on data and produce results that are not personally identifiable. Shadmon: paragraphs 414 and 418-419 disclose processing queries/requests as disclosed in the publication via trusted execution environment on confidential data to obtain a result. A catalog is used in the process, therefore, when a query is processed, the catalog provides the information on the log files that needs to be considered to satisfy the query and the contractor that maintains each log file. The said catalog contains the metadata information such that when a query is processed the metadata provides the list of log files to consider and where each file is stored. The results are aggregated/manipulated to obtain the unified result. Paragraphs 413-414 reveal the data is distributed based on the level of data protection and on the policies regarding access permissions for data consumer/requestor), wherein the TEE ensures cryptographic isolation and secure processing of the dataset as permitted by the identified privacy schema (Shadmon: paragraph 418 discloses the TEE exhibits a protected and secure memory and computation area where no access outside processes can gain access to them. The TEE query processor uses decentralized information flow control (IFC) techniques similar to IFDB to ensure that submitted queries do not reveal information the data consumer is not authorized to access and that the query results only rely on authenticated data ). Motivation similar to the motivation presented in claim 1.
As to claim 46, the combination of Bohrer in view of Shadmon teaches further comprising: a plurality of processing systems, each configured as a system node within a consortium network, the consortium network comprising multiple system nodes (Bohrer: Paragraph 16 and Claim 1 disclose the system comprises one or more computers connected to one or more networks providing service of enforcing privacy preferences on exchanges of personal data that is owned by the subject itself or held/owned by third parties such as enterprises. Thus the system utilizes a consortium/service enterprise network. Shadmon: paragraph 30 discloses members of the network are nodes on a blockchain network), and wherein each system node is configured to establish a set of permitted data operations for a service network using a plurality of privacy schemas (Bohrer: paragraph 33 discloses establishing authorization rules and data privacy policies/controls for requested data and requestors. The system provides functionalities of define authorization rules and privacy controls, send and handle requests for data, authenticate requesters, authorize release of data based on authorization rules and privacy policy matching and release data. Paragraph 16 and Claim 1 disclose the system comprises one or more computers connected to one or more networks providing service of enforcing privacy preferences on exchanges of personal data that is owned by the subject itself or held/owned by third parties such as enterprises. Thus the system utilizes a consortium/service enterprise network. Paragraph 49 further discloses permitted set of data operations for requested data such as specifying privacy preference rule for data requestors in the access list to access the data in the authorization dataset. The Privacy Preference Rule in an Authorization Rule contains two declarations: data subject's privacy preferences and access actions allowed by the data subject. The Privacy Preference also specifies why and how the data can be accessed in terms of the P3P standards. The privacy preferences rules, the access list and the authorization rules are the plurality of privacy schemas. Shadmon: paragraph 65 reveals the smart contracts document enforce the agreements that are made between peers (nodes) of the network, see also paragraph 120-122 which reveal a smart contract manages payments to the contractor, when the query is issued, the query is provided to a Coordinator node and processed by the Coordinator Node). Paragraph 355 discloses penalty would be enforced by a smart contract that would validate the integrity of the data maintained on the node or the node's response to a query by comparing the data or the query result to a different node that maintains the same data or process the same query over the same data. Or, if the node is not responsive, the smart contract can provide a time from which the penalty is triggered if the node remains unresponsive), with system nodes initialized through privacy contracts distributed via the consortium's distributed ledger (Shadmon: paragraph 65 reveals the smart contracts document enforce the agreements that are made between peers (nodes) of the network; paragraphs 305 reveals the smart contract is stored in the block chain (paragraph 415 disclose the smart contract encodes a decentralized protocol for updating schema and security policies)).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Bohrer’s system performing the transaction and recording the transaction metadata with Shadmon’s teachings of processing smart/privacy contracts to validate the integrity of the data maintained on the node or the node's response to a query (paragraph 355 of Shadmon).
As to claim 47, the combination of Bohrer in view of Shadmon teaches further comprising: a plurality of processing systems configured to (Bohrer: Paragraph 16 and Claim 1 . Shadmon: paragraph 30) receive a transaction request to perform the transaction in relation to the identity-centric dataset associated with a data owner, and to identify, based on parameters including data owner consent, transaction type, and data recipient identity, a suitable privacy schema from the plurality of privacy schemas for use in performing the transaction (Bohrer: paragraph 42 discloses the received request is handled by the Profile Responder of the system/service network which uses the Authentication engine to verify the identity of the requester (based on the data recipient identity) and the Policy Authorization engine to check the authority of the requester to access the requested data by using authorization rules and privacy policies (plurality of privacy schemas- data owner consent). Paragraph 46 also disclose the selection is based on access list which involves rules who can access the specified data. Each access less contains one or more authorized party, these types are user, group, token, and all. See also paragraphs 44-49, 82, and 84).
As to claim 48, the combination of Bohrer in view of Shadmon teaches further comprising: a plurality of processing systems configured (Bohrer: Paragraph 16 and Claim 1 . Shadmon: paragraph 30) to execute the transaction within a Trusted Execution Environment (TEE), utilizing smart contracts that encode data processing rules aligned with the identified privacy schema, thereby ensuring secure, isolated execution of one or more data operations from the set of permitted data operations upon the identity-centric dataset of the data owner (Bohrer: Figure 7 discloses the steps involves in performing the transaction/requested data. Paragraph 82, 84-88 further describe performing the transaction using one or more privacy level/identified schema from the permitted authorization rules of the data subject. Paragraph 86 reveals the different privacy levels/data label assignment operations that is performed in performing the data transaction request. Paragraph 87 further discloses checking the corresponding Boolean tag (generated transaction metadata) of a specific action in the preference settings (paragraph 77 discloses Boolean values are used to represent the access requirement flag). Paragraph 88 provides additional details of the data operation of filtering the data based on the privacy policies and authorization rules of the data subject. The filtered data is a manipulated dataset. Paragraph 9 also discloses manipulating data by transforming data so that it is no longer personally identifiable or to operate on data and produce results that are not personally identifiable. Shadmon: paragraphs 414 and 418-419 disclose processing queries/requests as disclosed in the publication via trusted execution environment on confidential data to obtain a result. A catalog is used in the process, therefore, when a query is processed, the catalog provides the information on the log files that needs to be considered to satisfy the query and the contractor that maintains each log file. The said catalog contains the metadata information such that when a query is processed the metadata provides the list of log files to consider and where each file is stored. The results are aggregated/manipulated to obtain the unified result. Paragraphs 413-414 reveal the data is distributed based on the level of data protection and on the policies regarding access permissions for data consumer/requestor. Paragraph 418 discloses the TEE exhibits a protected and secure memory and computation area where no access outside processes can gain access to them. The TEE query processor uses decentralized information flow control (IFC) techniques similar to IFDB to ensure that submitted queries do not reveal information the data consumer is not authorized to access and that the query results only rely on authenticated data). Motivation similar to the motivation presented in claim 14.
As to claim 49, the combination of Bohrer in view of Shadmon teaches wherein the service network stores a version history of privacy schemas (Bohrer: paragraph 38 discloses interaction history agent provides support for user specification of what actions should be intercepted. This could be stored in the form of rules or explicit action types. An intermediary or proxy can then be used to intercept the desired online actions and record them as additional profile data) and is configured to:(a) detect nonconformance of a requested operation with a current schema version (Bohrer: paragraph 82 reveals if there is no authorization rules or if the user is not on the access list, these are non-conformance results), and(b) execute a rollback to a prior schema version associated with the data subject's consent at the time of data collection (Bohrer: paragraph 82 reveals if there is no authorization rules or if the user is not on the access list, these are non-conformance results. The system returns a response with an empty response (initialize version response) and the authorization is discarded).
As to claim 50, the combination of Bohrer in view of Shadmon teaches wherein the transaction metadata includes at least two digital signatures:(i) a signature from the data owner indicating consent to the identified schema (Shadmon: paragraphs 76 and 172 disclose hash values which are fingerprints of the log files are used to authenticate the data; paragraph 425 discloses data consumers, data producers, table owners, and data contractors are each identified with blockchain addresses, which as well serve as identifiers in the access permissions. Signature-based access tokens are used to allow principals who are granted access to make an access request) , and(ii) a signature from the consortium network attesting to schema compliance and permitted operations (Shadmon: paragraph 425 discloses signature-based access tokens to allow principals who are granted access to make an access request. The signature-based access tokens are logged as proof of the access request ).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Bohrer’s system performing the transaction and recording the transaction metadata with Shadmon’s teachings of utilizing signatures to prevent security issues due to trusted intermediaries (paragraph 425 of Shadmon).
Claim(s) 51 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bohrer et al US 20030088520 (hereinafter Bohrer), in view of Shadmon et al US 20190158594 (hereinafter Shadmon), and in further view of Chen et al US 20200250302 (hereinafter Chen).
As to claim 51, the combination of Bohrer in view of Shadmon teaches all the limitations presented in claim 14 above, and further teaches (a) monitor executed operations for deviation from schema rules (Bohrer: paragraph 82 reveals if there is no authorization rules or if the user is not on the access list, these are deviation to the schema rules).
The combination of Bohrer in view of Shadmon does not teach, but Chen teaches wherein the service network comprises an audit module configured to (abstract discloses an audit module of the computer system )automatically generate a trace log comprising schema identifier, version, executed operation, and TEE instance identifier (paragraphs 81-82 disclose tracer management module, wherein the audit trigger module compares an audit rule (schema/version) with a control flow obtained by the tracer management module to determine (operation ) whether to continue with subsequent function operation or terminate current operation. Paragraph 119 discloses an identifier and a parameter of a TA that the CA expects to call, and the like. In this way, a module on the TEE side can obtain, from the shared memory, a value of the PID of the process. The audit module searches for an automaton instance whose identifier is the value of the PID. If the automaton instance does not exist, the current audit fails).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Bohrer’s system performing the transaction and recording the transaction metadata in view of Shadmon’s teachings of utilizing the TEE with Chen’s teachings of an audit module to implement system security by auditing information in a control flow (paragraph 2 of Chen).
Claim(s) 52 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bohrer et al US 20030088520 (hereinafter Bohrer), in view of Shadmon et al US 20190158594 (hereinafter Shadmon), and in further view of Sprague US 20190116038 (hereinafter Sprague).
As to claim 52, the combination of Bohrer in view of Shadmon teaches all the limitations presented in claim 1 above.
The combination of Bohrer in view of Shadmon does not teach wherein instantiating the trusted execution environment comprises: retrieving a hardware-bound attestation key from a secure element associated with the processing node; and validating the integrity of the TEE based on a challenge-response protocol involving the consortium ledger.
Sprague teaches wherein instantiating the trusted execution environment comprises: retrieving a hardware-bound attestation key from a secure element associated with the processing node (paragraphs 37 and 51 disclose verifying the integrity of the TEE using RvT token/attestation key from a cybersecurity controller) ; and validating the integrity of the TEE based on a challenge-response protocol involving the consortium ledger (paragraphs 15, 37, 51, 87-88 disclose verifying the integrity of the TEE using RvT token/attestation key from a cybersecurity controller. A multi-factor passcode is also used to verify the TEE).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Bohrer’s system performing the transaction and recording the transaction metadata in view of Shadmon’s teachings of utilizing the TEE with Sprague’s teachings of verifying the TEE to improve information assurance or confirmation that information on a device has not changed (paragraph 2 of Sprague).
Claim(s) 54 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bohrer et al US 20030088520 (hereinafter Bohrer), in view of Shadmon et al US 20190158594 (hereinafter Shadmon), and in further view of Hickman et al US 20130167192 (hereinafter Hickman).
As to claim 54, the combination of Bohrer in view of Shadmon teaches all the limitations presented in claim 1 above.
The combination of Bohrer in view of Shadmon does not teach, but Hickman further comprising masking a subset of identity attributes based on schema rules prior to encryption, wherein the masking is governed by attribute sensitivity levels defined in the schema (Figure 1, paragraphs 17 and 21 disclose determining applicable data policies for masking sensitivity data attributes. The determination is made before the masking/encoding. The data policy are rules/levels).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Bohrer’s system performing the transaction and recording the transaction metadata in view of Shadmon’s teachings of utilizing the TEE with Hickman’s teachings of utilizing rules for masking the sensitivity data attributes such that the sensitive data are detected with improved accuracy (paragraph 16 of Hickman).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FELICIA FARROW whose telephone number is (571)272-1856. The examiner can normally be reached M - F 7:30am-4:00pm (EST).
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, Alexander Lagor can be reached at (571)270-5143. 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.
/F.F/ Examiner, Art Unit 2437
/BENJAMIN E LANIER/ Primary Examiner, Art Unit 2437
1 Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 110 USPQ2d 1976 (2014)
2 Mayo Collaborative Services v. Prometheus Labs., Inc., 566 U.S. 66, 101 USPQ2d 1961 (2012)
3 Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 110 USPQ2d 1976 (2014)
4 Mayo Collaborative Services v. Prometheus Labs., Inc., 566 U.S. 66, 101 USPQ2d 1961 (2012)