DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Status
Claim 1 has been amended.
Claims 1-20 are pending. No claims are cancelled or newly added.
Drawings
The drawings were received on 2/17/26. These drawings are acceptable.
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 a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 2A Prong 1: The claims recite an abstract idea of targeted patient interactions collecting patient data from a service, analyzing patient data and generating and presenting recommended services wherein the targeted patient event is generated by the analysis of the patient data, which is a certain method of organizing human activity (e.g. fundamental economic principles or practices including hedging, insurance, mitigating risk; commercial or legal interactions including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, business relations; managing personal behavior or relationships or interactions between people including social activities, teaching, and following rules or instructions). The following limitations set forth the abstract idea:
Independent claim 1
receiving, data associated with a patient;
collecting, by at least one channel, patient data associated with the patient, wherein the patient data includes both structured and unstructured data across historical electronic health records (eHRs), real-time patient generated context and content that is collected from at least one partner service API;
analyzing,
generating,
presenting the recommended services and health outcomes to the patient in user interface.
Independent claim 11
wherein the patient data includes both structured and unstructured data across historical electronic heath records (eHRs), real-time patient data and patient generated context and content,
and
Step 2A Prong 2: The claim limitations recite the following additional elements that are beyond the judicial exception:
by a processor (Claim 1)
By an analytics engine (Claim 1)
a cloud infrastructure layer executing on a computing device that includes database storage and a network interface that provides for networking capabilities; (claim 11)
a data management layer executing on the computing that includes an Application Programming Interface (API) and communication layer, (claim 11)
a business process management layer, (claim 11)
a rules layer, (claim 11)
an ID management layer, (claim 11)
a data access layer, (claim 11)
a Lightweight Directory Access Protocol (LDAP) layer, (claim 11)
a database federation layer (claim 11)
by the cloud infrastructure layer (claim 11)
These additional elements are not indicative of integration into a practical application because: Regarding by a processor, by an analytics engine, a business process management layer, a rules layer, an ID management layer, a data access layer, a database federation layer, they add the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on or with a computer, or merely uses a computer as a tool to perform an abstract idea. See MPEP 2106.05 (f);
Regarding the a cloud infrastructure layer executing on a computing device that includes database storage and a network interface that provides for networking capabilities, by the cloud infrastructure layer, a data management layer executing on the computing that includes an Application Programming Interface (API) and communication layer, and a Lightweight Directory Access Protocol (LDAP) layer which generally links the use of the judicial exception to a particular technological environment or field of use (e.g. merely an attempt to limit the use of the abstract idea to a particular technological environment). See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716 and MPEP 2106.05 (h).
When considered as a combination, the combination of additional elements only generally limits the abstract idea to a particular technological environment of computing. As such the combination of additional elements does not amount to significantly more than the abstract idea.
Therefore under step 2A prong II the claims are directed to an abstract idea.
Step 2B: The claim limitations do not recite additional elements, or an ordered combination of additional elements, that are sufficient to amount to significantly more than the judicial exception.
As discussed with respect to step 2A prong 2 above, the additional elements by a processor, by an analytics engine, a business process management layer, a rules layer, an ID management layer, a data access layer, a database federation layer are mere instructions to apply an exception, and do not integrate a judicial exception into a practical application at step 2A or provide an inventive concept at step 2B.
According to the MPEP 2106, a conclusion that an additional element is mere instructions to apply an exception under step 2A should be re-evaluated at step 2B. Thus, the additional elements of by a processor, by an analytics engine, a business process management layer, a rules layer, an ID management layer, a data access layer, a database federation layer are simply the use of a computer in its ordinary capacity and does not provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262 and MPEP 2106.05 (f). For example, the additional elements only provide a result-oriented solution and lack details as to how the computer performs the modifications, which is equivalent to “apply it”. See Alice Corp. v. CLS Bank, 134 S. Ct. 2347, 2357 and MPEP 2106.05 (f).
A conclusion that an additional element is mere instructions to apply an exception under step 2A should be re-evaluated at step 2B. Regarding the from the collected a cloud infrastructure layer executing on a computing device that includes database storage and a network interface that provides for networking capabilities, by the cloud infrastructure layer, a data management layer executing on the computing that includes an Application Programming Interface (API) and communication layer, and a Lightweight Directory Access Protocol (LDAP) layer which generally links the use of the judicial exception to a particular technological environment or field of use (e.g. merely an attempt to limit the use of the abstract idea to a particular technological environment). See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716 and MPEP 2106.05 (h).
Therefore, when considering all the additional claim elements both individually and as an ordered combination, Examiner finds that the independent claims do not amount to significantly more than the exception.
Therefore, independent claims 1 and 11 are not patent eligible.
Dependent claims 8 and 18 disclose of additional elements of: Wearables, IOT devices, electronic health records, customer relation management systems, social media and prescription systems of which are which is insignificant extra-solution activity (e.g. insignificant application). See Apple, Inc. v. Ameranth, 842 F.3d 1229, 1241-1242 and MPEP 2106.05(g).
Dependent Claims 2 – 7, 9 – 10, 12 – 17, 19 – 20 further narrow the abstract idea and/or the additional elements disclosed in the claims have been addressed above. These claims do not integrate the abstract ideas into practical applications or amount to significantly more than the abstract idea.
Therefore, the dependent claims fail to cure this deficiency and are rejected accordingly.
Claim Rejections - 35 USC § 103
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1-10 are rejected under pre-AIA 35 U.S.C. 103 as being unpatentable over US PG Pubs 20170243028 – Lafever et al. hereinafter as LAFEVER in view of Haimson et al. hereinafter as HAIMSON (US PG Pubs 20200272919).
Regarding Claim 1:
LAFEVER discloses:
A computer implemented method for targeted patient interactions including:
receiving, by a processor, a patient identifier, wherein the patient identifier contains identifying data associated with a patient; (para. 0575)
collecting, by at least one channel, patient data associated with the patient, wherein the patient data ----includes both structured and unstructured data across historical electronic health records (eHRs) (para. 0538 Electronic Medical Record (EMR) contain specific data, such as red blood cell count, blood pressure, ICD-disease codes and the like; i.e., structured data and “notes” fields composed of text; i.e., unstructured data), real-time patient generated context (para. 0370 “Mobile devices implementing one or more aspects of the present disclosure may possess real-time knowledge of location, activity and/or behavior”) and content that is collected from at least one partner service API (collect, para. 0008. See also para. 0316 social media activity. APIs, para. 0610),
analyzing, by an analytical engine----, and by applying…a regression analysis or measures, the patient data to determine location, context, and content scores with propensities that determine predicted health needs of the patient (para. 0371 “physical locations, calling habits, content preferences, and online transactions” See also Figure 6; para. 0173, a privacy/anonymity level may consist of a mathematical specification, an “Anonymity Measure Score”, para. 0466, The Anonymity Measurement Score measurement schema ties statistical probabilities of re-identification to create multiple ratings depending on the level and degree of disassociation and/or replacement applied to data elements; para. 0539, any value that could be derived from any analysis of a notes field, including but not limited to Bayesian, Markovian, or heuristic analyses, could also be used to define the existence of a cohort and membership in that cohort could be enabled by an A-DDID assigned to all records belonging to said cohort);
generating, by the processor, recommended services in accordance with the predicted health needs to improve health outcomes (figure 1 G and fig. 6 blood pressure, request patient for collection para. 0631. Also see para. 0243 – 0247. Para. 0631 blood pressure related recommendation); and
presenting the recommended services and health outcomes to the patient in user interface ([0073] “device may, in response to the shared temporally unique representations (TDRs), receive targeted advertising or marketing information” and [0631] where TDRs include e.g., blood pressure information).
LAFEVER does not explicitly disclose analyzing the patient data by applying regression analysis or normative discourse measures.
However, HAIMSON teaches collecting patient data associated with the patient, wherein the patient data includes both structured and unstructured data across historical electronic health records, real-time patient generated context and content, and analyzing, by applying a regression analysis or normative discourse measures, the patient data to determine.. context and content scores with propensities that determine predicted health needs of the patient, generating recommended services in accordance with the predicted health needs to improve health outcomes and presenting the recommended services and health outcomes to the patient. HAIMSON teaches the use of medical records that may include analysis of at least one of structured and unstructured information relative to the patient and an ECOG score, a prognostic score that enables physicians to track a patient’s level of functioning. HAIMSON teaches applying one or more models to received medical results to generate prognostic results including, for example, survivability scores and other performance status indicators relating to the patient’s treatment or well-being. Prognostic results may include a variety of different predictions about a patient based on medical record, and may include a calculated survivability score that may include a time estimate of how long the patient is expected to survive and may be represented on a scale or as a percentage. Various other “performance status” indicators may be included in prognosis results and may include any indication of a patient’s current health or well-being, and may relate to the emotional or mental health of the patient. For example, based on analysis of notes taken by a physician, the system may determine whether a patient has a positive or negative outlook in response to a treatment, whether the patient shows signs of depression, whether the patient exhibits certain mental side-effects, or any other information regarding the patient’s emotional well-being, and may be represented as a score (e.g., a numerical value, a text-based classification, etc.) similar to the survivability score. Machine learning system may generate a trained model based on a set of training data associated with a patient and may use the model to generate a survivability score or a number of other predictions related to the patient. Training of model may involve the use of a training data set which may be input into training algorithm to develop the model. Training data may include a plurality of patient medical records. Machine learning system may extract one or more features from the records to determine correlations between the features and a particular patient result. The training process may correlate data such as the patient’s weight, gender, recorded vital signs, diagnosis code, etc. with an associated survivability of the patient or other result. The machine learning system may employ any suitable machine learning algorithm for example, training algorithm may include logistic regression that generates one or more functions or rules that relate extracted features to particular patient results. Other types of machine learning techniques may also be used, either in combination with or separate from the logistic regression technique, such as a linear regression model. The survivability prediction may indicate an estimated duration of the patient’s survival, including a time estimate of how long the patient is expected to survive. In some embodiments, the time estimate of how long the patient is expected to survive may be relative to an initiation date of a therapy, such as the administration of a drug or initiation of a particular cancer treatment. The survivability score may also be presented in various other formats. The predicted performance status is not limited to a survivability score, and may include other indicators of the patient's status, such as the current stage of treatment the patient is in, an assessment of the patient's current health or condition, a patient's response to a particular treatment, the patient's susceptibility to a certain disease, a patient's emotional or mental health, or various other status indicators. Prognosis results may also include a suitability of including the patient in a clinical trial. For example, system may determine the patient's suitability for one or more clinical trials based on a generated performance status indication, such as a generated survivability score, or other factors used in the machine learning process. The clinical trial may involve treating the patient using a particular therapy or technique. For example, this may include an innovative cancer therapy or an experimental drug treatment. The patient's suitability output may be represented in the prognosis results in a binary “recommended” or “not recommended” format, as shown in FIG. 3. Alternatively, the patient's suitability may be represented in a graduated format, such as on a scale (e.g. from 1-10), as a percentage, a range of classifications (e.g. “highly suitable,” “moderately suitable,” etc.), or in various other formats [abstract, paragraph 0004, 0006, 0026, 0030-0031, 0033, 0035-0039, 0049].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of LAFEVER to apply regression analysis or normative discourse measures to patient data to determine scores with propensities that determine predicted health needs of the patient, as taught by HAIMSON, because doing so provides a quantifiable assessment of a patient’s likelihood of death, short term improvement and overall well-being to help determine an appropriate treatment plan when considering a combination of a multitude of factors, many of which are subjective and not easily measurable and when an ECOG score is absent, using data from the patient’s medical record, and predicting the patient’s response to a particular treatment or assessing the patient’s suitability for a clinical trial [Haimson, paragraphs 0003 and 0005]
Regarding Claim 2:
LAFEVER / HAIMSON disclose the computer implemented method of claim 1.
LAFEVER further discloses:
2. wherein the context is anyone of a telecommunications, retail, patient products, pharma, financial, and healthcare context. ( healthcare, Fig. 1D-G)
Regarding Claim 3:
LAFEVER / HAIMSON disclose the computer implemented method of claim 1.
LAFEVER further discloses:
3. further including managing analytics of unstructured data. (unstructured data, para. 0539)
Regarding Claim 4:
LAFEVER / HAIMSON disclose the computer implemented method of claim 3.
LAFEVER further discloses:
4. further including a predictive analytics engine for creating or monetizing branding campaigns (advertising or marketing information based on location, para. 0073) and demand generation for Health Care interaction and quality. (demand, para. 0016)
Regarding Claim 5:
LAFEVER / HAIMSON disclose the computer implemented method of claim 1.
LAFEVER further discloses:
5. further comprising: aggregating the patient data into a single view of the patient; and determining, in real-time, the predicted health needs for health services from the single view. (Fig 1 and 1G and real-time, para. 0243 – 0247)
Regarding Claim 6:
LAFEVER / HAIMSON disclose the computer implemented method of claim 1.
LAFEVER further discloses:
6. further comprising: determining at least one analytical indicator to derive the normative discourse measures; determining how the patient is reacting to the recommended service; and adjusting a patient interaction with a health integration platform in accordance with how the patient is reacting. (Wherein a user interface allows the change of privacy policies over category of data. para. 0555)
Regarding Claim 7:
LAFEVER / HAIMSON disclose the computer implemented method of claim 1.
LAFEVER further discloses:
7. further comprising: developing a patient data model of a patient persona that is coupled to the patient’s interactions; and providing the recommended services in accordance with the patient data model. (data profile for each data subject, para. 0633)
Regarding Claim 8:
LAFEVER / HAIMSON disclose the computer implemented method of claim 1.
LAFEVER further discloses:
8. wherein the at least one channel includes wearables, loT devices, electronic health records, customer relation management (CRM) systems, social media, and prescription systems. ( para. 0027)
Regarding Claim 9:
LAFEVER / HAIMSON disclose the computer implemented method of claim 1.
LAFEVER further discloses:
9. further comprising applying predictive analytics provide a visualization of the patient data. (blood pressure levels as a graph. para. 0457)
Regarding Claim 10:
LAFEVER / HAIMSON disclose the computer implemented method of claim 1.
LAFEVER discloses:
10. further comprising: providing a single source for the patient data; and providing contextual view of the patient data in a user interface. (interface, para. 0375, para. 0324)
Claims 11 – 20 are rejected under pre-AIA 35 U.S.C. 103 as being Unpatentable over US PG Pubs 20170243028 – Lafever et al. hereinafter as LAFEVER in further view of WO2016118979 – Siebel et al. hereinafter as SIEBEL
Regarding Claim 11:
LAFEVER discloses:
11. A health exchange platform system, comprising:
a cloud infrastructure layer executing on a computing device that includes database storage and a network interface that provides for networking capabilities (cloud, Fig 1Y-1);
a data management layer executing on the computing device that includes an Application Programming Interface (API) and communication layer, a business process management layer, a rules layer, an ID management layer (identification, identifiers, para. 0009), a data access layer ( data privacy, para. 0017), a Lightweight Directory Access Protocol (LDAP) layer, (LDAP para. 0578),
wherein a patient identifier containing identifying data for a patient is received by the cloud infrastructure layer (cloud, Fig 1Y-1, para. 0575),
wherein patient data associated with the patient and at least one channel and at least one partner service is collected by the data management layer using the API ( collect, para. 0008, APIs, para. 0610),
wherein the patient data includes both structured and unstructured data across historical electronic heath records (eHRs) (para. 0538 Electronic Medical Record (EMR) contain specific data, such as red blood cell count, blood pressure, ICD-disease codes and the like; i.e., structured data, and “notes” fields composed of text; i.e., unstructured data), real-time patient data (para. 0370 real-time knowledge of location, activity and/or behavior) and patient generated context and content (para. 0316 social media activity),
and wherein an analytical engine in the data management layer analyzes the patient data to recommended services in accordance with predicted health needs to improve health outcomes (figure 1 G and fig. 6 blood pressure, request patient for collection para. 0631. Also see para. 0243 – 0247. See also para .0631 blood pressure related recommendation).
LAFEVER discloses of database but doesn’t explicitly disclose a database federation layer.
SIEBEL discloses a database federation layer (federated data, para. 0215).
One of ordinary skill in the art before the effective filling date of the Applicant’s invention would have recognized that applying the known technique of a database federation layer of SIEBEL would have yielded predictable results in an improved system. It would have been recognized that applying the teachings of SIEBEL to the teachings of LAFEVER would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate the database federation layer into a similar system. Further applying the database federation layer would have been recognized by those of ordinary skill in the art as result in an improved system that would allow more detailed results. Therefore, the combination would have been obvious.
Regarding Claim 12:
LAFEVER / SIEBEL disclose the health exchange platform system of claim 11
LAFEVER discloses:
12. further wherein the context is selected from any one of a telecommunications, retail, patient products, pharma, financial, and healthcare context. ( healthcare, Fig. 1D-G)
Regarding Claim 13:
LAFEVER / SIEBEL disclose the health exchange platform system of claim 11
LAFEVER discloses:
13. wherein the data management layer further manages analytics of unstructured data. (unstructured data, para. 0539)
Regarding Claim 14:
LAFEVER / SIEBEL disclose the health exchange platform system of claim 13
LAFEVER discloses:
14, wherein the data management layer further includes a predictive analytics engine for creating or monetizing branding campaigns (advertising or marketing information based on location, para. 0073) and demand generation for Health Care interaction and quality. (demand, para. 0016)
Regarding Claim 15:
LAFEVER / SIEBEL disclose the health exchange platform system of claim 11
LAFEVER discloses:
15. wherein the data management layer further aggregates the patient data into a single view of the patient, and wherein patient predicted health needs for health services from the single view are determined in near real-time. (Fig 1 and 1G and real-time, para. 0243 – 0247)
Regarding Claim 16:
LAFEVER / SIEBEL disclose the health exchange platform system of claim 11
LAFEVER discloses:
16. wherein the data management layer further determines at least one analytical indicator to derive normative discourse measures, and determines how the (Wherein a user interface allows the change of privacy policies over category of data. para. 0555 )
Regarding Claim 17:
LAFEVER / SIEBEL disclose the health exchange platform system of claim 11
LAFEVER discloses:
17. wherein the data management layer further develops a patient data model of a patient persona that is coupled to the patient's interactions and provides the recommended services in accordance with the patient data model. ( data profile for each data subject, para. 0633)
Regarding Claim 18:
LAFEVER / SIEBEL disclose the health exchange platform system of claim 11
LAFEVER discloses:
18. wherein the at least one channel includes wearables, loT devices, electronic health records, customer relation management (CRM) systems, social media, and prescription systems. ( para. 0027)
Regarding Claim 19:
LAFEVER / SIEBEL disclose the health exchange platform system of claim 11
LAFEVER discloses:
19. wherein the data management layer further applies predictive analytics provide a visualization of the patient data. (blood pressure levels as a graph. para. 0457)
Regarding Claim 20:
LAFEVER / SIEBEL disclose the health exchange platform system of claim 11
LAFEVER discloses:
20. wherein a single source for the patient data is provided, and wherein a contextual view of the patient data is presented in a user interface. (interface, para. 0375, para. 0324)
Response to Arguments
Applicant's amendments and arguments filed February 17, 2026 have been fully considered and either overcome the previous rejections or are not persuasive.
35 U.S.C. 112(a)
Applicant's arguments have been fully considered and are persuasive.
35 U.S.C. 101
Applicant's arguments have been fully considered but are not persuasive.
Regarding the 35 USC 101 rejection, Applicant argues on pages 10-11 that claims 1 and 11 are directed to specific computer-implemented improvements in the way health data is acquired, generated, analyzed and used to generate patient-facing recommendations. Similarly, Applicant argues that the requirement that patient data “includes both structured and unstructured data across EHRs, real-time patient generated context and content that is collected from at least one partner service API”, the use of an “analytical engine” that applies “a regression analysis or normative discourse measures” to determine “location, context and content scores with propensities that determine predicted health needs of the patient” and the generation of recommended services “in accordance with the predicted health needs to improve health outcomes” provide “significantly more” under Step 2B. The Applicant further argues that the claimed health exchange platform provides a unified “single source of truth” architecture allowing disparate health data sources to be federated via the database federation layer and accessed through standardized APIs and rules-driven workflows.
Examiner disagrees. Applicant does not specifically identify how “the way health data is acquired, generated, analyzed and used” or “the functioning of the underlying computer-based health platform itself” constitutes an improvement to the underlying computer or technology. However, receiving and collecting patient data and patient identifiers has been identified as being directed to the recited abstract idea, as is the analysis of the patient data and generation of recommended services. Further, the recited processor, is cited in an “apply it” manner in carrying out the abstract idea, particularly in performing regression analysis or normative discourse measures to determine location, context and content scores with propensities that determine predicted health needs and generate recommended services to improve health outcomes. Thus, the additional elements (e.g., the processor) fail to integrate the abstract idea into a practical application or provide significantly more, and the claim does not establish a technical solution to a technical problem, as receiving and collecting patient data to be analyzed to predict health needs of a patient and generate recommendations to improve patient health outcomes is not a technical problem, as medical diagnosis and treatment of patients predate computers and internet/network technology. Specifying that the patient data includes both structured and instructed data does not constitute significantly more, or a technical improvement.
Applicant also argues that the claims do not recite fundamental economic practices, generic marketing or social interactions.
Examiner disagrees. However, those are not the exhaustive types of concepts deemed to be “certain methods of organizing human activity”. Per MPEP 2106.04(a)(2)(II)(C), the sub-grouping "managing personal behavior or relationships or interactions between people" include social activities, teaching, and following rules or instructions. One such example of managing personal behavior recited in a claim include a mental process that a neurologist should follow when testing a patient for nervous system malfunctions, In re Meyer, 688 F.2d 789, 791-93, 215 USPQ 193, 194-96 (CCPA 1982). Further, this sub-grouping encompasses both activity of a single person (for example, a person following a set of instructions or a person signing a contract online) and activity that involves multiple people (such as a commercial interaction), and thus, certain activity between a person and a computer (for example a method of anonymous loan shopping that a person conducts using a mobile phone) may fall within the "certain methods of organizing human activity" grouping.
35 U.S.C. 103
Applicant's arguments have been fully considered but are not persuasive.
Applicant argues on page 13 that neither LaFever or Coffman teach or suggest combining historical EHR data, real-time patient-generated context/content and user-generated content to derive location, context and content scores with health propensities to predict health needs of a patient, or applying normative discourse measures to heterogeneous health data to compute propensities or predict health needs.
Examiner disagrees. It is noted that claim 1 recites applying “a regression analysis or normative discourse measures”. In other words, normative measures are not required to satisfy the claim. Similarly, the claim does not recite user-generated content. Further, in view of the Applicant’s amendments, specifying that the applied regression is “regression analysis” and the applied normative discourse are “normative discourse measures”, the prior art rejection has been updated, and Coffman is no longer relied upon to teach the limitations argued. See the updated prior art rejection of claim 1, where Haimson teaches using patient medical records that include at least one of structured and unstructured information, including information about the context of words or phrases that are part of the structured or unstructured information in the electronic text in the patient medical records. Haimson further applies a regression analysis as part of a machine learning process to predict health needs of a patient and generate and present recommended services and health outcomes to the patient.
With respect to claim 11, Applicant argues on page 15 that Siebel does not teach a system in which the data management layer collects “patient data associated with the patient and at least one channel and at least one partner service” where the patient data “includes both structured and unstructured data across EHRs, real-time patient data and patient generated context and content” nor does it describe an analytical engine that “analyzes the patient data to recommended services in accordance with predicted health needs to improve health outcomes”.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). The Applicant argues that Sibel does not teach limitations that it was not asserted as teaching, and thus the argument is not persuasive.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PETER H CHOI whose telephone number is (469)295-9171. The examiner can normally be reached M-Th 9am-7pm.
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.
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.
/PETER H CHOI/ Supervisory Patent Examiner, Art Unit 3681
Prosecution Insights