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 .
DETAILED ACTION
The IDS filed 10/13/2025, 10/15/2025 were received and considered.
Claims 1-20 are pending.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Claim Objections
Claims 11-14 are objected to because of the following informalities:
In claim 14, “ledge” should be replaced with “ledger” (lines 2 and 4).
In claim 11, claim 13 and claim 14, the claims recite both “distributed-ledger” and “distributed ledger”. It is suggested that these limitations be made consistent.
Appropriate correction is required.
Claim Interpretation - 35 USC § 101
Claim 1 recites determining a required security, selecting conditions, requesting user consent and executing a data transfer request – limitations that could be construed as abstract ideas with respect to 35 USC §101. However, the claim language makes clear that the method is performed by a “middle layer subsystem of a blockchain-regulated data-management system”, defined in the specification as “system 110, the middle layer, is provided to connect database 120, user subsystems 140, 150, and distributed ledger components 130. The middle layer 110 comprises interfaces 114, 115 to the user components 140, 150 respectively. It further comprises an interface 112 to the database 120 and an interface 113 to the distributed ledger 130”. In view of the specification and in further view of one having ordinary skill in the art of blockchain-based transaction management, the Examiner maintains that, if the above limitations were to be interpreted as abstract ideas, these additional elements recited in the claim extend the invention beyond any judicial exceptions, and that the additional elements integrate the exception into a practical application of such an exception.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 5-10, 12 and 19-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
Regarding claims 5, 12 and 19, the claims recite “balancing data-transfer security and total complexity of transactions comprised in the requested data transfer”, or similar. However, the specification does not teach how such balance is achieved, nor does the specification teach how “security” and “complexity of transactions” are calculated, such that a skilled artisan could make and use the invention.
Claims 6-10 and 20 inherit the deficiency.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 5, 12 and 19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 5, 12 and 19, the claims recite “balancing” (for example, claim 5, “balancing data-transfer security and total complexity of transactions comprised in the requested data transfer”). However, achieving a balance is not defined within the scope of the claims and thus appears to be a term of degree, open to interpretation. Therefore, the recited “balancing” renders the claims indefinite.
Claims 6-10 and 20 inherit the deficiency.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0099313 A1 (KONDRASHOV; Oleksandr et al.), in view of US 2023/0281333 A1 (Ricotta, JR.; Frank J. et al.) and US 2024/0362358 A1 (PATEL; DHARMESH M. et al.).
Regarding claim 1, Kondrashov discloses a method of securing data transfers, comprising: defining, by a middle layer subsystem (consent management service, ¶36; consent management platform 201 can include, for instance, the neutral server 109, consent management service 111, and server authentication module 131, ¶66) of a blockchain-regulated data-management system (consent management service 111 provides a cryptographic ledger 113 (also referred to as a blockchain 113) that keeps information ( e.g., metadata) about consent requests (e.g., from the data consumers 107) and consent responses (e.g., from the data subjects 105), ¶36), two or more sets of conditions for executing a data transfer (keeps consent requests, consent responses, consent revocations to provide access to client data (data subject), ¶36) as a sequence of user-consent steps in the form of respective smart contracts (the data subject 105 can provide a consent response to the consent response for instantiating a corresponding chaincode 121 on the data subject device 125 to indicate a consent status; ledger client 123 instantiates the chain code 121 that is programmed to create a consent response record in the cryptographic ledger 113 string metadata or other transaction evidence indicating a consent status that is an approval of the consent request, ¶75); receiving, by the middle layer subsystem, a data-transfer request (step 401, the ledger client 123 retrieves a metadata indicating a consent request from a cryptographic ledger 113; consent request is from a data consumer 107 to access to data 103 owned by a data subject 105, ¶77); determining, by the middle layer subsystem, a required security for the data-transfer request (neutral server 109 is permissioned to access the consent response record in the cryptographic ledger 113; consent response stores metadata or other evidence of a transaction indicating consent from the data subject 105 to the consent request by the data consumer 107, ¶82); and executing, by the middle layer subsystem, the requested data transfer after all requested user consent is approved (a neutral server 109 then reads the data 103 from the database of the data provider 101 on behalf of the data consumer 107 based on the cryptographic ledger 113, ¶82). Kondrashov lacks selecting, by the middle layer subsystem, one of the defined sets of conditions according to the determination. However, Ricotta, in an analogous art (obtaining user consent for access to data), teaches that it was known to store data access rules in a blockchain to place restrictions on granting access to user data (¶51), where the blockchain stores defined sets of conditions (owner consent contract 300 may also include timing rules 306 that determine when the owner consent 300 is active, ¶52; owner consent contract 300 stores one or more owner-specified access rules 304 in the form of commands (i.e., machine-readable instructions) that add to and/or modify the selection criteria of a query that is executed on the blockchain 100). In Ricotta, when a query for user data is made, access rules are obtained from the consent contracts (¶66) to determine consent (¶67). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Kondrashov to include selecting, by the middle layer subsystem, one of the defined sets of conditions according to the determination. One of ordinary skill in the art would have been motivated to perform such a modification to enable additional restrictions on granting access to user data, as taught by Ricotta. As modified, Kondrashov lacks requesting, by the middle layer subsystem, user consent according to the sequence (Kondrashov stores consent, but lacks requesting the consent explicitly according to the sequence). However, Patel, in an analogous art (providing consent for access to user/patient data, ¶86), teaches that it was known to store information required to gain consent from a user for their data (¶¶87-88; “operation 301, a patient device (e.g., personal electronic device such as a cell phone, a tablet computer, etc.) that is designated by the patient may be identified. The patient device may be identified by obtaining an identifier or metadata for the patient device stored in a registration repository and/or any other method”, ¶89), where the data includes procedures for obtaining consent from the user’s devices (¶¶88-89) and to, based on a request for information, access the consent procedure and request consent from the user according to the procedure (¶¶89-90; “operation 302, a first consent resolution action with the patient device to attempt to gain a first authorization to disclose the medical data may be performed. The first consent resolution action may include sending a first request for authorization to the patient device to grant access to medical data requested”, ¶90). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to further modify Kondrashov to include requesting, by the middle layer subsystem, user consent according to the sequence. One of ordinary skill in the art would have been motivated to perform such a modification to enable specification of the manner in which consent is obtained, as taught by Patel.1
Regarding claim 15, the claim is similar in scope to claim 1 and is therefore rejected using a similar rationale, where the system is implemented using a non-transitory computer-readable medium having processor-executable instructions stored thereon that, when executed, facilitate performance of the method steps (Kondrashov ¶6, ¶114).
Regarding claims 2 and 16, Kondrashov, as modified, teaches wherein the determination of the required security for the requested data-transfer is based on the data-transfer request and/or based on the data to be transferred (neutral server 109 is permissioned to access the consent response record in the cryptographic ledger 113; consent response stores metadata or other evidence of a transaction indicating consent from the data subject 105 to the consent request by the data consumer 107, ¶82).
Regarding claims 3 and 17, Kondrashov, as modified, teaches after requesting the user consent and before executing the requested data transfer, recording approval of user consent (Kondrashov teaches recording consent on a cryptographic ledger; subject device 125 then receives a result of a processing of the data 103 by the data consumer 107, ¶37).
Regarding claims 4 and 18, Kondrashov, as modified, teaches after executing the requested data transfer, recording the execution of the requested data transfer (the data consumer 107 can then use or process the data 103 provided by the neutral server 109, e.g., for use or processing according to the consent purpose stated in the consent request).
Claims 11, 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Kondrashov, in view of Ricotta.
Regarding claim 11, Kondrashov discloses a middle layer subsystem (consent management service, ¶36) of a blockchain-regulated data-management system (consent management service 111 provides a cryptographic ledger 113 (also referred to as a blockchain 113) that keeps information ( e.g., metadata) about consent requests (e.g., from the data consumers 107) and consent responses (e.g., from the data subjects 105), ¶36) for securing data transfers, wherein the middle layer subsystem comprises: interfaces to one or more user systems (consent management service, ¶36, communicates with neutral server, consent management service, Fig. 2; see also ¶¶35-36, describing interfacing with data subjects/users); one or more interfaces to a database (consent management service, ¶36, communicates with a data provider, Fig. 1, 101); one or more interfaces to a distributed-ledger system (consent management service, ¶36, communicates with a consortium network, Fig. 1, 115); and a processor (Fig. 8) configured to: create, based on input from the interfaces to the one or more user systems and/or the one or more interfaces to the database, conditions for executing a data transfer to or from the database (keeps consent requests, consent responses, consent revocations to provide access to client data (data subject), ¶36) as a sequence of user-consent steps (the data subject 105 can provide a consent response to the consent response for instantiating a corresponding chaincode 121 on the data subject device 125 to indicate a consent status; ledger client 123 instantiates the chain code 121 that is programmed to create a consent response record in the cryptographic ledger 113 string metadata or other transaction evidence indicating a consent status that is an approval of the consent request, ¶75) in the form of respective smart contracts (chaincode 121) to be stored on the distributed ledger system (consent management service 111 provides a cryptographic ledger 113 (also referred to as a blockchain 113) that keeps information ( e.g., metadata) about consent requests (e.g., from the data consumers 107) and consent responses (e.g., from the data subjects 105), ¶36); and determine a required security for the requested data transfer (the neutral server 109 interacts with the consent management service 111 to determine the consent response (e.g., a consent approval or consent status) from the data subject 105 for access to the data 103 by the data consumer 107), ¶36. Kondrashov lacks creating two or more sets of conditions. However, Ricotta, in an analogous art (obtaining user consent for access to data), teaches that it was known to store data access rules in a blockchain to place restrictions on granting access to user data (¶51), where the blockchain stores defined sets of conditions (owner consent contract 300 may also include timing rules 306 that determine when the owner consent 300 is active, ¶52; owner consent contract 300 stores one or more owner-specified access rules 304 in the form of commands (i.e., machine-readable instructions) that add to and/or modify the selection criteria of a query that is executed on the blockchain 100). In Ricotta, when a query for user data is made, access rules are obtained from the consent contracts (¶66) to determine consent (¶67). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Kondrashov to include creating two or more sets of conditions for executing a data transfer. One of ordinary skill in the art would have been motivated to perform such a modification to enable additional restrictions on granting access to user data, as taught by Ricotta.
Regarding claim 13, Kondrashov, as modified, teaches wherein the processor is further configured to: prompt execution of data transfers to or from the database (read data 103 owned by the data subjects, ¶35) after receiving a prompt from the interface to the distributed-ledger system (ledger is consulted for consent information, ¶35).
Regarding claim 14, Kondrashov, as modified, teaches wherein the processor is further configured to: transmit consent-request data from the distributed ledger system to one or more user via one or more respective interfaces of the interfaces to the one or more user systems (distributed ledger stores consent requests, ¶36); and transmit consent-approval data from the one or more users to the distributed-ledger system via the interface to the distributed-ledger system (content management service 111 provides a cryptographic ledger 113 (also referred to as a blockchain 113) that keeps information ( e.g., metadata) about consent requests (e.g., from the data consumers 107) and consent responses (e.g., from the data subjects 105), ¶36).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20170302678 A1 (Borlick; Matthew G. et al.) teaches determining a minimum level of security certification required to satisfy the security requirements for performing the selected operation (“storage controller determines the minimum security level required for an application or a dataset. The storage controller first determines which subset of storage clouds can provide at least the minimum security level for the application and/or dataset. Within the subset of determined storage clouds, the storage cloud with the best response time may be selected for executing the application or for storing the dataset”, ¶24).
US 20250053624 A1 (SHIRAI; RYOTARO) teaches requesting consents from a plurality of users whose information is requested (¶¶76-77).
“A blockchain-based consent mechanism for access to fitness data in the healthcare context” (Alhajri, May, Carsten Rudolph, and Ahmad Salehi Shahraki) teaches providing data from a provider to a requester based on consents, using self-executing smart contracts and blockchain (p. 22967, §A. System Architecture).
“A smart contract-based dynamic consent management system for personal data usage under GDPR” (Merlec, Mpyana Mwamba, et al.) teaches dynamic consent management for sharing personal data (abstract), including placing additional constraints on the usage of the data (p. 7, Figure 1 and p. 8, Figure 2).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J SIMITOSKI whose telephone number is (571)272-3841. The examiner can normally be reached Monday - Friday, 7:00-3:00.
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, Carl Colin can be reached at 571-272-3862. 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.
/Michael Simitoski/ Primary Examiner, Art Unit 2493
February 17, 2026
1 US 20240184916 A1 (Bella; Kimberly E. et al.) teaches a similar sequence for obtaining user consent (¶¶315-321).