DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Claims
The office action is in response to the claims filed on January 16, 2025 for the application filed January 16, 205 which claims priority to a foreign application filed on March 28, 2028. Claims 1-20 are currently pending and have been examined.
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 13-19 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.
Claim 13 recites the limitation "the information interaction platform" in lines 6-7 and 10. There is insufficient antecedent basis for this limitation in the claim. Claims 16 also recites "the information interaction platform" in line 2. For the purposes of examination, "the information interaction platform" is being interpreted as "the information interaction device".
Claims 14-19 are rejected at least based on their dependency on claim 13.
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 11-12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
The claims do not fall within at least one of the four categories of patent eligible subject matter because the information interaction platform is a product that does not have a physical or tangible form, such as information (often referred to as "data per se") or a computer program per se (often referred to as "software per se"), as the claims do not recite any structural limitations
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Eligibility Step 1:
Under step 1 of the 2019 Revised Patent Subject Matter Eligibility Guidance, claims 1-10 and 20 are directed towards an information interaction method (i.e. a process), which is a statutory category. Claims 13-19 are directed towards an information interaction device (i.e. a machine), which is a statutory category. Assuming claims 11-12 are amended such that they are also directed toward statutory categories, it must be determined if the claims are directed towards a judicial exception (i.e. a law of nature, a natural phenomenon, or an abstract idea). In the instant application, the claims are directed towards an abstract idea.
Eligibility Step 2A, Prong One:
Under step 2A, prong one of the 2019 Revised Patent Subject Matter Eligibility Guidance, independent claims 1, 11 and 13 are determined to be directed to an judicial exception because an abstract idea is recited in the claims which fall within the subject matter groupings of abstract ideas. The abstract idea (identified in bold) recited in the representative claim 1 is identified as:
An information interaction device, comprising: a processor and a memory, the memory storing at least one instruction, at least one program, a code set, or an instruction set therein, wherein the processor, when loading and executing the at least one instruction, the at least one program, the code set, or the instruction set, is caused to perform:
acquiring patient description information provided by a terminal corresponding to a first institution, wherein the first institution is an institution registered on the information interaction platform, and the terminal corresponding to the first institution is configured to acquire the patient description information provided by a target patient of the first institution;
determining role data of a plurality of medical practitioners corresponding to the first institution on the information interaction platform, wherein the role data is configured to identify information of the medical practitioners in the first institution; and
transmitting, based on the role data, the patient description information to a terminal of at least one medical practitioner of the plurality of medical practitioners corresponding to the first institution.
The identified limitations of the abstract idea fall within the subject matter grouping of certain methods of organizing human activity related and the sub grouping of commercial or legal interactions (including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations). Acquiring patient description information, determining role data of medical practitioners and transmitting the patient description information based on the role data is the commercial or legal interaction of role based access control of patient description information.
The determining role data and whether to transmit patient description information based on role data limitations of the abstract idea of fall within the subject matter grouping of mental processes. If a claim recites a limitation that can practically be performed in the human mind, with or without the use of a physical aid such as pen and paper, the limitation falls within the mental processes grouping, and the claim recites an abstract idea. Determining role data for medical practitioners and whether to transmit patient description information based on role data can be performed in the human mind using observations, evaluations, judgments and opinions.
Accordingly, claims 1, 11 and 13 recite an abstract idea under step 2A, prong one.
Eligibility Step 2A, Prong Two:
Under step 2A, prong two of the 2019 Revised Patent Subject Matter Eligibility Guidance, it must be determined whether the identified abstract ideas are integrated into a practical application. After evaluation, there is no indication that any additional elements or combination of elements integrate the abstract idea into a practical application, such as through: an additional element that reflects an improvement to the functioning of a computer, or an improvements to any other technology or technical field; an additional element that applies or uses a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition; an additional element that implements the judicial exception with, or uses the judicial exception in connection with, a particular machine or manufacture that is integral to the claim; an additional element that effects a transformation or reduction of a particular article to a different state or thing; or an additional element that applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception. As shown below, the additional elements, other than the abstract idea per se, when considered both individually and as an ordered combination, amount to no more than a recitation of: generally linking the abstract idea to a particular technological environment or field of use; insignificant extra-solution activity to the judicial exception; and/or adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea as evidenced below.
The additional elements recited in representative claim 13 are identified in italics as:
An information interaction device, comprising: a processor and a memory, the memory storing at least one instruction, at least one program, a code set, or an instruction set therein, wherein the processor, when loading and executing the at least one instruction, the at least one program, the code set, or the instruction set, is caused to perform:
acquiring patient description information provided by a terminal corresponding to a first institution, wherein the first institution is an institution registered on the information interaction platform, and the terminal corresponding to the first institution is configured to acquire the patient description information provided by a target patient of the first institution;
determining role data of a plurality of medical practitioners corresponding to the first institution on the information interaction platform, wherein the role data is configured to identify information of the medical practitioners in the first institution; and
transmitting, based on the role data, the patient description information to a terminal of at least one medical practitioner of the plurality of medical practitioners corresponding to the first institution.
The additional limitations are determined to be mere instructions to apply an abstract idea under MPEP §2106.05(f). The information interaction device, having memory storing instructions and a processed to execute the instructions are recited at a high level of generality and no more than mere instructions to implement an abstract idea on a computer. Similarly, the use of the terminal, which is recited at a high level of generality, is merely used as a tool to perform the abstract idea of acquiring and transmitting data. Therefore, these additional elements amount to no more than a recitation of the words "apply it" (or an equivalent) or no more than mere instructions to implement an abstract idea or other exception on a computer or no more than merely using a computer as a tool to perform an abstract idea.
Accordingly, claims 1, 11 and 13 do not recite additional elements which integrate the abstract idea into a practical application.
Eligibility Step 2B:
Under step 2B of the 2019 Revised Patent Subject Matter Eligibility Guidance, it must be determined whether provide an inventive concept by determining if the claims include additional elements or a combination of elements that are sufficient to amount to significantly more than the judicial exception. After evaluation, there is no indication that an additional element or combination of elements are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional limitations are determined to be mere instructions to apply an abstract idea under MPEP §2106.05(f), which does not amount to significantly more than the abstract idea.
Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements amounts to an inventive concept.
Dependent Claims:
The dependent claims merely present additional abstract information in tandem with further details regarding the elements from the independent claims and are, therefore, directed to an abstract idea for similar reasons as given above. None of these limitations are deemed to integrate the claims into a practical application or to amount to significantly more than the abstract idea as detailed below.
Regarding claims 2-3, 12 and 14-15, the claims recited limitations which recite abstract idea falling under the grouping of certain methods of organizing human activity. They claims recite steps for institutions acquiring registration information for medical practitioners, performing verification on the registration information and establishing role data based on passing the registration, which is the commercial or legal interaction of identity verification, credentialling and access management. The additional limitations reciting the use of a terminal is mere instructions to apply an abstract idea under MPEP §2106.05(f).
Regarding claims 4 and 16, the claims recite additional details of the acquiring of registration information and credentialling (i.e. providing certificates) based on passing verification, which are also directed to the abstract idea falling under the grouping of certain methods of organizing human activity. The additional limitations of the certificate issuer nodes, user nodes and institution nodes of a blockchain used to perform the abstract idea are determined to be no more than generally linking the use of a judicial exception to the particular technological environment or field of use of blockchains under MPEP §2106.05(h). Furthermore the nodes are recited at a high level of generality and mere used to implement the abstract idea and are determined to be mere instructions to apply an abstract idea under MPEP §2106.05(f).
Regarding claims 5 and 17, the additional limitations of acquiring patient data from terminals of institutions and storing data at nodes of institutions to mere data gathering and considered to be insignificant extra-solution activity to the judicial exception under MPEP §2106.05(g), which is well-understood, routine and conventional as evidenced by MPEP §2106.05(d), subsection II.
Regarding claims 6-10 and 18-19, defining the role data to cover query ranges and patients (i.e. information which may be accessed) for query requests in order to provide patient information based on the role data, identity verification on users/certificates and patient authorization is determined to also be directed to the abstract idea falling under the grouping of certain methods of organizing human activity and the subgrouping of commercial or legal interactions. As detailed above, the additional elements of using “nodes” to perform this process is determined to be mere instructions to apply an abstract idea under MPEP §2106.05(f).
Regarding the 20, the additional limitation a non-transitory computer storage medium used to perform the abstract idea is determined to be mere instructions to apply an abstract idea under MPEP §2106.05(f).
Therefore, whether taken individually or as an ordered combination, 1-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1 and 11 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Rajagopal et al. (WO 2024/171219 A1).
Regarding claim 1, Rajagopal discloses an information interaction method, applicable to an information interaction platform (Abstract and Fig. 6), the method comprising:
acquiring patient description information provided by a terminal corresponding to a first institution, wherein the first institution is an institution registered on the information interaction platform, and the terminal corresponding to the first institution is configured to acquire the patient description information provided by a target patient of the first institution (Paragraph [0131], Healthcare institutions produce data in the form of health records of the patients, which is of great interest to many organizations (insurance providers, re- searchers, etc.. To share this data without loss of privacy and security, the proposed system is used, and hence the institutions act as healthcare data providers. Paragraph [0072], In an embodiment, considering two health institutions H1 and H2, H1 can create a new record (transaction), and append it to the subchain 104 of a patient in that institution. Paragraph [0085], Doctor D 208 can be classified as the client device that belongs to Organization2 202/2. Peer P2 210 can be classified as the peer device that can endorse or commit the transaction for Organization2 202/2. Paragraph [0070], health organizations will be allowed to join the mainchain 104 by verification of their certification as a health institution by the government of the country and will be allowed inside the network. Also see paragraph [0033].);
determining role data of a plurality of medical practitioners corresponding to the first institution on the information interaction platform, wherein the role data is configured to identify information of the medical practitioners in the first institution (Paragraph [0099], The hyperledger fabric admin is registered for each organization. Once admin registration is completed, the admin identity can issue more identities for the respective organization. Paragraph [0108], Access control decisions can be made by Chaincode (and by the Hyperledger Fabric Runtime) based on an entity's attributes. This is called Attribute-based Access Control (ABAC). To make this possible, an identity’s enrollment Certificate (E-cert) may contain one or more attribute names and values. The chaincode then extracts an attribute’s value to make an access control decision. Also see paragraphs [0105], [0112] and [0129].); and
transmitting, based on the role data, the patient description information to a terminal of at least one medical practitioner of the plurality of medical practitioners corresponding to the first institution (Paragraph [0101], a function for Send Request to Access Data and If ‘Approved’ update the Doctor Identity (E-Cert) with PatientID is completed. Paragraph [0102], Once approved, the Doctor can read the patient’s previous health data and consult accordingly. Paragraph [0108], cess control decisions can be made by Chaincode (and by the Hyperledger Fabric Runtime) based on an entity's attributes. This is called Attribute-based Access Control (ABAC). To make this possible, an identity’s enrollment Certificate (E-cert) may contain one or more attribute names and values. The chaincode then extracts an attribute’s value to make an access control decision. For Example: In the smart contract instance we have 2 organizations. Org1 belongs to a patient and Org2 belongs to a doctor from a clinic. Paragraph [0112], the doctor identity from Org2 that got access to read the data will be updated with the ID of the Patient that gave the access. Further, the doctor identity has anew attribute where the patient identity ‘patient1843” gets mapped.i.c { name: ‘doctor64', value: 'patient1843" }. Here, ‘doctor64” is a client from org2, and ‘patient1843' is the patient identity. This chaincode then extracts the value of the attribute and makes the access control decision. Also see paragraph [0033].).
Regarding claims 11: all limitations as recited have been analyzed and rejected with respect to claim 1. Claim 11 pertains to an interaction platform, corresponding to the method of claim 1. Claim 11 does not teach or define any new limitations beyond claim 1; therefore claim 11 is rejected under the same rationale.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 2-10 and 12-20 are rejected under 35 U.S.C. 103 as being unpatentable over Rajagopal et al. (WO 2024/171219 A1) in view of Dods et al. (U.S. Patent No. 11,769,577).
Regarding claim 2, Rajagopal further discloses wherein prior to acquiring the patient description information provided by the terminal corresponding to the first institution, the method further comprises:
acquiring first registration information provided by Paragraph [0099], The hyperledger fabric admin is registered for each organization. Once admin registration is completed, the admin identity can issue more identities for the respective organization. Paragraph [0100], A register() function will register ‘patient’ and ‘doctor’ to the blockchain network.);
Paragraph [0099], The hyperledger fabric admin is registered for each organization. Once admin registration is completed, the admin identity can issue more identities for the respective organization. Paragraph [0108], Access control decisions can be made by Chaincode (and by the Hyperledger Fabric Runtime) based on an entity's attributes. This is called Attribute-based Access Control (ABAC). To make this possible, an identity’s enrollment Certificate (E-cert) may contain one or more attribute names and values. The chaincode then extracts an attribute’s value to make an access control decision. Also see paragraphs [0105], [0112] and [0129].);
acquiring second registration information provided by Paragraph [0099], The hyperledger fabric admin is registered for each organization. Once admin registration is completed, the admin identity can issue more identities for the respective organization. Paragraph [0100], A register() function will register ‘patient’ and ‘doctor’ to the blockchain network.);
Paragraph [0099], The hyperledger fabric admin is registered for each organization. Once admin registration is completed, the admin identity can issue more identities for the respective organization. Paragraph [0108], Access control decisions can be made by Chaincode (and by the Hyperledger Fabric Runtime) based on an entity's attributes. This is called Attribute-based Access Control (ABAC). To make this possible, an identity’s enrollment Certificate (E-cert) may contain one or more attribute names and values. The chaincode then extracts an attribute’s value to make an access control decision. Also see paragraphs [0105], [0112] and [0129].).
Rajagopal does not appear to explicitly disclose the first and second registration information is provided by a terminal of a first medical practitioner for the first and second institutions; performing verification on the first and second registration information; or that the first and second role data is established in response to the first and second registration information passing the verification.
Dods teaches that it was old and well known in the art of identity management at the time of the filing to acquire registration information provided by a terminal of a first medical practitioner for an institution (Column 8, lines 36-54, an authentication registry server 190 (of FIG. 1A) receives (Action 1 of FIG. 1A) a request 10 from an application 160 of a client device(s) 122 (belonging to a human requestor(s)) a request to authenticate the user of device 122 with the multi-organizational system 100B of FIG. 1B. In implementations, this request can be Email as the vehicle for sending this request, however other channels of Networks 101, e.g., SMS, HTTPS, etc. are also available. As also shown by FIG. 1A, the request 10 includes: (i) identity documentation identifying the user and captured by the user application at a time of making the request and (ii) claims made by an entity administrator supporting a role, as determined by rules of a trust framework adopted by the network members with request 10 for information. Column 9, lines 16-18, In block 203 and flow 303, registry server 190 sends (Action 2 of FIG. 1A) the identity documentation and claims via an external validator interface to a validator server 180.);
perform verification on the registration information (Column 9, lines 36-38, In block 204 and flow 304, a requestor's evidence and claims of authority are validated by the validator servers 180. Column 34, lines 7-13, Such documentation can be made available by authentication server 190 specifically to an auditor, e.g., an enterprise-level accreditor or a third-party accreditor, via validator server 180. This accreditor performs checking of credentials and documents, to support/verify the individual's claim that they are indeed the person they claim to be. Also see figs. 3A and 8C.).; and
in response to the registration information passing the verification, establishing role data of the medical practitioner in the institution (Column 9, lines 36-38, In block 204 and flow 304, a requestor's evidence and claims of authority are validated by the validator servers 180. The requestors are credentialed by the registry server 190. Also see column 5, lines 34-67 and column 6, lines 1-11.) to enable controlled access to a secure permissioned blockchain data distributed among disparate enterprise actors (Column 1, lines 59-60).
Therefore, it would have been obvious to one of ordinary skill in the art of identity management at the time of the filing to modify the method of Rajagopal such that the acquired registration information is from a terminal of the first medical practitioner for a institution, to perform verification on the registration information and to establish role data of the medical practitioner in the institution in response to the registration information passing the verification, as taught by Dods, in order to enable controlled access to a secure permissioned blockchain data distributed among disparate enterprise actors. Furthermore, as discussed in column 5, lines 34-67 and column 6, lines 1-11, Dods teaches that a client device/terminal uses an enterprise specific application sponsoring the requestor to request registration. Therefore, it would be obvious to one of ordinary skill in the art of identity management at the time of the filing that the client device/terminal of the first medical practitioner could request registration with a first and second institution, such that the first and second institutions verify and establish role data for the first medication practitioner when two different enterprises sponsor the same medical practitioner. For example, the first medical practitioner may be employed with a first and second institution or move from a first institution to a second institution.
Regarding claim 3, Rajagopal does not appear to explicitly disclose, but Dods further teaches that it was old and well known in the art of identity management at the time of the filing wherein performing the verification on the first registration information comprises:
providing the first registration information to the first institution, wherein the first institution is configured to perform the verification on the first registration information (Column 9, lines 16-18, In block 203 and flow 303, registry server 190 sends (Action 2 of FIG. 1A) the identity documentation and claims via an external validator interface to a validator server 180. Column 34, lines 7-13, Such documentation can be made available by authentication server 190 specifically to an auditor, e.g., an enterprise-level accreditor or a third-party accreditor, via validator server 180. This accreditor performs checking of credentials and documents, to support/verify the individual's claim that they are indeed the person they claim to be. Also see figs. 3A and 8C.); and
in response to receiving verification pass information provided by the first institution, determining that the first registration information passes the verification (Column 9, lines 36-38, In block 204 and flow 304, a requestor's evidence and claims of authority are validated by the validator servers 180. The requestors are credentialed by the registry server 190. Also see column 5, lines 34-67, column 6, lines 1-11 and column 7, lines discussing credentialling a client only after authentication/verification.) to enable controlled access to a secure permissioned blockchain data distributed among disparate enterprise actors (Column 1, lines 59-60).
Therefore, it would have been obvious to one of ordinary skill in the art of identity management at the time of the filing to modify the method of Rajagopal such that performing the verification on the first registration information comprises: providing the first registration information to the first institution, wherein the first institution is configured to perform the verification on the first registration information; and in response to receiving verification pass information provided by the first institution, determining that the first registration information passes the verification, as taught by Dods, in order to enable controlled access to a secure permissioned blockchain data distributed among disparate enterprise actors.
Regarding claim 4, Rajagopal further discloses wherein the information interaction platform further comprises: a certificate issuer node, a first user node, and a first institution node corresponding to the first institution in a block chain (Paragraph [0099]], In an embodiment, in the Hyperledger Fabric Architecture, the Certificate Authority (CA) is used to register Admin, Peer, Orderer, and Client for an Organization. Paragraph [0038]-[0040], mainchain layer 102 nodes comprise healthcare institutions; The nodes in the subchain layer 104 hence comprise at least one of: nodes of the hospitals involved, and the patient’s device. Paragraph [0066], Each organization in the subchain 104 is represented by a node. Also see claims 7-8 and paragraph [0085].).
Rajagopal further discloses providing a certificate to the first user node by the certificate issuer node (Paragraph [0099], The Certificate Authority registers identities, issues Enrollment Certificates (E-Certs) to the users, and also renews or revokes the certificate in a few cases.
Rajagopal does not appear to explicitly disclose, but Dods further teaches that it was old and well known in the art of identity management at the time of the filing wherein:
acquiring the first registration information provided by the terminal of the first medical practitioner for the first institution comprises:
acquiring, by the first user node, the first registration information provided by the terminal of the first medical practitioner for the first institution (Dods, Column 8, lines 36-54, an authentication registry server 190 (of FIG. 1A) receives (Action 1 of FIG. 1A) a request 10 from an application 160 of a client device(s) 122 (belonging to a human requestor(s)) a request to authenticate the user of device 122 with the multi-organizational system 100B of FIG. 1B. In implementations, this request can be Email as the vehicle for sending this request, however other channels of Networks 101, e.g., SMS, HTTPS, etc. are also available. As also shown by FIG. 1A, the request 10 includes: (i) identity documentation identifying the user and captured by the user application at a time of making the request and (ii) claims made by an entity administrator supporting a role, as determined by rules of a trust framework adopted by the network members with request 10 for information. Column 9, lines 16-18, In block 203 and flow 303, registry server 190 sends (Action 2 of FIG. 1A) the identity documentation and claims via an external validator interface to a validator server 180.);
providing the first registration information to the first institution comprises:
providing the first registration information to the first institution node (Dods, Column 34, lines 7-13, Such documentation can be made available by authentication server 190 specifically to an auditor, e.g., an enterprise-level accreditor or a third-party accreditor, via validator server 180. Enterprise-level accreditor is construed as a institution node, such as the peer/admin/healthcare institution/organization node of Rajagopal.); and
in response to receiving the verification pass information provided by the first institution, determining that the first registration information passes the verification comprises:
in response to acquiring the verification pass information, providing a certificate to the first user node by the certificate issuer node, wherein the certificate is configured to determine that the first registration information passes the verification (Dods, Column 9, lines 36-38, In block 204 and flow 304, a requestor's evidence and claims of authority are validated by the validator servers 180. The requestors are credentialed by the registry server 190. Also see column 5, lines 34-67, column 6, lines 1-11 and column 7, lines discussing credentialling a client only after authentication/verification and providing a providing a token to create unique digital identifier, construed as a certificate.) to enable controlled access to a secure permissioned blockchain data distributed among disparate enterprise actors (Dods, Column 1, lines 59-60).
Therefore, it would have been obvious to one of ordinary skill in the art of identity management at the time of the filing to modify the method of Rajagopal to include the limitations above, as taught by Dods, in order to enable controlled access to a secure permissioned blockchain data distributed among disparate enterprise actors.
Regarding claim 5, Rajagopal further discloses wherein upon acquiring the patient description information provided by the terminal corresponding to the first institution, the method further comprises:
storing the patient description information provided by the terminal corresponding to the first institution in the first institution node (Paragraph [0072], In an embodiment, considering two health institutions H1 and H2, H1 can create a new record (transaction), and append it to the subchain 104 of a patient in that institution, and can also create an access URL and key to the same, which will be accessible to the patient as well as to H1. Paragraph [0066], Each organization in the subchain 104 is represented by a node);
acquiring patient description information provided by a terminal corresponding to the second institution (Paragraph [0131], Healthcare institutions produce data in the form of health records of the patients, which is of great interest to many organizations (insurance providers, re- searchers, etc.. To share this data without loss of privacy and security, the proposed system is used, and hence the institutions act as healthcare data providers. Paragraph [0072], In an embodiment, considering two health institutions H1 and H2, H1 can create a new record (transaction), and append it to the subchain 104 of a patient in that institution, and can also create an access URL and key to the same, which will be accessible to the patient as well as to H1. Similarly, H2 can create a record whose access keys will be available only to H2. Paragraph [0085], Doctor D 208 can be classified as the client device that belongs to Organization2 202/2. Peer P2 210 can be classified as the peer device that can endorse or commit the transaction for Organization2 202/2. Paragraph [0070], health organizations will be allowed to join the mainchain 104 by verification of their certification as a health institution by the government of the country and will be allowed inside the network. Also see paragraph [0033].); and
storing the patient description information provided by the terminal corresponding to the second institution in the second institution node (Paragraph [0072], In an embodiment, considering two health institutions H1 and H2, H1 can create a new record (transaction), and append it to the subchain 104 of a patient in that institution, and can also create an access URL and key to the same, which will be accessible to the patient as well as to H1. Similarly, H2 can create a record whose access keys will be available only to H2. Paragraph [0066], Each organization in the subchain 104 is represented by a node.).
Regarding claim 6, Rajagopal further discloses wherein the role data comprises a data query range of the medical practitioners in the first institution (Paragraph [0108], Access control decisions can be made by Chaincode (and by the Hyperledger Fabric Runtime) based on an entity's attributes. This is called Attribute-based Access Control (ABAC). To make this possible, an identity’s enrollment Certificate (E-cert) may contain one or more attribute names and values. The chaincode then extracts an attribute’s value to make an access control decision.); and
the method further comprises:
acquiring, by the first institution node, a query request provided by the first user node, wherein the query request is configured to acquire the patient description information of the target patient of the first institution, and the first institution node is configured to determine, based on the role data, whether the patient description information is within a query range of the first medical practitioner (Paragraph [0104], The network architecture 100 uses Access Control Lists (ACLs) to manage access to resources by associating a policy with a resource. The ACL works on access control at the administration. Paragraph [0108], an identity’s enrollment Certificate (E-cert) may contain one or more attribute names and values. The chaincode then extracts an attribute’s value to make an access control decision. Paragraph [0110], Case 1: The Doctor requests Access to the Patient’s data and the patient approves the request. Paragraph [0112], In the first case, the doctor identity from Org2 that got access to read the data will be updated with the ID of the Patient that gave the access. Further, the doctor identity has anew attribute where the patient identity ‘patient1843” gets mapped.i.c { name: ‘doctor64', value: 'patient1843" }. Here, ‘doctor64” is a client from org2, and ‘patient1843' is the patient identity. This chaincode then extracts the value of the attribute and makes the access control decision. Paragraph [0036], the mainchain layer 102 comprises of a different set of nodes, where each node represents an institution/organization. Further, access control will be based on the institutions organization of the latest transaction on a subchain 104. Claim 7, wherein the mainchain node is configured to invoke and execute at least one smart contract configured to perform at least one of: access management and user-client request handling.); and
in response to determining that the patient description information is within the query range of the first medical practitioner, providing the patient description information to the first user node (Paragraph [0110], Case 1: The Doctor requests Access to the Patient’s data and the patient approves the request. Paragraph [0112], In the first case, the doctor identity from Org2 that got access to read the data will be updated with the ID of the Patient that gave the access. Further, the doctor identity has anew attribute where the patient identity ‘patient1843” gets mapped.i.c { name: ‘doctor64', value: 'patient1843" }. Here, ‘doctor64” is a client from org2, and ‘patient1843' is the patient identity. This chaincode then extracts the value of the attribute and makes the access control decision. Also see paragraphs [0072]-[0075].).
Regarding claim 7, Rajagopal further discloses acquiring, by the first institution node, the query request provided by the first user node comprises:
receiving, by the first institution node, the query request transmitted by a to-be-verified node; performing identity authentication on the to-be-verified node; and in response to the to-be-verified node passing the identity authentication, determining the to-be-verified node to be the first user node (Paragraph [0108], Access control decisions can be made by Chaincode (and by the Hyperledger Fabric Runtime) based on an entity's attributes. This is called Attribute-based Access Control (ABAC). To make this possible, an identity’s enrollment Certificate (E-cert) may contain one or more attribute names and values. The chaincode then extracts an attribute’s value to make an access control decision. Paragraph [0110], Case 1: The Doctor requests Access to the Patient’s data and the patient approves the request. Paragraph [0012], In the first case, the doctor identity from Org2 that got access to read the data will be updated with the ID of the Patient that gave the access. Further, the doctor identity has a new attribute where the patient identity ‘patient1843’ gets mapped.i.e {name: 'doctor64', value: 'patient1843'}. Here, ‘doctor64’ is a client from org2, and 'patient1843' is the patient identity. This chaincode then extracts the value of the attribute and makes the access control decision).
Regarding claim 8, Rajagopal further discloses wherein performing the identity authentication on the to-be-verified node comprises:
performing verification, by the first institution node, on a certificate provided by the to-be- verified node; in response to the certificate provided by the to-be-verified node passing the verification, determining that the to-be-verified node passes the identity authentication (Paragraph [0108], Access control decisions can be made by Chaincode (and by the Hyperledger Fabric Runtime) based on an entity's attributes. This is called Attribute-based Access Control (ABAC). To make this possible, an identity’s enrollment Certificate (E-cert) may contain one or more attribute names and values. The chaincode then extracts an attribute’s value to make an access control decision. Paragraph [0110], Case 1: The Doctor requests Access to the Patient’s data and the patient approves the request. Paragraph [0012], In the first case, the doctor identity from Org2 that got access to read the data will be updated with the ID of the Patient that gave the access. Further, the doctor identity has a new attribute where the patient identity ‘patient1843’ gets mapped.i.e {name: 'doctor64', value: 'patient1843'}. Here, ‘doctor64’ is a client from org2, and 'patient1843' is the patient identity. This chaincode then extracts the value of the attribute and makes the access control decision. Also see paragraph [0104].).
Regarding claim 9, Rajagopal further discloses wherein transmitting, based on the role data, the patient description information to the terminal of at least one medical practitioner of the plurality of medical practitioners corresponding to the first institution comprises:
determining, based on the role data, whether the target patient has a corresponding medical practitioner in the first institution ; and in response to the target patient having the corresponding medical practitioner in the first institution, transmitting the patient description information to a terminal of the corresponding medical practitioners (Paragraph [0108], Access control decisions can be made by Chaincode (and by the Hyperledger Fabric Runtime) based on an entity's attributes. This is called Attribute-based Access Control (ABAC). To make this possible, an identity’s enrollment Certificate (E-cert) may contain one or more attribute names and values. The chaincode then extracts an attribute’s value to make an access control decision. Paragraph [0110], Case 1: The Doctor requests Access to the Patient’s data and the patient approves the request. Paragraph [0012], In the first case, the doctor identity from Org2 that got access to read the data will be updated with the ID of the Patient that gave the access. Further, the doctor identity has a new attribute where the patient identity ‘patient1843’ gets mapped.i.e {name: 'doctor64', value: 'patient1843'}. Here, ‘doctor64’ is a client from org2, and 'patient1843' is the patient identity. This chaincode then extracts the value of the attribute and makes the access control decision. Paragraph [0102], Once approved, the Doctor can read the patient’s previous health data and consult accordingly. Also see paragraph [0093].).
Regarding claim 20, Rajagopal further discloses wherein prior to transmitting, based on the role data, the patient description information to the terminal of at least one medical practitioner of the plurality of medical practitioners corresponding to the first institution, the method further comprises:
acquiring authorization information provided by the target patient, wherein the authorization information is configured to authorize the information interaction platform, such that the information interaction platform is capable of transmitting the patient description information to the terminal of at least one medical practitioner of the plurality of medical practitioners corresponding to the first institution (Paragraph [0108], Access control decisions can be made by Chaincode (and by the Hyperledger Fabric Runtime) based on an entity's attributes. This is called Attribute-based Access Control (ABAC). To make this possible, an identity’s enrollment Certificate (E-cert) may contain one or more attribute names and values. The chaincode then extracts an attribute’s value to make an access control decision. Paragraph [0110], Case 1: The Doctor requests Access to the Patient’s data and the patient approves the request. Paragraph [0012], In the first case, the doctor identity from Org2 that got access to read the data will be updated with the ID of the Patient that gave the access. Further, the doctor identity has a new attribute where the patient identity ‘patient1843’ gets mapped.i.e {name: 'doctor64', value: 'patient1843'}. Here, ‘doctor64’ is a client from org2, and 'patient1843' is the patient identity. This chaincode then extracts the value of the attribute and makes the access control decision. Paragraph [0102], Once approved, the Doctor can read the patient’s previous health data and consult accordingly. Also see paragraphs [0076] and [0093].).
Regarding claim 20, Regarding further discloses a non-transitory computer storage medium, storing at least one instruction, at least one program, a code set, or an instruction set therein, wherein the at least one instruction, the at least one program, the code set, or the instruction set, when loaded and executed by a processor, causes the processor to perform the information interaction method as defined in claim 1 (Dods, Column 69, lines 34-41) to enable controlled access to a secure permissioned blockchain data distributed among disparate enterprise actors (Dods, Column 1, lines 59-60).
Therefore, it would have been obvious to one of ordinary skill in the art of identity management at the time of the filing to modify the method of Rajagopal to include the limitations above, as taught by Dods, in order to enable controlled access to a secure permissioned blockchain data distributed among disparate enterprise actors.
Regarding claims 12-20: all limitations as recited have been analyzed and rejected with respect to claims 1-10. Claims 12 pertains to an interaction platform, corresponding to the method of claims 2-4. Claims 13-19 pertain to an interaction device, corresponding to the method of claims 1-6 and 20. Claims 12-20 do not teach or define any new limitations beyond claims 12-20; therefore claims 12-20 are rejected under the same rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Devin C. Hein whose telephone number is (303)297-4305. The examiner can normally be reached 9:00 AM - 5:00 PM M-F MDT.
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, Jason B. Dunham can be reached at (571) 272-8109. 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.
/DEVIN C HEIN/Examiner, Art Unit 3686