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 . This non-final office action on merits is in response to the Patent Application filed on 11/27/2024.
Status of claims
Claims 1-15 are pending and considered below. This application claims the benefit of EP Application No. EP22 193 232.0 filed on 08/31/2022, and is a Continuation Application of PCT/EP2023/064225 filed on 05/26/2023, which claims the benefit to Provisional Application No. 63365539 filed on 05/31/2022.
Information Disclosure Statement
The information disclosure statements (IDS) filed on 03/29/2025 have been acknowledged. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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-15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
Under step 1, the analysis is based on MPEP 2106.03, and claims 1-14 are drawn to a method, and claim 15 is drawn to a system. Thus, each claim, on its face, is directed to one of the statutory categories (i.e., useful process, machine, manufacture, or composition of matter) of 35 U.S.C. §101.
Step 2A Prong One
Claim 1 recites the limitation of submitting a service request indicative of a request for determining a first personalized healthcare parameter, the first personalized healthcare parameter being indicative of a first healthcare condition of the patient; in response to receiving the service request, generating a first input data request; providing the first input data request to a first service application from a plurality of service applications, to determine, for the patient, a respective personalized healthcare parameter in response to receiving respective personalized input data, and to determine the first personalized healthcare parameter; wherein the first input data request…to inform about a first input data information; for determining the first personalized healthcare parameter, wherein the data specification specifies in which respective unit(s) of value the first input are required by the first service application; generating first personalized input data in the healthcare application, the first personalized input data being generated according to the first input data information, wherein the generation of first personalized input data comprises and generating the first personalized input data from the received healthcare data which includes checking whether the received healthcare data are complying with the data specification of first input data of the first service application; and wherein the first personalized healthcare parameter was determined in response to receiving the first personalized input data in the first service application, such determining comprising processing the first personalized input data. These limitations, as drafted, is a process that, under its broadest reasonable interpretation, cover performance of the limitations in the mind or by using a pen and paper. But for the “providing a healthcare application and an interface application running in a data processing component” or “by the interface application” or “requires the first service application” language, the claim encompasses a user simply identifying what information is needed, collecting the patient’s data, checking the data against the required format or units, and determining the patient’s healthcare parameters in their mind or by using a pen and paper. The mere nominal recitation of “providing a healthcare application and an interface application running in a data processing component” or “by the interface application” or “requires the first service application” does not take the claim limitations out of the mental processes grouping. Thus, the claim recites a mental process which is an abstract idea.
Independent claim 15 recites identical or nearly identical steps with respect to claim 1 (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and this claim is therefore determined to recite an abstract idea under the same analysis.
Under Step 2A Prong Two
The claimed limitations, as per method claim 1, include:
providing a healthcare application and an interface application running in a data processing component;
submitting, from the healthcare application to the interface application, a service request indicative of a request for determining a first personalized healthcare parameter, the first personalized healthcare parameter being indicative of a first healthcare condition of the patient;
in response to receiving the service request, generating a first input data request by the interface application;
providing the first input data request to a first service application from a plurality of service applications,
wherein each of the service applications is configured to determine, for the patient, a respective personalized healthcare parameter in response to receiving respective personalized input data, and
the first service application is configured to determine the first personalized healthcare parameter;
wherein the first input data request requires the first service application to inform about a first input data information;
receiving from the first personalized healthcare application the first input data information in the interface application, the first input data information being indicative of a data specification of first input data required by the first service application for determining the first personalized healthcare parameter, wherein the data specification specifies in which respective unit(s) of value the first input are required by the first service application;
receiving from the interface application the first input data information in the healthcare application;
generating first personalized input data in the healthcare application, the first personalized input data being generated according to the first input data information, wherein the generation of first personalized input data comprises receiving healthcare data from one or more healthcare data sources and generating the first personalized input data from the received healthcare data which includes checking whether the received healthcare data are complying with the data specification of first input data of the first service application;
receiving the first personalized healthcare parameter in the healthcare application, wherein the first personalized healthcare parameter was determined in response to receiving the first personalized input data in the first service application, such determining comprising processing the first personalized input data; and
outputting the first personalized healthcare parameter to a receiving device connected to the data processing component.
Examiner Note: underlined elements indicate additional elements of the claimed invention identified as performing the steps of the claimed invention.
The judicial exception expressed in claim 1 is not integrated into a practical application. The claim as a whole merely describes how to generally “apply” the concept of requesting, evaluating, and processing information to determine a personalized healthcare parameter in a computer environment. The claimed computer components (i.e., providing a healthcare application and an interface application running in a data processing component, from the healthcare application to the interface application, by the interface application, wherein each of the service applications is configured to, the first service application is configured to, and requires the first service application) are recited at a high level of generality and are merely invoked as tools to perform an existing process of collecting information, analyzing information and determining the result. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application.
The judicial exception expressed in claim 1 is not integrated into a practical application. The claim recites the additional elements of receiving from the first personalized healthcare application the first input data information in the interface application, the first input data information being indicative of a data specification of first input data required by the first service application; receiving from the interface application the first input data information in the healthcare application; receiving healthcare data from one or more healthcare data sources; receiving the first personalized healthcare parameter in the healthcare application; and outputting the first personalized healthcare parameter to a receiving device connected to the data processing component. This limitation is recited at a high level of generality (i.e., as a general means of collecting input and reporting a result), and amounts to merely data gathering and presenting data, which is a form of insignificant extra-solution activity. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application. The claim is directed to an abstract idea.
Therefore, under step 2A, the claims are directed to the abstract idea, and require further analysis under Step 2B.
Under step 2B
Claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A, the claim as a whole merely describes how to generally “apply” the concept of requesting, evaluating, and processing information to determine a personalized healthcare parameter in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e., an inventive concept) to the abstract idea.
Claim 1 does not include an additional element that are sufficient to amount to significantly more than the judicial exception. For the providing limitation that was considered extra-solution activity in Step 2A, this has been re-evaluated in Step 2B and determined to be well-understood, routine, conventional activity in the field. The specification does not provide any indication that the limitation of providing a medication based on an efficacy score is anything other than a conventional action that simply follows from the determination of the efficacy score (see Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016)). For these reasons, there is no inventive concept. The claim is not patent eligible.
Claims 6, 8-11, 14 recite no further additional elements, and only further narrow the abstract idea. The previously identified additional elements, individually and as a combination, do not integrate the narrowed abstract idea into a practical application for reasons similar to those explained above, and do not amount to significantly more than the narrowed abstract idea for reasons similar to those explained above.
Claims 2-5, 7, 12-13 recite the additional elements of in the interface application (claim 2), by the interface application (claim 3), providing service application information with the service request (claim 4), receiving the healthcare data from one or more healthcare data sources (claim 5), in the healthcare application (claim 7), storing the first personalized healthcare parameter having the first source data specification in the first healthcare data source (claim 7), receiving the first personalized input data by the interface application (claim 12), receiving the first personalized healthcare parameter by a medical device (claim 13). However, this additional element amounts to implementing an abstract idea on a generic computing device (OR mere linking to a particular environment or mere data gathering (i.e., an insignificant extra-solution activity)). As such, this additional element, when considered individually or in combination with the prior devices, does not integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Thus, as the dependent claims remain directed to a judicial exception, and as the additional elements of the claims do not amount to significantly more, the dependent claims are not patent eligible.
Therefore, the claims here fail to contain any additional element(s) or combination of additional elements that can be considered as significantly more and the claim is rejected under 35 U.S.C. 101 for lacking eligible subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-15 are rejected under 35 U.S.C. 103 as being unpatentable over Cohen et al. (U.S. Patent Publication 2006/0031094 A1), referred to hereinafter as Cohen, in view of Vasudevan (U.S. Patent No. 11922239 B1), referred to hereinafter as Vasudevan, and Valdes et al. (U.S. Patent Publication 2018/0150599 A1), referred to hereinafter as Valdes.
Regarding claim 1, Cohen teaches a method for providing a personalized healthcare parameter to a patient (Cohen [0062] Data analysis and presentations of the reported information may be employed to develop and support diagnostic and therapeutic parameters. Where information on the report relates to an individual subject, the diagnostic and therapeutic parameters may be used to assess the health status and relative well being of that subject, as well as to develop or modify treatment for the subject. Where information on the report relates to groups of subjects or conglomerates of data, the diagnostic and therapeutic parameters may be used to assess the health status and relative well being of groups of subjects with similar medical conditions, such as, but not limited to, diabetic subjects, cardiac subjects, diabetic subjects having a particular type of diabetes or cardiac condition, subjects of a particular age, sex or other demographic group, combinations thereof, or the like.”), comprising:
providing a healthcare application and an interface application running in a data processing component (Cohen [0049] “In the embodiment shown in FIG. 1, the data management system 16 comprises a group of interrelated software modules or layers that specialize in different tasks. The system software includes a device communication layer 24, a data parsing layer 26, a database layer 28, a reporting layer 30 and a user interface layer 32.” and Cohen [0008] “According to embodiments of the present invention, a medical data management system may be configured with a group of software modules running on one or more servers connected to a wide-area network, such as the Internet. Users may communicate with the medical data management system over the Internet, for example, using a conventional personal computer (PC or other suitable network device) having conventional browser software and/or other software for interacting with the system.”);
from the healthcare application to the interface application…. for determining a first personalized healthcare parameter, the first personalized healthcare parameter being indicative of a first healthcare condition of the patient (Cohen [0062] “Data analysis and presentations of the reported information may be employed to develop and support diagnostic and therapeutic parameters. Where information on the report relates to an individual subject, the diagnostic and therapeutic parameters may be used to assess the health status and relative well being of that subject, as well as to develop or modify treatment for the subject. Where information on the report relates to groups of subjects or conglomerates of data, the diagnostic and therapeutic parameters may be used to assess the health status and relative well being of groups of subjects with similar medical conditions, such as, but not limited to, diabetic subjects, cardiac subjects, diabetic subjects having a particular type of diabetes or cardiac condition, subjects of a particular age, sex or other demographic group, combinations thereof, or the like.” and Cohen [0063] “The user interface layer 32 supports interactions with the end user, for example, for user login and data access, software navigation, user data input, user selection of desired report types and the display of selected information. As described in more detail below, users may be subjects, healthcare providers, healthcare payer entities, system operators or administrators, or the like, depending upon the service being provided by the system and depending upon the invention embodiment. More comprehensive embodiments are capable of interacting with some or all of the above-noted types of users, wherein different types of users have access to different services or data or different levels of services or data.”);
the first input data information being indicative of a data specification of first input data required by the first service application for determining the first personalized healthcare parameter, wherein the data specification specifies in which respective unit(s) of value the first input are required by the first service application (Cohen [0052] “The data-parsing layer 26 is responsible for validating the integrity of device data received and for inputting it correctly into a database. A cyclic redundancy check CRC process for checking the integrity of the received data may be employed. Alternatively, or in addition, data may be received in packets or other data arrangements, where preambles or other portions of the data include device type identification information. Such preambles or other portions of the received data may further include device serial numbers or other identification information that may be used for validating the authenticity of the received information. In such embodiments, the system 16 may compare received identification information with pre-stored information to evaluate whether the received information is from a valid source.” and Cohen [0160] “In other embodiments, the insulin activity curve for the subject may be derived by providing insulin to the subject and taking BG tests of the subject, over a period or periods of time. Based on the shape of the insulin activity curve, the estimated or otherwise determined value (x) for BG after an nutritional event and the target value, an algorithm determines how much insulin is needed to direct the blood glucose level to the target level. The algorithm may employ an estimated or otherwise derived insulin sensitivity of the subject, ΔBG/unit of insulin to determine appropriate insulin amounts to direct the subject's BG toward the target level, along the insulin activity curve. The insulin sensitivity of the subject may be another parameter entered into the pump electronics through a user-input on the insulin pump.”);
wherein the first personalized healthcare parameter was determined in response to receiving the first personalized input data in the first service application, such determining comprising processing the first personalized input data (Cohen [0062] “Data analysis and presentations of the reported information may be employed to develop and support diagnostic and therapeutic parameters. Where information on the report relates to an individual subject, the diagnostic and therapeutic parameters may be used to assess the health status and relative well being of that subject, as well as to develop or modify treatment for the subject. Where information on the report relates to groups of subjects or conglomerates of data, the diagnostic and therapeutic parameters may be used to assess the health status and relative well being of groups of subjects with similar medical conditions, such as, but not limited to, diabetic subjects, cardiac subjects, diabetic subjects having a particular type of diabetes or cardiac condition, subjects of a particular age, sex or other demographic group, combinations thereof, or the like.” and Cohen [0071] “A system operator or administrator (or other system personnel, such as trained physicians or other trained medical personnel working for or with the entity operating the system), using a computer or other network device 24, may access the medical data management system 16, for example, to assist a user in a customer-help transaction, to access data for evaluation, for servicing the system including adding or modifying website content, or for other suitable activities. In an example embodiment, a physician or other trained medical personnel associated with the entity operating the system 16 may be provided with access to certain subject information for analysis. In yet further embodiments, such physicians or other trained personnel may operate a help desk environment, that allows users to contact help desk personnel for assistance with operation of system components and/or evaluation of subject or medical device information. Based on an analysis of such information, the system 16 physician or other medical personnel may provide treatment recommendations to a subject-user (or group of subject-users) or to the subject user's (or group's) designated healthcare provider(s). In a further example embodiment, the system 16 may store such treatment recommendations for access by a subject-user (or group of subject-users) and/or designated healthcare provider-user through a system website. In yet further example embodiments, the system 16 may require review and approval by the subject-user's designated healthcare provider of any treatment recommendations issued by a system 16 personnel, before such treatment recommendations are provided to the subject-user.”).
Cohen fails to explicitly teach submitting a service request indicative of a request;
in response to receiving the service request, generating a first input data request by the interface application;
providing the first input data request to a first service application from a plurality of service applications, wherein each of the service applications is configured to determine, for the patient, a respective personalized healthcare parameter in response to receiving respective personalized input data… wherein the first input data request requires the first service application to inform about a first input data information;
receiving from the first personalized application the first input data information in the interface application;
receiving from the interface application the first input data information in the application;
generating first personalized input data in the healthcare application, the first personalized input data being generated according to the first input data information, wherein the generation of first personalized input data comprises receiving healthcare data from one or more healthcare data sources and generating the first personalized input data from the received healthcare data which includes checking whether the received healthcare data are complying with the data specification of first input data of the first service application;
receiving the first personalized healthcare parameter in the application; and
outputting the first personalized healthcare parameter to a receiving device connected to the data processing component.
Vasudevan teaches submitting a service request indicative of a request (Vasudevan, Col. 2, lines 2-6, “The at least one API server is configured to receive an API call from the client application, wherein the API call includes at least credentials provided by the client application; send a request to the at least one authentication server, wherein the request includes the credentials”);
in response to receiving the service request, generating a first input data request by the interface application (Vasudevan Col. 2, lines 2-17, “The at least one API server is configured to receive an API call from the client application, wherein the API call includes at least credentials provided by the client application; send a request to the at least one authentication server, wherein the request includes the credentials; receive an authorization token from the at least one authentication server in response to the request, when the at least one authentication server determines successful authorization of the client application based on the credentials; send a first query to the metadata repository, wherein the first query includes the authorization token in its header; receive, from the metadata repository, an API signature as a response to the first query, wherein the API signature includes at least input parameters of the API and a definition of the API, the API signature being generated by the metadata repository using the API metadata information”);
providing the first input data request to a first service application (Vasudevan, Col 2, lines 1-13, “The at least one authentication server is configured to check authorization of a client application. The at least one API server is configured to receive an API call from the client application, wherein the API call includes at least credentials provided by the client application; send a request to the at least one authentication server, wherein the request includes the credentials; receive an authorization token from the at least one authentication server in response to the request, when the at least one authentication server determines successful authorization of the client application based on the credentials; send a first query to the metadata repository, wherein the first query includes the authorization token in its header.”);
in response to receiving respective personalized input data (Vasudevan, Col 2, lines 1-13, “The at least one authentication server is configured to check authorization of a client application. The at least one API server is configured to receive an API call from the client application, wherein the API call includes at least credentials provided by the client application; send a request to the at least one authentication server, wherein the request includes the credentials; receive an authorization token from the at least one authentication server in response to the request, when the at least one authentication server determines successful authorization of the client application based on the credentials; send a first query to the metadata repository, wherein the first query includes the authorization token in its header.”);
wherein the first input data request requires the first service application to inform about a first input data information (Vasudevan, Col 2, lines, 2-18, “The at least one API server is configured to receive an API call from the client application, wherein the API call includes at least credentials provided by the client application; send a request to the at least one authentication server, wherein the request includes the credentials; receive an authorization token from the at least one authentication server in response to the request, when the at least one authentication server determines successful authorization of the client application based on the credentials; send a first query to the metadata repository, wherein the first query includes the authorization token in its header; receive, from the metadata repository, an API signature as a response to the first query, wherein the API signature includes at least input parameters of the API and a definition of the API, the API signature being generated by the metadata repository using the API metadata information”);
receiving from the first personalized application the first input data information in the interface application (Vasudevan, Col 2, lines, 2-18, “The at least one API server is configured to receive an API call from the client application, wherein the API call includes at least credentials provided by the client application; send a request to the at least one authentication server, wherein the request includes the credentials; receive an authorization token from the at least one authentication server in response to the request, when the at least one authentication server determines successful authorization of the client application based on the credentials; send a first query to the metadata repository, wherein the first query includes the authorization token in its header; receive, from the metadata repository, an API signature as a response to the first query, wherein the API signature includes at least input parameters of the API and a definition of the API, the API signature being generated by the metadata repository using the API metadata information”);
receiving from the interface application the first input data information in the application ((Vasudevan, Col 2, lines 2-22, “The at least one API server is configured to receive an API call from the client application, wherein the API call includes at least credentials provided by the client application; send a request to the at least one authentication server, wherein the request includes the credentials; receive an authorization token from the at least one authentication server in response to the request, when the at least one authentication server determines successful authorization of the client application based on the credentials; send a first query to the metadata repository, wherein the first query includes the authorization token in its header; receive, from the metadata repository, an API signature as a response to the first query, wherein the API signature includes at least input parameters of the API and a definition of the API, the API signature being generated by the metadata repository using the API metadata information; send a second query to a target database, wherein the second query includes the API signature; receive, from the target database, an API response to the second query, wherein the API response includes target data that is retrieved from the target database; and send the API response to the client application.”);
receiving the first personalized healthcare parameter in the application (((Vasudevan, Col 2, lines 2-22, “The at least one API server is configured to receive an API call from the client application, wherein the API call includes at least credentials provided by the client application; send a request to the at least one authentication server, wherein the request includes the credentials; receive an authorization token from the at least one authentication server in response to the request, when the at least one authentication server determines successful authorization of the client application based on the credentials; send a first query to the metadata repository, wherein the first query includes the authorization token in its header; receive, from the metadata repository, an API signature as a response to the first query, wherein the API signature includes at least input parameters of the API and a definition of the API, the API signature being generated by the metadata repository using the API metadata information; send a second query to a target database, wherein the second query includes the API signature; receive, from the target database, an API response to the second query, wherein the API response includes target data that is retrieved from the target database; and send the API response to the client application.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to combine Cohen with Vasudevan because Cohen’s medical data management system relies on multiple backend modules that must receive user initiated requests and determine appropriate processing parameters, but Cohen provides no detailed mechanism for dynamically identifying which service module should handle a request or how the system should obtain the exact input parameter specification that the selected module requires. Vasudevan solves this well-recognized problem by teaching an API server that receives a request, queries a metadata repository, and obtains an “API signature” that specifies the required input parameters and formats for the selected backend service. Incorporating Vasudevan’s metadata driven API signature retrieval into Cohen’s architecture would have been a predictable and straightforward implementation choice because it employs a well known, industry standard microservice pattern to ensure that downstream services receive correctly formatted input data. Doing this would improve Cohen’s system by enforcing consistent request construction, eliminating mismatches between heterogeneous healthcare inputs and service expectations, and enhancing modular service integration, which these advantages directly align with both references. Therefore, applying Vasudevan’s API parameter discovery mechanism to Cohen’s service request flow would have been an obvious combination yielding expected benefits.
Valdes teaches from a plurality of service applications (Valdes [0029] “The health data service 101 may comprise a data server 109 and one or more service databases 111. The one or more service databases 111 may include a first database configured to store healthcare data records of users and a second database configured to store user healthcare profiles of the users. The first database may include one or more first sub-databases and each of the one or more first sub-databases may be configured to store the healthcare data records of users. The second database may include one or more second sub-databases and each of the one or more second sub-databases may be configured to store the user healthcare profiles of the users. In some embodiments, a single database may be configured to store the healthcare data records of users and the user healthcare profiles of the users. The health data server 101 may receive data records of various data types over one or more networks 113 from the data sources 103; each data source 103 may comprise a data source device 115 (for example, a healthcare data-generating system/device) and/or a source database 117. In operation, the data server 109 of the health data service 101 may receive data from a variety of data sources 103 over the one or more networks 113. The data server 109 may then standardize the received data according to a common data model, and store the standardized health data into a service database 111. The data server 109 may then execute one or more analytics processes on the standardized health data and provide the standardized health data over the one or more networks 113 to the user device 107 that may present health data reports and insights through various interactive graphical user interfaces (GUIs) to an end user, in accordance with the particular function or application executed by the user computing device 107.”);
wherein each of the service applications is configured to determine, for the patient, a respective personalized healthcare parameter (Valdes [0028] “FIG. 1A shows components of an exemplary healthcare data system 100, which may include a health data service 101, one or more data sources 103, and user devices 107. The health data service 101, the data sources 103, and the user computing devices 107 are connected to each other through a network 113.”, Valdes [0030] “A health data service 101 may receive records from a variety of data sources 103, and may convert the arriving data into a standardized data model that may be used to generate various GUIs or used to generate certain analytical data values resulting from various analytical algorithm models executed by a data server 109. In some embodiments, the health data service 101 may generate and transmit a request to a user on a user device 107 to receive records, and then the user may provide the health data service 101 access to the data sources 103 for obtaining the records. In some embodiments, the health data service 101 may generate and transmit a request to a user on a user device 107 to receive records, and then the user may access the data sources 103 for obtaining the records, and then transmit the records to the health data service 101. The records regarding the individual user/patient may be received and/or collected from diverse data sources 103 (as depicted in FIG. 1B) including, but not limited to information from claims through previous health plans 103 a, connected devices 103 b, clinical data 103 c, member data 103 d, genomics data 103 e, pharmacy data 103 f, physician data 103 g, and other sources such as multiple EMR's being used from different providers providing care to that user/patient, medication records from the pharmacy benefit managers (“PBMs”), information from labs and imaging centers, and direct input by the user/patient to provide a unified personal/individual health record.”);
generating first personalized input data in the healthcare application, the first personalized input data being generated according to the first input data information, wherein the generation of first personalized input data comprises receiving healthcare data from one or more healthcare data sources and generating the first personalized input data from the received healthcare data which includes checking whether the received healthcare data are complying with the data specification of first input data of the first service application ((Valdes [0031] “In some embodiments, the data collected from the diverse data sources 103 is organized into an individual health record for the user/patient. For instance, the data server 109 may generate user healthcare profile records for the users that is compiled using the incoming data records received from the various data sources 103 such as user/patient questionnaires or direct input, medical devices, patient portals, EMR systems, claims files, health plans, pharmacy benefits managers, labs, imaging centers, freestanding outpatient facilities, hospitals, physicians, and wearable devices. In some embodiments, the data server 109 may receive data records from the various data sources 103 and then convert the inbound data from a source data model, of the data source 103, to a standardized model employed by the various components of the healthcare data service 101. In order to convert the incoming data records, the data server 109 may execute one or more application programming interfaces (APIs) that map the data fields of the inbound data records to the data fields of the standardized model. For instance, records arriving from the data source 103 employing a healthcare application (e.g., AllScripts®) may provide inbound records having a first data model (e.g., HL7). These inbound records would then be converted by the data server 109 to the standardized model, associated with a consumer identifier (consumer ID) and stored into the service database 111. In one example, the individual healthcare data records collected from the variety of data sources 103 by the data server 109 may be integrated with universal health care concept codes of the standardized model to allow the healthcare data records to be encoded under specific medical diagnostic concepts. In some cases, the data server 109 may capture, share, and aggregate the healthcare data records collected from the variety of data sources 103 in a consistent manner by the standardized model universal health care concept codes terminology. The terminology may contain hierarchically specified health care concepts, each with unique meanings and logic-based definitions. Additionally, the health care concepts may have distinct relationships that support reliability and consistency for healthcare data record retrieval from the variety of data sources 103. As used herein, the universal health care concept codes corresponds to a standardized data model language that enables a consistent way of indexing, storing, retrieving, formatting, and aggregating healthcare data record across specialties and sites of medical care obtained from the variety of data sources 103. Each “universal health care concept code” is a unique identifier indicative of a node in a hierarchy of health care concepts to which other types of healthcare data record obtained from the variety of data sources 103 can be mapped.”);
outputting the first personalized healthcare parameter to a receiving device connected to the data processing component (Valdes [0063] “In a next step 214, the healthcare server computer display the one or more healthcare reports and insights based on evaluation of the data in the one or more data fields of the user healthcare profile on a graphical user interface of the user computing device. The one or more healthcare reports and insights may include ovulation report based on analysis of skin temperature, core temperature, and oxygen consumption obtained from the user healthcare profile; sleep onset/wake report based on analysis of heart rate, pulse rate, and respiration data obtained from the user healthcare profile; calories burned report based on analysis of heart rate, pulse rate, respiration rate, heat flow, activity, and oxygen consumption data obtained from the user healthcare profile; metabolic rate report based on analysis of heart rate, pulse rate, respiration rate, heat flow, activity, and oxygen consumption data obtained from the user healthcare profile; and activity level report based on heart rate, pulse rate, respiration rate, heat flow; stress level report based on analysis of heart rate, pulse rate, respiration rate, skin temperature, heat flow, galvanic skin; and relaxation level report based on EKG, beat-to-beat variability, heart rate, and pulse rate data obtained from the user healthcare profile.”).
Therefore, it would be obvious to a PHOSITA before the effective filing date of the invention to combine Cohen with Valdes because Cohen requires generating diagnostic or therapeutic parameters from heterogeneous medical data originating from numerous devices, records, and user inputs, but it does not describe how to reconcile differences in data formats, models, or units before the analytics are performed. Valdes addresses this technical challenge by teaching a standardized model conversion engine that receives data from diverse healthcare sources and automatically converts, normalizes, and validates those records into a uniform data specification suitable for downstream analytical processing. Integrating Valdes’s well established data standardization and model mapping techniques into Cohen’s system would have been a predictable design choice because it provides the functionality Cohen’s analytical layer implicitly requires, ensuring that the personalized input data conforms to the appropriate specification before generating individualized health parameters. The combination substitutes a known, effective data normalization mechanism for Cohen’s unspecified input handling operations, yielding improved accuracy and consistency, all of which a PHOSITA would reasonably do.
Regarding claim 2, Cohen, Vasudevan, Valdes teach the invention in claim 1, as discussed above, and further teach wherein the generating of the first input data request further comprises, in the interface application, determining one or more pre-selected first service applications from the plurality of service applications, each of the one or more pre-selected first service applications being configured to determine the first personalized healthcare parameter; and selecting the first service application from the one or more pre-selected first service applications (Vasudevan, Col 2, lines 2-22, “The at least one API server is configured to receive an API call from the client application, wherein the API call includes at least credentials provided by the client application; send a request to the at least one authentication server, wherein the request includes the credentials; receive an authorization token from the at least one authentication server in response to the request, when the at least one authentication server determines successful authorization of the client application based on the credentials; send a first query to the metadata repository, wherein the first query includes the authorization token in its header; receive, from the metadata repository, an API signature as a response to the first query, wherein the API signature includes at least input parameters of the API and a definition of the API, the API signature being generated by the metadata repository using the API metadata information; send a second query to a target database, wherein the second query includes the API signature; receive, from the target database, an API response to the second query, wherein the API response includes target data that is retrieved from the target database; and send the API response to the client application.” and
Valdes [0029] “The health data service 101 may comprise a data server 109 and one or more service databases 111. The one or more service databases 111 may include a first database configured to store healthcare data records of users and a second database configured to store user healthcare profiles of the users. The first database may include one or more first sub-databases and each of the one or more first sub-databases may be configured to store the healthcare data records of users. The second database may include one or more second sub-databases and each of the one or more second sub-databases may be configured to store the user healthcare profiles of the users. In some embodiments, a single database may be configured to store the healthcare data records of users and the user healthcare profiles of the users. The health data server 101 may receive data records of various data types over one or more networks 113 from the data sources 103; each data source 103 may comprise a data source device 115 (for example, a healthcare data-generating system/device) and/or a source database 117. In operation, the data server 109 of the health data service 101 may receive data from a variety of data sources 103 over the one or more networks 113. The data server 109 may then standardize the received data according to a common data model, and store the standardized health data into a service database 111. The data server 109 may then execute one or more analytics processes on the standardized health data and provide the standardized health data over the one or more networks 113 to the user device 107 that may present health data reports and insights through various interactive graphical user interfaces (GUIs) to an end user, in accordance with the particular function or application executed by the user computing device 107.” Valdes [0031] “In some embodiments, the data server 109 may receive data records from the various data sources 103 and then convert the inbound data from a source data model, of the data source 103, to a standardized model employed by the various components of the healthcare data service 101. In order to convert the incoming data records, the data server 109 may execute one or more application programming interfaces (APIs) that map the data fields of the inbound data records to the data fields of the standardized model. For instance, records arriving from the data source 103 employing a healthcare application (e.g., AllScripts®) may provide inbound records having a first data model (e.g., HL7). These inbound records would then be converted by the data server 109 to the standardized model, associated with a consumer identifier (consumer ID) and stored into the service database 111”. and
Cohen [0062] Data analysis and presentations of the reported information may be employed to develop and support diagnostic and therapeutic parameters. Where information on the report relates to an individual subject, the diagnostic and therapeutic parameters may be used to assess the health status and relative well being of that subject, as well as to develop or modify treatment for the subject. Where information on the report relates to groups of subjects or conglomerates of data, the diagnostic and therapeutic parameters may be used to assess the health status and relative well being of groups of subjects with similar medical con