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 .
DETAILED ACTION
Applicant's election with traversal of Group 1, claims 1-7 and 15-20, filed 03-25-2026, is acknowledged.
The traversal is on the ground(s) that the Restriction Requirement is improper and request reconsideration and withdrawal of the Restriction Requirement. Applicants’ arguments have been fully considered but they are not persuasive. Examiner submits that Group I is drawn to a method for constructing a medical informatics workflow comprising transferring medical data from a first medical data repository, configuring the data, refining the medical data set to produce a first refined data set, transferring the first refined medical data set, configuring an Al mode to refine an Al data set, refining the Al data set, transferring the refined Al data set, processing the first refined data set to generate a first processed medical data set, outputting the first processed medical data set to a second medical data repository, and integrating the first processed medical data set with a second medical data repository, classified in G16H/15/00. Group II is drawn to constructing a medical informatics workflow comprising to refine the first medical data set to produce a first refined medical data set, transfer the first set, refine an Al data set to produce a refined Al data set, transfer the refined Al data set, process the first refined data set to produce a first processed data set, output the first medical data set to the UI, and integrate the first processed data set with the UI, a UI connection to output the first refined medical data set to the UI, and a medical data repository connection, classified in G16H15/00. These inventions are distinct for the reasons given above and the search required for Group I is not required for the other Group. As a result, the restriction for examination purposes as indicated is proper
Claims 8-14 are withdrawn from further consideration pursuant to 37 CFR 1.142(b), as being drawn to a nonelected group, there being no allowable generic or linking claim. Applicant timely traversed the restriction (election) requirement in the reply filed on 03-25-2026.
The requirement is still deemed proper and is therefore made FINAL.
The pending claims 1-7 and 15-20 are presented for examination.
Claim Objections
6. Claims 1-2, 7, 15-16 are objected to because of the following informalities:
Claims 1-2, 7, 15-16 recite the limitation/acronym “AI” is not clearly defined or completely spelled out in the claims. Appropriate correction is required
Claim Rejections - 35 USC § 103
7. 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 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.
8. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
9. 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.
10. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
11. Claims 1-7 and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Avinash et al (US 20070118399 A1, hereinafter “Avinash”) in view of Soni et al (U.S. Patent 11984201 B2 hereinafter, “Soni”).
12. With respect to claim 1,
Avinash discloses a method for constructing a medical informatics workflow, comprising:
connecting (Avinash 399 [0086] – [0087], [0094], [0116] e.g. interconnection of the various resources, databases) a first medical data repository to a data retrieval node, the data retrieval node configured to obtain a first medical data set from the first medical data repository (Avinash 399 [0083] – [0087], [0094], [0116] – [0117] e.g. medical data - interconnection of the various resources, databases. [0117] The various types of controllable and prescribable resources, and the modalities of such resource types may include any available data resources which can be useful in performing the acquisition, processing, analysis functions offered by the present techniques. Specifically, the present technique contemplates that as few as a single resource may be provided, such as for integration of acquisition, processing and analysis over time, and, in a most useful configuration, a wide range of such resources are made available. …. As noted above, such controllable and prescribable resources may generally include electrical data sources, imaging data sources, clinical laboratory data sources, histologic data sources, pharmacokinetic data sources, and other miscellaneous sources of medical data);
transferring a first medical data set to the data retrieval node from the first medical data repository (Avinash 399 [0078], [0094], [0137], [0138], [0345] e.g. transferred – [0078] Healthcare facilities today are increasingly becoming large warehouses of information. In a typical healthcare facility, data is continuously acquired, transferred, processed, and stored. Such data ranges from patient records to scanned images to hospital logistics, and a wide variety of data types there between. …. As the quality of data and the number of different data sources increases, the management of the data becomes increasingly complex. Automated methods for data management have become very valuable in the healthcare environment.);
configuring the data retrieval node to refine the first medical data set using one or more data retrieval parameters;
refining, based on the one or more data retrieval parameters, the first medical data set to produce a first refined medical data set at the data retrieval node (Avinash 399 [0141], [0144], [0148], [0353] – [0355], [0360] e.g. refine parameter - [0353] In applications where the predictive model development module 370 is adapted for refinement of a computer-assisted process CAX, the model may identify or refine parameters useful in carrying out such processes. The output of the module 370 may therefore consist of one or more parameters identified as relating to a specific condition, event or diagnosis. Outputs from the predictive model development module 370, typically in the form of data relationships, may then be further refined or mapped onto parameters available to and used by the CAX processes 85 illustrated in FIG. 24. In a presently contemplated embodiment, therefore, a parameter refinement function 372 is provided wherein parameters utilized in the CAX processes 85 are identified, as indicated at reference numeral 37 4, and "best" or optimized values or ranges of the values are identified or as indicated at reference numeral 376. The parameters and their values or ranges are then supplied to the CAX process algorithms for future use in the specific process. As a general rule, the CAX processes produce some output as indicated at reference numeral 378. [0355] …. Similarly, the identification of parameters and parameter optimization carried out in the parameter refinement process can influence the predictive model development module. Furthermore, the results of the CAX process 85 can similarly affect the predictive model development module, such as for development or refinement of other CAX processes. [0360] Input refinement steps are carried out as indicated at block 386 in which the relationships are linked to various data inputs which are available from the resources or database or knowledge base. As noted in FIG. 25, such inputs 388 may be non-parametric, that is, relate to raw or processed data which is not specifically influenced by settings or parameters of the CAX process. Other input identification, as indicated at block 390, is targeted to parametric inputs which can be impacted by alteration of the CAX process. Based upon the input identification, the rule identification and the relationship identification, reconciliation and refinement of the model is possible as indicated at block 392. Again, such reconciliation and refinement may include addition or deletion of certain inputs, placement of certain conditions on inclusion of inputs, weighting of some inputs, and so forth. Such reconciliation and refinement may be carried out by the system or with input from an expert as indicated at reference numeral 6 in FIG. 25. The entire process, then, may be somewhat iterative as indicated by the return arrows in FIG. 25, such that the reconciliation and refinement process may further impact identification of relationships, rules and inputs.);
transferring the first refined medical data set to a programing node from the data retrieval node (Avinash 399 [0078], [0094], [0137], [0138], [0345] e.g. transferred – [0078] Healthcare facilities today are increasingly becoming large warehouses of information. In a typical healthcare facility, data is continuously acquired, transferred, processed, and stored. Such data ranges from patient records to scanned images to hospital logistics, and a wide variety of data types there between. Proper management of this data is crucial for the healthcare facility to operate efficiently as well as to meet regulatory requirements. As the quality of data and the number of different data sources increases, the management of the data becomes increasingly complex. Automated methods for data management have become very valuable in the healthcare environment.);
configuring an Al node to refine an Artificial Neural Network data set using one or more Artificial Neural Network parameters (Avinash 399 [0285] – [0287], [0411] – [0414] e.g. Artificial Neural Network …. parameter; refine … artificial intelligence; Artificial Neural Network [0285] A general diagrammatical representation of an artificial neural network is shown in FIG. 15 and designated by the reference numeral 202.…. A first layer, input layer 204, is assigned to accept a set of data representing an input pattern, a second layer, output layer 208, is assigned to provide a set of data representing an output pattern, and an arbitrary number of intermediate layers, hidden layers 206, convert the input pattern to the output pattern. … [0286] Briefly, the principle of neural network 202 can be explained in the following manner. Normalized input data 210, which may be represented by numbers ranging from 0 to 1, are supplied to input units of the neural network. … The weighting factors and offset values are internal parameters of the neural network 202, which are determined for a given set of input and output data. [0287] … The internal parameters of the neural network are adjusted to minimize the difference between the actual outputs of the neural network and the desired outputs. By iteration of this procedure in a random sequence for the same set of input and output data, the neural network learns a relationship between the training input data and the desired output data. Once trained sufficiently, the neural network can distinguish different input data according to its learning experience.);
refining, based on the one or more Artificial Neural Network parameters, the Al data set to produce a refined Artificial Neural Network data set (Avinash 399 [0285] – [0287], [0411] – [0414]);
transferring the refined Artificial Neural Network data set to the programming node from the Al node (Avinash 399 [0078], [0094], [0137], [0138], [0345] e.g. transferred – [0078] Healthcare facilities today are increasingly becoming large warehouses of information. In a typical healthcare facility, data is continuously acquired, transferred, processed, and stored. Such data ranges from patient records to scanned images to hospital logistics, and a wide variety of data types there between. Proper management of this data is crucial for the healthcare facility to operate efficiently as well as to meet regulatory requirements. As the quality of data and the number of different data sources increases, the management of the data becomes increasingly complex. Automated methods for data management have become very valuable in the healthcare environment.);
processing the first refined medical data set, wherein the programming node applies the refined Artificial Neural Network data to process the first refined medical data set to generate a first processed medical data set (Avinash 399 [0285] – [0287], [0411] – [0414]); and
outputting the first processed medical data set to a second medical data repository (Avinash 399 [0285] – [0287], [0411] – [0414]); and
integrating the first processed medical data set with a second medical data repository (Avinash 399 [0345] – [0349] e.g. The repositories 352 may be the same or other repositories, and may be useful by the patient network interface for certain processing functions carried out by the interface, such as comparison of patient data to known ranges or demographic information, integration into patient displayed interface pages of background and specific information relating to disease states, care, diagnoses and prognoses, and so forth. The patient network interface 348 where necessary, may further communicate with a translator or processing module as indicated generally at reference numeral 354. The translator and processing modules may completely or partially transform the accessed data or the patient data for analysis and storage. Again, the translator and processing functions may be bi-directional such that they may translate and process both data originating from the patient and data transferred to the patient from outside resources. [0346] An integrated patient record module 356 is designed to generate an integrated patient record, as represented generally by reference numeral 362 in FIG. 23. As used in the present context, the integrated patient record may include a wide range of information, both acquired directly from the patient, as well as acquired from institutions which provide care to the patient. The record may also include data derived from such data, such as resulting from analysis of raw patient data, image data, and the like both by automated techniques and by human care providers, where appropriate. Similarly, the integrated patient record may include information incorporated from reference data repositories 352. The integrated patient record module preferably stores some or all of the integrated patient record 362 in one or more data repository 358. [0347] As noted above, the system 344 permits creation of an integrated patient record 362 which may include a wide range of patient data. In practice, the integrated patient record, or portions of the patient record, may be stored at various locations, such as at a patient location as indicated adjacent to the patient data block 346, at individual care providers (e.g. with a primary care physician) as indicated adjacent to block 350, or within a data repository 358 accessed by the integrated patient record module 356. It should also be noted that some or all of the functionality provided by the patient network interface 348, the translator and processing module 354 and the integrated patient record module 356 may be local or remote to the patient. …. Similarly, the patient record repository 358 may be local or remote from the patient. [0348] The integrated patient record module 356 also is preferably designed to communicate with the IKB 12 via an IKB interface 360. The interface 360 may conform to the general functionalities described above with respect to access, validation, tailoring for patient needs or uses, and so forth. The IKB interface 360 permits the extraction of information from resources 18, which may be internal to specific institutions as indicated in FIG. 23. The interface also permits data from the patient to be uploaded to such resources and institutions. As also noted in FIG. 23, the integrated patient record 356, fully or in part, may be stored generally within the IKB 12 to facilitate access by care providers, for example. …. [0349] … The system also provides a powerful tool for accessing patient data, including raw data, processed data, links, updates, …. Moreover, the integration of the patient data with other functionality and data from other resources permits the integrated patient record to be created and stored periodically or in advance of specific needs by the patient or by an institution, or compiled at the time of a specific query by linking to and accessing data for response to the query.).
Although Avinash substantially teaches the claimed invention, Avinash does not explicitly indicate Al parameters … Al data set.
Soni teaches the limitations by stating
configuring the data retrieval node to refine the first medical data set using one or more data retrieval parameters;
refining, based on the one or more data retrieval parameters, the first medical data set to produce a first refined medical data set at the data retrieval node (Soni col. 4 line 64 – col. 6 line 26, col. 22 lines 20-33 e.g. [col. 4 line 64 – col. 6 line 26] medical data – (20) An example framework includes a computer and/or other processor executing one or more deep generative models such as a Generative Adversarial Network, etc., trained on aggregated medical machine time series data converted into a single standardized data structure format. The data can be organized in an ordered arrangement per patient to generate synthetic data samples and corresponding synthetic events and/or to generate missing data for time-series real data imputation, for example. Thus, additional, synthetic data/events can be generated to provide more data for training, testing, etc., of artificial intelligence network models, and/or data missing from a time series can be imputed and/or otherwise interpolated to provide a time series of data for modeling, analysis, etc. … (22) Medical data can be obtained from imaging devices, sensors, laboratory tests, and/or other data sources. [col. 22 lines 20-33] (110) However, if the first set of synthetic data does not match the expected/observed/predicted pattern, value range, and/or other characteristic of the real data (e.g., such that the discriminator 820 determines that all or most of the first set of synthetic data is "fake" and classifies the synthetic data set as fake or synthetic), then at block 1340, synthetic data generation parameters are adjusted. For example, synthetic data generation weights, input variable/vector, etc., can be adjusted to cause the generator 810 to generate a different, second set of synthetic data (e.g., including data and annotation channels, only data channel(s), etc.). Control then reverts to block 1310 to generate what is then a second set of synthetic data to be analyzed and output or further refined according to blocks 1310-1340.);
transferring the first refined medical data set to a programing node from the data retrieval node;
configuring an Al node to refine an Al data set using one or more Al parameters;
refining, based on the one or more Al parameters (Soni col. 6 lines 39-47, claim 1 e.g. [col. 6 lines 39-47] (33) Deep learning in a neural network environment includes numerous interconnected nodes referred to as neurons. Input neurons, activated from an outside source, activate other neurons based on connections to those other neurons which are governed by the machine parameters. A neural network behaves in a certain manner based on its own parameters. Learning refines the machine parameters, and, by extension, the connections between neurons in the network, such that the neural network behaves in a desired manner. [claim 1] 1. A synthetic time series data generation apparatus comprising: … b) analyze the synthetic data set with respect to a real data set using a second artificial intelligence network model to classify the synthetic data set, the real data set collected from at least one patient data source and having a second classification, the second classification different from the first classification at least in that the first classification indicates synthetic data generation by a model and the second classification indicates data captured fora patient; c) when the second artificial intelligence network model classifies the synthetic data set as having the first classification, adjust the first artificial intelligence network model, rather than the second artificial intelligence network model, using feedback from the second artificial intelligence network model to tune the first artificial intelligence network model and repeat a)-b ), the feedback including the first classification of the synthetic data set by the second artificial intelligence network model, the feedback including a loss function computed between the real data set and the synthetic data set and an error gradient associated with the loss function to adjust at least one parameter of the first artificial intelligence network model; and d) when the second artificial intelligence network model classifies the synthetic data set as having the second classification, output the synthetic data set for use in association with the second classification, wherein use of the synthetic data set includes to impute synthetic waveform signal data as missing data to complete a captured waveform.), the Al data set to produce a refined Al data set;
transferring the refined Al data set to the programming node from the Al node;
processing the first refined medical data set, wherein the programming node applies the refined Al data to process the first refined medical data set to generate a first processed medical data set; and
outputting the first processed medical data set to a second medical data repository.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of Avinash and Soni, to provide a more rigorous, encompassing and integrated approach to the access, processing, organization and analysis for medical data that can permit refinement of health care processing (Avinash [0009]).
13. With respect to claim 2,
Avinash further discloses
providing the first refined medical data set from the data retrieval node to one or more additional nodes, the one or more additional nodes configured to obtain the first refined medical data set from the data retrieval node;
configuring the one or more additional nodes to refine the first medical data set using one or more additional refining parameters (Avinash 399 [0302], [0315] – [0316], [0339], [0366], [0392] e.g. additional data resource/information/access/searches/data acquisition);
refining, based on the one or more additional refining parameters, the first refined medical data set to produce a second refined medical data set (Avinash 399 [0302], [0315] – [0316], [0339], [0366], [0392] e.g. additional data resource/information/access/searches/data acquisition); and
processing the second refined medical data set to produce the first processed
medical data set, wherein the programming node applies the refined Al data to process the second refined medical data set (Avinash 399 [0296] e.g. [0296] The interface layer, and the programming included therein and in the data processing system may permit a wide range of processing functions to be executed based upon a range of triggering events).
14. With respect to claim 3,
Avinash further discloses wherein the one or more additional nodes include a reasoning node, a programming node (Avinash 399 [0296] e.g. [0296] The interface layer, and the programming included therein and in the data processing system may permit a wide range of processing functions to be executed based upon a range of triggering events), a visualization node, a text node, a data retrieval node, an order node, a task node, or a note bar.
15. With respect to claim 4,
Avinash further discloses wherein refining, based on the one or more additional refining parameters, the first refined medical data set to produce a second refined medical data set is performed with the one or more additional nodes in sequence (Avinash 399 [0108] – [0109], [0295] - [0296] e.g. sequences).
16. With respect to claim 5,
Avinash further discloses wherein refining, based on the one or more additional refining parameters, the first refined medical data set to produce a second refined medical data set is performed with the one or more additional nodes in parallel (Avinash 399 [0367] e.g. parallel).
17. With respect to claim 6,
Avinash further discloses displaying a visualization on a user interface (UI) based on the set of the first processed medical data set (Avinash 399 [0119], [0320] – [0321], [0324] – [0325] e.g. graphical user interface).
18. With respect to claim 7,
Avinash further discloses wherein the one or more Al parameters include a summarizer, an information identifier (Avinash 399 [0458] e.g. identifier), an information extractor (Avinash 399 [0084], [0089] – [0096] e.g. extraction), a drafter, an inconsistency detector, or an editor.
19. Claims 15-17 are same as claims 1-3 and are rejected for the same reasons as applied hereinabove.
20. With respect to claim 18,
Avinash further discloses wherein at least one of the first medical data set and the first refined medical data set comprise at least one of: numeric data, sequence type data, Boolean data, set data, dictionary data, binary type data, text data, date-and-time data, demographic data, vital signs data, medical orders data, lab results data, imaging studies data, and clinical notes data (Avinash 399 [0011] e.g. image).
21. With respect to claim 19,
Avinash further discloses wherein the first medical data repository comprises a database provided by a user, an external database, or an internal database (Avinash 399 [0086] – [0087], [0094], [0116] e.g. interconnection of the various resources, databases).
22. With respect to claim 20,
Avinash further discloses wherein the one or more data retrieval parameters comprise at least one of: a data type, a data filter, a data source, conditional logic, programming logic, an arithmetic operator, a comparison operator, a custom text input, a text formatting, an input connector, an output connector, a data visualization format (Avinash 399 [0107], [0119], [0141] e.g. filter).
Conclusion
The prior art made of record, listed on form PTO-892, and not relied upon, if any, is considered pertinent to applicant's disclosure.
23. The examiner requests, in response to this office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
24. When responding to this office action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the reference cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SyLing Yen whose telephone number is 571-270-1306. The examiner can normally be reached on Mon-Fri 8:30am - 5:00pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sanjiv Shah can be reached at 571-272-4098. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SYLING YEN/Primary Examiner, Art Unit 2166
June 17, 2026
Prosecution Insights