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 .
Election/Restrictions
NO restrictions warranted at applicant’s time of filing for CONtinuation.
Priority
This application claims domestic priority under 35 USC 119b as CONtinuation of non-provisional application # 17/293,396, filed on 05/12/2021, now US PAT 12113781;
Further non-provisional application # 17/293,396 national stage application under 35 USC 371 to PCT/US2019/061008, filed on 11/12/2019, which further claims domestic priority under 35 USC 119e to provisional application # 62/760,789, filed on 11/13/2018.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 08/09/2024, 11/20/2024, 07/09/2025, the submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
Applicant’s drawings filed on 08/09/2024 has been inspected and is in compliance with MPEP 608.02.
Specification
Applicant’s specification filed on 08/09/2024 has been considered, and is therefore, in compliance with MPEP 608.01.
Claim Objections
NO claim objections warranted at applicant’s time of filing for CONtinuation.
Claim Interpretation – 35 USC 112th f
It is in the examiner’s opinion that claims 1- 20 do not invoke means for or step plus functional claim language under the meaning of the statue.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim[s] 8 is 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. The claim language is unclear based on the recited phrase of “and/or,” specifically, it is unclear as which claim limitations are “further limiting” and which claim limitations are for “intended use.”
For example, in claim # 8, “.......wherein the one or more updates to the permission settings include:
a grant of access to at least some of the user data of the user; and/or a revocation of access to at least some of the user data of the user;””
Appropriate action required.
***For examination purposes, the examiner will assume that the “or” operator is further limiting the claim language.
Claim[s] 17 is 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. It is unclear from the pre-able as to whether a “system,” is being claims or “method” claim.
For example, in claim # 17:
“In a computer system that implements a distributed ledger trust network (DLTN)
server configured to provide access to a DLTN, a method comprising:.................”
Appropriate action required.
***For examination purposes of subject matter eligibility, the examiner will assume that claim 17 is a method claim.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim[s] 11 – 16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) 11 - 16 does/do not fall within at least one of the four categories of patent eligible subject matter because the claim language encompasses signal per se. The claim language recites a “computer readable media,” (or CRM) that takes the form of a signal or carrier wave. In the specification as filed, the language contained in paragraph 0039, recites that the CRM can take the form of various non — transitory embodiments, however, the specification also recites various transitory embodiments, in which the claim language intends for the claimed CRM to take the form of a signal or carrier wave, or light wave..etc., [i.e. “any other optical medium” or “..a computer-readable medium may take many forms, including but not limited to.....”]. Clearly, a signal, carrier wave, or energy does not fall in one of the statutory categories of: a process, a machine, a manufacture, a chemical composition, or an improvement thereof under the meaning of the statute.
Appropriate action required.
Double Patenting
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based e-Terminal Disclaimer may be filled out completely online using web-screens. An e-Terminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about e-Terminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim[s] 1 – 20 are rejected on the ground of non-statutory double patenting as being unpatentable over claim[s] 1 – 18, 21, 22 of U.S. Patent No. 12113781.
Although the claims at issue are not identical, they are not patentably distinct from each other because both the subject matter of the pending application and the reference patent are the same or similar in scope in the following manner:
managing permissions to access user data in a distributed ledger trust
network, where a user can share access to user data with other reviewers/users in a permissioned based manner. Access to user data can depend on the classification of the user data, the role of user, duration of the access to user data, selectively approving or rejecting access by the user.
Also, see the table below for a claim-by-claim comparison.
Pending US Application # 18/799,880
US PAT # 12113781
1. A computer system comprising memory and one or more processing units, wherein the computer system implements a distributed ledger trust network (“DLTN’”) server configured to perform operations comprising:
receiving, from a DLTN client, a request for permission settings for user data of a user;
retrieving the permission settings;
sending, to the DLTN client, the permission settings;
receiving, from the DLTN client, one or more updates to the permission settings; and
based on the one or more updates to the permission settings, updating the permission settings, the user data of the user being stored in a blockchain of the DLTN in association with identity of the user, the user data having been encrypted using a set of encryption keys that are user-specific and context-specific.
1. (Currently Amended) One or more non-transitory computer-readable media having stored therein computer-executable instructions for causing a computer system that implements a distributed ledger trust network (“DLTN’”) server, when programmed thereby, to perform operations to provide access to a DLTN, the operations comprising:
receiving, from a DLTN client, a request for permission settings for user data of a user;
retrieving the permission settings;
sending, to the DLTN client, the permission settings;
receiving, from the DLTN client, one or more updates to the permission settings; and
based on the one or more updates to the permission settings, updating the permission settings, the user data of the user being stored in a blockchain of the DLTN in association with identity of the user, the user data having been encrypted using a set of encryption keys that are user-specific and context-specific, wherein the set of encryption keys is one of multiple sets of encryption keys specific to the user, each of the multiple sets of encryption keys being associated with a different context that is a different data category or different subset of other users, and wherein the permission settings, depending on the different contexts, respectively, control access to the multiple sets of encryption keys.
2. The computer system of claim 1, wherein the operations further comprise:
creating a Web page that includes any categories of the user data of the user that are publicly accessible; and
sending, to the DLTN client, a link to the Web page.
2. (Previously Presented) The one or more non-transitory computer-readable media of claim 1, wherein the operations further comprise:
creating a Web page that includes any categories of the user data of the user that are publicly accessible; and
sending, to the DLTN client, a link to the Web page.
3. The computer system of claim 1, wherein the permission settings are stored in encrypted form in storage accessible to an authentication service, the permission settings being encrypted and decrypted using a master key of the authentication service, and wherein the permission settings are enforceable by the authentication service in conjunction with one or more access rules.
3. (Previously Presented) The one or more non-transitory computer-readable media of claim 1, wherein the permission settings are stored in encrypted form in storage accessible to an authentication service, the permission settings being encrypted and decrypted using a master key of the authentication service, and wherein the permission settings are enforceable by the authentication service in conjunction with one or more access rules.
4. The computer system of claim 1, wherein the permission settings are stored in encrypted form in the blockchain of the DLTN in association with the identity of the user, and wherein:
the retrieving the permission settings includes searching the blockchain for the permission settings or requesting the permission settings from a service of the DLTN; and
the updating the permission settings includes storing a new version of one or more of the permission settings in a new block in the blockchain.
4. (Previously Presented) The one or more non-transitory computer-readable media of claim 1, wherein the permission settings are stored in encrypted form in the blockchain of the DLTN in association with the identity of the user, and wherein:
the retrieving the permission settings includes searching the blockchain for the permission settings or requesting the permission settings from a service of the DLTN; and
the updating the permission settings includes storing a new version of one or more of the permission settings in a new block in the blockchain.
5. The computer system of claim 1, wherein the operations further comprise, based on one of the one or more updates to the permission settings:
decrypting at least some of the user data of the user using a first encryption key among the set of encryption keys;
re-encrypting the at least some of the user data of the user using a second encryption key, different than the first encryption key, among the set of encryption keys; and
storing the re-encrypted user data of the user in a new block in the blockchain.
5. (Currently Amended) The one or more non-transitory computer-readable media of claim 1, wherein the operations further comprise, based on one of the one or more updates to the permission settings:
decrypting at least some of the user data of the user using a first encryption key among the set of encryption keys;
re-encrypting the at least some of the user data of the user using a second encryption key, different than the first encryption key, among the set of encryption keys; and
storing the re-encrypted user data of the user in a new block in the blockchain.
6. The computer system of claim 1, wherein the request for permission settings is part of a request to enroll the user, and wherein the one or more updates to the permission settings are changes to default, initial values for the permission settings.
6. (Previously Presented) The one or more non-transitory computer-readable media of claim 1, wherein the request for permission settings is part of a request to enroll the user, and wherein the one or more updates to the permission settings are changes to default, initial values for the permission settings.
7. The computer system of claim 1, wherein the request for permission settings is part of a request to review the permission settings, and wherein the one or more updates to the permission settings are changes to previously set values for the permission settings.
7. (Previously Presented) The one or more non-transitory computer-readable media of claim 1, wherein the request for permission settings is part of a request to review the permission settings, and wherein the one or more updates to the permission settings are changes to previously set values for the permission settings.
8. The computer system of claim 1, wherein the one or more updates to the permission settings include:
a grant of access to at least some of the user data of the user; and/or
a revocation of access to at least some of the user data of the user.
8. (Previously Presented) The one or more non-transitory computer-readable media of claim 1, wherein the one or more updates to the permission settings include one of:
a grant of access to at least some of the user data of the user; and
a revocation of access to at least some of the user data of the user.
9. The computer system of claim 1, wherein the blockchain is a private blockchain, and wherein the DLTN server manages access to the private blockchain.
9. (Previously Presented) The one or more non-transitory computer-readable media of claim 1, wherein the blockchain is a private blockchain, and wherein the DLTN server manages access to the private blockchain.
10. The computer system of claim 1, wherein:
the DLTN server includes a Web application and implements an application programming interface (“API”) accessible to the DLTN client; and
the DLTN client is implemented as a separate executable application, as client-side scripting logic executing in a Web browser environment, or as a set of functions of a Web browser to control client-facing scripting logic executed by the DLTN server.
10. (Previously Presented) The one or more non-transitory computer-readable media of claim 1, wherein:
the DLTN server includes a Web application and implements an application programming interface (“API”) accessible to the DLTN client; and
the DLTN client is implemented as a separate executable application, as client-side scripting logic executing in a Web browser environment, or as a set of functions of a Web browser to control client-facing scripting logic executed by the DLTN server.
11. One or more computer-readable media having stored therein computer-executable instructions for causing a computer system that implements a distributed ledger trust network (“DLTN’) server, when programmed thereby, to perform operations to provide access to a DLTN, the operations comprising:
receiving, from a DLTN client, a request to access user data of a user, the user data of the user being stored in a blockchain of the DLTN in association with identity of the user, the user data having been encrypted using a set of encryption keys that are user-specific and context- specific;
retrieving permission settings;
determining, based on the permission settings, that access is not granted for a reviewer to the user data of the user; and
sending, to the DLTN client, an indication that access is not granted for the reviewer to the user data of the user.
11. (Currently Amended) A computer-implemented method, in a computer system that implements a distributed ledger trust network (“DLTN”) server configured to provide access to a DLTN, the method comprising:
receiving, from a DLTN client, a request to access user data of a user, the user data of the user being stored in a blockchain of the DLTN in association with identity of the user, the user data having been encrypted using a set of encryption keys that are user-specific and context- specific, wherein the set of encryption keys is one of multiple sets of encryption keys specific to the user, each of the multiple sets of encryption keys being associated with a different context that is a different data category or different subset of other users;
retrieving permission settings for the user data of the user, wherein the permission settings, depending on the different contexts, respectively, control access to the multiple sets of encryption keys;
determining, based on the permission settings, that access is not granted for a reviewer to the user data of the user; and
sending, to the DLTN client, an indication that access is not granted for the reviewer to the user data of the user.
12. The one or more computer-readable media of claim 11, wherein the operations further comprise:
receiving, from the DLTN client, an indication that the reviewer seeks approval by the user of access to the user data of the user; and
sending, to a DLTN client of the user or a client messaging application of the user, a request for approval by the user of the reviewer to access user data of the user.
12. (Original) The method of claim 11, further comprising:
receiving, from the DLTN client, an indication that the reviewer seeks approval by the user of access to the user data of the user; and
sending, to a DLTN client of the user or a client messaging application of the user, a request for approval by the user of the reviewer to access user data of the user.
13. The one or more computer-readable media of claim 11, wherein the permission settings are stored in encrypted form in storage accessible to an authentication service, the permission settings being encrypted and decrypted using a master key of the authentication service, and wherein the permission settings are enforceable by the authentication service in conjunction with one or more access rules.
13. (Original) The method of claim 11, wherein the permission settings are stored in encrypted form in storage accessible to an authentication service, the permission settings being encrypted and decrypted using a master key of the authentication service, and wherein the permission settings are enforceable by the authentication service in conjunction with one or more access rules.
14. The one or more computer-readable media of claim 11, wherein the permission settings are stored in encrypted form in the blockchain of the DLTN in association with the identity of the user, and wherein:
the retrieving the permission settings includes searching the blockchain for the permission settings or requesting the permission settings from a service of the DLTN.
14. (Original) The method of claim 11, wherein the permission settings are stored in encrypted form in the blockchain of the DLTN in association with the identity of the user, and wherein:
the retrieving the permission settings includes searching the blockchain for the permission settings or requesting the permission settings from a service of the DLTN.
15. The one or more computer-readable media of claim 11, wherein the operations further comprise:
sending, to another DLTN client, a request for approval of the reviewer to access to the user data of the user, wherein the request for approval is sent in encrypted form over a secure connection;
receiving, from the other DLTN client, an indication of approval or rejection of the request for approval, wherein the indication of approval or rejection is received in encrypted form over the secure connection; and
selectively updating the permission settings in the blockchain of the DLTN.
15. (Original) The method of claim 11, further comprising:
sending, to another DLTN client, a request for approval of the reviewer to access to the user data of the user;
receiving, from the other DLTN client, an indication of approval or rejection of the request for approval; and
selectively updating the permission settings in the blockchain of the DLTN.
16. The one or more computer-readable media of claim 15, wherein the operations further comprise, based on the indication of approval or rejection of the request:
decrypting at least some of the user data of the user using a first encryption key among the set of encryption keys;
re-encrypting the at least some of the user data of the user using a second encryption key, different than the first encryption key, among the set of encryption keys; and
storing the re-encrypted user data of the user in a new block in the blockchain.
17. (Currently Amended) The method of claim 15, further comprising, based on the indication of approval or rejection of the request:
decrypting at least some of the user data of the user using a first encryption key among the set of encryption keys;
re-encrypting the at least some of the user data of the user using a second encryption key, different than the first encryption key and
storing the re-encrypted user data of the user in a new block in the blockchain.
17. Ina computer system that implements a distributed ledger trust network (“DLTN”) server configured to provide access to a DLTN, a method comprising:
sending, to a DLTN client, a previously approved request from a reviewer to grant access to user data of a user, the user data of the user being stored in a blockchain of a DLTN in association with identity of the user, the user data having been encrypted using a set of encryption keys that are user-specific and context-specific;
receiving, from the DLTN client, an indication of revocation of the previously approved request; and
updating the permission settings.
18. (Currently Amended) A computer system comprising memory and one or more processing units, wherein the computer system implements a distributed ledger trust network
(“DLTN’”) server configured to perform operations comprising:
sending, to a DLTN client, a previously-approved request from a reviewer to grant access to user data of a user, the user data of the user being stored in a blockchain of a DLTN in association with identity of the user, the user data having been encrypted using a set of
encryption keys that are user-specific and context-specific, wherein the set of encryption keys is one of multiple sets of encryption keys specific to the user, each of the multiple sets of encryption keys being associated with a different context that is a different data category or
different subset of other users;
receiving, from the DLTN client, an indication of revocation of the previously-approved request; and
updating permission settings for the user data of the user, wherein the permission
settings, depending on the different contexts, respectively, control access to the multiple sets of
encryption keys.
18. The method of claim 17, wherein the previously approved request is sent in encrypted form over a secure connection, and wherein the indication of revocation of the previously approved request is received in encrypted form over the secure connection.
16. (Original) The method of claim 15, wherein the request for approval is sent in encrypted form over a secure connection, and wherein the indication of approval or rejection is received in encrypted form over the secure connection.
19. The method of claim 17, wherein:
the permission settings are stored in encrypted form in storage accessible to an authentication service; or
the permission settings are stored in encrypted form in the blockchain of the DLTN in association with the identity of the user, and
the updating the permission settings includes storing a new version of one or more of the permission settings in a new block in the blockchain.
21. (Original) The computer system of claim 18, wherein the permission settings are stored in encrypted form in the blockchain of the DLTN in association with the identity of the
user, and wherein:
the updating the permission settings includes storing a new version of one or more of the permission settings in a new block in the blockchain.
20. The method of claim 17, further comprising, based on the indication of revocation of the previously approved request:
decrypting at least some of the user data of the user using a first encryption key among the set of encryption keys;
re-encrypting the at least some of the user data of the user using a second encryption key, different than the first encryption key, among the set of encryption keys; and
storing the re-encrypted user data of the user in a new block in the blockchain.
22. (Currently Amended) The computer system of claim 18, the operations further comprising, based on the indication of revocation of the previously-approved request:
decrypting at least some of the user data of the user using a first encryption key among the set of encryption keys;
re-encrypting the at least some of the user data of the user using a second encryption key, different than the first encryption key; and
storing the re-encrypted user data of the user in a new block in the blockchain.
Claim Rejections - 35 USC § 102
NO rejections warranted at applicant’s time of filing for CONtinutation.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claim(s) 1, 2, 4, 6 – 12, 14, 15, 17, 19 is/are rejected under 35 U.S.C.
103 as being unpatentable over Bulleit et al. [US PGPUB # 2020/0226285] in view of
Mirica et al. [US PAT # 11145391]
As per claim 1. Bulleit does teach a computer system comprising memory and one or more processing units [paragraph: 0259, lines 1 – 4, and wherein the indication of revocation of the previously approved request is received in encrypted form over the secure connection], wherein the computer system implements a distributed ledger trust network (“DLTN’”) server configured to perform operations [paragraph: 0176] comprising:
receiving, from a DLTN client, a request for permission settings for user data of a user [Figure # 4, steps 416 and 418 and paragraph: 0106, lines 6 – 11, At 416, the value-added certificate authorization system(s) 160 [i.e. applicant’s DLTN client] may request permissions for the application to access particular user healthcare data resources 416. This particular healthcare data may reside in an EHR stored at a resource system 150 of the user's healthcare provider 102.];
retrieving the permission settings [Figure # 4, steps 418 and paragraph: 0107, At 418, the user may indicate permission(s) for the application to access particular healthcare data resources. The permission(s) may include permission for a single entity (e.g., patient's doctor), or multiple entities (e.g., patient's doctor, patient's pharmacy, patient's health insurance company, and patient's mother). In some cases, the permission(s) as granted by the user 102 may indicate conditional permissions, where the user 102 may specific one or more stipulations under which a party may gain access to the particular healthcare data.];
sending, to the DLTN client, the permission settings [Figure # 4, steps 418, paragraph: 0107, At 418, the user may indicate permission(s) for the application to access particular healthcare data resources. The permission(s) may include permission for a single entity (e.g., patient's doctor), or multiple entities (e.g., patient's doctor, patient's pharmacy, patient's health insurance company, and patient's mother). In some cases, the permission(s) as granted by the user 102 may indicate conditional permissions, where the user 102 may specific one or more stipulations under which a party may gain access to the particular healthcare data.];
receiving, from the DLTN client, one or more updates to the permission settings [Figure # 5, steps: 518, paragraph: 0115, lines 1 – 6, At 518, the value-added certificate authorization system(s) 160 may instruct the blockchain system(s) 180 to add the new permissions for the particular HIR. This process may entail determining that the user 102, having his or her CSI and associated with the first client system 104, is authorized to modify the permissions for the particular HIR]; and
based on the one or more updates to the permission settings, updating the permission settings, the user data of the user being stored in a blockchain of the DLTN in association with identity of the user [Figure # 5, step 520, and paragraph: 0116, lines 1 – 5, At 520, new permissions may be added to the healthcare blockchain as a smart contract. The smart contract may be generated at the blockchain system(s) 180, in accordance with the requested permissions as instructed in 514. The smart contract, as incorporated in the blockchain at this operation 516, may be configured to issue access token(s) (e.g., OAuth2 tokens) to permissioned users 102 of the particular HIR, subject the permissions conditions stipulated with the modified permissions.].
Bulleit does not clearly teach the claim limitation of: “...the user data having been encrypted using a set of encryption keys that are user-specific and context-specific.”
However, Mirica does teach the claim limitation of: “...the user data having been encrypted using a set of encryption keys that are user-specific and context-specific [col. 2, lines 46 – 51, All information is encrypted in a private blockchain ledger comprising a secure chain of decentralized ledger blocks. This allows the participant, or gatekeeper thereof, to give permission to network participants to view some or all of the records in the secure chain of decentralized ledger blocks.].
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Bulleit and Mirica in order for the managing of the user/patient permission[s] of the user/patient data stored on the healthcare provider blockchain of Bulleit to include a user interface that manages/controls aspects of access to the user/patient permission[s] of Mirica. This would allow for real – time management/control of the user/patient permission[s] thru the user interface. See col. 2, lines 64 – 67 and col. 3, lines 1 – 7 of Mirica.
As per claim 2. Bulleit does teach the computer system of claim 1, wherein the operations further comprise:
creating a Web page that includes any categories of the user data of the user that are publicly accessible [Bulleit, Figure # 19, and paragraph: 0217, FIG. 19 is illustrative screen shot example of a three-dimensional user interface on a client device for enabling user to review, revoke or modify permissions and conditions thereof, according to example embodiments of the disclosure. As shown, there may be a first user 1714, and a second user 1716 who may be accorded permissions to access HIRs that attend the applications to which the first user has subscribed 1700, 1702, 1704, 1706 subject to the conditions and restrictions set by the first user 102 and/or authorized other users 102. This interface, in example embodiments, may be interactive to allow a user 102 of client device 104 to set permissions for user(s) 1714, 1716. The mechanism by which the user 102 scrolls along the various axis, expands or contract viewing area(s), activate various fields, or the like, may vary with the operating systems of the user's client system 104.]; and
sending, to the DLTN client, a link to the Web page [Bulleit, paragraph: 0061, lines 11 – 14, In other cases, a user 102 may access value-added certificate authorization system(s), via their client system(s) 104 to establish their CSI. A user 102, via his or her client system 104, may access value-added certificate authorization system(s) [i.e. applicant’s DLTN client] 160 by any suitable manner, such as an HTTPS URL and or other web address.].
As per claim 4. Bulleit as modified does teach the computer system of claim 1, wherein the permission settings are stored in encrypted form in the blockchain of the DLTN in association with the identity of the user [Bulleit, paragraph: 0070, lines 21 – 27, For example, smart contracts incorporating the permissions, as set by a user 102, for access to his or her HIRs may be incorporated in the healthcare blockchain by the blockchain system(s) 180. Indeed, the blockchain system(s) 180 may also enable the execution of the conditions incorporated in the smart contracts, as incorporated in the healthcare blockchain. Where further of Mirica, at col. 2, lines 46 – 51, All information is encrypted in a private blockchain ledger comprising a secure chain of decentralized ledger blocks. This allows the participant, or gatekeeper thereof, to give permission to network participants to view some or all of the records in the secure chain of decentralized ledger blocks], and wherein:
the retrieving the permission settings includes searching the blockchain for the permission settings or requesting the permission settings from a service of the DLTN [Bulleit, Figure # 5, steps 502, 504, 506, 508, and paragraph: 0111, At 502, current permissions for a particular HIR may be requested by a first client system 104. This request may be sent to the value-added certificate authorization system(s) 160. The value-added certificate authorization system(s) 160 may then at 504 request the current permissions for the health information resource from the healthcare blockchain system(s) 180 to determine the permissions associated with the particular HIR. At 506 the smart contracts in the blockchain associated with the particular resource may generate a file indicating the current permissions of the particular resources associated with a given application. The current permissions for the particular health information resource may be sent to the value-added certificate authorization system(s) 160. Next, the value-added certificate authorization system(s) 160, at 508, may send the current permissions for the particular health information resource to the first client system 104.]; and
the updating the permission settings includes storing a new version of one or more of the permission settings in a new block in the blockchain [Bulleit, Figure # 5, step 520, and paragraph: 0116, lines 1 – 5, At 520, new permissions may be added to the healthcare blockchain as a smart contract. The smart contract may be generated at the blockchain system(s) 180, in accordance with the requested permissions as instructed in 514. The smart contract, as incorporated in the blockchain at this operation 516, may be configured to issue access token(s) (e.g., OAuth2 tokens) to permissioned users 102 of the particular HIR, subject the permissions conditions stipulated with the modified permissions].
As per claim 6. Bulleit does teach the computer system of claim 1, wherein the request for permission settings is part of a request to enroll the user [Bulleit, Figure # 2, step 206, and paragraph: 0078, At 206, value-added certificate authorization system(s) 160 may determine and/or verify that the user 102 is not already registered to access to the healthcare blockchain. In other words, process 206 may prevent the registration of multiple CSIs to a single user 102 and/or it may initiate a new user registration process of operation 208. The case where a requesting user already has an established CSI key is discussed below in conjunction with FIG. 3. Where further of Bulleit, paragraph: 0079, lines 1 – 5, At 208, value-added certificate authorization system(s) 160 may permit and determine to request authorization to register the user 102. This may entail the user 102, via his or her client systems 104, acknowledging one or more stipulations and/or agreeing to adhere to rules and/or regulations associated with the mechanism of managing and providing HIR as disclosed herein.], and wherein the one or more updates to the permission settings are changes to default, initial values for the permission settings [Bulleit, Figure # 5, step 520, and paragraph: 0116, lines 1 – 5, At 520, new permissions may be added to the healthcare blockchain as a smart contract. The smart contract may be generated at the blockchain system(s) 180, in accordance with the requested permissions as instructed in 514. The smart contract, as incorporated in the blockchain at this operation 516 ].
As per claim 7. Bulleit does teach the computer system of claim 1, wherein the request for permission settings is part of a request to review the permission settings [Bulleit, Figure # 5, steps: 502, 504, 506, 508, 510, and paragraph: 0111, At 502, current permissions for a particular HIR may be requested by a first client system 104. This request may be sent to the value-added certificate authorization system(s) 160. The value-added certificate authorization system(s) 160 may then at 504 request the current permissions for the health information resource from the healthcare blockchain system(s) 180 to determine the permissions associated with the particular HIR. At 506 the smart contracts in the blockchain associated with the particular resource may generate a file indicating the current permissions of the particular resources associated with a given application. The current permissions for the particular health information resource may be sent to the value-added certificate authorization system(s) 160. Next, the value-added certificate authorization system(s) 160, at 508, may send the current permissions for the particular health information resource to the first client system 104.
Then further of Bulleit, at paragraph: 0112, At 510, the first client device 104 may then display the current permissions and conditions associated with a particular application. As discussed herein, the permissions associated with the particular application may include conditional resource access permissions. For example, the conditions may show that the user's brother may have access to the HIRs for the next 30 days, or a researcher may have access to the heath resource if it is anonymized. In example embodiments, such conditions and/or stipulations of the permissions of the particular HIR may be displayed to the user 102 on a display of the first client system 104], and wherein the one or more updates to the permission settings are changes to previously set values for the permission settings [Bulleit, Figure # 5, steps: 512, 514, 516, 518, 520, 524, and paragraph: 0113, At 512, the first client device 104 may receive indications of desired changes to the current permissions of the particular HIRs. These changes may be entered by a user 102 who has rights to change the permissions for the particular HIR, such as a patient for whom the HIR pertains, on the first client system 104. For example, the new desired permissions and/or changes to the permissions may be entered on any suitable user interface of the first client system 104, such as a graphical interface on a touch screen of the first client system 104.
Then further of Bulleit, at paragraph: 0114, At 514, the first client device 104 may generate a request for new permissions for the HIR. This request may indicate all of the changes to the current permissions, as requested by the user 102 at 508. The new permission requests and/or changes to the current permissions for the particular HIR may be coded in one or more messages. At 512, the first client device may send the request via one or more networks 110 for new permissions to the value-added certificate authorization system(s) 160.
Then of further of Bulleit, at paragraph: 0115, At 518, the value-added certificate authorization system(s) 160 may instruct the blockchain system(s) 180 to add the new permissions for the particular HIR. This process may entail determining that the user 102, having his or her CSI and associated with the first client system 104, is authorized to modify the permissions for the particular HIR. This verification may be performed locally at the certificate verification system(s) 160, or alternatively, may be performed by query to the blockchain system(s) 180 or by invoking a smart contract resident within the blockchain system 180. The value-added certificate authorization system(s) 160, according to some example embodiments, may instruct the blockchain system(s) 180 only after verifying the identity and permissions of the requesting users using his or her CSI, as received from the first client system 104.
Then further of Bulleit, paragraph: 0116, At 520, new permissions may be added to the healthcare blockchain as a smart contract. The smart contract may be generated at the blockchain system(s) 180, in accordance with the requested permissions as instructed in 514. The smart contract, as incorporated in the blockchain at this operation 516, may be configured to issue access token(s) (e.g., OAuth2 tokens) to permissioned users 102 of the particular HIR, subject the permissions conditions stipulated with the modified permissions. It should be noted that older permissions may remain as part of the healthcare blockchain. However, updated permissions, or in other words, it is appreciated that an aspect of normal blockchain operations provides that the most temporally recent permissions associated with a HIR will control the access thereto. Moreover, another feature of private, or permissioned, blockchains of the sort to used in the healthcare blockchain system is the ability for the consensus participating nodes to direct a hard fork—i.e., a new version of the blockchain correcting errors in code and or data contained therein.
Then further of Bulleit, at paragraph: 0117, At 522, there may be a variety of notifications of permission states that are sent to other entities that may be affected by the changes in the permissions for the particular HIR. For example, the value-added certificate authorization system(s) 160 may be sent a confirmation of the changes. In some cases, the value-added certificate authorization system(s) 160 may maintain an independent registry of permissions, at least for a limited period of time. The block chain system(s) 180 may optionally notify one or more resource system(s) 150 where the particular HIR resides, unless those resource system(s) 150 are nodes of the blockchain, or in other words, are also blockchain system(s) 180 themselves. One or more other client system(s) 104 may also be notified. For example, if permissions are extended, revoked, and/or conditions modified, for a second CSI, and the user 102 associated with that CSI, then the client system 104 associated with that CSI, and the healthcare applications operating thereon, may be notified of any permission changes pertaining to the second CSI. It is also appreciated that any and all systems operating as full peer nodes on the blockchain always have near real time information on any and all state changes occurring in the network thus rendering the need for further notifications moot.
Then further of Bulleit, at paragraph: 0118, At 520, a confirmation of the change in permissions state may be sent to the first client system 104. Thus, the user 102 may receive confirmation of the changes that he or she wished to implement for his or her particular HIR.].
As per claim 8. Bulleit does teach the computer system of claim 1, wherein the one or more updates to the permission settings include:
a grant of access to at least some of the user data of the user [Bulleit, Figure # 17, steps: 1704, 1706, 1710, 1712]; and/or
a revocation of access to at least some of the user data of the user [Bulleit, Figure # 17, steps: 1704, 1706, 1708].
As per claim 9. Bulleit does teach the computer system of claim 1, wherein the blockchain is a private blockchain [Bulleit, and paragraph: 0116, lines 15 – 19, Moreover, another feature of private, or permissioned, blockchains of the sort to used in the healthcare blockchain system is the ability for the consensus participating nodes to direct a hard fork—i.e., a new version of the blockchain correcting errors in code and or data contained therein], and wherein the DLTN server manages access to the private blockchain [Bulleit, paragraph: 0056, The environment 100 may include resource system(s) 150 that may be an electronic health record (EHR) server [i.e. applicant’s DLTN server] configured to intake, store, and/or provide HIRs to authorized users 102. The resource system(s) 150 may be operated, controlled, and/or owned by one or more healthcare providers, independent repositories of HIR, pharmacies, insurers, research organizations, or indeed any suitable party. The resource system(s) 150 may be configured to provide a requested HIR to a requesting party, if that party is authorized to receive the requested HIR. The resource system(s) 150 may determine if a requesting party is authorized to receive requested HIR (e.g., PHI) by determining if a valid access token is received along with the request for the HIR.].
As per claim 10. Bulleit does teach the computer system of claim 1, wherein:
the DLTN server includes a Web application and implements an application programming interface (“API”) accessible to the DLTN client [Bulleit, paragraph: 0076, lines 1 – 10, The operations 200 may include, at 202, the client system generating a request to access the blockchain. The request to access the blockchain may alternatively by considered a request to certify a self-sovereign identity that one may use via his or her client system 104 to access the blockchain. In some example embodiments, the request may be generated by interacting with a web interface of a value-added certificate autho