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 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 (an abstract idea) without reciting significantly more.
Regarding independent claims 1, 10, and 19
Step 1 — whether the claim falls within any statutory category. See MPEP 2106.03.
Claim 1 is drawn to a system claim reciting at least one device, a database, and at least one processor. Therefore, claim 1 falls within one of the four categories of statutory subject matter, namely a machine.
Claim 10 is drawn to a method claim. Therefore, claim 10 falls within one of the four categories of statutory subject matter, namely a process.
Claim 19 is drawn to a system claim reciting at least one device, a database, a network connection, and at least one processor. Therefore, claim 19 falls within one of the four categories of statutory subject matter, namely a machine.
Step 2A Prong 1 — whether the claim recites a judicial exception. See MPEP 2106.04, subsection II.
Regarding independent claim 1, the claim is directed to a system that preprocesses data extracted from a data source, stores the preprocessed data, extracts features from the preprocessed data to generate vectors, applies the vectors to a model, and generates from the vectors a signature representing an individual's propensity to engage in healthcare-related activities.
The limitation of "preprocess the extracted data, including performance of one or more of a transformation of the extracted data, a filtering of the extracted data, a modification of the extracted data, and a standardization of the extracted data" recites an abstract idea because it describes reformatting, selecting among, altering, and conforming information to a common form. Under the broadest reasonable interpretation, the claim does not recite any particular technique by which the transformation, filtering, modification, or standardization is accomplished. A human being can review collected records and rewrite, select, alter, or conform them to a uniform form using observation and judgment. This limitation therefore falls within the mental processes grouping of abstract ideas, that is, concepts performed in the human mind including observation, evaluation, judgment, and opinion. See MPEP § 2106.04(a)(2), subsection III.
The limitation of "perform vector extraction to extract features of at least a portion of the preprocessed data and generate a plurality of vectors from the extracted features of the preprocessed data" recites an abstract idea because it describes identifying salient items of information within a body of records and organizing those items into an ordered set of values. Under the broadest reasonable interpretation, the claim does not recite any particular feature-extraction algorithm, embedding technique, or dimensionality-reduction operation. Organizing information into an ordered set of numerical values is a mathematical relationship, and identifying which items of information to select is an evaluation and judgment. This limitation therefore falls within the mathematical concepts grouping and the mental processes grouping of abstract ideas. See MPEP § 2106.04(a)(2), subsections I and III.
The limitation of "generate, using the machine learning model and the plurality of vectors, a willingness signature associated with an individual, wherein the willingness signature is a numerical value or a probability distribution that represents a propensity of the individual to engage in healthcare-related activities" recites an abstract idea because it describes evaluating collected information about a person and producing a score or probability reflecting how likely that person is to engage in a particular kind of conduct. Under the broadest reasonable interpretation, the claim does not recite specific details regarding how the machine learning model derives the signature from the vectors. Computing a numerical value or a probability distribution from a set of values is a mathematical relationship, and assessing a person's likely future conduct from information about that person is an evaluation and judgment that a human being can perform mentally or with pen and paper. This limitation therefore falls within the mathematical concepts grouping and the mental processes grouping of abstract ideas. See MPEP § 2106.04(a)(2), subsections I and III.
Additionally, the generation of a score representing an individual's propensity to engage in healthcare-related activities, as described throughout the specification as a "willingness score" used to inform healthcare providers, payors, insurance companies, financial institutions, and government agencies in making decisions concerning that individual (specification ¶¶ [0053], [0094], [0098], [0099]), recites a fundamental economic practice, namely evaluating a consumer's likelihood of engaging in and paying for services. This limitation therefore also falls within the certain methods of organizing human activity grouping of abstract ideas. See MPEP § 2106.04(a)(2), subsection II.
Accordingly, independent claim 1 recites an abstract idea under Step 2A Prong One because the claim includes limitations falling within the mathematical concepts, certain methods of organizing human activity, and mental processes groupings of abstract ideas. Therefore, the analysis should proceed to Step 2A Prong Two.
Independent claim 10 is a method claim reciting limitations similar to claim 1, including preprocessing extracted data, storing the preprocessed data, performing vector extraction to generate a plurality of vectors, inputting the vectors into a machine learning model, and generating a willingness signature representing a propensity of an individual to engage in healthcare-related activities. These limitations recite an abstract idea for similar reasons as claim 1.
Independent claim 19 is a system claim reciting limitations similar to claims 1 and 10, and further reciting performing longitudinal record monitoring on the vectors over time, generating a longitudinal record, detecting updates to the vectors, retraining the model, issuing a notification, and providing recommendations, feedback, trend analysis, and score adjustments. Observing a set of values over time, recording their progression, noticing that they have changed, revising an assessment in light of the change, informing another person of the change, and offering advice based on the assessment are each acts of observation, evaluation, and judgment that a human being can perform mentally or with pen and paper. These limitations recite an abstract idea for similar reasons as claims 1 and 10.
Accordingly, under MPEP 2106.04, subsection II, and MPEP 2106.04(a)(2), subsections I, II, and III, independent claims 10 and 19 recite a judicial exception, namely an abstract idea.
Step 2A Prong 2 — whether the claim as a whole integrates the recited judicial exception into a practical application of the exception, or whether the claim is "directed to" the judicial exception. This evaluation is performed by (1) identifying whether there are any additional elements recited in the claim beyond the judicial exception, and (2) evaluating those additional elements individually and in combination to determine whether the claim as a whole integrates the exception into a practical application. See MPEP 2106.04(d).
Regarding independent claim 1, this claim recites additional elements of:
"at least one device configured to extract data from at least one internet-connected data source";
"at least one internet-connected data source";
"a database configured to store the preprocessed data";
"at least one processor"; and
"input the plurality of vectors into a machine learning model trained using historical data from the at least one internet-connected data source."
These limitations amount to no more than insignificant extra-solution activity and mere instructions to apply the judicial exception using generic computer components. The extraction of data from the internet-connected data source merely gathers the information on which the recited abstract idea operates, and the storage of the preprocessed data in the database merely retains that information for later use. See MPEP § 2106.05(g). The recited device, internet-connected data source, database, processor, and machine learning model are recited at a high level of generality and merely serve as tools for performing the abstract idea of organizing an individual's information, generating a signature from that information, and assessing that individual's propensity to engage in healthcare-related activities. See MPEP § 2106.05(f).
With respect to the recited machine learning model in particular, the claim recites only that the model is "trained using historical data" and that the plurality of vectors is input into it. The claim does not recite any particular model architecture, any particular training algorithm or objective, any particular manner in which the vectors are structured for input, or any improvement to the training or operation of the model itself. Under the 2024 Guidance Update on Patent Subject Matter Eligibility, Including on Artificial Intelligence, a claim that merely invokes a machine learning model as a tool to carry out an abstract idea, without reciting a specific improvement to the model or to computer technology, does not integrate the exception into a practical application. See MPEP § 2106.05(f).
The claim does not recite a particular improvement to the functioning of the device, the database, the processor, the machine learning model, or any other technology or technical field. See MPEP § 2106.05(a). The specification confirms that the asserted advance lies in the healthcare-financial assessment itself rather than in any computing technology, describing the invention as a "computerized decision support system for acquiring, normalizing and computing a healthcare financial scoring model ('willingness score')" (specification ¶ [0053]) implemented on an electronic device 101 comprising a conventional bus 110, processor 120, memory 130, I/O interface 150, display 160, and communication interface 170 (specification ¶¶ [0057]–[0058]). The claim also does not recite a particular machine that is integral to the claimed system, a transformation of a particular article to a different state or thing, or any other meaningful limitation that applies the exception in a manner beyond merely implementing the abstract idea in a computer environment. See MPEP §§ 2106.05(b), 2106.05(c), and 2106.05(e). To the extent the claim limits the abstract idea to data obtained from an internet-connected source and processed by a machine learning model, such limitations merely link the judicial exception to a technological environment or field of use. See MPEP § 2106.05(h).
Accordingly, the additional elements, individually and in combination, do not integrate the recited judicial exception into a practical application. Therefore, independent claim 1 is directed to the abstract idea under Step 2A, Prong Two.
Regarding independent claim 10, this claim is drawn to a method claim reciting limitations similar to claim 1 and is rejected under the same rationale. Claim 10 recites additional elements of "at least one internet-connected data source," "storing the preprocessed data in a database," and "inputting the plurality of vectors into a machine learning model trained using historical data from the at least one internet-connected data source." These limitations amount to no more than data gathering, data storage, and mere instructions to apply the abstract idea using a generic machine learning model. See MPEP §§ 2106.05(f), 2106.05(g), and 2106.05(h). Therefore, independent claim 10 is directed to the abstract idea under Step 2A, Prong Two.
Regarding independent claim 19, this claim is drawn to a system claim reciting limitations similar to claims 1 and 10 and is rejected under the same rationale. Claim 19 also recites additional elements of:
"a natural language processing model having access to a document data store";
"cause the preprocessed data to be stored using a blockchain network";
"a network connection between at least one processor and another device"; and
"generate a visual display of the longitudinal record and the willingness signature to the other device."
These limitations amount to no more than mere instructions to apply the judicial exception using generic computer components and insignificant extra-solution activity. The recited natural language processing model and document data store are invoked generically as tools for preparing the data on which the abstract idea operates, without any recitation of a particular language model, a particular augmentation or enrichment technique, or an improvement to natural language processing technology. See MPEP § 2106.05(f). The recited blockchain network is invoked solely as a storage location for the preprocessed data, without any recitation of a particular consensus mechanism, data structure, or improvement to distributed-ledger technology, and therefore amounts to selecting a generic storage medium and generally linking the abstract idea to a technological environment. See MPEP §§ 2106.05(f) and 2106.05(h). The recited network connection and visual display amount to transmitting the result of the abstract determination to a recipient and presenting it, which is insignificant post-solution activity. See MPEP § 2106.05(g). Therefore, independent claim 19 is directed to the abstract idea under Step 2A, Prong Two.
Step 2B — whether the claim amounts to significantly more than the judicial exception. See MPEP § 2106.05.
Regarding independent claim 1, the claim recites additional elements of:
at least one device configured to extract data from at least one internet-connected data source;
at least one internet-connected data source;
a database configured to store the preprocessed data;
at least one processor; and
a machine learning model trained using historical data.
These additional elements, individually and in combination, do not amount to significantly more than the judicial exception. The recited device, data source, database, and processor are generic computer components performing generic computer functions, including receiving data, storing data, processing data, and producing an output. Such generic computer implementation is well-understood, routine, and conventional when recited at this level of generality. See MPEP §§ 2106.05(d) and 2106.07(a)(III). The specification itself confirms as much, disclosing that the electronic device may be "a smartphone, a tablet personal computer (PC), a mobile phone, a video phone, an e-book reader, a desktop PC, a laptop computer, a netbook computer, a workstation, a personal digital assistant (PDA)" (specification ¶ [0035]) and that the processor may be "one or more microprocessors, microcontrollers, digital signal processors (DSPs), application specific" integrated circuits (specification ¶ [0058]).
The extraction of data from the internet-connected data source and the storage of the preprocessed data in the database amount to mere data gathering and data retention, which do not provide an inventive concept. See MPEP § 2106.05(g). The recited machine learning model is used only as a tool to generate the signature from the vectors, without reciting any particular model architecture, training improvement, or technological improvement to the machine learning model itself. This amounts to no more than instructions to apply the abstract idea using a generic computer environment. See MPEP § 2106.05(f). The specification confirms that conventional, off-the-shelf models are contemplated, disclosing the use of "linear regression," "logistic regression," "decision trees and random forests," "support vector machines," "K-means, Hierarchical clustering," "principal component analysis (PCA)," and "t-distributed stochastic neighbor embedding (t-SNE)" (specification ¶¶ [0076]–[0077]), each of which is a well-understood, routine, and conventional machine learning technique.
Additionally, limiting the abstract idea to healthcare data obtained from an internet-connected source and analyzed by a machine learning model merely links the abstract idea to a particular technological environment or field of use. See MPEP § 2106.05(h). Accordingly, claim 1 does not include additional elements that amount to significantly more than the judicial exception.
Regarding independent claim 10, the claim recites additional elements of at least one internet-connected data source, a database, and a machine learning model trained using historical data. These additional elements, individually and in combination, do not amount to significantly more than the judicial exception for the same reasons set forth above with respect to claim 1. See MPEP §§ 2106.05(d), 2106.05(f), 2106.05(g), 2106.05(h), and 2106.07(a)(III). Accordingly, claim 10 does not include additional elements that amount to significantly more than the judicial exception.
Regarding independent claim 19, the claim recites additional elements of:
at least one device, an internet-connected data source, a database, and at least one processor;
a natural language processing model having access to a document data store;
a blockchain network for storing the preprocessed data;
a network connection between the at least one processor and another device;
a machine learning model trained using historical data; and
generating a visual display of the longitudinal record and the willingness signature.
These additional elements, individually and in combination, do not amount to significantly more than the judicial exception. The recited device, data source, database, processor, and network connection are generic computer components performing generic computer functions and are well-understood, routine, and conventional when recited at this level of generality. See MPEP §§ 2106.05(d) and 2106.07(a)(III). The natural language processing model, the document data store, and the blockchain network are each invoked at a high level of generality as tools for preparing and storing the data on which the abstract idea operates, without any recitation of a particular technique or of an improvement to natural language processing or distributed-ledger technology. This amounts to no more than instructions to apply the abstract idea using generic components. See MPEP § 2106.05(f). The specification describes the blockchain merely as a place where "processed data can also be securely stored" (specification ¶ [0095]) and the natural language processing merely as a means to "analyze unstructured data, such as medical records, and extract relevant information to be stored in the database" (specification ¶ [0073]), neither of which identifies any technical advance.
The generation of a visual display of the longitudinal record and the willingness signature amounts to presenting the result of the abstract determination to a recipient and is insignificant post-solution activity that does not provide an inventive concept. See MPEP § 2106.05(g). Further, limiting the abstract idea to a networked healthcare system employing a machine learning model merely links the judicial exception to a technological environment or field of use. See MPEP § 2106.05(h). Accordingly, claim 19 does not include additional elements that amount to significantly more than the judicial exception.
Regarding dependent claims 2–9, 11–18, and 20
Dependent claims 2–9, 11–18, and 20 merely narrow the previously identified abstract idea limitations recited in independent claims 1, 10, and 19. For the reasons described above with respect to independent claims 1, 10, and 19, the judicial exceptions recited in these dependent claims are not meaningfully integrated into a practical application, nor do they amount to significantly more than the abstract ideas. The additional limitations introduced in the dependent claims further define the abstract idea using longitudinal observation of values, detection of changes in those values, revision of an assessment in light of the changes, communication of the assessment to a recipient, provision of advice based on the assessment, selection among conventional statistical techniques, and comparison of a current status against a threshold and a lower limit. These limitations constitute mathematical concepts and mental processes, including organizing, computing, comparing, observing, evaluating, and judging information, which are practically capable of being performed in the human mind or with the assistance of pen and paper. Accordingly, dependent claims 2–9, 11–18, and 20 also recite abstract ideas that do not integrate into a practical application and do not amount to significantly more than the judicial exception. Therefore, claims 2–9, 11–18, and 20 are rejected under 35 U.S.C. § 101.
Step 1 — whether the claim falls within any statutory category. See MPEP § 2106.03.
Dependent claims 2–9 depend from independent claim 1, which is drawn to a system. Therefore, each of claims 2–9 falls under at least one of the four categories of statutory subject matter, namely a machine.
Dependent claims 11–18 depend from independent claim 10, which is drawn to a method. Therefore, each of claims 11–18 falls under at least one of the four categories of statutory subject matter, namely a process.
Dependent claim 20 depends from independent claim 19, which is drawn to a system. Therefore, claim 20 falls under at least one of the four categories of statutory subject matter, namely a machine.
Step 2A Prong 1 — whether the claim recites a judicial exception. See MPEP § 2106.04, subsection II; MPEP § 2106.04(a)(2), subsections I, II, and III.
Regarding claim 2, this claim recites the limitations of "perform longitudinal record monitoring on the plurality of vectors over time" and "generate a longitudinal record of the individual based on the longitudinal record monitoring." These limitations are directed toward the abstract idea of a mental process because observing a set of values as they change over a period of time and compiling a record of that progression are acts of observation and evaluation that a human being can perform mentally or with pen and paper. See MPEP § 2106.04(a)(2), subsection III.
Regarding claim 3, this claim recites the limitations of "detect, based on the longitudinal record monitoring, updates to the plurality of vectors" and "retrain the machine learning model using the updates to the plurality of vectors." These limitations are directed toward the abstract idea of a mental process because noticing that observed values have changed, and revising one's basis of assessment in light of that change, are acts of observation, evaluation, and judgment. See MPEP § 2106.04(a)(2), subsection III. The claim does not recite any particular retraining algorithm or any improvement to the training of a machine learning model.
Regarding claim 4, this claim recites the limitation of "issue a real-time notification to one or more third parties based on the detected updates to the plurality of vectors." This limitation is directed toward the abstract idea of a mental process and of certain methods of organizing human activity, because informing another person of an observed change is an act of communication and managing interactions between people. See MPEP § 2106.04(a)(2), subsections II and III.
Regarding claim 5, this claim recites the limitations of "receive a request by the other device to access the longitudinal record" and "generate a visual display of the longitudinal record and the willingness signature to the other device." These limitations are directed toward the abstract idea of a mental process because receiving an inquiry for recorded information and presenting that information to the inquirer are acts of observation and communication. See MPEP § 2106.04(a)(2), subsection III.
Regarding claim 6, this claim recites the limitation of "provide to the other device, using the willingness signature, one or more of personalized recommendations, feedback, trend analysis, score adjustments, and real-time data monitoring updates." This limitation is directed toward the abstract idea of a mental process and of certain methods of organizing human activity because formulating advice for a person based on an assessment of that person, analyzing observed values for trends, and adjusting a score are acts of evaluation, judgment, and opinion, and constitute managing interactions between people. See MPEP § 2106.04(a)(2), subsections II and III.
Regarding claim 7, this claim recites the limitation of "cause the preprocessed data to be stored using a blockchain network." This limitation is not an abstract idea but is an additional element addressed under Step 2A Prong Two and Step 2B below.
Regarding claim 8, this claim recites the limitation of "wherein the preprocessing of the extracted data includes using a natural language processing model having access to a document data store to perform automated data augmentation and data enrichment on the extracted data." To the extent this limitation describes supplementing and categorizing collected records by reference to a reference source, it is directed toward the abstract idea of a mental process, because a human being can read a record, consult a reference work, and annotate or categorize the record accordingly. See MPEP § 2106.04(a)(2), subsection III. The recited natural language processing model and document data store are additional elements addressed under Step 2A Prong Two and Step 2B below.
Regarding claim 9, this claim recites the limitation of "wherein, to generate the willingness signature, the machine learning model is configured to perform at least one of feature classification, data clustering, and linear or logistic regression." This limitation is directed toward the abstract idea of a mathematical concept, specifically organizing information and manipulating information through mathematical correlations, because classification, clustering, and linear and logistic regression are mathematical operations performed on sets of values. See MPEP § 2106.04(a)(2), subsection I.
Regarding claims 11–18, these claims recite limitations corresponding to those of claims 2–9 respectively and are directed toward abstract ideas for the same reasons set forth above with respect to claims 2–9.
Regarding claim 20, this claim recites the limitations of "determine a health threshold value based on the longitudinal record," "monitor the health of the individual via a determination of whether a current status of the individual is within a range between the health threshold value and a lower limit," and "inform the other device of the current status of the individual when it is determined that the current status is within the range between the health threshold value and the lower limit." These limitations are directed toward the abstract idea of a mathematical concept and of a mental process, because setting a numerical threshold from recorded values and comparing a current value against an upper and a lower bound are mathematical relationships, and deciding on that basis whether to inform another person is an act of evaluation and judgment. See MPEP § 2106.04(a)(2), subsections I and III.
Step 2A Prong 2 — whether the claim as a whole integrates the recited judicial exception into a practical application. See MPEP 2106.04(d).
Regarding claims 2–6, 9, 11–15, 18, and 20, these claims recite the additional element of "at least one processor" and, in claims 5, 6, 14, 15, and 20, the additional elements of a network connection and "another device" or "a device." These limitations amount to no more than generally linking the use of the judicial exception to a particular technological environment or field of use, and to mere instructions to apply the abstract idea using generic computer components that act as tools on which the abstract idea operates. See MPEP §§ 2106.05(f) and 2106.05(h). The transmission of a notification and the generation of a visual display recited in claims 4, 5, 13, 14, and 20 amount to insignificant post-solution activity. See MPEP § 2106.05(g). Accordingly, these limitations fail to integrate the exception into a practical application.
Regarding claims 7 and 16, these claims recite the additional element of "a blockchain network." This limitation amounts to no more than selecting a generic storage medium on which to retain the data used by the abstract idea, and generally links the use of the judicial exception to a particular technological environment. The claim does not recite any particular consensus mechanism, ledger structure, cryptographic technique, or improvement to distributed-ledger technology. See MPEP §§ 2106.05(f) and 2106.05(h). Accordingly, this limitation fails to integrate the exception into a practical application.
Regarding claims 8 and 17, these claims recite the additional elements of "a natural language processing model" and "a document data store." These limitations amount to no more than mere instructions to apply the abstract idea using a generic computer model and a generic data repository, and constitute insignificant pre-solution activity directed to preparing the data on which the abstract idea operates. The claim does not recite any particular language model, any particular augmentation or enrichment technique, or any improvement to natural language processing technology. See MPEP §§ 2106.05(f) and 2106.05(g). Accordingly, these limitations fail to integrate the exception into a practical application.
Step 2B — whether the claim amounts to significantly more than the judicial exception. See MPEP § 2106.05.
Regarding dependent claims 2–9, 11–18, and 20, the additional elements identified above, considered individually and in combination, do not amount to significantly more than the judicial exception. The recited processor, database, network connection, other device, blockchain network, natural language processing model, and document data store are generic computer components performing generic computer functions, including storing data, retrieving data, transmitting data, processing data, and displaying results. Such generic computer implementation is well-understood, routine, and conventional when recited at this level of generality. See MPEP §§ 2106.05(d) and 2106.07(a)(III). The data-gathering, data-storage, notification, and display steps amount to insignificant extra-solution activity that does not provide an inventive concept. See MPEP § 2106.05(g). The recited machine learning techniques of claims 9 and 18, namely feature classification, data clustering, and linear or logistic regression, are conventional statistical techniques recited without any improvement, as confirmed by the specification's own characterization of them as known approaches (specification ¶¶ [0076]–[0077]). See MPEP § 2106.05(d). Accordingly, dependent claims 2–9, 11–18, and 20 do not include additional elements that amount to significantly more than the judicial exception, and are rejected under 35 U.S.C. § 101.
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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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, 2, 3, 5, 6, 9-12, 14, 15, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Rangadass et al. (Rangadass), US 2013/0054272 A1, in view of Wexler et al. (Wexler), US 2021/0383925 A1, and further in view of Bostic et al. (Bostic), US 2021/0202103 A1.
Regarding claim 1, Rangadass teaches a system comprising:
"at least one device configured to extract data from at least one internet-connected data source" — Rangadass teaches a receive module 84 within cOS 12 that receives data 82 from medical systems 14 and business systems 26, where those data sources interface with cOS 12 over the Internet (Rangadass, page 6, ¶ [0065]: "A receive module 84 in cOS 12 may receive data 82 (including medical data and non-medical data)"; page 7, ¶ [0071]: "receive module 84 may include suitable network interfaces for interfacing with other network elements in network 11. Receive module 84 may include signal processors, and other hardware to enable it to perform its operations"; page 2, ¶ [0016]: "Medical systems 14 and business systems 26 may interface with cOS 12 through external services 36 (e.g., Internet, wireless communication networks, etc.) that may interface with cOS 12"; page 6, ¶ [0060]: "The data may be provided to health record 52 through plurality of data sources 76(1)-76(N) (e.g., data source 1, data source 2 … data source N)"; FIG. 2).
"and preprocess the extracted data, including performance of one or more of a transformation of the extracted data, a filtering of the extracted data, a modification of the extracted data, and a standardization of the extracted data;" — Rangadass teaches a data converter module 86 that converts the received data 82 into a uniform format, which is a transformation and a standardization of the extracted data, and further teaches modifying the data into formats suitable to the recipient (Rangadass, page 6, ¶ [0065]: "A data converter module 86 may convert data 82 into a uniform format (e.g., associated with health record 52)"; page 4, ¶ [0041]: "cOS 12 may aggregate information from the various medical data sources, convert them to a uniform format (e.g., XML based format), and store the information in cOS data store 50 as health record 52 of the individual"; page 7, ¶ [0071]: "Data converter module 86 may also include data converters that can convert data from one format into another (e.g., uniform format). Incoming data whose format cannot be identified may be converted into a default format (e.g., image format)"; page 5, ¶ [0051]: "Data services 46 may also provide a data access layer, exchanging data between consumers and providers in appropriate formats suitable to recipients, irrespective of formats of data from suppliers"; page 8, ¶ [0077]: "At 154, data 82 may be converted into health record 52").
"a database configured to store the preprocessed data; and" — Rangadass teaches a cOS data store 50 that stores the converted, uniformly formatted data as health record 52 (Rangadass, page 2, ¶ [0017]: "Data processed by cOS 12 may be stored in a cOS data store 50 in various formats, including as a health record 52, a healthcare signature 54, and a longitudinal medical record 56"; page 6, ¶ [0065]: "data converter module 86 may store health record 52 in cOS data store 50"; FIGS. 1 and 5).
"at least one processor configured to:" — Rangadass teaches a processor 100 and a memory element 102 that perform the recited operations (Rangadass, page 6, ¶ [0066]: "A processor 100 and a memory element 102 may facilitate performing various operations described herein"; page 8, ¶ [0082]: "the activities outlined herein may be implemented with fixed logic or programmable logic (e.g., software/computer instructions executed by a processor)"; FIG. 5).
"perform vector extraction to extract features of at least a portion of the preprocessed data" — Rangadass teaches a vector generator module 88 that parses the health record 52 and extracts vectors 78 therefrom, where each vector is a measurable parameter of the individual (Rangadass, page 6, ¶ [0065]: "A vector generator module 88 may extract vectors 78 from data 82"; page 7, ¶ [0072]: "vector generator module 88 may include parsers and other syntactic analyzers that can identify vectors 78 and extract them as needed. Vector generator module 88 may parse health record 52 (or data 82), identify vectors 78, extract them into temporary files"; page 4, ¶ [0042]: "cOS 12 may extract vectors from the medical data (or health record 52)"; page 2, ¶ [0021]: "each 'vector' represents a measurable piece of medical data, such as height, weight, heart rate, blood sugar level, etc."; page 8, ¶ [0077]: "At 156, vectors 78 may be extracted from health record 52").
"and generate a plurality of vectors from the extracted features of the preprocessed data;" — Rangadass teaches generating a plurality of vectors 78 from the health record 52 (Rangadass, page 1, ¶ [0013]: "extracting a plurality of vectors from the medical data in the health record"; page 6, ¶ [0061]: "The data may include vectors 78, such as heart rate 78(1) blood pressure 78(2), blood glucose 78(3), height 78(4), weight 78(5), age 78(6), … blood oxygen level 78(N). Any measurable health or medically related parameter may be included in vectors 78"; page 9, claim 1: "extracting a plurality of vectors from the medical data in the health record"; FIG. 3).
Rangadass teaches generating a healthcare signature 54 of the individual from the plurality of vectors 78, where the healthcare signature is an aggregation of the vectors represented mathematically as an array (Rangadass, page 2, ¶ [0021]; page 6, ¶ [0061]). However, Rangadass does not teach "generate, using the machine learning model and the plurality of vectors, a willingness signature associated with an individual, wherein the willingness signature is a numerical value or a probability distribution that represents a propensity of the individual to engage in healthcare-related activities."
In the same field of endeavor, Wexler teaches:
"generate, using the machine learning model and the plurality of vectors, a willingness signature associated with an individual," — Wexler teaches an analyzing device 102 that uses machine learning models 122 to analyze input data and generate output data for a user, and that generates from that data a propensity value for the individual (Wexler, page 3, ¶ [0030]: "the analyzing device 102 is configured to analyze the input data and generate the output data using one or more machine learning models 122. The machine learning models 122 can include supervised learning models, unsupervised learning models, semi-supervised learning models, and/or reinforcement learning models generated by one or more modeling engines 112"; page 5, ¶ [0045]: "Additional further values can be generated from the history of task completions, prompts and reinforcements. For example, propensity and/or sensitivity can be generated").
"wherein the willingness signature is a numerical value or a probability distribution" — Wexler teaches that the propensity value is a base probability computed as a maximum likelihood estimator, and further teaches returning a probability distribution (Wexler, page 5, ¶ [0045]: "Propensity can be the base probability of completing a task, effectively representing the effects of all factors not explicitly represented in the model"; page 5, ¶ [0046]: "The system can then generate values of propensity and sensitivity as the maximum likelihood estimators given the data and a probability function"; page 7, ¶ [0063]: "Simulated behavior functions return a probability distribution for behaviors based on the state of the user and a selected action"; page 7, ¶ [0062]: "Update functions are used to update the state of the user and associated probability distributions for particular behaviors that are determined based on the state of the user, the parameters of the user, recent behaviors of the user").
"that represents a propensity of the individual to engage in healthcare-related activities." — Wexler teaches that the propensity is the probability that the individual will complete a health-management task, where the tasks relate to the management of the individual's medical conditions (Wexler, page 5, ¶ [0045]: "Propensity can be the base probability of completing a task"; page 5, ¶ [0042]: "task completion by the individual over time, with more emphasis on task adherence in the near future"; page 1, ¶ [0019]: "the system 100 can be used to identify, manage, monitor, and/or provide recommendations relating to diabetes, hypoglycemia, hyperglycemia, pre-diabetes, hypertension, hyperlipidemia, ketoacidosis, liver failure").
Rangadass and Wexler are analogous to the claimed invention as both are from the same field of endeavor of computerized systems that aggregate an individual's health-related data and generate an individualized metric for that individual. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the vector extraction and signature generation of Rangadass with the machine-learning propensity generation of Wexler. The motivation to combine Rangadass and Wexler is as recited by Wexler (page 4, ¶ [0037]: "which may improve the likelihood of successfully helping individuals to meet and maintain behavioral targets"), so as to render the static signature of Rangadass predictive of the individual's future healthcare engagement, which Rangadass identifies as an objective of its system (page 2, ¶ [0023]: "Applications in cOS 12 can provide predictive analytics and care coordination workflows for all stakeholders in the care continuum").
The combination of Rangadass and Wexler, however, does not teach "input the plurality of vectors into a machine learning model trained using historical data from the at least one internet-connected data source; and".
In the same field of endeavor, Bostic teaches:
"input the plurality of vectors into a machine learning model" — Bostic teaches generating a feature vector from patient information and inputting that feature vector into a machine learned model, which outputs a score (Bostic, page 21, ¶ [0214]: "the testing recommendation module 304 may generate a set of features (e.g., a feature vector) based on the proposed prescription … for the patient and the patient information (e.g., a patient's age, a patient's sex, a patient's weight, a patient's body type, a patient's medication history)"; page 21, ¶ [0216]: "the testing recommendation module 304 may input the set of features to the model, which outputs a confidence score for each type of potential test given the features").
"trained using historical data from the at least one internet-connected data source;" — Bostic teaches ingesting healthcare data from a plurality of patient data providers and determining relationships between that patient data and historical data for use by the machine learning module (Bostic, page 1, Abstract: "Systems and methods are provided for simulating a patient health state by determining one or more relationships between patient data and historical data, creating enriched data elements based on the determined relationships, and using a machine learning module to compute a current health state for a patient and to simulate a future health state of the patient"; page 1, ¶ [0007]: "ingesting healthcare data of a patient received from one of a plurality of patient data providers; enriching at least one new data element of the ingested healthcare data based on the determined one or more relationships among the ingested healthcare data; transmitting the at least one new data element to a raw data cluster; transmitting the raw data cluster to a machine learning module"; page 3, ¶ [0019]: "transmitting the ingested healthcare data to a data store; transmitting the data store to a machine learning module"; FIG. 2, elements 222, 226, 230, 234, 238).
Rangadass, Wexler, and Bostic are analogous to the claimed invention as all three are from the same field of endeavor of ingesting an individual's health-related data from a plurality of data providers and applying that data to generate an individualized metric. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the combination of Rangadass and Wexler with the feature-vector input and historical-data training of Bostic. The motivation to combine Rangadass, Wexler, and Bostic is to supply the trained model of Wexler with the vectors already extracted by Rangadass, thereby obtaining the accuracy benefit that Bostic attributes to training on historical data (page 1, Abstract).
Regarding claim 2, the limitations of claim 1 from which claim 2 depends are rejected under the same rationale set forth above with respect to claim 1.
Regarding the limitations added by claim 2, Rangadass teaches:
"wherein the at least one processor is further configured to:" — Rangadass teaches a processor 100 that performs the recited operations by way of a longitudinal module 90 (Rangadass, page 6, ¶ [0066]: "A processor 100 and a memory element 102 may facilitate performing various operations described herein"; page 7, ¶ [0070]: "the various modules (e.g., receive module 84, data converter module 86, vector generator module 88, longitudinal module 90, display module 92, transmit module 94, operating system workflow module 96, monitoring and routing module 98) illustrated in the FIGURE may form a portion of an application in cOS 12"; FIG. 5).
"perform longitudinal record monitoring on the plurality of vectors over time; and" — Rangadass teaches a longitudinal module 90 that tracks the plurality of vectors 78 over time by reviewing the timestamps of the underlying data and retrieving the corresponding vectors from the cOS data store 50 (Rangadass, page 6, ¶ [0065]: "A longitudinal module 90 may track vectors 78 over time, generate longitudinal medical record 56"; page 4, ¶ [0043]: "The vectors may be monitored over time to generate longitudinal medical record 56 of the individual. For example, the individual's blood glucose level may be monitored over the course of a year, and presented as a timeline, showing the impact of medications, exercise, diet, and other daily activities and parameters on the specific vector"; page 7, ¶ [0073]: "longitudinal module 90 may include scripts that can review timestamps of data, and/or retrieve relevant vectors 78 from cOS data store 50 based on timestamps of the original data 82. Longitudinal module 90 may temporarily store retrieved vectors 78 and aggregate them over time"; page 8, ¶ [0077]: "At 160, vectors 78 may be monitored over time"; page 9, claim 5: "monitoring the plurality of vectors over time").
"generate a longitudinal record of the individual based on the longitudinal record monitoring." — Rangadass teaches generating a longitudinal medical record 56 of the individual from the vectors so monitored, the record being the progression of those same vectors over time (Rangadass, page 2, ¶ [0021]: "'Longitudinal medical record' can include a progression of the vectors over time. Longitudinal medical record 56 can include medical data that represents the individual's health condition as it changes (or remains constant) over time. In other words, longitudinal medical records 56 can present a health history of the individual, obtained by observing the same vectors over long periods of time"; page 6, ¶ [0064]: "Longitudinal medical record 56 may be represented as N curves, each curve i representing vector 78(i) plotted over time 90"; page 7, ¶ [0073]: "aggregate them over time to generate longitudinal medical record 56"; page 8, ¶ [0077]: "At 162, longitudinal medical record 56 may be generated"; page 9, claim 5: "generating a longitudinal medical record of the individual"; FIG. 4).
Regarding claim 3, the limitations of claims 1 and 2 from which claim 3 depends are rejected under the same rationale set forth above with respect to claims 1 and 2.
Regarding the limitations added by claim 3, Rangadass teaches:
"wherein the at least one processor is further configured to:" — Rangadass teaches a processor 100 that performs the recited operations by way of the modules of cOS 12 (Rangadass, page 6, ¶ [0066]: "A processor 100 and a memory element 102 may facilitate performing various operations described herein"; page 7, ¶ [0070]: "the various modules (e.g., receive module 84, data converter module 86, vector generator module 88, longitudinal module 90, display module 92, transmit module 94, operating system workflow module 96, monitoring and routing module 98) illustrated in the FIGURE may form a portion of an application in cOS 12"; FIG. 5).
Rangadass teaches that the longitudinal medical record 56 reflects changes in the monitored vectors over time and that such changes may be observed as trends (Rangadass, page 2, ¶ [0021]; page 4, ¶ [0043]). However, Rangadass does not teach "detect, based on the longitudinal record monitoring, updates to the plurality of vectors; and retrain the machine learning model using the updates to the plurality of vectors."
In the same field of endeavor, Wexler teaches:
"detect, based on the longitudinal record monitoring, updates to the plurality of vectors; and" — Wexler teaches obtaining new data for the user, accessing the user history items maintained for that user, and estimating from the new data and that history an updated state of the user, where the state is an array of user values that changes at every step (Wexler, page 1, Abstract: "The method can include obtaining new data and accessing one or more user history items regarding a user; estimating a state of the user"; page 3, ¶ [0034]: "The state estimator 114 can use corresponding machine learning models 122 to generate the estimated user states. For example, the state estimator 114 can use the models 122 to predict based on the current state and the user history 124 that blood glucose levels will reach a threshold level"; page 7, ¶ [0062]: "State includes an array of user values that are observable or estimable, and can change every step based on the actions from the software application and the behavior of the user"; page 5, ¶ [0045]: "Additional further values can be generated from the history of task completions, prompts and reinforcements").
"retrain the machine learning model using the updates to the plurality of vectors." — Wexler teaches updating the model on the basis of the user's response to the executed action, and further teaches that the adaptive support model is iteratively improved and continues to learn from the tracked behavior of each user over time (Wexler, page 1, Abstract: "identifying and executing an action for affecting a response of the user in assisting the user adjust a user behavior; and updating a model based on the response of the user"; page 4, ¶ [0037]: "one or more elements of an adaptive intervention are iteratively improved via data-driven testing (e.g., optimization), which may improve the likelihood of successfully helping individuals to meet and maintain behavioral targets"; page 5, ¶ [0042]: "an adaptive support model can be configured to learn from a multitude of users while keeping track of the messages and behavior of each user over time, in order to serve them with the optimal messages at every time slot").
Rangadass and Wexler are analogous to the claimed invention as both are from the same field of endeavor of computerized systems that monitor an individual's health-related data over time and generate an individualized metric for that individual. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the longitudinal vector monitoring of Rangadass with the state updating and model updating of Wexler. The motivation to combine Rangadass and Wexler is as recited by Wexler (page 4, ¶ [0037]: "which may improve the likelihood of successfully helping individuals to meet and maintain behavioral targets"), so that the signature of Rangadass remains accurate as the monitored vectors change, which Rangadass teaches will occur (page 2, ¶ [0021]: "medical data that represents the individual's health condition as it changes (or remains constant) over time").
Regarding claim 5, the limitations of claims 1 and 2 from which claim 5 depends are rejected under the same rationale set forth above with respect to claims 1 and 2.
Regarding the limitations added by claim 5, Rangadass teaches:
"further comprising a network connection between the at least one processor and another device that allows the other device to request access to the willingness signature and the longitudinal record," — Rangadass teaches a network 11 connecting cOS 12, in which processor 100 resides, to clients 58(1)-58(N), and further teaches that the healthcare signature 54 and the longitudinal medical record 56 stored in cOS data store 50 are retrievable by queries submitted from those clients (Rangadass, page 2, ¶ [0017]: "cOS 12 may also facilitate transmitting the data to, and displaying the data on, various clients 58(1)-58(N) (collectively referred to as clients 58)"; page 5, ¶ [0052]: "Clients 58(1)-58(N) may include any electronic device, client, server, peer, service, application, or other object capable of sending, receiving, or forwarding information over a network (e.g., network 11). Examples of clients 58(1)-58(N) include computers, laptops, smartphones, printers, etc."; page 4, ¶ [0037]: "health record 52, healthcare signature 54 and longitudinal medical record 56 may be stored in cOS data store 50 and retrieved by suitable queries on clients 58"; page 4, ¶ [0044]: "health record 52, healthcare signature 54 and longitudinal medical record 56 stored in cOS data store 50 may be searchable through a search query on a suitable interface"; FIG. 1).
"wherein the at least one processor is further configured to:" — Rangadass teaches a processor 100 that performs the recited operations by way of a display module 92 and a monitoring and routing module 98 (Rangadass, page 6, ¶ [0066]: "A display module 92 may facilitate displaying health record 52, healthcare signature 54, longitudinal medical record 56 and other information in suitable formats on an appropriate interface (e.g., on a display screen at client 58(1)) . . . A processor 100 and a memory element 102 may facilitate performing various operations described herein"; FIG. 5).
"receive a request by the other device to access the longitudinal record; and" — Rangadass teaches that a query for the stored record is generated at the client and received by cOS 12, which then retrieves the requested data (Rangadass, page 4, ¶ [0037]: "a physician may click a tab on a suitable interface in client 58(1), which may generate a query for healthcare signature 54. Vectors may be extracted from health record 52, and transmitted to client 58(1), where the interface may render the vectors in a suitable format as healthcare signature 54"; page 7, ¶ [0069]: "A physician may later access health record 52 on clients 58 by querying the unique identifier"; page 8, ¶ [0091] as to access verification generally).
"generate a visual display of the longitudinal record and the willingness signature to the other device." — Rangadass teaches generating, at the requesting client, an interface displaying both the longitudinal medical record 56 and the healthcare signature 54 (Rangadass, page 6, ¶ [0066]: "A display module 92 may facilitate displaying health record 52, healthcare signature 54, longitudinal medical record 56 and other information in suitable formats on an appropriate interface (e.g., on a display screen at client 58(1))"; page 7, ¶ [0074]: "FIG. 6 is a simplified diagram illustrating example details of an interface 110 for displaying data on clients 58(1)-58(N). Interface 110 may include messages 112, medical charts 114, lab results 116, medical images 118, health record 52, healthcare signature 54, and longitudinal medical record 56"; page 8, ¶ [0077]: "At 164, cOS 12 may facilitate displaying health record 52, healthcare signature 54, longitudinal medical record 56 and other information (e.g., messages, patient summary, etc.) on suitable interface 110"; page 9, claim 7: "facilitating displaying the health record, the healthcare signature and the longitudinal medical record of the individual on an interface"; FIGS. 6 and 7).
Regarding claim 6, the limitations of claims 1, 2, and 5 from which claim 6 depends are rejected under the same rationale set forth above with respect to claims 1, 2, and 5.
Regarding the limitations added by claim 6, Rangadass teaches:
"wherein the at least one processor is further configured to:" — Rangadass teaches a processor 100 that performs the recited operations by way of a display module 92 and a transmit module 94 (Rangadass, page 6, ¶ [0066]: "A display module 92 may facilitate displaying health record 52, healthcare signature 54, longitudinal medical record 56 and other information in suitable formats on an appropriate interface (e.g., on a display screen at client 58(1)). A transmit module 94 may facilitate transmitting data 82 to authorized users . . . A processor 100 and a memory element 102 may facilitate performing various operations described herein"; FIG. 5).
Rangadass teaches transmitting to the requesting client 58 information derived from the monitored vectors, including trends observed in those vectors over time (Rangadass, page 4, ¶ [0043]; page 7, ¶ [0074]). However, Rangadass does not teach "provide to the other device, using the willingness signature, one or more of personalized recommendations, feedback, trend analysis, score adjustments, and real-time data monitoring updates."
In the same field of endeavor, Wexler teaches:
"provide to the other device, using the willingness signature, one or more of personalized recommendations," — Wexler teaches transmitting recommendations to the user device, where the recommended action is selected on the basis of the individual's estimated state and the propensity value generated for that individual (Wexler, page 2, ¶ [0028]: "one or more users can access the system 100 via the user devices 104, e.g., to send data to the analyzing devices 102 . . . and/or receive data from the system 100 (e.g., predictions, notifications, recommendations, instructions, support, etc.)"; page 4, ¶ [0035]: "The system 100 can use the future health states to determine and recommend one or more user actions that may be implemented between now and a future time to avoid the thresholding health states"; page 4, ¶ [0036]: "recommended actions having lower physical demands, recommended actions requiring longer durations, and/or recommendation timings further away from the thresholding event. Details regarding the state estimator 114 and the corresponding recommendations are described below"; page 5, ¶ [0046]: "the probability of the individual completing a task according to a function of the recent average prompt frequency, recent average task completion frequency, recent average reinforcement frequency, current propensity, and/or current sensitivity").
"feedback," — Wexler teaches providing reinforcements to the individual in response to the individual's behavior, and evaluating the effect of those reinforcements on the individual (Wexler, page 5, ¶ [0045]: "Sensitivity can be the strength and direction of the effects of reinforcements on an individual. Sensitivities can be ranged from 'receptive' (e.g., reinforcing strong . . .)"; page 7, ¶ [0063]: "Reward functions are functions that determine if a reward should be given based on user behavior(s) and optionally the user's state").
"trend analysis," — Wexler teaches deriving from the tracked values recent average frequencies of task completion, prompts, and reinforcements, and predicting from the current state and user history the future trajectory of the individual's health state (Wexler, page 5, ¶ [0044]: "representing recent average prompt frequency, recent average task completion frequency, and recent average reinforcement frequency"; page 3, ¶ [0034]: "the state estimator 114 can generate activity predictions for a predetermined future duration based on the obtained data. The state estimator 114 can start from a current health state (e.g., blood glucose level) and extrapolate or derive future health states according to the activity predictions").
"score adjustments, and real-time data monitoring updates." — Bostic teaches that the model outputs a confidence score for the recommendation provided to the recipient and that the recommendation is selected by comparing that score against a threshold (Bostic, page 21, ¶ [0215]: "the recommendation may include a confidence score that indicates a degree of confidence in the recommendation. The testing recommendation module 304 may determine whether to select a recommendation made by a model based on the confidence score corresponding to the recommendation (e.g., when the confidence score exceeds a threshold)"; page 21, ¶ [0216]: "the testing recommendation module 304 may input the set of features to the model, which outputs a confidence score for each type of potential test given the features").
Rangadass and Wexler are analogous to the claimed invention as both are from the same field of endeavor of computerized systems that monitor an individual's health-related data and deliver individualized results to a recipient device. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the transmission and display of monitored data to the requesting client of Rangadass with the propensity-based recommendations, reinforcements, and trend values of Wexler. The motivation to combine Rangadass and Wexler is as recited by Wexler (page 4, ¶ [0037]: "which may improve the likelihood of successfully helping individuals to meet and maintain behavioral targets"), so that the data delivered to the requesting device of Rangadass is actionable rather than merely descriptive.
Regarding claim 9, the limitations of claim 1 from which claim 9 depends are rejected under the same rationale set forth above with respect to claim 1.
Regarding the limitations added by claim 9, Rangadass teaches:
"wherein, to generate the willingness signature," — Rangadass teaches a vector generator module 88 that generates the signature of the individual from the plurality of vectors extracted from the preprocessed data (Rangadass, page 6, ¶ [0065]: "A vector generator module 88 may extract vectors 78 from data 82, and generate healthcare signature 54"; page 7, ¶ [0072]: "Vector generator module 88 may parse health record 52 (or data 82), identify vectors 78, extract them into temporary files, aggregate the extracted vectors 78 and insert them into health signature 54"; page 8, ¶ [0077]: "At 158, healthcare signature 54 may be generated from vectors 78").
Rangadass teaches that its applications can provide predictive analytics for the stakeholders in the care continuum (Rangadass, page 2, ¶ [0023]). However, Rangadass does not teach "the machine learning model is configured to perform at least one of feature classification, data clustering, and linear or logistic regression."
In the same field of endeavor, Wexler teaches:
"the machine learning model is configured to perform at least one of feature classification, data clustering, and linear or logistic regression." — Wexler teaches that the machine learning models 122 used to analyze the individual's input data and generate the output data are selected from an enumerated set that expressly includes classification algorithms, clustering algorithms, and linear and logistic regression algorithms (Wexler, page 3, ¶ [0030]: "the analyzing device 102 is configured to analyze the input data and generate the output data using one or more machine learning models 122. The machine learning models 122 can include supervised learning models, unsupervised learning models, semi-supervised learning models, and/or reinforcement learning models generated by one or more modeling engines 112. Examples of machine learning models suitable for use with the present technology include, but are not limited to: regression algorithms (e.g., ordinary least squares regression, linear regression, logistic regression, stepwise regression, multivariate adaptive regression splines, locally estimated scatterplot smoothing), instance-based algorithms (e.g., k-nearest neighbor, learning vector quantization, self-organizing map, locally weighted learning, support vector machines), regularization algorithms (e.g., ridge regression, least absolute shrinkage and selection operator, elastic net, least-angle regression), decision tree algorithms (e.g., classification and regression trees, Iterative Dichotomiser 3 (ID3), C4.5, C5.0, chi-squared automatic interaction detection, decision stump, M5, conditional decision trees), Bayesian algorithms (e.g., naïve Bayes, Gaussian naïve Bayes, multinomial naïve Bayes, averaged one-dependence estimators, Bayesian belief networks, Bayesian networks), clustering algorithms (e.g., k-means, k-medians, expectation maximization, hierarchical clustering)").
Rangadass and Wexler are analogous to the claimed invention as both are from the same field of endeavor of computerized systems that aggregate an individual's health-related data and generate an individualized metric for that individual. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to generate the signature of Rangadass using the enumerated machine learning models of Wexler. The motivation to combine Rangadass and Wexler is as recited by Wexler (page 4, ¶ [0037]: "which may improve the likelihood of successfully helping individuals to meet and maintain behavioral targets"), so as to realize the predictive analytics that Rangadass identifies as an object of its system (page 2, ¶ [0023]: "Applications in cOS 12 can provide predictive analytics and care coordination workflows for all stakeholders in the care continuum").
Regarding claim 10, claim 10 is a method claim, whereas claim 1 is a system claim. Claim 10 otherwise recites limitations that correspond to those of claim 1, and is therefore rejected under the same rationale set forth above with respect to claim 1.
Regarding claim 11, claim 11 recites limitations that correspond to those of claim 2, and is therefore rejected under the same rationale set forth above with respect to claim 2.
Regarding claim 12, claim 12 recites limitations that correspond to those of claim 3, and is therefore rejected under the same rationale set forth above with respect to claim 3.
Regarding claim 14, claim 14 recites limitations that correspond to those of claim 5, and is therefore rejected under the same rationale set forth above with respect to claim 5.
Regarding claim 15, claim 15 recites limitations that correspond to those of claim 6, and is therefore rejected under the same rationale set forth above with respect to claim 6.
Regarding claim 18, claim 18 recites limitations that correspond to those of claim 9, and is therefore rejected under the same rationale set forth above with respect to claim 9.
Claims 4, 8, 13, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Rangadass et al. (Rangadass), US 2013/0054272 A1, in view of Wexler et al. (Wexler), US 2021/0383925 A1, further in view of Bostic et al. (Bostic), US 2021/0202103 A1, and further in view of Singh et al. (Singh), US 2023/0084146 A1.
Regarding claim 4, the limitations of claims 1, 2, and 3 from which claim 4 depends are rejected under the same rationale set forth above with respect to claims 1, 2, and 3.
Regarding the limitations added by claim 4, Rangadass teaches:
"wherein the at least one processor is further configured to" — Rangadass teaches a processor 100 that performs the recited operations by way of a transmit module 94 and a monitoring and routing module 98 (Rangadass, page 6, ¶ [0066]: "A transmit module 94 may facilitate transmitting data 82 to authorized users. An operating system workflow module 96 may keep track of processes in cOS 12. A monitoring and routing module 98 may monitor communication within cOS 12 and with external entities, including medical systems 14, business systems 26 and clients 58. A processor 100 and a memory element 102 may facilitate performing various operations described herein"; FIG. 5).
Rangadass teaches transmitting data to authorized users and to clients 58 associated with a particular physician (Rangadass, page 6, ¶ [0066]; page 7, ¶ [0068]). However, Rangadass does not teach "issue a real-time notification to one or more third parties based on the detected updates to the plurality of vectors."
In the same field of endeavor, Wexler teaches:
"issue a . . . notification to one or more third parties" — Wexler teaches that the system generates and transmits notifications to users of the system, and that such users expressly include healthcare professionals and computing devices in addition to the patient (Wexler, page 2, ¶ [0028]: "one or more users can access the system 100 via the user devices 104, e.g., to send data to the analyzing devices 102 (e.g., health-related information, contextual information) and/or receive data from the system 100 (e.g., predictions, notifications, recommendations, instructions, support, etc.). The users can be individual users (e.g., patients, healthcare professionals, etc.), computing devices, software applications, objects, functions, and/or any other types of users"; page 1, ¶ [0019]: "the system 100 receives input data and performs monitoring, processing, analysis, forecasting, interpretation, etc. of the input data in order to generate user reports, behavior goals, instructions, notifications, recommendations, support, and/or other information").
"based on the detected updates to the plurality of vectors." — Wexler teaches that the notification is issued as a consequence of the updated state estimated from the newly obtained user data, that is, in response to the detected change in the monitored values (Wexler, page 1, Abstract: "The method can include obtaining new data and accessing one or more user history items regarding a user; estimating a state of the user; identifying and executing an action for affecting a response of the user"; page 4, ¶ [0035]: "the state estimator 114 can start from a current health state (e.g., blood glucose level) and extrapolate or derive future health states according to the activity predictions. The system 100 can use the future health states to determine and recommend one or more user actions that may be implemented between now and a future time to avoid the thresholding health states"; page 2, ¶ [0028]: "For example, upon obtaining any of").
Rangadass and Wexler are analogous to the claimed invention as both are from the same field of endeavor of computerized systems that monitor an individual's health-related data and report the results to interested parties. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the transmission of monitored data to authorized users of Rangadass with the state-triggered notification of Wexler. The motivation to combine Rangadass and Wexler is as recited by Rangadass (page 6, ¶ [0063]: "a person could have a monitor for heart attacks that would automatically call 911 in case of heart trouble"), which identifies automatic alerting upon a detected change in the monitored vectors as an object of its system.
The combination of Rangadass and Wexler, however, does not teach "issue a real-time notification."
In the same field of endeavor, Singh teaches:
"issue a real-time notification" — Singh teaches a notification module that transmits a notification alerting a third-party provider to the status of the individual's claim, and further teaches that the underlying determinations are updated in real time as new data is received (Singh, page 20, ¶ [0108]: "The provider module 662 can further include a notification module, a workflow module, an analytics module, or any combination thereof that populate the dashboard on the provider device. For example, the notification module can be configured to transmit a notification to the provider server 620 that alerts the provider, via the displayed dashboard, regarding the status of an insurance claim (e.g., a payer has denied a claim)"; page 17, ¶ [0089]: "The optional eighth step 280 can also include updating the ordered database of appeal candidate entries in real-time based on newly inputted data. For example, . . . based on newly inputted data, the percentage likelihood of a given appeal candidate in the ordered database may change and the optional eighth step 280 can include reordering the ordered database in real-time as percentage likelihoods fluctuate given the newest data").
Rangadass, Wexler, and Singh are analogous to the claimed invention as all three are from the same field of endeavor of computerized systems that process an individual's healthcare data and report an individualized result to a provider or other interested party. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the notification of Wexler with the real-time updating and provider alerting of Singh. The motivation to combine Rangadass, Wexler, and Singh is as recited by Singh (page 17, ¶ [0089]: "reordering the ordered database in real-time as percentage likelihoods fluctuate given the newest data"), so that the third party is alerted while the detected change is still actionable.
Regarding claim 8, the limitations of claim 1 from which claim 8 depends are rejected under the same rationale set forth above with respect to claim 1.
Regarding the limitations added by claim 8, Rangadass teaches:
"wherein the preprocessing of the extracted data includes" — Rangadass teaches that the preprocessing of the extracted data is performed by a data converter module 86 that identifies the content of the incoming data and converts it into a uniform format prior to storage (Rangadass, page 6, ¶ [0065]: "A data converter module 86 may convert data 82 into a uniform format (e.g., associated with health record 52)"; page 7, ¶ [0071]: "data converter module 86 may be implemented in software and may include file format identifiers, file content based format identifiers, MIME type identifiers, etc. Data converter module 86 may also include data converters that can convert data from one format into another (e.g., uniform format)"; page 4, ¶ [0041]: "cOS 12 may aggregate information from the various medical data sources, convert them to a uniform format (e.g., XML based format)").
Rangadass teaches that the data to be preprocessed includes unstructured content such as facsimiles, emails, and scanned paper mails, and further teaches that an optical character recognition system may translate scanned mail into an electronic searchable form (Rangadass, page 7, ¶ [0068]; page 3, ¶ [0034]). However, Rangadass does not teach "using a natural language processing model having access to a document data store to perform automated data augmentation and data enrichment on the extracted data."
In the same field of endeavor, Singh teaches:
"using a natural language processing model" — Singh teaches receiving a natural language data file representing the doctor's notes for the individual and processing that natural language file to structure it for input to the machine learning algorithm (Singh, page 1, Abstract: "receiving, at a server, a natural language data file representing doctors notes from a provider visit related to a service instance; receiving, at the server, a structured data set including patient profile data, diagnosis and procedure codes, and quantitative data related to a payment requested; processing at least the natural language data file using a medical dictionary to output a set of key medical terms"; page 9, ¶ [0055]: "data may take the form of unstructured, natural language text as in the case of an appeal letter, claim letter, claim denial letter, doctor's notes, etc. Accordingly, the data may be first processed to structure the data using different filtering or processing techniques, including as an example, utilizing various medical dictionaries").
"having access to a document data store" — Singh teaches that the processing is performed by comparing the words and phrases of the extracted natural language data against a medical library of stored documents, and identifies the constituent documents of that library (Singh, page 9, ¶ [0059]: "To aid in identifying the master set of key words and/or phrases, the fourth step 140 can include comparing words and phrases in the labeled, selected data to words and phrases contained a medical library (e.g., a medical dictionary, medical guidelines, etc.) For example, if the phrase 'medial collateral ligament' appears within both the selected data (e.g., doctor's notes) and the medical library, the phrase will be identified as part of the master set of key words and/or phrases"; page 9, ¶ [0058]: "The master set of key words and phrases can be extracted from, for example, insurance claim forms prepared by one or more providers, insurance claim appeal forms prepared by one or more providers, doctor notes associated with one or more patients, explanation of benefit forms prepared by the payer, claim denial letters prepared by the payer, claim acceptance letters prepared by one or more payers, or any combination thereof").
"to perform automated data augmentation and data enrichment on the extracted data." — Singh teaches that the extracted data is thereby supplemented with an identified master set of key medical terms and is further categorized into a plurality of defined fields, so that the resulting data set contains information not present in the raw extracted data (Singh, page 8, ¶ [0054]: "structuring the selected, labeled training data. This step is optional, and may include pre-processing of data to make it clean for inputting into the machine learning algorithm"; page 9, ¶ [0057]: "the fourth step 140 includes analyzing the labeled, selected data to identify a master set of key words and/or phrases used in the labeled, selected data . . . selecting a master set of key words and/or phrases from the data aids the machine learning algorithm in identifying patterns and successfully predicting outcomes"; page 9, ¶ [0056]: "structuring of the data may refer to identifying and categorizing each piece of data in each of the labeled sets. For example, the data in each labeled set can be categorized into one or more of a plurality of fields, including, for example, a provider name, a provider address, . . . a patient name, . . . doctor notes associated with the patient and/or procedure, a procedure code, a diagnosis code, a services provided date, a billed amount").
Rangadass and Singh are analogous to the claimed invention as all two are from the same field of endeavor of computerized systems that receive an individual's healthcare data from a plurality of sources, process that data into a form suitable for downstream analysis, and generate an individualized result therefrom. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to perform the format conversion of Rangadass using the medical-dictionary-based natural language processing of Singh. The motivation to combine Rangadass and Singh is as recited by Singh (page 9, ¶ [0057]: "selecting a master set of key words and/or phrases from the data aids the machine learning algorithm in identifying patterns and successfully predicting outcomes"), which addresses the unstructured-content problem that Rangadass identifies with respect to its own incoming data (page 3, ¶ [0034]: "an employee may manually enter relevant information from the paper mail into a pre-defined template").
Regarding claim 13, claim 13 recites limitations that correspond to those of claim 4, and is therefore rejected under the same rationale set forth above with respect to claim 4.
Regarding claim 17, claim 17 recites limitations that correspond to those of claim 8, and is therefore rejected under the same rationale set forth above with respect to claim 8.
Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Rangadass et al. (Rangadass), US 2013/0054272 A1, in view of Wexler et al. (Wexler), US 2021/0383925 A1, further in view of Bostic et al. (Bostic), US 2021/0202103 A1, and further in view of Saxena et al. (Saxena), US 2018/0165598 A1.
Regarding claim 7, the limitations of claim 1 from which claim 7 depends are rejected under the same rationale set forth above with respect to claim 1.
Regarding the limitations added by claim 7, Rangadass teaches:
"wherein the at least one processor is further configured to" — Rangadass teaches a processor 100 that causes the converted data to be stored by way of a data converter module 86 and the cOS data store 50 (Rangadass, page 6, ¶ [0065]: "data converter module 86 may store health record 52 in cOS data store 50; vector generator module 88 may store healthcare signature 54 in cOS data store 50; and longitudinal module 90 may store longitudinal medical record 56 in cOS data store 50"; page 6, ¶ [0066]: "A processor 100 and a memory element 102 may facilitate performing various operations described herein"; FIG. 5).
Rangadass teaches storing the preprocessed data in a cOS data store 50 and further teaches that such information may be provided in any database, register, table, cache, queue, control list, or storage structure (Rangadass, page 2, ¶ [0017]; page 8, ¶ [0084]). However, Rangadass does not teach "cause the preprocessed data to be stored using a blockchain network."
In the same field of endeavor, Saxena teaches:
"cause the preprocessed data to be stored using a blockchain network." — Saxena teaches that the data received from the plurality of data sources and processed by the cognitive platform is stored in a blockchain, and further teaches that the analytics infrastructure of that platform includes a blockchain database as a storage sub-component (Saxena, page 22, ¶ [0203]: "repositories of multi-structured data 1104 may include unstructured data (e.g., a document), semi-structured data (e.g., a social media post), and structured data (e.g., a string, an integer, etc.), such as data stored in a relational database management system (RDBMS) or a blockchain. In various embodiments, such data may be stored in a data lake 1114, a data warehouse 1116, a blockchain 1117, or some combination thereof"; page 12, ¶ [0112]: "the cloud analytics infrastructure 344 component may also include a distributed object storage 478 sub-component, a distributed full text search 480 sub-component, a document database 482 sub-component, a blockchain database 483 sub-component, a graph database 484 sub-component, and various other sub-components"; page 1, Abstract: "receiving data from a plurality of data sources, at least some of the plurality of data sources comprising financial related data sources and blockchain data sources; processing the data from the plurality of data sources to provide a financial-related, blockchain-associated cognitive insight"; page 13, ¶ [0123]: "a blockchain broadly refers to a decentralized, distributed data structure whose contents are r[eplicated]"; page 14, ¶ [0126]: "the distributed and replicated nature of a blockchain makes it difficult to modify historical records").
Rangadass and Saxena are analogous to the claimed invention as all two are from the same field of endeavor of computerized systems that receive data from a plurality of data sources, process that data, store the processed data in a repository, and generate an individualized insight therefrom. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to store the preprocessed data of Rangadass in the blockchain of Saxena. The motivation to combine Rangadass and Saxena is as recited by Saxena (page 14, ¶ [0126]: "the distributed and replicated nature of a blockchain makes it difficult to modify historical records"), which addresses the data integrity and access-control concerns that Rangadass identifies with respect to the individual's aggregated medical and non-medical data (page 7, ¶ [0076]: "the medical information may not be visible, due to security and privacy concerns, among other reasons").
Regarding claim 16, claim 16 recites limitations that correspond to those of claim 7, and is therefore rejected under the same rationale set forth above with respect to claim 7.
Claims 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rangadass et al. (Rangadass), US 2013/0054272 A1, in view of Wexler et al. (Wexler), US 2021/0383925 A1, further in view of Bostic et al. (Bostic), US 2021/0202103 A1, further in view of Singh et al. (Singh), US 2023/0084146 A1, and further in view of Saxena et al. (Saxena), US 2018/0165598 A1.
Regarding claim 19, Rangadass teaches a system comprising:
"at least one device configured to extract data from at least one internet-connected data source" — Rangadass teaches a receive module 84 within cOS 12 that receives data 82 from medical systems 14 and business systems 26, where those data sources interface with cOS 12 over the Internet (Rangadass, page 6, ¶ [0065]: "A receive module 84 in cOS 12 may receive data 82 (including medical data and non-medical data)"; page 7, ¶ [0071]: "receive module 84 may include suitable network interfaces for interfacing with other network elements in network 11. Receive module 84 may include signal processors, and other hardware to enable it to perform its operations"; page 2, ¶ [0016]: "Medical systems 14 and business systems 26 may interface with cOS 12 through external services 36 (e.g., Internet, wireless communication networks, etc.) that may interface with cOS 12"; page 6, ¶ [0060]: "The data may be provided to health record 52 through plurality of data sources 76(1)-76(N) (e.g., data source 1, data source 2 … data source N)"; FIG. 2).
"and preprocess the extracted data, including performance of one or more of a transformation of the extracted data, a filtering of the extracted data, a modification of the extracted data, and a standardization of the extracted data," — Rangadass teaches a data converter module 86 that converts the received data 82 into a uniform format, which is a transformation and a standardization of the extracted data, and further teaches modifying the data into formats suitable to the recipient (Rangadass, page 6, ¶ [0065]: "A data converter module 86 may convert data 82 into a uniform format (e.g., associated with health record 52)"; page 4, ¶ [0041]: "cOS 12 may aggregate information from the various medical data sources, convert them to a uniform format (e.g., XML based format), and store the information in cOS data store 50 as health record 52 of the individual"; page 7, ¶ [0071]: "Data converter module 86 may also include data converters that can convert data from one format into another (e.g., uniform format). Incoming data whose format cannot be identified may be converted into a default format (e.g., image format)"; page 5, ¶ [0051]: "Data services 46 may also provide a data access layer, exchanging data between consumers and providers in appropriate formats suitable to recipients, irrespective of formats of data from suppliers"; page 8, ¶ [0077]: "At 154, data 82 may be converted into health record 52").
"a database configured to store the preprocessed data; and" — Rangadass teaches a cOS data store 50 that stores the converted, uniformly formatted data as health record 52 (Rangadass, page 2, ¶ [0017]: "Data processed by cOS 12 may be stored in a cOS data store 50 in various formats, including as a health record 52, a healthcare signature 54, and a longitudinal medical record 56"; page 6, ¶ [0065]: "data converter module 86 may store health record 52 in cOS data store 50"; FIGS. 1 and 5).
"a network connection between at least one processor and another device," — Rangadass teaches a network 11 connecting cOS 12, in which processor 100 resides, to clients 58(1)-58(N) (Rangadass, page 2, ¶ [0017]: "cOS 12 may also facilitate transmitting the data to, and displaying the data on, various clients 58(1)-58(N) (collectively referred to as clients 58)"; page 5, ¶ [0052]: "Clients 58(1)-58(N) may include any electronic device, client, server, peer, service, application, or other object capable of sending, receiving, or forwarding information over a network (e.g., network 11). Examples of clients 58(1)-58(N) include computers, laptops, smartphones, printers, etc."; page 6, ¶ [0066]: "A processor 100 and a memory element 102 may facilitate performing various operations described herein"; FIG. 1).
"the at least one processor configured to:" — Rangadass teaches a processor 100 and a memory element 102 that perform the recited operations (Rangadass, page 6, ¶ [0066]: "A processor 100 and a memory element 102 may facilitate performing various operations described herein"; page 8, ¶ [0082]: "the activities outlined herein may be implemented with fixed logic or programmable logic (e.g., software/computer instructions executed by a processor)"; FIG. 5).
"perform vector extraction to extract features of at least a portion of the preprocessed data" — Rangadass teaches a vector generator module 88 that parses the health record 52 and extracts vectors 78 therefrom, where each vector is a measurable parameter of the individual (Rangadass, page 6, ¶ [0065]: "A vector generator module 88 may extract vectors 78 from data 82"; page 7, ¶ [0072]: "vector generator module 88 may include parsers and other syntactic analyzers that can identify vectors 78 and extract them as needed. Vector generator module 88 may parse health record 52 (or data 82), identify vectors 78, extract them into temporary files"; page 4, ¶ [0042]: "cOS 12 may extract vectors from the medical data (or health record 52)"; page 2, ¶ [0021]: "each 'vector' represents a measurable piece of medical data, such as height, weight, heart rate, blood sugar level, etc."; page 8, ¶ [0077]: "At 156, vectors 78 may be extracted from health record 52").
"and generate a plurality of vectors from the extracted features of the preprocessed data;" — Rangadass teaches generating a plurality of vectors 78 from the health record 52 (Rangadass, page 1, ¶ [0013]: "extracting a plurality of vectors from the medical data in the health record"; page 6, ¶ [0061]: "The data may include vectors 78, such as heart rate 78(1) blood pressure 78(2), blood glucose 78(3), height 78(4), weight 78(5), age 78(6), … blood oxygen level 78(N). Any measurable health or medically related parameter may be included in vectors 78"; page 9, claim 1: "extracting a plurality of vectors from the medical data in the health record"; FIG. 3).
"perform longitudinal record monitoring on the plurality of vectors over time;" — Rangadass teaches a longitudinal module 90 that tracks the plurality of vectors 78 over time by reviewing the timestamps of the underlying data and retrieving the corresponding vectors from the cOS data store 50 (Rangadass, page 6, ¶ [0065]: "A longitudinal module 90 may track vectors 78 over time, generate longitudinal medical record 56"; page 4, ¶ [0043]: "The vectors may be monitored over time to generate longitudinal medical record 56 of the individual. For example, the individual's blood glucose level may be monitored over the course of a year, and presented as a timeline, showing the impact of medications, exercise, diet, and other daily activities and parameters on the specific vector"; page 7, ¶ [0073]: "longitudinal module 90 may include scripts that can review timestamps of data, and/or retrieve relevant vectors 78 from cOS data store 50 based on timestamps of the original data 82. Longitudinal module 90 may temporarily store retrieved vectors 78 and aggregate them over time"; page 8, ¶ [0077]: "At 160, vectors 78 may be monitored over time"; page 9, claim 5: "monitoring the plurality of vectors over time").
"generate a longitudinal record of the individual based on the longitudinal record monitoring;" — Rangadass teaches generating a longitudinal medical record 56 of the individual from the vectors so monitored, the record being the progression of those same vectors over time (Rangadass, page 2, ¶ [0021]: "'Longitudinal medical record' can include a progression of the vectors over time. Longitudinal medical record 56 can include medical data that represents the individual's health condition as it changes (or remains constant) over time. In other words, longitudinal medical records 56 can present a health history of the individual, obtained by observing the same vectors over long periods of time"; page 6, ¶ [0064]: "Longitudinal medical record 56 may be represented as N curves, each curve i representing vector 78(i) plotted over time 90"; page 7, ¶ [0073]: "aggregate them over time to generate longitudinal medical record 56"; page 8, ¶ [0077]: "At 162, longitudinal medical record 56 may be generated"; page 9, claim 5: "generating a longitudinal medical record of the individual"; FIG. 4).
"receive, via the network connection, a request by the other device to access the longitudinal record;" — Rangadass teaches that a query for the stored record is generated at the client and received by cOS 12, which then retrieves the requested data (Rangadass, page 4, ¶ [0037]: "a physician may click a tab on a suitable interface in client 58(1), which may generate a query for healthcare signature 54. Vectors may be extracted from health record 52, and transmitted to client 58(1), where the interface may render the vectors in a suitable format as healthcare signature 54" and "health record 52, healthcare signature 54 and longitudinal medical record 56 may be stored in cOS data store 50 and retrieved by suitable queries on clients 58"; page 4, ¶ [0044]: "health record 52, healthcare signature 54 and longitudinal medical record 56 stored in cOS data store 50 may be searchable through a search query on a suitable interface"; page 7, ¶ [0069]: "A physician may later access health record 52 on clients 58 by querying the unique identifier").
"generate a visual display of the longitudinal record and the willingness signature to the other device; and" — Rangadass teaches generating, at the requesting client, an interface displaying both the longitudinal medical record 56 and the healthcare signature 54 (Rangadass, page 6, ¶ [0066]: "A display module 92 may facilitate displaying health record 52, healthcare signature 54, longitudinal medical record 56 and other information in suitable formats on an appropriate interface (e.g., on a display screen at client 58(1))"; page 7, ¶ [0074]: "FIG. 6 is a simplified diagram illustrating example details of an interface 110 for displaying data on clients 58(1)-58(N). Interface 110 may include messages 112, medical charts 114, lab results 116, medical images 118, health record 52, healthcare signature 54, and longitudinal medical record 56"; page 8, ¶ [0077]: "At 164, cOS 12 may facilitate displaying health record 52, healthcare signature 54, longitudinal medical record 56 and other information (e.g., messages, patient summary, etc.) on suitable interface 110"; page 9, claim 7: "facilitating displaying the health record, the healthcare signature and the longitudinal medical record of the individual on an interface"; FIGS. 6 and 7).
Rangadass teaches generating a healthcare signature 54 of the individual from the plurality of vectors 78, where the healthcare signature is an aggregation of the vectors represented mathematically as an array (Rangadass, page 2, ¶ [0021]; page 6, ¶ [0061]). However, Rangadass does not teach the following limitations:
"generate, using the machine learning model and the plurality of vectors, a willingness signature associated with an individual,"
"wherein the willingness signature is a numerical value or a probability distribution"
"that represents a propensity of the individual to engage in healthcare-related activities,"
"wherein to generate the willingness signature, the machine learning model is configured to perform at least one of feature classification, data clustering, and linear or logistic regression;"
"detect, based on the longitudinal record monitoring, updates to the plurality of vectors;"
"retrain the machine learning model using the updates to the plurality of vectors;"
"issue a real-time notification to one or more third parties based on the detected updates to the plurality of vectors;"
"provide to the other device, using the willingness signature, one or more of personalized recommendations, feedback, trend analysis, score adjustments, and real-time data monitoring updates."
In the same field of endeavor, Wexler teaches:
"generate, using the machine learning model and the plurality of vectors, a willingness signature associated with an individual," — Wexler teaches an analyzing device 102 that uses machine learning models 122 to analyze input data and generate output data for a user, and that generates from that data a propensity value for the individual (Wexler, page 3, ¶ [0030]: "the analyzing device 102 is configured to analyze the input data and generate the output data using one or more machine learning models 122. The machine learning models 122 can include supervised learning models, unsupervised learning models, semi-supervised learning models, and/or reinforcement learning models generated by one or more modeling engines 112"; page 5, ¶ [0045]: "Additional further values can be generated from the history of task completions, prompts and reinforcements. For example, propensity and/or sensitivity can be generated").
"wherein the willingness signature is a numerical value or a probability distribution" — Wexler teaches that the propensity value is a base probability computed as a maximum likelihood estimator, and further teaches returning a probability distribution (Wexler, page 5, ¶ [0045]: "Propensity can be the base probability of completing a task, effectively representing the effects of all factors not explicitly represented in the model"; page 5, ¶ [0046]: "The system can then generate values of propensity and sensitivity as the maximum likelihood estimators given the data and a probability function"; page 7, ¶ [0063]: "Simulated behavior functions return a probability distribution for behaviors based on the state of the user and a selected action"; page 7, ¶ [0062]: "Update functions are used to update the state of the user and associated probability distributions for particular behaviors that are determined based on the state of the user, the parameters of the user, recent behaviors of the user").
"that represents a propensity of the individual to engage in healthcare-related activities," — Wexler teaches that the propensity is the probability that the individual will complete a health-management task, where the tasks relate to the management of the individual's medical conditions (Wexler, page 5, ¶ [0045]: "Propensity can be the base probability of completing a task"; page 5, ¶ [0042]: "task completion by the individual over time, with more emphasis on task adherence in the near future"; page 1, ¶ [0019]: "the system 100 can be used to identify, manage, monitor, and/or provide recommendations relating to diabetes, hypoglycemia, hyperglycemia, pre-diabetes, hypertension, hyperlipidemia, ketoacidosis, liver failure").
"wherein to generate the willingness signature, the machine learning model is configured to perform at least one of feature classification, data clustering, and linear or logistic regression;" — Wexler teaches that the machine learning models 122 used to analyze the individual's input data and generate the output data are selected from an enumerated set that expressly includes classification algorithms, clustering algorithms, and linear and logistic regression algorithms (Wexler, page 3, ¶ [0030]: "Examples of machine learning models suitable for use with the present technology include, but are not limited to: regression algorithms (e.g., ordinary least squares regression, linear regression, logistic regression, stepwise regression, multivariate adaptive regression splines, locally estimated scatterplot smoothing), instance-based algorithms (e.g., k-nearest neighbor, learning vector quantization, self-organizing map, locally weighted learning, support vector machines), regularization algorithms (e.g., ridge regression, least absolute shrinkage and selection operator, elastic net, least-angle regression), decision tree algorithms (e.g., classification and regression trees, Iterative Dichotomiser 3 (ID3), C4.5, C5.0, chi-squared automatic interaction detection, decision stump, M5, conditional decision trees), Bayesian algorithms (e.g., naïve Bayes, Gaussian naïve Bayes, multinomial naïve Bayes, averaged one-dependence estimators, Bayesian belief networks, Bayesian networks), clustering algorithms (e.g., k-means, k-medians, expectation maximization, hierarchical clustering)").
"detect, based on the longitudinal record monitoring, updates to the plurality of vectors;" — Wexler teaches obtaining new data for the user, accessing the user history items maintained for that user, and estimating from the new data and that history an updated state of the user, where the state is an array of user values that changes at every step (Wexler, page 1, Abstract: "The method can include obtaining new data and accessing one or more user history items regarding a user; estimating a state of the user"; page 3, ¶ [0034]: "The state estimator 114 can use corresponding machine learning models 122 to generate the estimated user states. For example, the state estimator 114 can use the models 122 to predict based on the current state and the user history 124 that blood glucose levels will reach a threshold level"; page 7, ¶ [0062]: "State includes an array of user values that are observable or estimable, and can change every step based on the actions from the software application and the behavior of the user").
"retrain the machine learning model using the updates to the plurality of vectors;" — Wexler teaches updating the model on the basis of the user's response to the executed action, and further teaches that the adaptive support model is iteratively improved and continues to learn from the tracked behavior of each user over time (Wexler, page 1, Abstract: "identifying and executing an action for affecting a response of the user in assisting the user adjust a user behavior; and updating a model based on the response of the user"; page 4, ¶ [0037]: "one or more elements of an adaptive intervention are iteratively improved via data-driven testing (e.g., optimization), which may improve the likelihood of successfully helping individuals to meet and maintain behavioral targets"; page 5, ¶ [0042]: "an adaptive support model can be configured to learn from a multitude of users while keeping track of the messages and behavior of each user over time, in order to serve them with the optimal messages at every time slot").
"issue a . . . notification to one or more third parties based on the detected updates to the plurality of vectors;" — Wexler teaches that the system generates and transmits notifications to users of the system, that such users expressly include healthcare professionals and computing devices in addition to the patient, and that the notification is issued as a consequence of the updated state estimated from the newly obtained user data (Wexler, page 2, ¶ [0028]: "one or more users can access the system 100 via the user devices 104, e.g., to send data to the analyzing devices 102 (e.g., health-related information, contextual information) and/or receive data from the system 100 (e.g., predictions, notifications, recommendations, instructions, support, etc.). The users can be individual users (e.g., patients, healthcare professionals, etc.), computing devices, software applications, objects, functions, and/or any other types of users"; page 4, ¶ [0035]: "the state estimator 114 can start from a current health state (e.g., blood glucose level) and extrapolate or derive future health states according to the activity predictions. The system 100 can use the future health states to determine and recommend one or more user actions that may be implemented between now and a future time to avoid the thresholding health states").
"provide to the other device, using the willingness signature, one or more of personalized recommendations, feedback, trend analysis, score adjustments, and real-time data monitoring updates." — Wexler teaches transmitting recommendations to the recipient device selected on the basis of the individual's estimated state and propensity value, providing reinforcements in response to the individual's behavior, and deriving recent average frequency values and future-state extrapolations from the tracked data (Wexler, page 2, ¶ [0028]: "receive data from the system 100 (e.g., predictions, notifications, recommendations, instructions, support, etc.)"; page 4, ¶ [0035]: "The system 100 can use the future health states to determine and recommend one or more user actions"; page 5, ¶ [0046]: "the probability of the individual completing a task according to a function of the recent average prompt frequency, recent average task completion frequency, recent average reinforcement frequency, current propensity, and/or current sensitivity"; page 5, ¶ [0045]: "Sensitivity can be the strength and direction of the effects of reinforcements on an individual"; page 3, ¶ [0034]: "the state estimator 114 can generate activity predictions for a predetermined future duration based on the obtained data").
Rangadass and Wexler are analogous to the claimed invention as both are from the same field of endeavor of computerized systems that aggregate an individual's health-related data and generate an individualized metric for that individual. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the vector extraction, signature generation, longitudinal monitoring, and client display of Rangadass with the machine-learning propensity generation, model updating, notification, and recommendation of Wexler. The motivation to combine Rangadass and Wexler is as recited by Wexler (page 4, ¶ [0037]: "which may improve the likelihood of successfully helping individuals to meet and maintain behavioral targets"), so as to realize the predictive analytics that Rangadass identifies as an object of its system (page 2, ¶ [0023]: "Applications in cOS 12 can provide predictive analytics and care coordination workflows for all stakeholders in the care continuum").
The combination of Rangadass and Wexler, however, does not teach "input the plurality of vectors into a machine learning model trained using historical data from the at least one internet-connected data source;".
In the same field of endeavor, Bostic teaches:
"input the plurality of vectors into a machine learning model" — Bostic teaches generating a feature vector from patient information and inputting that feature vector into a machine learned model, which outputs a score (Bostic, page 21, ¶ [0214]: "the testing recommendation module 304 may generate a set of features (e.g., a feature vector) based on the proposed prescription … for the patient and the patient information (e.g., a patient's age, a patient's sex, a patient's weight, a patient's body type, a patient's medication history)"; page 21, ¶ [0216]: "the testing recommendation module 304 may input the set of features to the model, which outputs a confidence score for each type of potential test given the features").
"trained using historical data from the at least one internet-connected data source;" — Bostic teaches ingesting healthcare data from a plurality of patient data providers and determining relationships between that patient data and historical data for use by the machine learning module (Bostic, page 1, Abstract: "Systems and methods are provided for simulating a patient health state by determining one or more relationships between patient data and historical data, creating enriched data elements based on the determined relationships, and using a machine learning module to compute a current health state for a patient and to simulate a future health state of the patient"; page 1, ¶ [0007]: "ingesting healthcare data of a patient received from one of a plurality of patient data providers; enriching at least one new data element of the ingested healthcare data based on the determined one or more relationships among the ingested healthcare data; transmitting the at least one new data element to a raw data cluster; transmitting the raw data cluster to a machine learning module"; page 3, ¶ [0019]: "transmitting the ingested healthcare data to a data store; transmitting the data store to a machine learning module"; FIG. 2, elements 222, 226, 230, 234, 238).
Rangadass, Wexler, and Bostic are analogous to the claimed invention as all three are from the same field of endeavor of ingesting an individual's health-related data from a plurality of data providers and applying that data to generate an individualized metric. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the combination of Rangadass and Wexler with the feature-vector input and historical-data training of Bostic. The motivation to combine Rangadass, Wexler, and Bostic is to supply the trained model of Wexler with the vectors already extracted by Rangadass, thereby obtaining the accuracy benefit that Bostic attributes to training on historical data (page 1, Abstract).
The combination of Rangadass, Wexler, and Bostic, however, does not teach the following limitations:
"wherein the preprocessing of the extracted data includes using a natural language processing model having access to a document data store to perform automated data augmentation and data enrichment on the extracted data;"
"issue a real-time notification"
In the same field of endeavor, Singh teaches:
"wherein the preprocessing of the extracted data includes using a natural language processing model" — Singh teaches receiving a natural language data file representing the doctor's notes for the individual and processing that natural language file to structure it for input to the machine learning algorithm (Singh, page 1, Abstract: "receiving, at a server, a natural language data file representing doctors notes from a provider visit related to a service instance; receiving, at the server, a structured data set including patient profile data, diagnosis and procedure codes, and quantitative data related to a payment requested; processing at least the natural language data file using a medical dictionary to output a set of key medical terms"; page 9, ¶ [0055]: "data may take the form of unstructured, natural language text as in the case of an appeal letter, claim letter, claim denial letter, doctor's notes, etc. Accordingly, the data may be first processed to structure the data using different filtering or processing techniques, including as an example, utilizing various medical dictionaries").
"having access to a document data store" — Singh teaches that the processing is performed by comparing the words and phrases of the extracted natural language data against a medical library of stored documents, and identifies the constituent documents of that library (Singh, page 9, ¶ [0059]: "To aid in identifying the master set of key words and/or phrases, the fourth step 140 can include comparing words and phrases in the labeled, selected data to words and phrases contained a medical library (e.g., a medical dictionary, medical guidelines, etc.) For example, if the phrase 'medial collateral ligament' appears within both the selected data (e.g., doctor's notes) and the medical library, the phrase will be identified as part of the master set of key words and/or phrases"; page 9, ¶ [0058]: "The master set of key words and phrases can be extracted from, for example, insurance claim forms prepared by one or more providers, insurance claim appeal forms prepared by one or more providers, doctor notes associated with one or more patients, explanation of benefit forms prepared by the payer, claim denial letters prepared by the payer, claim acceptance letters prepared by one or more payers, or any combination thereof").
"to perform automated data augmentation and data enrichment on the extracted data;" — Singh teaches that the extracted data is thereby supplemented with an identified master set of key medical terms and is further categorized into a plurality of defined fields, so that the resulting data set contains information not present in the raw extracted data (Singh, page 8, ¶ [0054]: "structuring the selected, labeled training data. This step is optional, and may include pre-processing of data to make it clean for inputting into the machine learning algorithm"; page 9, ¶ [0057]: "the fourth step 140 includes analyzing the labeled, selected data to identify a master set of key words and/or phrases used in the labeled, selected data … selecting a master set of key words and/or phrases from the data aids the machine learning algorithm in identifying patterns and successfully predicting outcomes"; page 9, ¶ [0056]: "structuring of the data may refer to identifying and categorizing each piece of data in each of the labeled sets. For example, the data in each labeled set can be categorized into one or more of a plurality of fields, including, for example, a provider name, a provider address, … a patient name, … doctor notes associated with the patient and/or procedure, a procedure code, a diagnosis code, a services provided date, a billed amount").
"issue a real-time notification" — Singh teaches a notification module that transmits a notification alerting a third-party provider to the status of the individual's claim, and further teaches that the underlying determinations are updated in real time as new data is received (Singh, page 20, ¶ [0108]: "The provider module 662 can further include a notification module, a workflow module, an analytics module, or any combination thereof that populate the dashboard on the provider device. For example, the notification module can be configured to transmit a notification to the provider server 620 that alerts the provider, via the displayed dashboard, regarding the status of an insurance claim (e.g., a payer has denied a claim)"; page 17, ¶ [0089]: "The optional eighth step 280 can also include updating the ordered database of appeal candidate entries in real-time based on newly inputted data. For example, … based on newly inputted data, the percentage likelihood of a given appeal candidate in the ordered database may change and the optional eighth step 280 can include reordering the ordered database in real-time as percentage likelihoods fluctuate given the newest data").
Rangadass, Wexler, Bostic, and Singh are analogous to the claimed invention as all four are from the same field of endeavor of computerized systems that receive an individual's healthcare data from a plurality of sources, process that data into a form suitable for downstream analysis, and report an individualized result to a provider or other interested party. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to perform the format conversion of Rangadass using the medical-dictionary-based natural language processing of Singh, and to issue the notification of Wexler in real time as taught by Singh. The motivation to combine Rangadass, Wexler, Bostic, and Singh is as recited by Singh (page 9, ¶ [0057]: "selecting a master set of key words and/or phrases from the data aids the machine learning algorithm in identifying patterns and successfully predicting outcomes"), which addresses the unstructured-content problem that Rangadass identifies with respect to its own incoming data (page 3, ¶ [0034]: "an employee may manually enter relevant information from the paper mail into a pre-defined template").
The combination of Rangadass, Wexler, Bostic, and Singh, however, does not teach "cause the preprocessed data to be stored using a blockchain network;".
In the same field of endeavor, Saxena teaches:
"cause the preprocessed data to be stored using a blockchain network;" — Saxena teaches that the data received from the plurality of data sources and processed by the cognitive platform is stored in a blockchain, and further teaches that the analytics infrastructure of that platform includes a blockchain database as a storage sub-component (Saxena, page 22, ¶ [0203]: "repositories of multi-structured data 1104 may include unstructured data (e.g., a document), semi-structured data (e.g., a social media post), and structured data (e.g., a string, an integer, etc.), such as data stored in a relational database management system (RDBMS) or a blockchain. In various embodiments, such data may be stored in a data lake 1114, a data warehouse 1116, a blockchain 1117, or some combination thereof"; page 12, ¶ [0112]: "the cloud analytics infrastructure 344 component may also include a distributed object storage 478 sub-component, a distributed full text search 480 sub-component, a document database 482 sub-component, a blockchain database 483 sub-component, a graph database 484 sub-component, and various other sub-components"; page 1, Abstract: "receiving data from a plurality of data sources, at least some of the plurality of data sources comprising financial related data sources and blockchain data sources; processing the data from the plurality of data sources to provide a financial-related, blockchain-associated cognitive insight"; page 14, ¶ [0126]: "the distributed and replicated nature of a blockchain makes it difficult to modify historical records").
Rangadass, Wexler, Bostic, Singh, and Saxena are analogous to the claimed invention as all five are from the same field of endeavor of computerized systems that receive data from a plurality of data sources, process that data, store the processed data in a repository, and generate an individualized insight therefrom. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to store the preprocessed data of Rangadass in the blockchain of Saxena. The motivation to combine Rangadass, Wexler, Bostic, Singh, and Saxena is as recited by Saxena (page 14, ¶ [0126]: "the distributed and replicated nature of a blockchain makes it difficult to modify historical records"), which addresses the data integrity and access-control concerns that Rangadass identifies with respect to the individual's aggregated medical and non-medical data (page 7, ¶ [0076]: "the medical information may not be visible, due to security and privacy concerns, among other reasons").
Regarding claim 20, the limitations of claim 19 from which claim 20 depends are rejected under the same rationale set forth above with respect to claim 19.
Regarding the limitations added by claim 20, Rangadass teaches:
"wherein the at least one processor is further configured to:" — Rangadass teaches a processor 100 that performs the recited operations by way of a longitudinal module 90, a monitoring and routing module 98, and a transmit module 94 (Rangadass, page 6, ¶ [0066]: "A transmit module 94 may facilitate transmitting data 82 to authorized users … A monitoring and routing module 98 may monitor communication within cOS 12 and with external entities, including medical systems 14, business systems 26 and clients 58. A processor 100 and a memory element 102 may facilitate performing various operations described herein"; FIG. 5).
Rangadass teaches that the longitudinal medical record 56 is used to assess the health history of the individual and to discern trends in the monitored vectors (Rangadass, page 4, ¶ [0043]; page 6, ¶ [0064]). However, Rangadass does not teach the following limitations:
"determine a health threshold value based on the longitudinal record;"
"monitor the health of the individual via a determination of whether a current status of the individual is within a range between the health threshold value and a lower limit; and"
"inform the other device of the current status of the individual when it is determined that the current status is within the range between the health threshold value and the lower limit."
In the same field of endeavor, Wexler teaches:
"determine a health threshold value based on the longitudinal record;" — Wexler teaches that the state estimator determines, from the individual's current state and the maintained user history, a threshold level that the individual's monitored health value will reach (Wexler, page 3, ¶ [0034]: "The state estimator 114 can use corresponding machine learning models 122 to generate the estimated user states. For example, the state estimator 114 can use the models 122 to predict based on the current state and the user history 124 that blood glucose levels will reach a threshold level at a time when the user will likely be incapacitated (e.g., sleeping or intoxicated). In some embodiments, the state estimator 114 can generate activity predictions for a predetermined future duration based on the obtained data").
"monitor the health of the individual via a determination of whether a current status of the individual is within a range between the health threshold value and a lower limit; and" — Wexler teaches beginning from the individual's current health state, deriving future health states, and determining actions to keep the individual clear of the thresholding health states, where the monitored conditions are expressly bounded on both sides by an upper and a lower thresholding state (Wexler, page 4, ¶ [0035]: "the state estimator 114 can start from a current health state (e.g., blood glucose level) and extrapolate or derive future health states according to the activity predictions. The system 100 can use the future health states to determine and recommend one or more user actions that may be implemented between now and a future time to avoid the thresholding health states"; page 1, ¶ [0019]: "the system 100 can be used to identify, manage, monitor, and/or provide recommendations relating to diabetes, hypoglycemia, hyperglycemia, pre-diabetes, hypertension, hyperlipidemia, ketoacidosis, liver failure"; page 1, ¶ [0019]: "the system 100 receives input data and performs monitoring, processing, analysis, forecasting, interpretation, etc. of the input data").
"inform the other device of the current status of the individual when it is determined that the current status is within the range between the health threshold value and the lower limit." — Wexler teaches transmitting notifications reporting the individual's status to the recipient devices of the system, where the recipients expressly include healthcare professionals and computing devices, and where the notification is issued as a consequence of the estimated state (Wexler, page 2, ¶ [0028]: "one or more users can access the system 100 via the user devices 104, e.g., to send data to the analyzing devices 102 (e.g., health-related information, contextual information) and/or receive data from the system 100 (e.g., predictions, notifications, recommendations, instructions, support, etc.). The users can be individual users (e.g., patients, healthcare professionals, etc.), computing devices, software applications, objects, functions, and/or any other types of users"; page 1, ¶ [0019]: "the system 100 receives input data and performs monitoring, processing, analysis, forecasting, interpretation, etc. of the input data in order to generate user reports, behavior goals, instructions, notifications, recommendations, support, and/or other information to the patient that may be useful for self-care of diseases or conditions, such as chronic conditions").
Rangadass and Wexler are analogous to the claimed invention as both are from the same field of endeavor of computerized systems that monitor an individual's health-related data over time and report the results to interested parties. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the longitudinal vector monitoring and client reporting of Rangadass with the threshold determination, state monitoring, and status notification of Wexler. The motivation to combine Rangadass and Wexler is as recited by Rangadass (page 6, ¶ [0063]: "a person could have a monitor for heart attacks that would automatically call 911 in case of heart trouble"), which identifies automatic reporting upon the individual's monitored values reaching a defined condition as an object of its system.
The combination of Rangadass and Wexler, however, does not teach "determine a health threshold value based on the longitudinal record" insofar as the threshold is compared against a score computed by the model.
In the same field of endeavor, Bostic teaches:
"determine a health threshold value" — Bostic teaches that the machine learned model outputs a score for the individual and that the system determines whether that score satisfies a threshold before acting on it (Bostic, page 21, ¶ [0215]: "the recommendation may include a confidence score that indicates a degree of confidence in the recommendation. The testing recommendation module 304 may determine whether to select a recommendation made by a model based on the confidence score corresponding to the recommendation (e.g., when the confidence score exceeds a threshold)"; page 21, ¶ [0216]: "the testing recommendation module 304 may input the set of features to the model, which outputs a confidence score for each type of potential test given the features").
Rangadass, Wexler, and Bostic are analogous to the claimed invention as all three are from the same field of endeavor of ingesting an individual's health-related data and applying that data to generate an individualized metric that is evaluated and reported. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the combination of Rangadass and Wexler with the threshold comparison of the model output of Bostic. The motivation to combine Rangadass, Wexler, and Bostic is to determine, before informing the recipient device, whether the individual's status warrants reporting, thereby limiting the reports delivered to the recipient to those that satisfy the threshold as taught by Bostic (page 21, ¶ [0215]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUNG VAN LE whose telephone number is (571)270-0164. The examiner can normally be reached 8 a.m. - 5 p.m..
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, Cesar Paula can be reached at (571) 272-4128. 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.
/HUNG VAN LE/Examiner, Art Unit 2145
/CESAR B PAULA/Supervisory Patent Examiner, Art Unit 2145
Prosecution Insights