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 .
Claim Objections
Claims 1, 10, and 19 are objected to because of the following informalities:
In lines 6-7 of claim 1, it is unclear whether “one or more requestors” is the same as one or more requestors in line 5, therefore, “restricting access by one or more requestors” should read “restricting access by the one or more requestors”. Appropriate correction is required. The same objection is applied to claim 10, lines 7-8 and claim 19, lines 9-10.
In line 11, it is unclear whether “a requestor” is referring to the same “one or more requestors” in line 5 and lines 6-7. Appropriate correction is required. The same objection is applied to claim 10, line 12 and claim 19, line 14.
Claims 5 and 14 are objected to because of the following informalities:
In line 1, “wherein contextual access permissions” should read “wherein the contextual access permissions”.
In line 2, “based at least one of” should read “based on at least one of”.
Appropriate correction is required.
Claims 7-8 and 16-17 are objected to because of the following informalities:
In line 1, it is unclear whether “a context-specific database query” is the same as “a context-specific database query” in claim 1, line 15. Therefore, in claims 7-8, “generating a context specific database query” should read “generating the context specific database query”. Similarly, in claims 16-17, it is unclear whether “a context-specific database query” is the same as “a context-specific database query” in claim 10, line 16. Therefore, the same objection of claims 7-8 applies to claims 16-17.
In line 2, “facilitating retrieval of contextually available health data” should read “facilitating retrieval of the contextually available health data” for consistency with independent claim 1. Similarly, in line 3 of claims 16-17, “facilitating retrieval of contextually available health data” should read “facilitating retrieval of the contextually available health data” for consistency with independent claim 10.
Appropriate correction is required.
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 because the claimed invention is directed to an abstract idea without significantly more.
Independent Claims
Step 1 analysis:
Claim 1 is drawn to a method (i.e., process), Claim 10 is drawn to a non-transitory computer-readable storage medium (i.e., manufacture), and Claim 19 is drawn to a system, which are all within the four statutory categories. (Step 1 – Yes, the claim falls into one of the statutory categories).
Step 2A analysis – Prong One:
Claim 1 recites:
A method for managing patient health data in an online medical platform, the method comprising:
storing patient health data arising from multiple different data sources to a patient health database;
storing requestor data arising from one or more requestors to a requestor database;
storing a set of contextual access permissions for enabling or restricting access by one or more requestors to the patient health data under different contexts, wherein the set of contextual access permissions are embodied in one or more digital contracts storing context-dependent consent obtained from the one or more patients for sharing the patient health data;
receiving, over a network from a requestor, a request to access the patient health data for the one or more patients, the request including at least a requestor identifier and one or more types of requested information;
based on the set of contextual access permissions, the requestor identifier, and the one or more types of requested information, generating a context-specific database query to the patient health database associated with the request and facilitating retrieval of contextually available health data relevant to the context-specific database query;
determining a delivery context for transmitting the contextually available health data to the requestor; and
facilitating transmission of the contextually available health data over the network to the requestor according to the delivery context.
The series of steps as recited above describes managing personal behavior or relationships or interactions between people including following rules or instructions, and therefore fall within the scope of certain methods of organizing human activity. Fundamentally, the method is that of a person managing health data through interaction with a requestor, which encompasses a person interacting with another individual including following rules or instructions. Accordingly, the claim recites an abstract idea of managing interactions between people.
The series of steps as recited above also falls within the “mental processes” grouping of abstract ideas, and describes concepts that can be performed in the human mind through observation, evaluation, judgement, and opinion. Receiving a request, generating a query, and determining a delivery context can all be performed in the human mind, with or without the use of a physical aid. Additionally, the act of storing patient health data and requestor data can be performed in the human mind. Therefore, the claim recites an abstract idea of a mental process.
Claims 10 and 19 recite/describe nearly identical steps as claim 1 (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and these claims are therefore determined to recite an abstract idea under the same analysis.
Step 2A analysis – Prong 2:
This judicial exception is not integrated into a practical application. Specifically, independent claims 1, 10, and 19 recite the following additional elements beyond the abstract idea: a non-transitory computer-readable storage medium and one or more processors. These limitations are recited at a high level of generality and amount to no more than mere instructions to apply the exception using generic computer components. The limitations do not impose any meaningful limits on practicing the abstract idea, and therefore do not integrate the abstract idea into a practical application (see MPEP 2106.05(f)).
The limitations “storing a set of contextual access permissions”, “receiving, over a network from a requestor, a request to access the patient health data”, and “facilitating transmission of the contextually available health data… to the requestor” are mere data gathering and output recited at a high level of generality, and thus are insignificant extra-solution activity. See MPEP 2106.05(g) (“whether the limitation is significant”). In addition, all uses of the recited judicial exceptions require such data gathering and output, and, as such, these limitations do not impose any meaningful limits on the claim. These limitation amount to necessary data gathering and output.
The additional elements do not show an improvement to the functioning of a computer or to any other technology, rather the additional elements perform general computing functions and do not indicate how the particular combination improves any technology or provides a technical solution to a technical problem. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, Claims 1, 10, and 19 are directed to an abstract idea without practical application. (Step 2A – Prong 2: No, the additional elements are not integrated into a practical application).
Step 2B analysis:
As discussed above in “Step 2A analysis – Prong 2”, the identified additional elements in Independent Claims 1, 10, and 19 are equivalent to adding the words “apply it” on a generic computer, and/or generally link the use of the judicial exception to a particular technological environment or field of use. Therefore, the claims as a whole do not amount to significantly more than the judicial exception itself.
Additional elements of “storing a set of contextual access permissions”, “receiving, over a network from a requestor, a request to access the patient health data”, and “facilitating transmission of the contextually available health data… to the requestor” were found to be insignificant extra-solution activity in Step 2A, Prong Two, because they were determined to be insignificant limitations as necessary data gathering and outputting. However, a conclusion that an additional element is insignificant extra-solution activity in Step 2A, Prong Two should be re-evaluated in Step 2B. See MPEP 2106.05, subsection I.A. At Step 2B, the evaluation of the insignificant extra-solution activity consideration takes into account whether or not the extra-solution activity is well understood, routine, and conventional in the field. See MPEP 2106.05(g).
Generic computer components recited as performing generic computer functions that are well- understood, routine and conventional activities amount to no more than implementing the abstract idea with a computerized system. Here, the claim limitations are similar to receiving and sending information over a network (Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); OJP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); See MPEP 2106.05(d)(II)(i)).
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above with respect to integration of the abstract idea into a practical application, using the additional elements to perform the steps for managing patient health data amount to no more than using computer related devices to implement the abstract idea.
The use of a computer or processor to merely automate or implement the abstract idea cannot provide significantly more than the abstract idea itself. (See MPEP 2106.05(f) where mere instructions to apply an exception does not render an abstract idea patent eligible). There is no indication that the additional limitations alone or in combination improves the functioning of a computer or any other technology, improves another technology or technical field, or effects a transformation or reduction of a particular article to a different state or thing. Therefore, the claims are not patent eligible. The Examiner has therefore determined that no additional element, or combination of additional claims elements is/are sufficient to ensure the claims amount to significantly more than the abstract idea identified above (Step 2B: Independent claims - NO).
Dependent Claims
Dependent Claims 2-9, 11-18, 20 are directed towards elements used to describe the contextual access permissions, data sources, and the process of generating a query. These elements describe managing personal behavior or relationships or interactions between people including following rules or instructions, and therefore fall within the same scope of certain methods of organizing human activity as in the independent claims.
The elements as recited above also falls within the same “mental processes” grouping of abstract ideas as the independent claims, and describes concepts that can be performed in the human mind through observation, evaluation, judgement, and opinion. Therefore, the dependent claims recite an abstract idea of a mental process.
This judicial exception is not integrated into a practical application. The limitations are recited at a high level of generality and amount to no more than mere instructions to apply the exception using generic computer components. The limitations do not impose any meaningful limits on practicing the abstract idea, and therefore do not integrate the abstract idea into a practical application (see MPEP 2106.05(f)).
The additional elements do not show an improvement to the functioning of a computer or to
any other technology, rather the additional elements perform general computing functions and do not
indicate how the particular combination improves any technology or provides a technical solution to a
technical problem. Accordingly, these additional elements, when considered separately and as an
ordered combination, do not integrate the abstract idea into a practical application because they do not
impose any meaningful limits on practicing the abstract idea. Therefore, the dependent claims are
directed to an abstract idea without practical application. (Step 2A – Prong 2: No, the additional
elements are not integrated into a practical application).
The additional elements in Dependent Claims 2-9, 11-18, and 20 are recited at a high level of generality and are equivalent to adding the words “apply it” on a generic computer, and/or generally link the use of the judicial exception to a particular technological environment or field of use. Therefore, the claims as a whole do not amount to significantly more than the judicial exception itself.
For the role of a computer in a computer implemented invention to be deemed meaningful in
the context of this analysis, it must involve more than performance of “well-understood, routine, [and]
conventional activities previously known to the industry.” Further, “the mere recitation of a generic
computer cannot transform a patent ineligible abstract idea into a patent-eligible invention.”
The use of a computer or processor to merely automate or implement the abstract idea cannot
provide significantly more than the abstract idea itself. (See MPEP 2106.05(f) where mere instructions to apply an exception does not render an abstract idea patent eligible). There is no indication that the
additional limitations alone or in combination improves the functioning of a computer or any other
technology, improves another technology or technical field, or effects a transformation or reduction of a
particular article to a different state or thing. Therefore, the claims are not patent eligible.
The Examiner has therefore determined that no additional element, or combination of
additional claims elements is/are sufficient to ensure the claims amount to significantly more than the
abstract idea identified above (Step 2B: Dependent claims - NO).
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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-3, 5-12, and 14-20 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Van De Craen et al. (WO 2014/206795) (Hereinafter Van De Craen).
Regarding Claim 1, Van De Craen teaches the following:
method for managing patient health data in an online medical platform (Pg. 6, lines 14-15 and Pg. 9, lines 19-23: a method of providing medical data via a software application), the method comprising:
storing patient health data arising from multiple different data sources to a patient health database (Abstract: The data provider can store the medical data locally or can retrieve the medical data from a remote source, such as a personal health record (PHR) server);
storing requestor data arising from one or more requestors to a requestor database (Pg. 15, lines 16-25: the data provider requests authentication, and the device obtains authentication information such as a user ID and password, which could be stored in the patient device. The authentication information can be the patient to whom the requested medical data corresponds);
storing a set of contextual access permissions for enabling or restricting access by one or more requestors to the patient health data under different contexts (Pg. 15, lines 16-19, Pg. 3, lines 13-20: the data provider requests authentication from the patient device, which obtains authentication information which could be stored in the patient device. The user can set access restrictions so that only certain data elements of the medical data are shared. The one or more access parameters can include: a time period parameter defining a time period during which the second module is allowed to access the medical data; and/or data element parameters identifying which ones of a plurality of data elements included in the medical data can be accessed by the second module.), wherein the set of contextual access permissions are embodied in one or more digital contracts storing context-dependent consent obtained from the one or more patients for sharing the patient health data (Pg. 10, lines 3-10: The user interface can receive user input selecting one or more access parameters relating to how medical data should be shared with a second device. This allows a user to define the extent to which the medical data will be shared with the second device. Examples of access parameters that can be selected by user input include, but are not limited to, a time period during which the second device is allowed to access the medical data, and data element restrictions. Specifically, the medical data can include a plurality of data elements, and a user can set the data element restrictions to control which of the data elements may be accessed by the second device.);
receiving, over a network from a requestor, a request to access the patient health data for the one or more patients (Abstract, Pg. 2, lines 9-10: a first module arranged to provide data request information for requesting access to the medical data from the data provider. The device and data provider can be arranged to communicate over any wired or wireless connection, such as Bluetooth or Wireless Local Area Network (WLAN)), the request including at least a requestor identifier and one or more types of requested information (Pg. 2, lines 24-25 and Pg. 12, lines 12-14: in some embodiments the data request information can be a unique identifier assigned to the medical data. The patient device receives the authentication request and prompts a user to enter authentication information, for example a user identifier (ID) and password (PWD));
based on the set of contextual access permissions, the requestor identifier, and the one or more types of requested information, generating a context-specific database query to the patient health database associated with the request and facilitating retrieval of contextually available health data relevant to the context-specific database query (Pg. 2, lines 29-31 and 33-34-Pg. 3, line 1, Pg. 14, lines 12-14: The second module can obtain the identifier from the first module, and query the database to retrieve the information identifying the known location of the corresponding medical data. As a further alternative, in some embodiments the second module can request the medical data by transmitting the unique identifier to the data provider, and the data provider can retrieve the medical data by querying a database as described above. In response to successful authentication, the controller retrieves the requested medical data by using the data access management module to obtain the medical data from the appropriate data source);
determining a delivery context for transmitting the contextually available health data to the requestor (Pg. 10, lines 25-27 and Pg. 8, lines 16-18: any suitable data request information providing module, which could for example be a display as shown in Fig. 2, an RFID transmitter, or a network interface module. The device can display the data request information as a quick-response code or in a different format, such as a barcode or plain text); and
facilitating transmission of the contextually available health data over the network to the requestor according to the delivery context (Pg. 10, lines 32-33, Pg. 14, lines 1 and 14-15, Pg. 15, lines 26-28: In response to successful authentication, the controller transmits the medical data to the physician device through the communications module over a network).
Regarding Claim 2, Van De Craen teaches the method of claim 1, and further teaches the following:
The method of claim 1, wherein medical data management platform stores a multiple-to-one mapping of patient identifiers for each of the one or more patients, and wherein the patient identifiers are respectively associated with contextual patient information originating from different patient record databases associated with different data sources (Pg. 16, lines 21-26, Fig. 7: medical data for the patient may be stored in each one of the PHRs under the same patient identifier. Different ones of the PHR systems 751, 752, 753 may use different patient identifiers for the same patient. In such embodiments, to access medical data for the same patient the data provider 730 can be 25 arranged to store a cross-reference of the different patient identifies that the different PHR systems 751, 752, 753 use for the same patient.).
Regarding Claim 3, Van De Craen teaches the method of claim 1, and further teaches the following:
The method of claim 1, wherein the contextual access permissions associated with the one or more patients are managed in a server-side central database (Pg. 2, lines 27-29: Each identifier assigned to the medical data can be stored in a database and cross-referenced to information identifying a known location of the corresponding medical data).
Regarding Claim 5, Van De Craen teaches the method of claim 1, and further teaches the following:
The method of claim 1, wherein contextual access permissions restrict availability of the patient health data based at least one of: an identity of the requestor, an entity type of the requestor, a temporal constraint limiting a time range for accessing the patient health data, a data type constraint limiting accessible data types, an outcome-based constraint limiting access dependent on a medical outcome associated with the one or more patients, and an event-based constraint limiting access dependent on occurrence of one or more specific events (Pg. 3, lines 13-17, Pg. 12, lines 32-34-Pg. 13, lines 1-7, and Pg. 17, lines 13-14: The one or more access parameters can include: a time period parameter defining a time period during which the second module is allowed to access the medical data; and/or data element parameters identifying which ones of a plurality of data elements included in the medical data can be accessed by the second module.).
Regarding Claim 6, Van De Craen teaches the method of claim 1, and further teaches the following:
The method of claim 1, wherein the multiple different data sources include one or more of an electronic healthcare records (EHR) system, a connected medical equipment system, a medical facility platform system, a manufacturer system, a clinical research system, a shipping management system, a public health system, an insurance claims system, and one or more client devices (Pg. 9, lines 20-13, Pg. 17, lines 4-7: the patient device can be a smart phone , and the physician device can communicate with the patient device to access the medical data. The data provider can also receive data from personal health records (PHRs), one or more electronic medical records (EMRs), and one or more electronic health records (EHRs)).
Regarding Claim 7, Van De Craen teaches the method of claim 1, and further teaches the following:
The method of claim 1, wherein generating a context-specific database query to the patient health database associated with the request and facilitating retrieval of contextually available health data relevant to the context-specific database query (Pg. 2, lines 29-31, Pg. 3, lines 8-10: In some embodiments, the first module is arranged to include one or more access parameters in the data request information, the access parameters comprising parameters relating to how the medical data is to be shared with the second module. The second module can obtain the identifier from the first module, and query the database to retrieve the information identifying the known location of the corresponding medical data) comprises:
generating a database query associated with the one or more types of requested information (Pg. 2, lines 29-31, Pg. 3, lines 3-7: The second module can obtain the identifier from the first module, and query the database to retrieve the information identifying the known location of the corresponding medical data. the data request information could include a query to request a specific subset such as a request for family history data relating to information about disorders suffered by direct relatives of the patient, or a request for recent patient data comprising medical data for the patient from a recent time period (e.g. from 6 months ago up to present day));
retrieving initial health data matching the database query (Pg. 11, lines 20-23: Once the data request information has been obtained, the controller requests the medical data from the data provider based on the data request information, through the communication module. The requested medical data will then be received from the data provider); and
applying the contextual access permissions and contextual information including the requestor identifier to refine the initial health data to determine the contextually available health data (Pg. 3, lines 10-13, Pg. 4, lines 1-4: the second module is arranged to transmit the access parameters to the data provider when requesting the medical data, and the data provider is arranged to control access to the medical data by the second module based on the access parameters. the data provider is arranged to respond to the request from the second module to access the medical data by requesting authentication from the patient to whom the requested medical data corresponds, and is arranged to provide the requested medical data to the second module in response to successful authentication.).
Regarding Claim 8, Van De Craen teaches the method of claim 1, and further teaches the following:
The method of claim 1, wherein generating a context-specific database query to the patient health database associated with the request and facilitating retrieval of contextually available health data relevant to the context-specific database query (Pg. 2, lines 29-31, Pg. 3, lines 8-10: In some embodiments, the first module is arranged to include one or more access parameters in the data request information, the access parameters comprising parameters relating to how the medical data is to be shared with the second module. The second module can obtain the identifier from the first module, and query the database to retrieve the information identifying the known location of the corresponding medical data) comprises:
generating a tailored database query based on the one or more types of requested information, the contextual access permissions, and contextual information including the requestor identifier to obtain the contextually available health data (Pg. 2, lines 25-20: Different identifiers can be assigned to medical data for different patients, and different identifiers can be assigned to predefined subsets of medical data for the same patient. Each identifier can be stored in a database and cross-referenced to information identifying a known location of the corresponding medical data. The second module can obtain the identifier from the first module and query the database to retrieve the information.).
Regarding Claim 9, Van De Craen teaches the method of claim 1, and further teaches the following:
The method of claim 1, wherein the set of contextual access permissions include first contextual access permissions granted by the one or more patients and second contextual access permission granted to the requestor (Pg. 13, lines 8-12: the data provider transmits an authentication request to the patient device, but the authentication request can also be transmitted to the physician device instead in different circumstances), and wherein the contextually available health data is within respective scopes of both the first contextual access permissions and the second contextual access permissions (Pg. 3, lines 18-20: The access parameters can be used to control the manner in which the second module is permitted to access the medical data. For example, a user (patient or provider) can set the access restrictions so that only certain data elements of the medical data are shared.).
Regarding Claim 10, Van De Craen teaches the following:
A non-transitory computer-readable storage medium storing instructions for managing patient health data in an online medical platform, the instructions when executed by one or more processors causing the one or more processors to perform steps (Pg. 6, lines 14-15, 30-32 and Pg. 9, lines 19-23: a computer-readable storage medium arranged to store a computer program which, when executed by a device, causes the device to perform any of the methods described including a method of providing medical data via a software application) comprising:
storing patient health data arising from multiple different data sources to a patient health database (Abstract: The data provider can store the medical data locally or can retrieve the medical data from a remote source, such as a personal health record (PHR) server);
storing requestor data arising from one or more requestors to a requestor database (Pg. 15, lines 16-25: the data provider requests authentication, and the device obtains authentication information such as a user ID and password, which could be stored in the patient device. The authentication information can be the patient to whom the requested medical data corresponds);
storing a set of contextual access permissions for enabling or restricting access by one or more requestors to the patient health data under different contexts, wherein the set of contextual access permissions are embodied in one or more digital contracts storing context-dependent consent obtained from the one or more patients for sharing the patient health data (Pg. 15, lines 16-19, Pg. 3, lines 13-20: the data provider requests authentication from the patient device, which obtains authentication information which could be stored in the patient device. The user can set access restrictions so that only certain data elements of the medical data are shared. The one or more access parameters can include: a time period parameter defining a time period during which the second module is allowed to access the medical data; and/or data element parameters identifying which ones of a plurality of data elements included in the medical data can be accessed by the second module.);
receiving, over a network from a requestor, a request to access the patient health data for the one or more patients (Abstract, Pg. 2, lines 9-10: a first module arranged to provide data request information for requesting access to the medical data from the data provider. The device and data provider can be arranged to communicate over any wired or wireless connection, such as Bluetooth or Wireless Local Area Network (WLAN)), the request including at least a requestor identifier and one or more types of requested information (Pg. 2, lines 24-25 and Pg. 12, lines 12-14: in some embodiments the data request information can be a unique identifier assigned to the medical data. The patient device receives the authentication request and prompts a user to enter authentication information, for example a user identifier (ID) and password (PWD));
based on the set of contextual access permissions, the requestor identifier, and the one or more types of requested information, generating a context-specific database query to the patient health database associated with the request and facilitating retrieval of contextually available health data relevant to the context-specific database query (Pg. 2, lines 29-31 and 33-34-Pg. 3, line 1, Pg. 14, lines 12-14: The second module can obtain the identifier from the first module, and query the database to retrieve the information identifying the known location of the corresponding medical data. As a further alternative, in some embodiments the second module can request the medical data by transmitting the unique identifier to the data provider, and the data provider can retrieve the medical data by querying a database as described above. In response to successful authentication, the controller retrieves the requested medical data by using the data access management module to obtain the medical data from the appropriate data source);
determining a delivery context for transmitting the contextually available health data to the requestor (Pg. 10, lines 25-27 and Pg. 8, lines 16-18: any suitable data request information providing module, which could for example be a display as shown in Fig. 2, an RFID transmitter, or a network interface module. The device can display the data request information as a quick-response code or in a different format, such as a barcode or plain text); and
facilitating transmission of the contextually available health data over the network to the requestor according to the delivery context (Pg. 10, lines 32-33, Pg. 14, lines 1 and 14-15, Pg. 15, lines 26-28: In response to successful authentication, the controller transmits the medical data to the physician device through the communications module over a network).
Regarding Claim 11, Van De Craen teaches the non-transitory computer-readable storage medium of claim 10, and further teaches the following:
The non-transitory computer-readable storage medium of claim 10, wherein medical data management platform stores a multiple-to-one mapping of patient identifiers for each of the one or more patients, and wherein the patient identifiers are respectively associated with contextual patient information originating from different patient record databases associated with different data sources (Pg. 16, lines 21-26, Fig. 7: medical data for the patient may be stored in each one of the PHRs under the same patient identifier. Different ones of the PHR systems 751, 752, 753 may use different patient identifiers for the same patient. In such embodiments, to access medical data for the same patient the data provider 730 can be 25 arranged to store a cross-reference of the different patient identifies that the different PHR systems 751, 752, 753 use for the same patient.).
Regarding Claim 12, Van De Craen teaches the non-transitory computer-readable storage medium of claim 10, and further teaches the following:
The non-transitory computer-readable storage medium of claim 10, wherein the contextual access permissions associated with the one or more patients are managed in a server-side central database (Pg. 2, lines 27-29: Each identifier assigned to the medical data can be stored in a database and cross-referenced to information identifying a known location of the corresponding medical data).
Regarding Claim 14, Van De Craen teaches the non-transitory computer-readable storage medium of claim 10, and further teaches the following:
The non-transitory computer-readable storage medium of claim 10, wherein contextual access permissions restrict availability of the patient health data based at least one of: an identity of the requestor, an entity type of the requestor, a temporal constraint limiting a time range for accessing the patient health data, a data type constraint limiting accessible data types, an outcome-based constraint limiting access dependent on a medical outcome associated with the one or more patients, and an event-based constraint limiting access dependent on occurrence of one or more specific events (Pg. 3, lines 13-17, Pg. 12, lines 32-34-Pg. 13, lines 1-7, and Pg. 17, lines 13-14: The one or more access parameters can include: a time period parameter defining a time period during which the second module is allowed to access the medical data; and/or data element parameters identifying which ones of a plurality of data elements included in the medical data can be accessed by the second module.).
Regarding Claim 15, Van De Craen teaches the non-transitory computer-readable storage medium of claim 10, and further teaches the following:
The non-transitory computer-readable storage medium of claim 10, wherein the multiple different data sources include one or more of: an electronic healthcare records (EHR) system, a connected medical equipment system, a medical facility platform system, a manufacturer system, a clinical research system, a shipping management system, a public health system, an insurance claims system, and one or more client devices (Pg. 9, lines 20-13, Pg. 17, lines 4-7: the patient device can be a smart phone , and the physician device can communicate with the patient device to access the medical data. The data provider can also receive data from personal health records (PHRs), one or more electronic medical records (EMRs), and one or more electronic health records (EHRs)).
Regarding Claim 16, Van De Craen teaches the non-transitory computer-readable storage medium of claim 10, and further teaches the following:
The non-transitory computer-readable storage medium of claim 10, wherein generating a context-specific database query to the patient health database associated with the request and facilitating retrieval of contextually available health data relevant to the context-specific database query (Pg. 2, lines 29-31, Pg. 3, lines 8-10: In some embodiments, the first module is arranged to include one or more access parameters in the data request information, the access parameters comprising parameters relating to how the medical data is to be shared with the second module. The second module can obtain the identifier from the first module, and query the database to retrieve the information identifying the known location of the corresponding medical data) comprises:
generating a database query associated with the one or more types of requested information (Pg. 2, lines 29-31, Pg. 3, lines 3-7: The second module can obtain the identifier from the first module, and query the database to retrieve the information identifying the known location of the corresponding medical data. the data request information could include a query to request a specific subset such as a request for family history data relating to information about disorders suffered by direct relatives of the patient, or a request for recent patient data comprising medical data for the patient from a recent time period (e.g. from 6 months ago up to present day));
retrieving initial health data matching the database query (Pg. 11, lines 20-23: Once the data request information has been obtained, the controller requests the medical data from the data provider based on the data request information, through the communication module. The requested medical data will then be received from the data provider); and
applying the contextual access permissions and contextual information including the requestor identifier to refine the initial health data to determine the contextually available health data (Pg. 3, lines 10-13, Pg. 4, lines 1-4: the second module is arranged to transmit the access parameters to the data provider when requesting the medical data, and the data provider is arranged to control access to the medical data by the second module based on the access parameters. the data provider is arranged to respond to the request from the second module to access the medical data by requesting authentication from the patient to whom the requested medical data corresponds, and is arranged to provide the requested medical data to the second module in response to successful authentication.).
Regarding Claim 17, Van De Craen teaches the non-transitory computer-readable storage medium of claim 10, and further teaches the following:
The non-transitory computer-readable storage medium of claim 10, wherein generating a context-specific database query to the patient health database associated with the request and facilitating retrieval of contextually available health data relevant to the context-specific database query (Pg. 2, lines 29-31, Pg. 3, lines 8-10: In some embodiments, the first module is arranged to include one or more access parameters in the data request information, the access parameters comprising parameters relating to how the medical data is to be shared with the second module. The second module can obtain the identifier from the first module, and query the database to retrieve the information identifying the known location of the corresponding medical data) comprises:
generating a tailored database query based on the one or more types of requested information, the contextual access permissions, and contextual information including the requestor identifier to obtain the contextually available health data (Pg. 2, lines 25-20: Different identifiers can be assigned to medical data for different patients, and different identifiers can be assigned to predefined subsets of medical data for the same patient. Each identifier can be stored in a database and cross-referenced to information identifying a known location of the corresponding medical data. The second module can obtain the identifier from the first module and query the database to retrieve the information.).
Regarding Claim 18, Van De Craen teaches the non-transitory computer-readable storage medium of claim 10, and further teaches the following:
The non-transitory computer-readable storage medium of claim 10, wherein the set of contextual access permissions include first contextual access permissions granted by the one or more patients and second contextual access permission granted to the requestor (Pg. 13, lines 8-12: the data provider transmits an authentication request to the patient device, but the authentication request can also be transmitted to the physician device instead in different circumstances),
and wherein the contextually available health data is within respective scopes of both the first contextual access permissions and the second contextual access permissions (Pg. 3, lines 18-20: The access parameters can be used to control the manner in which the second module is permitted to access the medical data. For example, a user (patient or provider) can set the access restrictions so that only certain data elements of the medical data are shared.).
Regarding Claim 19, Van De Craen teaches the following:
A computer system (Pg. 2, line 5 and Pg. 8, lines 14-15: a system for accessing patient data implemented using a smartphone, tablet, general purpose computer, or any other suitable apparatus) comprising:
one or more processors (Pg. 22, lines 16-17: A single processor may fulfill the functions of the invention); and
a non-transitory computer-readable storage medium storing instructions for managing patient health data in an online medical platform, the instructions when executed causing the one or more processors to perform steps (Pg. 6, lines 14-15, 30-32 and Pg. 9, lines 19-23: a computer-readable storage medium arranged to store a computer program which, when executed by a device, causes the device to perform any of the methods described including a method of providing medical data via a software application) comprising:
storing patient health data arising from multiple different data sources to a patient health database (Abstract: The data provider can store the medical data locally or can retrieve the medical data from a remote source, such as a personal health record (PHR) server);
storing requestor data arising from one or more requestors to a requestor database (Pg. 15, lines 16-25: the data provider requests authentication, and the device obtains authentication information such as a user ID and password, which could be stored in the patient device. The authentication information can be the patient to whom the requested medical data corresponds);
storing a set of contextual access permissions for enabling or restricting access by one or more requestors to the patient health data under different contexts, wherein the set of contextual access permissions are embodied in one or more digital contracts storing context-dependent consent obtained from the one or more patients for sharing the patient health data (Pg. 15, lines 16-19, Pg. 3, lines 13-20: the data provider requests authentication from the patient device, which obtains authentication information which could be stored in the patient device. The user can set access restrictions so that only certain data elements of the medical data are shared. The one or more access parameters can include: a time period parameter defining a time period during which the second module is allowed to access the medical data; and/or data element parameters identifying which ones of a plurality of data elements included in the medical data can be accessed by the second module.);
receiving, over a network from a requestor, a request to access the patient health data for the one or more patients (Abstract, Pg. 2, lines 9-10: a first module arranged to provide data request information for requesting access to the medical data from the data provider. The device and data provider can be arranged to communicate over any wired or wireless connection, such as Bluetooth or Wireless Local Area Network (WLAN)), the request including at least a requestor identifier and one or more types of requested information (Pg. 2, lines 24-25 and Pg. 12, lines 12-14: in some embodiments the data request information can be a unique identifier assigned to the medical data. The patient device receives the authentication request and prompts a user to enter authentication information, for example a user identifier (ID) and password (PWD));
based on the set of contextual access permissions, the requestor identifier, and the one or more types of requested information, generating a context-specific database query to the patient health database associated with the request and facilitating retrieval of contextually available health data relevant to the context-specific database query (Pg. 2, lines 29-31 and 33-34-Pg. 3, line 1, Pg. 14, lines 12-14: The second module can obtain the identifier from the first module, and query the database to retrieve the information identifying the known location of the corresponding medical data. As a further alternative, in some embodiments the second module can request the medical data by transmitting the unique identifier to the data provider, and the data provider can retrieve the medical data by querying a database as described above. In response to successful authentication, the controller retrieves the requested medical data by using the data access management module to obtain the medical data from the appropriate data source);
determining a delivery context for transmitting the contextually available health data to the requestor (Pg. 10, lines 25-27 and Pg. 8, lines 16-18: any suitable data request information providing module, which could for example be a display as shown in Fig. 2, an RFID transmitter, or a network interface module. The device can display the data request information as a quick-response code or in a different format, such as a barcode or plain text); and
facilitating transmission of the contextually available health data over the network to the requestor according to the delivery context (Pg. 10, lines 32-33, Pg. 14, lines 1 and 14-15, Pg. 15, lines 26-28: In response to successful authentication, the controller transmits the medical data to the physician device through the communications module over a network).
Regarding Claim 20, Van De Craen teaches the computer system of claim 19, and further teaches the following:
The computer system of claim 19, wherein medical data management platform stores a multiple-to-one mapping of patient identifiers for each of the one or more patients, and wherein the patient identifiers are respectively associated with contextual patient information originating from different patient record databases associated with different data sources (Pg. 16, lines 21-26, Fig. 7: medical data for the patient may be stored in each one of the PHRs under the same patient identifier. Different ones of the PHR systems 751, 752, 753 may use different patient identifiers for the same patient. In such embodiments, to access medical data for the same patient the data provider 730 can be 25 arranged to store a cross-reference of the different patient identifies that the different PHR systems 751, 752, 753 use for the same patient.).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Van De Craen et al. (WO 2014/206795) (Hereinafter Van De Craen) in view of Wang (US Patent No. 11,315,666 B2).
Regarding Claim 4, Van De Craen teaches the method of claim 1, however, Van De Craen does not teach the following that is met by Wang:
The method of claim 1, wherein the contextual access permissions associated with the one or more patients are managed in a distributed database using blockchain (Fig. 3, Col. 5, lines 53-61 and Col. 6, lines 20-21: receiving, by the blockchain node, a medical data query request, where the medical data query request includes a digital signature of a user who initiates a query and a queried user identifier; authenticating, by the blockchain node, the user who initiates the query based on the digital signature; and sending, by the blockchain node, medical data corresponding to the queried user identifier to the user who initiates the query when the authentication succeeds. The blockchain network can set an access permission for the medical data).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the method of managing patient health data, as taught by Van De Craen, with the blockchain network of Wang, because by having the access permissions in a blockchain network, the authentication needs can be different based on the user who initiates the query, effectively protecting the privacy of the patient (see Wang Col. 6, lines 22-25).
Regarding Claim 13, Van De Craen teaches the non-transitory computer-readable storage medium of claim 10, however, Van De Craen does not teach the following that is met by Wang:
The non-transitory computer-readable storage medium of claim 10, wherein the contextual access permissions associated with the one or more patients are managed in a distributed database using blockchain (Fig. 3, Col. 5, lines 53-61 and Col. 6, lines 20-21: receiving, by the blockchain node, a medical data query request, where the medical data query request includes a digital signature of a user who initiates a query and a queried user identifier; authenticating, by the blockchain node, the user who initiates the query based on the digital signature; and sending, by the blockchain node, medical data corresponding to the queried user identifier to the user who initiates the query when the authentication succeeds. The blockchain network can set an access permission for the medical data).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the method of managing patient health data, as taught by Van De Craen, with the blockchain network of Wang, because by having the access permissions in a blockchain network, the authentication needs can be different based on the user who initiates the query, effectively protecting the privacy of the patient (see Wang Col. 6, lines 22-25).
Relevant Prior Art of Record Not Currently Being Applied
The relevant art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Shelton et al. (WO 2024/069562) discloses a system and method for managing data subject to patient consent which gathers patient data from a variety of sources including a sensing system, surgical hub, databases such as EMRs, monitoring devices, and more. The system gathers conditional consent from a patient and determines whether to block access to the health data associated with the patient based on the data request.
Ferry (US 2015/0178449) discloses a method and system for automated personal health information retrieval and release. A requestor requests access to health information of a patient, the request is presented to a system manager which determined whether the requestor is authorized to access the data, and a delivery medium is specified for sending the requested health data to a designated destination.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALEXIS K VAN DUZER whose telephone number is (571)270-5832. The examiner can normally be reached Monday thru Thursday 8-5 CT.
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, Marc Jimenez can be reached at (571) 272-4530. 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.
/A.K.V./Examiner, Art Unit 3681
/MARC Q JIMENEZ/Supervisory Patent Examiner, Art Unit 3681