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 Claims
This action is in reply to the communication filed on 12/08/2025.
Claims 1, 5, and 13-14 have been amended.
Claims 1-20 are currently pending and have been examined.
This action is made final.
Objections
The file wrapper is missing a signed inventor’s oath/declaration of invention from the inventors.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. § 101 as being directed to a judicial exception (i.e. a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1 Analysis:
Independent Claims 1, 5, and 13 are within the four statutory categories. Claims 1, 5, and 13 are directed toward a method, system, and non-transitory computer-readable medium (i.e. machine) respectively. Dependent Claims 2-4, 5-12, and 14-20 are also directed toward a method, system, and non-transitory computer-readable medium and therefore also fall into one of the four statutory categories.
Step 2A Analysis – Prong One:
Claim 1, which is indicative of the inventive concept, recites the following:
A computer-implemented method, comprising: providing, by a first agent of a computing resources service provider, a request to process an electronic record associated with a user;
generating, by a second agent, a single-use distinct identifier associated with the user, the single-use distinct identifier being a cryptographic key;
storing a first entry to a node of a decentralized network without including personal identifiable information (PII) of the user, the first entry comprising the single-use distinct identifier that replaces the PII;
causing the second agent of the computing resources service provider, as a result of causing the second agent to receive a notification of the electronic record, to assign a provider to fulfill the request;
storing a second entry to the node, the second entry comprising an assignment of the provider to fulfill the request;
causing a third agent of the computing resources service provider to request, from the second agent, the PII of the user;
as a result of verifying, by the second agent, that the third agent is authorized to access the PII, causing the second agent to provide the PII to the third agent;
and causing the third agent to process the electronic record in completion of the request.
The limitations as shown in underline above, given the broadest reasonable interpretation, cover the abstract idea of certain methods of organizing human activity because they recite managing personal behavior or relationships or interactions between people (i.e. social activities, teachings, and following rules or instructions- in this case, the steps of providing a request to process a record, generating an identifier, storing an entry, and verifying authorizations), e.g., see MPEP 2106.04(a)(2). Any limitations not identified above as part of the abstract idea are deemed “additional elements” and will be discussed in further detail below.
Dependent Claims 2, 4, 7-12, 14, and 16-20 include other limitations directed toward the abstract idea. For example, Claim 2 recites providing the PII, Claim 4 recites the first entry is stored and includes data associated with the user, Claim 7 recites de-identifying information associated with the PII of the user, Claim 8 recites the registration information is usable to identify an association, Claim 9 recites the request comprises the address of the node, Claim 10 recites the request comprises information from a record, Claim 11 recites verifying authorization to access PII and then providing the PII, Claim 12 recites the being managed by a provider service, Claim 14 recites the providing PII, Claim 16 recites the processing the record and storing at least a third entry, Claim 17 recites notifying an agent, Claim 18 recites causing receiving a notification of a change in services, Claim 19 recites providing PII to the third agent upon verification that the provider was assigned to fulfill the request, Claim 20 recites the updating the record to include a status of the request being fulfilled. These limitations only serve to further narrow the abstract idea, and a claim may not preempt abstract ideas, even if the judicial exception is narrow, e.g. see MPEP 2106.04. Additionally, any limitations in the dependent claims not addressed above are part of the additional elements and will be further addressed below. Hence, dependent Claims 2, 4, 7-12, 14, and 16-20 are nonetheless directed toward fundamentally the same abstract idea as the independent claims.
Step 2A Analysis – Prong One:
Claims 1, 5, and 13 are not integrated into practical application because the additional elements (i.e. the non-underlined limitations above- in this case, the first agent, second agent, third agent, electronic record, cryptographic key, and node of a decentralized network of Claim 1, the processors, memory, first agent, second agent, third agent, electronic record, cryptographic key, and node of a decentralized network of Claim 5, and the non-transitory computer-readable storage medium, processors, first agent, second agent, third agent, electronic record, and node of a decentralized network of Claim 13) are recited at a high level of generality (i.e. as a generic processor performing generic computer functions) such that they amount to no more than mere instructions to apply an exception using generic computer parts. For example, Applicant’s specification explains that the patient agent 106 may be a software agent that acts on behalf of a patient, such as user 102, on a blockchain. In some embodiments, this patient agent 106 may comprise software or a software agent that operates in a cloud computing, Internet- based, computing resources service provider that may be associated with a healthcare business entity. In at least one embodiment, a patient agent 106 may comprise a plurality of patient agents (see Applicant’s specification, ¶ 0033). These application modules or instructions can be executed by the one or more processors 702. In various embodiments, the storage subsystem 706 additionally provides a repository for storing data used in accordance with the present disclosure. In some embodiments, the storage subsystem 706 comprises a memory subsystem 708 and a file/disk storage subsystem 710 [0106]. The key wallet 112, also known as a cryptographic key wallet or cryptocurrency wallet, may comprise public addresses and private cryptographic keys, messages, and files and/or directories and metadata for the files and/or directories [0036]. A prescriber agent, such as prescriber agent 204, may provide a request to process an electronic record, such as EHR 114 in FIG. 1, associated with a patient, such as patient 202 in FIG. 2 and user 102 in FIG. 1 [0074]. As an example, a digital medical prescription may be processed by a computing node of a healthcare information system that may receive a new prescription from a prescriber, receive PII and a single-use public key to identify a patient…[0026]. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into practical application because they do not impose any meaningful limits on the abstract idea. Therefore, independent Claims 1, 5, and 13 are directed to an abstract idea without practical application.
Dependent Claims 2-4, 6, 8-12, and 14-20 also recite additional elements, but
these limitations amount to no more than mere instructions to apply an exception. Claim 2 recites a new additional element of a data storage and the previously recited cryptographic key and second agent and specifies the second agent provides the PII and the cryptographic key that is stored in a data storage. Claim 3 recites the electronic record and third agent and a new element of a combined record and specifies the third agent processes the electronic record with the PII to create a combined electronic record. Claim 4 recites the previously recited node and electronic record and specifies the first entry is stored to the node and includes at least a hash of an electronic record associated with a user. Claim 6 recites the previously recited cryptographic key and new elements of a public key and a public-private key and specifies the cryptographic key is a public key of a public-private pair. Claim 8 recites the second software agent and a new element of a software agent collection of records and specifies registration information of the second agent is stored in a software agent collection of records, the software agent collection of records being usable by the first agent to identify that the second agent is associated with the user. Claim 9 recites the node and specifies the request comprises an address of the node. Claim 10 recites the electronic record and a new element of a token and specifies the request comprises information from a record to combine with the electronic record, the information usable to generate a token and verify that the token is associated with the second agent, the record, and the PII. Claim 11 recites previously recited additional elements of the electronic record, second agent, and third agent and specifies the entity processes the electronic record by causing the second agent to verify that the third agent is authorized to access the PII. Claim 12 recites the second agent and computing resource service provider and specifies the second agent is managed by a provider service as a shared service of a plurality of users of a computing resource service provider. Claim 14 recites previously recited elements of the second and third software agent, data storage, and a new element of a private database record, and Claim 14 specifies the second agent provides the PII to the third agent by accessing a data storage that includes a private database record of the user that links the single-use distinct identifier with an identifier of the PII. Claim 15 recites previously recited elements of the note and electronic record and states the first entry is stored to the node and includes at least a hash of an original electronic record. Claim 16 recites the previously recited electronic record and the node and specifies the third software agent processes the electronic record, on behalf of the provider, by at least storing a third entry to the node. Claim 17 recites previously recited additional element of the computer system, first software agent, and the electronic record and recites causing the node to notify the first software agent that the electronic record has been processed. Claim 18 recites the previously recited electronic record second software agent, and third software agent and specifies receiving a request to process an additional electronic record, causing the second agent to receive a notification of a change, and causing the third agent to fulfill the request. Claim 19 recites the previously recited second and third agent the second agent provides the PII to the third agent upon verification. Claim 20 recites previously recited computer system, electronic record, third agent, and node and specifies causing the computer to cause the third agent to update the electronic record to include a status of the request being fulfilled on the node. However, these additional elements are described only at a high level of generality and are being used in their expected fashion, so these additional elements do not integrate the abstract idea into a practice application because they do not impose any meaningful limits on the abstract idea. These additional elements amount to no more than mere instructions to apply an exception, and hence, do not integrate the aforementioned abstract idea into practical application.
Step 2B Analysis:
The claims, whether considered separately or as an ordered combination, do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional elements of the first agent, second agent, third agent, electronic record, cryptographic key, and node of a decentralized network of Claim 1, the processors, memory, first agent, second agent, third agent, electronic record, cryptographic key, and node of a decentralized network of Claim 5, and the non-transitory computer-readable storage medium, processors, first agent, second agent, third agent, electronic record, and node of a decentralized network of Claim 13 amount to no more than mere instructions to apply an exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept (“significantly more”). MPEP 2106.05(I)(A) indicates that merely stating “apply it” or equivalent to the abstract idea cannot provide an inventive concept (“significantly more”). Accordingly, even in combination, these additional elements do not provide significantly more. As such, Claims 1, 5, and 13 are not patent eligible.
Dependent Claim 7 does not recite any additional elements and only narrows the abstract idea by specifying the system de-identifies information associated with personal identifiable information of the user.
Dependent Claims 2-3, 6, 8, 10, and 14 recite a new additional element. Claim 2 recites a data storage. Claim 2 recites a new additional element of a data storage and the previously recited cryptographic key and second agent and specifies the second agent provides the PII and the cryptographic key that is stored in a data storage. Claim 3 recites the electronic record and third agent and a new element of a combined record and specifies the third agent processes the electronic record with the PII to create a combined electronic record. Claim 6 recites the previously recited cryptographic key and new elements of a public key and a public-private key and specifies the cryptographic key is a public key of a public-private pair. Claim 8 recites the second software agent and a new element of a software agent collection of records and specifies registration information of the second agent is stored in a software agent collection of records, the software agent collection of records being usable by the first agent to identify that the second agent is associated with the user. Claim 10 recites the electronic record and a new element of a token and specifies the request comprises information from a record to combine with the electronic record, the information usable to generate a token and verify that the token is associated with the second agent, the record, and the PII. Claim 14 recites previously recited elements of the second and third software agent, data storage, and a new element of a private database record, and Claim 14 specifies the second agent provides the PII to the third agent by accessing a data storage that includes a private database record of the user that links the single-use distinct identifier with an identifier of the PII.
Dependent Claims 4, 9, 11-12, 15-20 narrow previously recited additional elements. Claim 4 recites the previously recited node and electronic record and specifies the first entry is stored to the node and includes at least a hash of an electronic record associated with a user. Claim 9 recites the node and specifies the request comprises an address of the node. Claim 11 recites previously recited additional elements of the electronic record, second agent, and third agent and specifies the entity processes the electronic record by causing the second agent to verify that the third agent is authorized to access the PII. Claim 12 recites the second agent and computing resource service provider and specifies the second agent is managed by a provider service as a shared service of a plurality of users of a computing resource service provider. Claim 15 recites previously recited elements of the note and electronic record and states the first entry is stored to the node and includes at least a hash of an original electronic record. Claim 16 recites the previously recited electronic record and the node and specifies the third software agent processes the electronic record, on behalf of the provider, by at least storing a third entry to the node. Claim 17 recites previously recited additional element of the computer system, first software agent, and the electronic record and recites causing the node to notify the first software agent that the electronic record has been processed. Claim 18 recites the previously recited electronic record second software agent, and third software agent and specifies receiving a request to process an additional electronic record, causing the second agent to receive a notification of a change, and causing the third agent to fulfill the request. Claim 19 recites the previously recited second and third agent the second agent provides the PII to the third agent upon verification. Claim 20 recites previously recited computer system, electronic record, third agent, and node and specifies causing the computer to cause the third agent to update the electronic record to include a status of the request being fulfilled on the node. Hence, Claims 1-20 do not include any additional elements that amount to “significantly more” than the judicial exception.
Thus, taken alone, the additional elements do not amount to significantly more than the abstract idea identified above. Furthermore, looking at the limitations as an ordered combination does not add anything that is already present when looking at the elements taken individually, and there is no indication that the combination of elements improves the functioning of computer implementation.
Therefore, whether taken individually or as an ordered combination, Claims 1-20 are nonetheless rejected under 35 U.S.C 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
Claims 1-2, 4, 6, 8-9, and 11-19 are rejected under 35 USC § 103 as being unpatentable over Austríng et al. (US 20200402629 A1) in view of Caswell et al. (US 20070005536 A1), Tran et al. (US 20200101367 A1), and Smets et al. (US 20180240111 A1).
Regarding Claim 1, Austríng discloses the following:
A computer-implemented method, comprising: providing, by a first agent of a computing resources service provider, a request to process an electronic record associated with a user; (Austríng discloses a method of providing blockchain-based electronic health record data patient transactions, the method implemented by a server system comprising one or more processors executing computer program instructions that, when executed, perform the method [0034]. Users can review their pharmacy and clinical data,…or request prescription refills [0098]. The user/patient is interpreted as a first agent (see ¶ 0004-5 of Applicant’s specification, which states that the agents may be a software, but does not specify the agent cannot be a human.))
generating, by a second agent, a distinct identifier associated with the user, the distinct identifier being a cryptographic key; (Austríng discloses the EHR Data API 110 can return a single purpose patient ID (SPPID) 224 to the client computer system [0062]. Each node can contain specific information (e.g., patient name, address, medication, etc.) in the graph/hierarchy that can be encrypted with its own encryption key [0152]. The EHR Data API is interpreted as the second agent.)
storing a first entry to a node of a decentralized network without including personal identifiable information (PII) of the user, the first entry comprising the distinct identifier that replaces the PII; (Austríng discloses no patient identifiable information will be stored in the EHR patient transaction blockchain in order to assure the anonymity of the patient data. Instead, when a new blockchain transaction is initiated by an entity for a particular patient, the EHR database can be queried to determine if the patient already has a record in the database. If the patient has a record in the EHR database, a Single Purpose Patient ID (SPPID) can be generated and returned to the requesting entity. The SPPID can be used instead of patient identifiable information [0009]. The initial network structure can include various nodes, located in various locations, designed to provide maximum throughput for distributed applications connected to the network [0011].)
storing a second entry to the node, (Austríng discloses the initial network structure can include various nodes, located in various locations, designed to provide maximum throughput for distributed applications connected to the network. By recording all prescription transactions on the blockchain …government and law enforcement agencies can have a national view of all prescription data [0011]. All data can be stored on the blockchain as a graph/hierarchy structure. Each node can contain specific information (e.g., patient name, address, medication, etc.) in the graph/hierarchy that can be encrypted with its own encryption key [0152].)
and causing the third agent to process the electronic record in completion of the request. (Austríng discloses the prescription can be finalized once the fulfillment option has been determined…The pharmacy provider or application 258 can be notified by the EHR Blockchain API 275 of a new transaction 280, such as a prescription transaction. The pharmacy provider 258 can retrieve the prescription information from the blockchain prescription transaction 280 to select the drug, the NDC the pharmacy wants to dispense from, or the drug price, among other selections. In another exemplary embodiment, the pharmacy provider 258 can write a modified prescription record 260 to the blockchain prescription transaction 280, through the EHR Blockchain API 275, indicating the selected drug, the NDC, and the drug price, related to the prescription [0069]. The pharmacy provider is interpretted as the third agent.)
Austríng does not disclose the second agent assigning a provider which is met by Caswell:
causing the …agent of the computing resources service provider, as a result of causing the … agent to receive a notification of the electronic record, to assign a provider to fulfill the request; (Caswell teaches a third aspect of the present invention provides a program product stored on a computer useable medium for managing a request for a customer, the computer useable medium comprising program code for causing a computer to perform the following functions: receive the request at an application; define a delivery task list comprising one or more tasks required to fulfill the request; assign a service provider to perform each of the one or more tasks; [0009].)
the…entry comprising the assignment of the provider to fulfill the request; (Caswell teaches the computer software comprising instructions for causing a computer system to perform the following functions: receive the request at an application;…[0010-110].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record as disclosed by Austríng to incorporate assigning a provider to fulfill the request as taught by Caswell. This modification would create a system and methods capable of automating the process of providing management without high levels of human interaction (see Caswell, ¶ 0002).
Austríng and Caswell do not teach the verification of an agent prior to providing access to information which is met by Tran:
causing a third agent of the computing resources service provider to request, from the second agent, the PII of the user; (Tran teaches a first request message is received in real-time on the first cloud application stored on the cloud server network device with the one or more processors from a second cloud application. The first request message includes a request for desired cloud electronic content stored in the plural cloud storage objects…[0094].)
as a result of verifying, by the second agent, that the third agent is authorized to access the PII, causing the second agent to provide the PII to the third agent; (Tran teaches such participants may request registration of their digital identity which links their real-world identity with their blockchain-based digital identity, thus allowing them to interact with the blockchain using their real-world identity. Upon request, the registration authority verifies their identity and records the result in the blockchain, available for all to inspect [0145].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record as disclosed by Austríng to incorporate verifying a second party’s authorization and providing access to information following verification as taught by Tran. This modification would create a system and methods capable of facilitating secure operation on a blockchain (see Tran, ¶ 0049).
Austríng, Caswell, and Tran do not teach the distinct identifier being single-use which is met by Smets:
…a single-use distinct identifier… (Smets teaches the first cryptographic material may comprise cryptographic keys. The cryptographic keys may comprise one or more of one or more single use keys and a long term use key [0015].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record as disclosed by Austríng to incorporate distinct identifier being single-use as taught by Tran. This modification would create a system and methods capable of providing effective use and management of cryptographic keys (see Smets, ¶ 0007).
Regarding Claim 13, this claim recites limitations that are substantially similar to those recited in Claim 1 above; thus, the same rejection applies. Austríng further discloses the following:
A non-transitory computer-readable storage medium storing thereon executable instructions that, as a result of being executed by one or more processors of a computer system, (Austríng discloses memory 106 can comprise electronic storage that can include non-transitory storage media that electronically stores information. Electronic storage can store machine-readable instructions, software algorithms, algorithms… and/or other information that enables server(s) to function [0044].)
Austríng does not disclose the following limitation met by Tran:
a software agent (Tran teaches FIG. 14A shows an exemplary smart contract agent running in electronic agents that carry out transactions… An agent is an autonomous software entity that is situated in some environment where it can monitor and response to changes proactively or reactively by itself or through communication with other agents to persistently achieve certain goal/task on behalf of user or other agents. These agents can form contract with other agents and use the smart contract framework discussed above for ensuring certainty in executing their tasks [0283, see also Fig. 14A]. The smart contract agent is interpreted as a software agent.)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record using three agents as disclosed by Austríng to incorporate the agents being software agents as taught by Tran. This modification would create a system and methods which can optimize cost or operational efficiency (see Tran, ¶ 0287).
Regarding Claim 2, Austríng, Caswell, Tran, and Smets teach the limitations as seen in the rejection of Claim 1 above. Austríng discloses the following:
wherein the second agent provides the PII and the cryptographic key that is stored in a data storage, the cryptographic key being usable to identify the user. (Austríng discloses all data can be stored on the blockchain…each node can contain specific information (e.g., patient name, address, medication, etc.) in the graph/hierarchy that can be encrypted with its own encryption key [0152]. The patient specific information is interpretted as the PII.)
Regarding Claim 4, Austríng, Caswell, Tran, and Smets teach the limitations as seen in the rejection of Claim 1 above. Austríng discloses the following:
…wherein the first entry is stored to the node and… (Austríng discloses the SPPID can be used instead of patient identifiable information [0009]. The initial network structure can include various nodes, located in various locations, designed to provide maximum throughput for distributed applications connected to the network [0011].)
Austríng and Caswell do not teach the inclusion of a hash into the node which is taught by Tran:
includes at least a hash of an original electronic record associated with the user. (Tran teaches Provider 2 may insert an entry for Provider 1 into its address resolution table for future use. Provider 1 caches the response information in its table and can now pull information from Provider 2 and/or supplement the information known to Provider 2 with hashed addresses to storage areas controlled by Provider 1 [0191].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record using three agents as disclosed by Austríng to incorporate the entry being stored on a hash of the record associated with a user as taught by Tran. This modification would create a system and methods which can prevent fraudulent and harmful activities from arising (see Tran, ¶ 0004).
Regarding Claim 15, this claim recites limitations that are substantially similar to Claim 4 above; thus, the same rejection applies.
Regarding Claim 6, Austríng, Caswell, and Smets teach the limitations as seen in the rejection of Claim 5 above. Austríng further discloses:
wherein the cryptographic key…(Austríng discloses the EHR Data API 110 can return a single purpose patient ID (SPPID) 224 to the client computer system [0062]. Each node can contain specific information (e.g., patient name, address, medication, etc.) in the graph/hierarchy that can be encrypted with its own encryption key [0152].)
Austríng, Caswell, and Smets do not teach the following limitation met by Tran:
…is a public key of a public-private key pair. (Tran teaches each identifier is a public-private key pair [0179].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record using three agents as disclosed by Austríng to incorporate the cryptographic key being a public-private pair as taught by Tran. This modification would create a system and methods which can prevent fraudulent and harmful activities from arising (see Tran, ¶ 0004).
Regarding Claim 8, Austríng, Caswell, Tran, and Smets teach the limitations as seen in the rejection of Claim 5 above. Austríng further discloses:
…the second agent…the first agent (Austríng discloses the EHR Data API 110 can return a single purpose patient ID (SPPID) 224 to the client computer system [0062]. Each node can contain specific information (e.g., patient name, address, medication, etc.) in the graph/hierarchy that can be encrypted with its own encryption key [0152]. The EHR Data API is interpretted as the second agent. Users can review their pharmacy and clinical data,…or request prescription refills [0098].)
Austríng and Cashwell do not teach the following limitations met by Tran:
wherein registration information…is stored in a software agent collection of records, the software agent collection of records being usable…to identify that the…agent is associated with the user. (Tran teaches the system supports the registration of named participants (i.e. certifiers, auditors, producers, and manufacturers). Such participants may request registration of their digital identity which links their real-world identity with their blockchain-based digital identity, thus allowing them to interact with the blockchain using their real-world identity. Upon request, the registration authority verifies their identity and records the result in the blockchain, available for all to inspect [0145].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record using three agents as disclosed by Austríng to incorporate providing registration information associated with the users as taught by Tran. This modification would create a system and methods which can prevent fraudulent and harmful activities from arising (see Tran, ¶ 0004).
Regarding Claim 9, Austríng, Caswell, and Smets teach the limitations as seen in the rejection of Claim 5 above. Austríng further discloses:
wherein the request…(Austríng discloses users can review their pharmacy and clinical data,…or request prescription refills [0098].)
Austríng and Cashwell do not teach the following limitations met by Tran:
…comprises an address of the node. (Tran teaches the transaction 303 includes the recipient's address 324 (e.g., a hash value based on the receiver's public key), the Blockchain token 309 (i.e., a stock ID 328 and its position 326), past ownership information 331 (if any), and optional other information 310 [0140].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for receiving a request to process a record, generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record using three agents as disclosed by Austríng to incorporate utilizing the address of the node as taught by Tran. This modification would create a system and methods which can prevent fraudulent and harmful activities from arising (see Tran, ¶ 0004).
Regarding Claim 11, Austríng, Caswell, and Smets teach the limitations as seen in the rejection of Claim 7 above. Austríng further discloses:
second agent…the third agent…(Austríng discloses the EHR Data API 110 can return a single purpose patient ID (SPPID) 224 to the client computer system [0062]. Each node can contain specific information (e.g., patient name, address, medication, etc.) in the graph/hierarchy that can be encrypted with its own encryption key [0152]. The EHR Data API is interpretted as the second agent. The pharmacy provider 258 can retrieve the prescription information from the blockchain prescription transaction 280 to select the drug, the NDC the pharmacy wants to dispense from, or the drug price, among other selections. In another exemplary embodiment, the pharmacy provider 258 can write a modified prescription record 260 to the blockchain prescription transaction 280, through the EHR Blockchain API 275, indicating the selected drug, the NDC, and the drug price, related to the prescription [0069]. The pharmacy provider is interpretted as the third agent.)
Austríng and Cashwell do not teach the following limitations met by Tran:
wherein the entity processes the electronic record as a result of: causing the [second] agent to verify that a third agent is authorized to access the PII of the user, the [third] agent acting on behalf of the entity; (Tran teaches a first request message is received in real-time on the first cloud application stored on the cloud server network device with the one or more processors from a second cloud application. The first request message includes a request for desired cloud electronic content stored in the plural cloud storage objects…[0094].)
and causing the [second] agent to provide the PII to the [third] agent. (Tran teaches such participants may request registration of their digital identity which links their real-world identity with their blockchain-based digital identity, thus allowing them to interact with the blockchain using their real-world identity. Upon request, the registration authority verifies their identity and records the result in the blockchain, available for all to inspect [0145].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record as disclosed by Austríng to incorporate verifying a second party’s authorization and providing access to information following verification as taught by Tran. This modification would create a system and methods capable of facilitating secure operation on a blockchain (see Tran, ¶ 0049).
Regarding Claim 12, Austríng, Caswell, Tran, and Smets teach the limitations as seen in the rejection of Claim 7 above. Austríng further discloses:
wherein the second agent… as a shared service of a plurality of users of a computing resource service provider (Austríng teaches FIG. 2 shows a schematic view of an electronic health record data blockchain system transaction, in accordance with one or more exemplary embodiments of the present disclosure. The EHR data blockchain system 200 can include and an Electronic Health Record (EHR) system 204 including electronic health records 226 for a plurality of patients stored in an EHR database 202 [0057, Fig. 2].)
Austríng and Caswell do not teach the management of the agent by a provider service which is met by Tran:
…is managed by a provider service…(Tran teaches the blockchain address may be controlled and/or managed by a third party embedding service provider [0121].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record as disclosed by Austríng to incorporate the agent being managed by the service provider as taught by Tran. This modification would create a system and methods capable of facilitating secure operation on a blockchain (see Tran, ¶ 0049).
Regarding Claim 14, Austríng, Caswell, Tran, and Smets teach the limitations as seen in the rejection of Claim 13 above. Austríng further discloses:
wherein the second software agent provides the PII to the third software agent by at least accessing a data storage that includes a private database record of the user that links the distinct identifier with an identifier of the PII. (Austríng discloses a patient’s private information, including the patient's name, address, phone number, social security number, insurance information, medical history, clinical information, and other relevant information, can be stored in an Electronic Health Record (EHR) database, such as an Electronic Patient Outcome Record (EPOR), Solid POD, XML file, or other suitable data storage element. Advantageously, no patient identifiable information will be stored in the EHR patient transaction blockchain in order to assure the anonymity of the patient data. Instead, when a new blockchain transaction is initiated by an entity for a particular patient, the EHR database can be queried to determine if the patient already has a record in the database. If the patient has a record in the EHR database, a Single Purpose Patient ID (SPPID) can be generated and returned to the requesting entity [0009].)
Austríng and Caswell do not teach providing of the PII to the new agent as well as the implementation of software agents which are taught by Tran:
wherein the [second] software agent provides the PII to the [third] software agent (Tran teaches such participants may request registration of their digital identity which links their real-world identity with their blockchain-based digital identity, thus allowing them to interact with the blockchain using their real-world identity. Upon request, the registration authority verifies their identity and records the result in the blockchain, available for all to inspect [0145].)
…software agent… (Tran teaches FIG. 14A shows an exemplary smart contract agent running in electronic agents that carry out transactions… An agent is an autonomous software entity that is situated in some environment where it can monitor and response to changes proactively or reactively by itself or through communication with other agents to persistently achieve certain goal/task on behalf of user or other agents. These agents can form contract with other agents and use the smart contract framework discussed above for ensuring certainty in executing their tasks [0283, see also Fig. 14A]. The smart contract agent is interpreted as a software agent.)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record as disclosed by Austríng to incorporate verifying a second party’s authorization and providing access to information following verification as taught by Tran. This modification would create a system and methods capable of facilitating secure operation on a blockchain (see Tran, ¶ 0049).
Regarding Claim 16, Austríng, Caswell, Tran, and Smets teach the limitations as seen in the rejection of Claim 13 above. Austríng further discloses:
wherein the third software agent processes the electronic record, on behalf of the provider, by at least storing a third entry to the node. (Austríng discloses the pharmacy provider or application 258 can be notified by the EHR Blockchain API 275 of a new or modified transaction 280, such as a prescription transaction. The pharmacy provider can retrieve the prescription information from the blockchain prescription transaction 280…. The pharmacy provider can write a price paid record 268 to the blockchain prescription transaction, through the EHR blockchain API, indicating the drug and final price paid. Additionally, this record can be a smart contract that executes, given certain conditions, to effect a specific outcome, such as indicating the final payment amount paid. The SPPID 224 can be stored along with the record 268 [0073].)
Regarding Claim 17, Austríng, Caswell, Tran, and Smets teach the limitations as seen in the rejection of Claim 13 above. Austríng further discloses:
wherein the executable instructions further comprise…(Austríng discloses the method implemented by a server system comprising one or more processors executing computer program instructions that, when executed, perform the method [0034].)
instructions that cause the computer system to cause the node…that the electronic record has been processed. (Austríng discloses once a transaction 280 is completed, the SPPID 224 can only be used to read information, associated with the transaction, from the blockchain 125 [0063]. This is interpreted as conducting an action when the process is completed.)
…first…agent (Austríng discloses a method of providing blockchain-based electronic health record data patient transactions, the method implemented by a server system comprising one or more processors executing computer program instructions that, when executed, perform the method [0034]. Users can review their pharmacy and clinical data,…or request prescription refills [0098]. The user/patient is interpretted as a first agent.)
Austríng does not disclose notifying the patient agent when the process is complete which is met by Caswell:
notify…that the…has been processed (Caswell teaches notifying the customer upon completion of the one or more tasks [0007].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record as disclosed by Austríng to incorporate notifying the patient agent when the process is complete as taught by Caswell. This modification would create a system and methods capable of automating the process of providing management without high levels of human interaction (see Caswell, ¶ 0002).
Austríng and Caswell do not teach the agents being software agents which is met by Tran:
the…software agent (Tran teaches FIG. 14A shows an exemplary smart contract agent running in electronic agents that carry out transactions… An agent is an autonomous software entity that is situated in some environment where it can monitor and response to changes proactively or reactively by itself or through communication with other agents to persistently achieve certain goal/task on behalf of user or other agents. These agents can form contract with other agents and use the smart contract framework discussed above for ensuring certainty in executing their tasks [0283, see also Fig. 14A]. The smart contract agent is interpretted as a software agent.)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record as disclosed by Austríng to incorporate verifying a second party’s authorization and providing access to information following verification as taught by Tran. This modification would create a system and methods capable of facilitating secure operation on a blockchain (see Tran, ¶ 0049).
Regarding Claim 18, Austríng, Caswell, Tran, and Smets teach the limitations as seen in the rejection of Claim 13 above. Austríng further discloses:
wherein the executable instructions further include instructions that further cause the computer system to: receive a subsequent request to process an additional electronic record associated with the user; (Austríng discloses the third-party databases 106 can include an electronic medical record system (EMR), an Electronic Patient Outcome Record (EPOR) database, pharmacy databases, a plurality of patient databases,… the third-party databases can function as archival nodes. The archival nodes can keep a real-time …encrypted copy of the distributed ledger 125. The archival node can provide fault tolerance and makes the contents of the distributed ledger 125 readily available to a host so that additional data processing, reporting, and analytics can be achieved [0055].)
and if the second…agent, acting on behalf of the user, (Austríng discloses the EHR Data API 110 can return a single purpose patient ID (SPPID) 224 to the client computer system [0062]. Each node can contain specific information (e.g., patient name, address, medication, etc.) in the graph/hierarchy that can be encrypted with its own encryption key [0152]. The EHR Data API is interpretted as the second agent.)
…does not request a different provider, cause the third…agent to fulfill the subsequent request with the provider. (Austríng discloses the prescription can be finalized once the fulfillment option has been determined, such that the patient can go to a pharmacy to fill the prescription. The pharmacy provider or application 258 can be notified by the EHR Blockchain API 275 of a new transaction 280, such as a prescription transaction. The pharmacy provider 258 can retrieve the prescription information from the blockchain …the pharmacy provider 258 can write a modified prescription record 260 to the blockchain prescription transaction 280, through the EHR Blockchain API 275, indicating the selected drug, the NDC, and the drug price, related to the prescription [0069].)
Austríng does not disclose the following limitations met by Caswell:
as a result of the provider being assigned to fulfill the request, (Caswell teaches a third aspect of the present invention provides a program product stored on a computer useable medium for managing a request for a customer, the computer useable medium comprising program code for causing a computer to perform the following functions: receive the request at an application; define a delivery task list comprising one or more tasks required to fulfill the request; assign a service provider to perform each of the one or more tasks; [0009].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record as disclosed by Austríng to incorporate assigning a provider to fulfill the request as taught by Caswell. This modification would create a system and methods capable of automating the process of providing management without high levels of human interaction (see Caswell, ¶ 0002).
Austríng and Caswell do not teach the following limitations met by Tran:
…software agent…(Tran teaches FIG. 14A shows an exemplary smart contract agent running in electronic agents that carry out transactions… An agent is an autonomous software entity that is situated in some environment where it can monitor and response to changes proactively or reactively by itself or through communication with other agents to persistently achieve certain goal/task on behalf of user or other agents. These agents can form contract with other agents and use the smart contract framework discussed above for ensuring certainty in executing their tasks [0283, see also Fig. 14A]. The smart contract agent is interpretted as a software agent.)
…cause the second…agent to receive a notification of a change in services associated with the provider; (Tran teaches patients can…be notified whenever a new relationship is suggested or an update is available [0190]. The third party is automatically notified of new permissions, and can follow the link to discover all information needed for retrieval [0194].)
Regarding Claim 19, Austríng, Caswell, Tran, and Smets teach the limitations as seen in the rejection of Claim 13 above. Austríng further discloses:
second agent…third agent……(Austríng discloses the EHR Data API 110 can return a single purpose patient ID (SPPID) 224 to the client computer system [0062]. Each node can contain specific information (e.g., patient name, address, medication, etc.) in the graph/hierarchy that can be encrypted with its own encryption key [0152]. The EHR Data API is interpretted as the second agent. The pharmacy provider 258 can retrieve the prescription information from the blockchain prescription transaction 280 to select the drug, the NDC the pharmacy wants to dispense from, or the drug price, among other selections. In another exemplary embodiment, the pharmacy provider 258 can write a modified prescription record 260 to the blockchain prescription transaction 280, through the EHR Blockchain API 275, indicating the selected drug, the NDC, and the drug price, related to the prescription [0069]. The pharmacy provider is interpretted as the third agent.)
Austríng and Caswell do not teach the agents being software agents which is met by Tran:
the…software agent (Tran teaches FIG. 14A shows an exemplary smart contract agent running in electronic agents that carry out transactions… An agent is an autonomous software entity that is situated in some environment where it can monitor and response to changes proactively or reactively by itself or through communication with other agents to persistently achieve certain goal/task on behalf of user or other agents. These agents can form contract with other agents and use the smart contract framework discussed above for ensuring certainty in executing their tasks [0283, see also Fig. 14A]. The smart contract agent is interpretted as a software agent.)
wherein the [second]…agent provides the PII to the [third]…agent upon verification that the provider was assigned to fulfill the request, the third software agent acting on behalf of the provider. (Tran teaches such participants may request registration of their digital identity which links their real-world identity with their blockchain-based digital identity, thus allowing them to interact with the blockchain using their real-world identity. Upon request, the registration authority verifies their identity and records the result in the blockchain, available for all to inspect [0145].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record as disclosed by Austríng to incorporate verifying a second party’s authorization and providing access to information following verification as well as the agents being software agents as taught by Tran. This modification would create a system and methods capable of facilitating secure operation on a blockchain (see Tran, ¶ 0049).
Claim 3 is rejected under 35 USC § 103 as being unpatentable over Austríng, Caswell, Tran, and Smets in view of Yu et al. (US 20110112970 A1).
Regarding Claim 3, Austríng, Caswell, Tran, and Smets teach the limitations as seen in the rejection of Claim 1 above. Austríng further discloses:
wherein the third agent processes the electronic record… (Austríng discloses the prescription can be finalized once the fulfillment option has been determined, such that the patient can go to a pharmacy to fill the prescription. The pharmacy provider or application 258 can be notified by the EHR Blockchain API 275 of a new transaction 280, such as a prescription transaction. The pharmacy provider 258 can retrieve the prescription information from the blockchain prescription transaction 280 to select the drug, the NDC the pharmacy wants to dispense from, or the drug price, among other selections. In another exemplary embodiment, the pharmacy provider 258 can write a modified prescription record 260 to the blockchain prescription transaction 280, through the EHR Blockchain API 275, indicating the selected drug, the NDC, and the drug price, related to the prescription [0069].)
Austríng, Caswell, Tran, and Smets do not teach the following limitations met by Yu:
…by at least combining the electronic record with the PII to create a combined electronic record, the combined electronic record being verifiably equivalent to an original electronic record that includes the PII…(Yu teaches the health record and the III [identifiable individual information] information is then combined for display, typically as a single record [0060].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record as disclosed by Austríng to incorporate combining the electronic record with PII as taught by Yu. This modification would create a system and methods which can help a healthcare provider track a patient’s health status while remaining secure (see Yu, ¶ 0004).
Claims 5 and 7 are rejected under 35 USC § 103 as being unpatentable over Austríng et al. (US 20200402629 A1) in view of Caswell et al. (US 20070005536 A1) and Smets et al. (US 20180240111 A1).
Regarding Claim 5, Austríng discloses the following:
A system, comprising: one or more processors; and memory that stores computer-executable instructions that, if executed, cause the one or more processors to: (Austríng discloses the server 102 can include one or more processors (or cores) 104, a memory 106, and machine-readable instructions 108 [0042].)
send, by a first agent, a request to process an electronic record associated with a user; (Austríng discloses users can review their pharmacy and clinical data,…or request prescription refills [0098].)
cause, a second agent, to generate a…distinct identifier of the user, the distinct identifier being a cryptographic key; (Austríng discloses the EHR Data API 110 can return a single purpose patient ID (SPPID) 224 to the client computer system [0062]. Each node can contain specific information (e.g., patient name, address, medication, etc.) in the graph/hierarchy that can be encrypted with its own encryption key [0152].)
add a first entry to a node of a decentralized network, the first entry comprising the distinct identifier; (Austríng discloses no patient identifiable information will be stored in the EHR patient transaction blockchain in order to assure the anonymity of the patient data. Instead, when a new blockchain transaction is initiated by an entity for a particular patient, the EHR database can be queried to determine if the patient already has a record in the database. If the patient has a record in the EHR database, a Single Purpose Patient ID (SPPID) can be generated and returned to the requesting entity. The SPPID can be used instead of patient identifiable information [0009]. The initial network structure can include various nodes, located in various locations, designed to provide maximum throughput for distributed applications connected to the network [0011].)
add, by the second agent, a second entry to the node, (Austríng discloses the initial network structure can include various nodes, located in various locations, designed to provide maximum throughput for distributed applications connected to the network. By recording all prescription transactions on the blockchain… government and law enforcement agencies can have a national view of all prescription data [0011]. All data can be stored on the blockchain as a graph/hierarchy structure. Each node can contain specific information (e.g., patient name, address, medication, etc.) in the graph/hierarchy that can be encrypted with its own encryption key [0152].)
Austríng does not disclose assigning a provider which is met by Caswell:
cause the…agent to receive a notification of the electronic record;…to assign an entity to process…; (Caswell teaches a third aspect of the present invention provides a program product stored on a computer useable medium for managing a request for a customer, the computer useable medium comprising program code for causing a computer to perform the following functions: receive the request at an application; define a delivery task list comprising one or more tasks required to fulfill the request; assign a service provider to perform each of the one or more tasks; [0009].)
…comprising the assignment of the entity; (Caswell teaches the computer software comprising instructions for causing a computer system to perform the following functions: receive the request at an application; define a delivery task list comprising one or more tasks required to fulfill the request; assign a service provider to perform each of the one or more tasks;…[0010-110].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record as disclosed by Austríng to incorporate assigning a provider to fulfill the request as taught by Caswell. This modification would create a system and methods capable of automating the process of providing management without high levels of human interaction (see Caswell, ¶ 0002).
Austríng and Caswell do not teach the distinct identifier being single-use which is met by Smets:
…single-use distinct identifier…being a cryptographic key… (Smets teaches the first cryptographic material may comprise cryptographic keys. The cryptographic keys may comprise one or more of one or more single use keys and a long term use key [0015].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record as disclosed by Austríng to incorporate distinct identifier being single-use as taught by Tran. This modification would create a system and methods capable of providing effective use and management of cryptographic keys (see Smets, ¶ 0007).
Regarding Claim 7, Austríng, Caswell, and Smets teach the limitations as seen in the rejection of Claim 5 above. Austríng further discloses:
wherein the system de-identifies information associated with personal identifiable information (PII) of the user. (Austríng discloses the present disclosure… 6. accesses and retrieves patient identifiable information (PII) and generates a non-patient-identifiable Single Purpose Patient ID (SPPID) for a particular patient for use in a discrete transaction [0241].)
Claim 10 is rejected under 35 USC § 103 as being unpatentable over Austríng, Caswell, and Smets in view of Yu et al. (US 20110112970 A1).
Regarding Claim 10, Austríng, Caswell, and Smets teach the limitations as seen in the rejection of Claim 7 above. Austríng further discloses:
wherein the request comprises… (Austríng discloses a method of providing blockchain-based electronic health record data patient transactions, the method implemented by a server system comprising one or more processors executing computer program instructions that, when executed, perform the method [0034]. Users can review their pharmacy and clinical data,…or request prescription refills [0098].
Austríng, Caswell, and Smets do not teach updating the electronic record to include the status which is met by Yu:
information from a record to combine with the electronic record, the information usable to generate a token and verify that the token is associated with the…[second agent], the record, and the PII. (Yu teaches the health record and the III [identifiable individual information] information is then combined for display, typically as a single record [0060]. The token for each user is generated through a token generation process that takes certain input and generates a unique token for each user. FIG. 16 illustrates a token generation process… As shown in FIG. 16, an instruction string 1602 for the token is input to the token generating process 1604 [0079, Fig. 16-17].)
It would have been an obvious addition to include the correlation of the token with being not only with the PII and the record, but also with the agent. This modification would have been a simple substitution of one known element for another to obtain predictable results. It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record as disclosed by Austríng to incorporate using the information from the electronic record to generate a token associated with PII as taught by Yu. This modification would create a system and methods which can help a healthcare provider track a patient’s health status while remaining secure (see Yu, ¶ 0004).
Claim 20 is rejected under 35 USC § 103 as being unpatentable over Austríng, Caswell, Tran, and Smets in view of Brunner et al. (US 20190156938 A1).
Regarding Claim 20, Austríng, Caswell, Tran, and Smets teach the limitations as seen in the rejection of Claim 13 above. Austríng further discloses:
wherein the executable instructions further include instructions that further cause the computer system to cause the third software agent… (Austríng discloses a computer system comprising one or more processors programmed to execute computer program instructions… [0035]. The EHR Data API 110 can be operably coupled to the pre- and post-edit module 114 to provide relevant patient information related to the transaction to the pre- and post-edit module 114. In another exemplary embodiment, the EHR patient transaction blockchain API 112 can be operably coupled to the pre- and post-edit module 114 to store the particular, discrete data retrieved from the EHR for a patient related to the transaction [0050]. The EHR Data API is interpretted as the third software agent.)
Austríng, Caswell, Tran, and Smets do not teach updating the electronic record to include the status which is met by Brunner:
…to update the electronic record to include a status of the request being fulfilled on the node. (Brunner teaches at 304, the prescription is accepted by the designated pharmacy and the status is set to accepted. at 305, the prescription is filled, and status of the prescription is set to filled. At each step, the appropriate system records are updated, and transactions can be recorded to a blockchain as described above [0063, Fig. 3].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the systems and methods for generating a distinct identifier for a user, storing the distinct identifier that replaces PII to a node, and causing an agent to process an electronic record as disclosed by Austríng to incorporate updating the record with the status of the request as taught by Brunner. This modification would create a system and methods which can securely manage records to mitigate poor prescribing of drugs (see Brunner, ¶ 0004-5).
Response to Arguments
Regarding rejections under 35 USC 101 to Claims 1-20, Applicant’s arguments have been considered but are not persuasive. The rejection has been updated in light of the amendments above.
Applicant argues under Step 2A, Prong Two, when viewed as a whole, the amended claims demonstrate an improvement to blockchain technology and/or a technical field of blockchain transactions (see p. 8 of Applicant’s Remarks).
Regarding (a), Examiner respectfully disagrees. First, Examiner notes that nowhere in the claims is a blockchain actually recited, and at most is a decentralized network. Further, paragraph 27 of the instant specification states the technology described are necessarily rooted in computer technology in order to overcome problems specifically arising with the computing resources required to transmit electronic health records, in legal compliance with federal regulations. Being in legal compliance with federal regulations is not a technical problem, it is a legal/regulatory issue. Whether or not the transmitted data includes or excludes PII doesn’t affect the functioning of the computer or how the data is transmitted, and there is nothing in the claims that indicate otherwise. By enacting all of the additional measures of the claims to remove PII would make the system less efficient and take longer. Paragraph 11 of the instant specification states “Techniques for de-identification and re-identification, as described herein, are in accordance with methods and approaches defined in the ‘Guidance of De-Identification of Protected Health Information’”. This indicates that the techniques are known in the art, so even if this limitation had any additional elements present and was not an abstract idea, it is not novel and is known in the art.
The specification does not provide any evidence as to how ‘single-use’ tokens solves or addresses any problem. Rather, the limitation of the token being single-use appears to be one option for an identifier.
MPEP 2106.05(f) states when determining whether a claim simply recites a judicial exception with the words "apply it" (or an equivalent), such as mere instructions to implement an abstract idea on a computer, examiners may consider the following: (1) Whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished. The recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words “apply it”. See Electric Power Group, LLC v. Alstom, S.A., 830 F.3d 1350, 1356, 119 USPQ2d 1739, 1743-44 (Fed. Cir. 2016); Intellectual Ventures I v. Symantec, 838 F.3d 1307, 1327, 120 USPQ2d 1353, 1366 (Fed. Cir. 2016); Internet Patents Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1417 (Fed. Cir. 2015). The claims appear to merely recite the solution with no details of how this solution is reached.
Applicant argues as whole, independent claim 1 integrates the alleged abstract idea into a practical application. For example, the amended independent claim 1 includes additional elements of "generating, by a second agent, a single-use distinct identifier associated with the user, the single-use distinct identifier being a cryptographic key" and "storing a first entry to a node of a decentralized network without including personal identifiable information (PII) of the user, the first entry comprising the single-use distinct identifier that replaces the PII." The claim further describes, e.g., a first agent, a second agent, and a third agent that can interact in a way that is enabled, e.g., using the single-use distinct identifier and storing an entry to a node of a decentralized network, which improve blockchain technology and/or a technical field of blockchain transactions. Thus, the claim is eligible because, as a whole, it integrates the judicial exception into a practical application (p. 8-9).
Regarding (b), Examiner respectfully disagrees. The limitations that are being argued are abstract (other than the cryptographic key) and an abstract idea cannot provide an improvement to technology of a technical field (see MPEP § 2106.05(a)(III) stating “it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology. After determining that a claim recites a judicial exception in Step 2A Prong One, examiners should evaluate whether the claim as a whole integrates the recited judicial exception into a practical application of the exception in Step 2A Prong Two. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception (see MPEP § 2106.04(d) - Integration of a Judicial Exception Into A Practical Application). The court has provided limitations that are indicative that an additional element (or combination of elements) may have integrated the exception into a practical application and limitations that did not integrate a judicial exception into a practical application (see MPEP § 2106.04(d)(I) – Relevant Considerations for Evaluating Whether Additional Elements integrate a Judicial Exception into a Practical Application). Here the instant claims seem more analogous to "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP § 2106.05(f). Further, the specification does not explain how ‘single-use’ tokens solve or address any problem. Rather, this type of token appear to be one option or way to use an identifier which amounts to “apply it” rather that providing any improvement or technical solution.
Applicant argues under Step 2B, amended claim 1 amounts to significantly more than an ineligible judicial exception. Example 35 from the 101 Examples from December 2016 in combination, these steps do not represent merely gathering data for comparison or security purposes, but instead set up a sequence of events that address unique problems associated with bank cards and ATMs (e.g., the use of stolen or "skimmed" bank cards and/or customer information to perform unauthorized transactions). The additional elements in claim 2 thus represent significantly more (i.e., provide an inventive concept) because they are a practical implementation of the abstract idea of fraud prevention that performs identity verification in a non-conventional and non-generic way, even though the steps use well-known components (a processor and mobile communication device). Similarly here, amended claim 1 recites additional elements, such as, "generating, by a second agent, a single-use distinct identifier associated with the user, the single-use distinct identifier being a cryptographic key" and "storing a first entry to a node of a decentralized network without including personal identifiable information (PII) of the user, the first entry comprising the single-use distinct identifier that replaces the PII." This, along with the other elements in claim 1, describes a specific manner of using a single-use distinct identifier, a first agent, a second agent, and a third agent to enable use of a decentralized network in such a way that is neither well-understood, routine, nor conventional, particularly when integrated with the claim 1, as a whole. Therefore, the present claims amount to significantly more than an ineligible concept (p. 10-11).
Regarding (c), Examiner respectfully disagrees. The instant claims are not analogous to those in Claim 2 of Example 35 of the December 2016 USPTO Guidance. In the example, the combination of the steps operates in a non-conventional and non-generic way to ensure the customer’s identity is verified in a secure manner and they address unique problems associated with bank cards and ATMs. Conversely, the instant claims do not appear to solve a unique problem in a non-conventional way. If it is asserted that the invention improves upon conventional functioning of a computer, or upon conventional technology or technological processes, a technical explanation as to how to implement the invention should be present in the specification. That is, the disclosure must provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art. Conversely, if the specification explicitly sets forth an improvement but in a conclusory manner (i.e., a bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art), the examiner should not determine the claim improves technology. An indication that the claimed invention provides an improvement can include a discussion in the specification that identifies a technical problem and explains the details of an unconventional technical solution expressed in the claim, or identifies technical improvements realized by the claim over the prior art (MPEP § 2106.05(a)).
Regarding rejections under 35 USC 103 to Claims 1-20, Applicant’s arguments have been considered, but they are not persuasive. The rejection has been updated in light of the amendments above, rejecting Claim 1 as being unpatentable over Austríng, Caswell, Tran, and Smets.
Applicant argues Caswell doesn’t teach a “second agent” so it doesn’t teach “causing the second agent of the computing resources service provider, as a result of causing the second agent to receive a notification of the electronic record, to assign a provider to fulfill the request” as rejected.
Examiner respectfully disagrees. Once Caswell receives the request, it then assigns a service provider to perform a task (which could be to fulfill the request). In Caswell, the request is processed by somebody other than the requestor (e.g., a second agent).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OLIVIA R GEDRA whose telephone number is (571)270-0944. The examiner can normally be reached Monday - Friday 8:00am-5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Peter H Choi can be reached at (469)295-9171. 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.
/OLIVIA R. GEDRA/Examiner, Art Unit 3681
/PETER H CHOI/Supervisory Patent Examiner, Art Unit 3681