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 .
Response to Amendment
This action is in response to the amendment filed on 02/17/2026. Claims 1, 4-6, 8, 12-13, and 15-18 are amended. Claims 1-20 are currently examined below
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claim 1, the limitations “automatically initiating a first of the API calls, to access the first location and extract the first set of data having the first clinical nomenclature, and dynamically generating a first set of data corresponding to a third nomenclature…” and “automatically initiating a second of the API calls, to access the first location, and dynamically generating a second set of data corresponding to the third nomenclature..”. A review of the specification has found no mention of generating data corresponding to a third nomenclature.
Regarding claim 1, the limitation “generating the set of code via the one or more hardware processors for initiating Application Programming Interface (API) calls to access data corresponding to the one or more configuration values, wherein generating the set of code comprises; (a) creating at least a portion of the custom application; and (b) creating, in the at least a portion of the custom application, an identification of the first location and an identification of the second location based on the associating of the first location and the second location with the set of code corresponding to the custom application” does not appear to be supported by the specification. The Examiner points to at least paragraph [68] which states in part, “Code generated, e.g., accessed, modified, and/or developed, by the application builder 106 may create or facilitate creation of one or more custom applications or part(s) of one or more custom applications.” If anything, this indicates that the code is already generated before creation of the custom application instead of the custom application being a part of the code generation process.
Claims 15 and 18 feature limitations similar to those of claim 1, and are therefore rejected using the same rationale.
Dependent claims are rejected as well since they inherit the limitations of independent claims 1, 15 and 18.
Regarding claim 5, the limitation “The one or more non-transitory media of Claim 4, wherein the presenting comprises displaying on a graphical user interface (GUI)information associated with patient data content to obtain treatment guidance, and wherein the operations further comprise: in response to displaying the content, receiving via the GUI an input relating to the treatment guidance” does not appear to be supported by the specification. The Examiner points to paragraph [81] which states, in part, “Further, as described above, operations performed during execution of the custom application may comprise presenting information associated with patient data artifacts to obtain treatment guidance.” This is the only mention of “treatment guidance” within the specification, and it is silent in regards to receiving inputs via a GUI relating to treatment guidance.
Regarding claim 6, the limitation “The one or more non-transitory media of Claim 5, wherein the information is displayed in a format and style that are each determined by the one or more hardware processors based on (a) historical data relating to prior use of the set of code and a display device and (b) artificial intelligence (Al) model with the information relating to the historical data.” The Examiner points to paragraph [72] which states, in part, “One or more of the computing system, the user device 102, the EHR system 108, or another component may present one or both of the extracted data and the processed data in a default or a user-selected display format or style (e.g., based on one or more of prior use by a user or device, historical data 138, ML model data 148, and ML, Al model data, neural network data, and adaptive agents).” This does not equate to displaying based on historical data relating to prior use of the code and a display device, or Al model with the information relating to the historical data. There is no mention of data regarding prior use of the code and display device, nor is there mention of AI model data relating to historical data.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1, the limitation “generating the set of code via the one or more hardware processors for initiating Application Programming Interface (API) calls to access data corresponding to the one or more configuration values, wherein generating the set of code comprises; (a) creating at least a portion of the custom application; and (b) creating, in the at least a portion of the custom application, an identification of the first location and an identification of the second location based on the associating of the first location and the second location with the set of code corresponding to the custom application” is indefinite. It is unclear as to how the generation of code (i.e., instructions) may be comprised of the creation of a custom application.
Regarding claim 1, the limitation “presenting, by the one or more hardware processors, the first set of data associated with the first resource and the second set of data associated with the second resource” is indefinite. The claim is preceded by “automatically initiating a first of the API calls, to access the first location and extract the first set of data having the first clinical nomenclature, and dynamically generating a first set of data corresponding to a third nomenclature based on: accessing the first location with the selection of the first resource and with the one or more configuration values” and “automatically initiating a second of the API calls, to access the second location and extract the second set of data having the second clinical nomenclature, and dynamically generating a second set of data corresponding to the third nomenclature based on: accessing the second location with the selection of the second resource and with the one or more configuration values”. It is unclear as to which data is being presented (i.e., the extracted data or the generated data)
Regarding claim 6, the limitation “The one or more non-transitory media of Claim 5, wherein the information is displayed in a format and style that are each determined by the one or more hardware processors based on (a) historical data relating to prior use of the set of code and a display device and (b) artificial intelligence (Al) model with the information relating to the historical data.” is indefinite. It is unclear as to how the AI model relates to the presentation of the information. For example, it is unclear if the model uses the historical data is input in order to output information regarding how the information is displayed, if the model information is somehow used in conjunction with the historical data to somehow determine how the information is displayed, or something else altogether.
Claims 15 and 18 features limitations similar to those of claim 1, and are therefore rejected using the same rationale.
Dependent claims are rejected as well since they inherit the limitations of the independent claims.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Representative claim 1 recites (additional limitations crossed out):
identifying,
receiving a selection of: (a) a first location, of the plurality of differing locations, wherein a first set of data stored at the first location has a first clinical nomenclature corresponding to a non-standardized format, and (b) a second location of the plurality of differing locations, wherein a second set of data stored at the second location has a second clinical nomenclature differing from the first clinical nomenclature;
associating the first location and the second location with a set of code corresponding to a custom application to be created, wherein associating the first location and the second location with the set of code corresponds to linking or recognizing the first location and the second location for inclusion in the set of code;
receiving a selection of a first resource defined by a first EHR system corresponding to the first health care location and a selection of a second resource defined by a second EHR system corresponding to the second location;
analyzing,
identifying,
presenting,
receiving one or more configuration values for the one or more configuration fields; and
(
the first location with the selection of the first resource and with the one or more configuration values; and
presenting,
The above limitations, as drafted, are processes that, under their broadest reasonable interpretation, covers the management of personal behaviors. That is, other than reciting the utilization of a “non-transitory computer readable medium”, and “processors” to perform the steps, nothing precludes the steps from being described as the management of personal behavior. For example, but for the computer components, the claims describe identifying a plurality of health care location (i.e., sources of data), receiving a selection of a health care location, receiving the selection of a category, determining data associated with the category, providing sub-categories based on the determined data, receiving selection of a sub-category, and presenting data associated with the category/sub-category from the selected health care location, which describes the management of personal behavior. If a claim limitation, under its broadest reasonable interpretation, covers the management of personal behavior, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
The judicial exception is not integrated into a practical application. In particular, the claims only recite the additional elements of a “non-transitory computer readable medium”, and “processors” to perform the steps. These additional elements are recited at a high level of generality (see at least para. [122]) such that they amount to no more than mere instructions to apply the exception using generic computing components. The claims also recite the additional limitations of “generating the set of code via the one or more hardware processors for initiating Application Programming Interface (API) calls to access data corresponding to the one or more configuration values…”, “executing the set code via the one or more hardware processors, wherein the one or more hardware processors upon executing the code cause”, “automatically initiating a first of the API calls”, and “automatically initiating a second of the API calls”. However, the generation and execution of code to initiate API calls is recited at a high level of generality, and the code and API calls are merely used as tools to implement the abstract idea (i.e. apply it).
Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. More specifically, the additional elements fail to include (1) improvements to the functioning of a computer or to any other technology or technical field (see MPEP 2106.05(a)), (2) applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition (see Vanda memo), (3) applying the judicial exception with, or by use of, a particular machine (see MPEP 2106.05(b)), (4) effecting a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05(c)), or (5) applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (see MPEP 2106.05(e) and Vanda memo).
Rather, the limitations merely add the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)) or generally link the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h)), particularly as it relates to the recited “non-transitory computer readable medium”, “processors”, “code” and “API call” elements. The claims are therefore still directed to an abstract idea
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using a “non-transitory computer readable medium”, “processors”, “code” and “API calls” to perform the steps amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.
Claims 2-14 are dependent on claim 1, and include all the limitations of claim 1. Claims 16-17 are dependent on claim 15, and include all the limitations of claim 15. Claims 19-20 are dependent on claim 18, and include all the limitations of claim 18. Therefore, they are also found to be directed to an abstract idea. Claim 5 features a “graphical user interface”. However, this merely places the presentation of data within a computer environment. Claim 8 features “training and executing a machine-learning model”. However, there are no details regarding these processes. Without some prohibition in the claims regarding scalability, computation load, etc., the training and execution of this “machine-learning model” could reasonably be considered an additional abstract idea in the “mental process” category, but for which is simply automated (i.e. “apply it”). The remaining dependent claims merely serve to further narrow the abstract idea of the independent claims. Therefore, the dependent claims are found to be directed to an abstract idea without significantly more, and the claims are not found to be patent eligible.
Claim Rejections - 35 USC § 103
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.
Claim(s) 1-5, 7, 10, and 12-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Auer (US 2002/0116226) in view of Woodlief (US 2022/0076794) and Elenchin (US 2021/0165836).
Regarding claim 1, Auer discloses One or more non-transitory media having computer-readable instructions which, when executed by one or more hardware processors, cause the one or more hardware processor to perform a plurality of operations, the operations comprising:
receiving a selection of a first resource defined by a first EHR system corresponding to the first location and a selection of a second resource defined by a second EHR system corresponding to the second location;
analyzing, by the one or more hardware processors, a first set of metadata associated with the first resource to identify a first set of characteristics corresponding to the first resource and a second set of metadata associated with the second resource to identify a second set of characteristics corresponding to the second resource
identifying, at the one or more hardware processors, one or more configuration fields (i) associated with the first resource based on the first set of characteristic and/or (ii), associated with the second resource based on the second set of characteristics;
presenting, by the one or more hardware processors, the one or more configuration fields associated with the first resource and/or the second resource;
receiving one or more configuration values for the one or more configuration fields;
(See Para. [0028] – “For example, user selection of the cardiology category 235a from the list of available categories causes the system to retrieve from data base 25 the entire list of available parameters 270 associated with this category for display in scrollable menu window 272. Category label field 240 associates a name for the selected category to be edited/defined. As shown, user selection of category label 235a causes the category label "cardiology" to appear in field 240. The order in which the categories are to be displayed in the graphical and tabular trends pages is indicated by user-selectable field 237 which shows-each of the system-defined categories labeled as 1-5. User selection of a given category and editing of this field value causes the categories to be reordered according to the user-entered value” and Para. [0029] – “Graphical window area 250 contains selected sets of parameters 251, 253 for graphical display and comprises first window 252 (Trend Panel 1), second window 254 (Trend Panel 2) and third window 256 (Trend Panel 3). Each window can accommodate up to four parameters. Parameter selection icons or controls comprising left and right arrow keys 282, 284 enable user selection of the parameters to be displayed from the super-set of possible parameters 270. The Examiner asserts that the language regarding a selection of a second resource and analyzing a second set of metadata represents a mere duplication of parts. See MPEP §2144 VI B, and In re Harza, 274 F.2d 669, 671; 124 USPQ 378, 380 (CCPA 1960), where it is stated that "the mere duplication of parts has no patentable significance unless a new and unexpected result is produced…". As no unexpected result is produced by the requirement of the steps being performed a second time, there is no patentable significance in doing so.)
Auer does not disclose:
identifying, at the one or more hardware processors, a plurality of differing locations from which to extract data, the plurality of differing locations selected from a group comprising at least a physical health care facility and a physical electronic healthcare record (EHR) system;
receiving a selection of (a) a first location, of the plurality of differing locations, wherein a first set of data stored at the first location has a first clinical nomenclature corresponding to a non-standardized format, and (b) a second location of the plurality of differing locations, wherein a second set of data stored at the second location has a second clinical nomenclature differing from the first clinical nomenclature
(See Woodlief, Para. [0089] – “FIG. 6 is an exemplary interface 600 for selecting recipients for an electronic record request, according to an embodiment of the invention. The interface 600 allows the requesting medical provider 100 select external medical providers 102 which are registered with the medical network 104 by entering a provider name in the text boxes 602. As the name is typed into a text box 602, a scrollable dropdown list can appear (not shown) that is auto-populated with matching external medical provider names.” The Examiner asserts that the language regarding a second health care database structure represents a mere duplication of parts. See MPEP §2144 VI B, and In re Harza, 274 F.2d 669, 671; 124 USPQ 378, 380 (CCPA 1960), where it is stated that "the mere duplication of parts has no patentable significance unless a new and unexpected result is produced…". As no unexpected result is produced by the requirement of the steps being performed a second time, there is no patentable significance in doing so. Further, the language indicating that the first location’s data has a first clinical nomenclature and the second location’s data has a clinical nomenclature different from the first clinical nomenclature is simply a label for the data and adds little, if anything, to the claimed acts or steps and thus does not serve to distinguish over the prior art. Any differences related merely to the meaning and information conveyed through labels (i.e., the nomenclature of the location’s data) which does not explicitly alter or impact the steps of the method (i.e., selecting a location) does not patentably distinguish the claimed invention from the prior art in terms of patentability. Therefore, it would have been obvious to a person of ordinary skill in the art at the time of invention to have the selected medical providers (i.e., locations) of Woodlief have differing nomenclatures because the nomenclature of the selected medical providers (i.e., locations) does not functionally alter or relate to the steps of the method and merely labeling the database structures differently from that of the prior art does not patentably distinguish the claimed invention. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Auer to select medical providers to request electronic records from as taught by Woodlief since it would allow a user to identify a particular data source.
Auer and Woodlief do not disclose:
associating the first location and the second location with a set of code corresponding to a custom application to be created, wherein associating the first location and the second location with the set of code corresponds to linking or recognizing the first location and the second location for inclusion in the set of code
generating the set of code via the one or more hardware processors for initiating Application Programming Interface (API) calls to access data corresponding to the one or more configuration values wherein generating the set of code comprises;
creating at least a portion of the custom application;
creating, in the at least a portion of the custom application, an identification of the first location and an identification of the second location based on the associating of the first location and the second location with the set of code corresponding to the custom application;
Executing the set of code via the one or more hardware processors, wherein the one or more hardware processors upon executing the set of code cause:
Automatically initiating a first of the API calls, to access the first location and extract the first set of data having the first clinical nomenclature, and dynamically generating a first set of data corresponding to a third nomenclature based on: accessing the first location with the selection of the first resource and with the one or more configuration values; and
Automatically initiating a second of the API calls, to access the second location and extract the second set of data having the second clinical nomenclature, and dynamically generating a second set of data corresponding to the third nomenclature based on: accessing the second location with the selection of the second resource and with the one or more configuration values
(At least in light of the 112 rejection above, Elenchin teaches this. See Elenchin, Para. [0042] – “Once created, the listener 210 can identify an on-demand user initiated trigger requesting an item and notify the assembly runtime 204. The assembly runtime 204 can then interpret the instructions of the script and execute the script. Execution of the script, as used herein, refers generally to accessing data indicated in the script and compiled said data to create the requested item. Execution is achieved by querying the originating source for the requested data via a FHIR API call. The requested items are then received by the assembly runtime 204 and compiled in the requested document.”, Para. [0043] – “The addresser 208 can address the item, according to the instructions in the script, and communicate with the communication protocol 110 for communication of the item to one or more destinations disparate from the originating source (such as destination 112).”, Para. [0044] – “As is shown in FIG. 1, FHIR APis are utilized between the CDA assembler 108, the cloud 102, Source A 104, Source B 106, and any other originating sources (not shown) while the output to the communication protocol 110 is in CDA format.”, and Para. [0047] – “ Turning now to FIG. 4, a flow diagram is provided showing a method 400 in accordance with some embodiments of the present invention. Initially, at block 410, a triggering event is identified, wherein the triggering event initiates creation of an item associated with at least one script, wherein the at least one script includes instructions indicating data to include in the item, and wherein the script includes at least one mapping of a Fast Healthcare Interoperability Resources (FHIR) resource to a resource of at least one standard. At block 420, a first source system is queried for the data indicated in the at least one script to be included in the item. At block 430, the item is created utilizing the at least one mapping of the FHIR resource to the resource of the at least one standard. At block 440, a first destination is designated for the item, wherein the first destination is disparate from the first source system. Finally, at block 450, the item is communicated to the first destination utilizing a messaging protocol.” The Examiner asserts that the language regarding initiating a second of the API calls and generating a second set of standardized-nomenclature extracted data represents a mere duplication of parts. See MPEP §2144 VI B, and In re Harza, 274 F.2d 669, 671; 124 USPQ 378, 380 (CCPA 1960), where it is stated that "the mere duplication of parts has no patentable significance unless a new and unexpected result is produced…". As no unexpected result is produced by the requirement of the steps being performed a second time, there is no patentable significance in doing so. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the system of Auer and Woodlief to utilize APIs as taught by Elenchin since APIs provide a means to expose the underlying data of a database without knowledge of the database layout (see Para. [0019] of Elenchin)).
Auer discloses presenting, by the one or more hardware processors, the first set of data associated with the first resource and the second set of data associated with the second resource. (See Para. [0028] – “Parameter selection icons or controls comprising left and right arrow keys 282, 284 enable user selection of the parameters to be displayed from the super-set of possible parameters 270.” The Examiner asserts that the language regarding presenting the second set of standardized-nomenclature extracted data represents a mere duplication of parts. See MPEP §2144 VI B, and In re Harza, 274 F.2d 669, 671; 124 USPQ 378, 380 (CCPA 1960), where it is stated that "the mere duplication of parts has no patentable significance unless a new and unexpected result is produced…". As no unexpected result is produced by the requirement of the steps being performed a second time, there is no patentable significance in doing so.
Regarding claim 2, Auer discloses The one or more non-transitory media of Claim 1, wherein:
prior to receiving the selection of the first resource, the first EHR system is analyzed to identify a plurality of resources associated with the first EHR system
the plurality of resources are associated with a FHIR standard, include the first resource, and are presented as a candidate set of resources for user selection.
(See Para. [0005] - “The user customization menu also facilitates user definition of multiple default parameter sets for storage and later retrieval from a data base. The default sets of medical parameters include at least two associated with the following medical categories: cardiology, laboratory results, hemodynamic functions, ventilation parameters and neurology.” The Examiner asserts that since the data is related to medical categories, that it is associated with an FHIR standard.)
Regarding claim 3, Auer partially discloses The one or more non-transitory media of Claim 1, wherein (a) initiating the first of the API calls extracts data associated with the first resource and associated with a FHIR protocol, and (b) the data associated with the first resource is presented in accordance with the one or more configuration values. (Auer discloses present the data associated with the first resource in accordance with the one or more configuration values. See Para. [0028] – “Parameter selection icons or controls comprising left and right arrow keys 282, 284 enable user selection of the parameters to be displayed from the super-set of possible parameters 270.” However, Auer does not explicitly disclose the remainder of the limitation. See Elenchin, Para. [0006] – “In accordance with the media, the method comprises identifying a triggering event, wherein the triggering event initiates creation of an item associated with at least one script, wherein the at least one script includes instructions indicating data to include in the item, and wherein the script includes at least one mapping of a Fast Healthcare Interoperability Resources (FHIR) resource to a resource of at least one standard; querying a first source system for the data indicated in the at least one script to be included in the item; creating the item utilizing the at least one mapping of the FHIR resource to the resource of the at least one standard; designating a first destination for the item, wherein the first destination is disparate from the first source system; and communicating the item to the first destination utilizing a messaging protocol.” It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Auer to utilize APIs as taught by Elenchin since APIs provide a means to expose the underlying data of a database without knowledge of the database layout (see Para. [0019] of Elenchin).
Regarding claim 4, Auer discloses The one or more non-transitory media of Claim 3, wherein executing the set of code causes automatically and dynamically performing, by the one or more hardware processors:
Accessing a set of resources at the first EHR system; and
retrieving from the first EHR system, a subset of the set of resources that corresponds to patient data content associated with at least one EHR record in the first EHR system.
(See at least Para. [0026] – “A user request for medical parameter data associated with a given patient (step 208) causes the search engine on server 20 to search and retrieve all data parameters meeting the predetermined search criteria.” )
Regarding claim 5, Auer discloses The one or more non-transitory media of Claim 4, wherein the presenting comprises displaying on a graphical user interface (GUI)information associated with patient data content to obtain treatment guidance, and wherein the operations further comprise: in response to displaying the content, receiving via the GUI an input relating to the treatment guidance. (See Para. [0005] – “A network compatible, configurable user interface system for displaying a set of user-selectable, sequentially generated patient medical parameters, together with an associated time indication comprises a display menu generator for generating a customization menu that enables user selection of a default set of medical parameters from a plurality of available sets of default medical parameters.” The Examiner notes that the language “to obtain treatment guidance” is a statement of intended use and fails to result in a manipulative difference between the claimed invention and the prior art.)
Regarding claim 7, Auer discloses The one or more non-transitory media of Claim 1, wherein the first EHR system is FHIR compliant and configured to be mapped to one or more of: patient medical records associated with a particular hospital, or patient medical records associated with an HIE platform and related to immunization status. (Auer discloses the HER system being mapped to patient medical records associated with a particular hospital. See at least Fig. 1. However, Auer does not explicitly disclose the EHR is FHIR compliant. However, the Examiner asserts that the EHR being FHIR compliant is simply a label for the EHR and adds little, if anything, to the claimed acts or steps and thus does not serve to distinguish over the prior art. Any differences related merely to the meaning and information conveyed through labels (i.e., the compliance of the EHR ) which does not explicitly alter or impact the steps of the method does not patentably distinguish the claimed invention from the prior art in terms of patentability. Therefore, it would have been obvious to a person of ordinary skill in the art at the time of invention to have the EHR of Auer be FHIR compliant because the compliance of the EHR does not functionally alter or relate to the steps of the method and merely labeling the EHR differently from that of the prior art does not patentably distinguish the claimed invention.)
Regarding claim 10, Auer discloses The one or more non-transitory media of Claim 1, wherein the one or more configuration fields are associated with a plurality of selectable user scope fields. (See at least Figs. 3A and 3D, and associated text. The Examiner notes that the specification fails to define “user scope fields”. Therefore, they shall be interpreted as any type of field.)
Regarding claim 12, Auer discloses The one or more non-transitory media of Claim 1, wherein:
the selection of the first resource indicates a resource type;
the operations further comprise automatically and dynamically performing, by the one or more hardware processors:
in response to the selection of the first resource, analyzing the first set of metadata associated with the first resource; and
based on analyzing the first set of metadata associated with the first resource, identifying the first set of characteristics and the one or more configuration fields; and
presenting the one or more configuration fields includes presenting: a plurality of selectable resource parameter fields, a user-definable number of instances data field, a type of display format field, and a display location of data field
(See Para. [0028] – “For example, user selection of the cardiology category 235a from the list of available categories causes the system to retrieve from data base 25 the entire list of available parameters 270 associated with this category for display in scrollable menu window 272. Category label field 240 associates a name for the selected category to be edited/defined. As shown, user selection of category label 235a causes the category label "cardiology" to appear in field 240. The order in which the categories are to be displayed in the graphical and tabular trends pages is indicated by user-selectable field 237 which shows-each of the system-defined categories labeled as 1-5. User selection of a given category and editing of this field value causes the categories to be reordered according to the user-entered value” and Para. [0029] – “Graphical window area 250 contains selected sets of parameters 251, 253 for graphical display and comprises first window 252 (Trend Panel 1), second window 254 (Trend Panel 2) and third window 256 (Trend Panel 3). Each window can accommodate up to four parameters. Parameter selection icons or controls comprising left and right arrow keys 282, 284 enable user selection of the parameters to be displayed from the super-set of possible parameters 270. The Examiner notes that the “user-definable number of instances data field, a type of display format field, and a display location of data field” are not defined by the specification, and are therefore interpreted as any type of field.)
Regarding claim 13, Auer discloses The one or more non-transitory media of Claim 12, wherein: the selection of the first resource indicates an Observation resource type, and the plurality of selectable resource parameter fields is included in a drop-down menu that includes: a VITAL SIGN (BMI) selectable field, a VITAL SIGN (Pressure) selectable field, a LAB (Creatinine) selectable field, and a LAB (Hemoglobin) selectable field. (See at least Para. [0028] and Figs. 3A and 3D. The Examiner notes that the specification fails to define an “Observation resource type”. Therefore, the Examiner shall interpret it as any type of resource/category. Further, while Auer does not explicitly feature the fields VITAL SIGN (BMI), VITAL SIGN (Pressure), LAB (Creatinine), and LAB (Hemoglobin), the Examiner notes that the particular type of field (ex. VITAL SIGN (BMI)) is considered non-functional descriptive material, of which does not explicitly alter or impact the steps of the method in such a way as to establish a new and unobvious functional relationship with the method as claimed. As such, the non-functional descriptive material limitation can be given little to no patentable weight. See MPEP 2111.05.)
Regarding claim 14, Auer discloses The one or more non-transitory media of Claim 1, wherein:
the selection of the first resource is based on a drop-down menu that includes a Patient resource type, an Observation resource type, a Procedure resource type, and a MedicationRequest resource type; and
in response to a selection of the Observation resource type, a plurality of selectable Resource Parameter fields associated with the Observation resource type are presented.
(See at least Para. [0028] and Figs. 3A and 3D. The Examiner notes that the specification fails to define the “Observation resource type”, “Procedure resource type” and “MedicationRequest resource type”. Therefore, the Examiner shall interpret them as any type of resource/category.)
Claim 15 features limitations similar to those of claim 1, and is therefore rejected using the same rationale.
Claim 16 features limitations similar to those of claim 2, and is therefore rejected using the same rationale.
Claim 17 features limitations similar to those of claim31, and is therefore rejected using the same rationale.
Claim 18 features limitations similar to those of claim 1, and is therefore rejected using the same rationale.
Claim 19 features limitations similar to those of claim 2, and is therefore rejected using the same rationale.
Claim 20 features limitations similar to those of claim 3, and is therefore rejected using the same rationale.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Auer (US 2002/0116226) in view of Woodlief (US 2022/0076794) and Elenchin (US 2021/0165836), and in further view of Reiner (US 2014/0324469)
Regarding claim 6, Auer, Woodlief and Elenchin do not explicitly disclose The one or more non-transitory media of Claim 5, wherein the information is displayed in a format and style that are each determined by the one or more hardware processors based on (a) historical data relating to prior use of the set of code and a display device and (b) artificial intelligence (Al) model with the information relating to the historical data.. (See Reiner, Para. [0146] – “In one embodiment, the objective is for the program 110 to create a presentation format which is quick and intuitive, dynamic, and customizable, based upon the preferences and viewing patterns of each individual end user.” It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Auer, Woodlief and Elenchin to utilize the teachings of Reiner since at Auer, Woodlief, Elenchin, Reiner are within the same field of endeavor (i.e., interaction with EHR’s), and all of the claimed elements were known in the prior art and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions and the combination would have yielded predictable results to one of ordinary skill in the art at the time of the invention
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Auer (US 2002/0116226) in view of Woodlief (US 2022/0076794) and Elenchin (US 2021/0165836), and in further view of Lucas (US 2020/0176098)
Regarding claim 8, Auer, Woodlief and Elenchin do not explicitly disclose The one or more non-transitory media of Claim 1, the operations further comprising: training a machine-learning model to identify a candidate set of resources for selection by a user; after the training, executing the machine-learning model, based on data associated with the user; and in response to executing the machine-learning model, receiving an output from the machine-learning model identifying the candidate set of resources for the selection by the user. (see Lucas, Para. [0007] – “In another aspect, a method includes the steps of determining a first concept from a text of a medical record from an electronic health record system, the first concept relating to a patient, identifying a match to the first concept in a first list of concepts, wherein the first list of concepts is not a predetermined authority, referencing the first concept with an entity in a database of related concepts, identifying a match to a second concept in a second list of concepts, the second list of concepts not directly linked to the first list of concepts except by a relationship to the entity, wherein the second list of concepts is the predetermined authority, and providing the second concept as an identifier of the patient's medical record.”, and para. [0039] – “In the field of clinical abstraction from EHR and EMR documents, machine learning or deep learning may be combined with NLP techniques to abstract relevant medical concepts. While the detailed implementations of these are disclosed in more detail below, an exemplary abstraction performed on a simple text is now provided to give a general understanding of one aspect of the disclosure. For instance, the simple text “The patient was given Tylenol 50 mg at 10:35 am.” may be analyzed using a machine learning algorithm (MLA) trained on EHR and EMR documents relating to thousands of patients to recognize medications that the patient was prescribed in order to generate the table of FIG. 2.” It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Auer, Woodlief and Elenchin to utilize the teachings of Lucas since it would allow for the extraction of key characteristics of medical data (Para. [0006] of Lucas).)
Claim(s) 9 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Auer (US 2002/0116226) in view of Woodlief (US 2022/0076794) and Elenchin (US 2021/0165836), and in further view of Scherrer (US 2010/0185871).
Regarding claim 9, Aurer, Woodleif, and Elenchin do not explicitly disclose The one or more non-transitory media of Claim 1, wherein:
the one or more configuration fields are associated with user scopes, the user scopes including a plurality of resources associated with a corresponding plurality of selectable scopes; and
at least one of the plurality of selectable scopes is associated with a selectable read-access permission field and a selectable write-access permission field.
(see Scherrer, Para. [0037] – “The depicted categories include "Basic Information," "Financial Information," and "Medical Information," although a greater or lesser number of categories may be displayed. For each category of information, the user may specify whether they would like to provide read access, write access, or both read and write access to the third party that is associated with the user authentication device. Read access allows the third party to view stored personal information of the user. Write access allows the third party to add information to a user's stored personal information. The user may specify whether to provide the third party read and/or write access by selecting a read check box 360 or a write check box 370.” It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Auer, Woodlief and Elenchin to utilize the teachings of Scherrer since it would indicate which parties have permissions to modify the presented data.
Regarding claim 11, Auer, Woodlief and Elenchin do not explicitly disclose The one or more non-transitory media of Claim 1, wherein the one or more configuration fields are associated with a plurality of patient scope fields, wherein each patient scope field is associated with a resource of the EHR that is configurable via user selection to one or more of read-access enabled, read-access disabled, white-access enabled, or write-access disabled. (see Scherrer, Para. [0037]. The Examiner notes that the specification fails to define “patient scope field”. Further the language “a resource of the EHR that is configurable via user selection to one or more of read-access enabled, read-access disabled, white-access enabled, or write-access disabled” is merely a label for the resource and adds little, if anything, to the claimed acts or steps and thus does not serve to distinguish over the prior art. Any differences related merely to the meaning and information conveyed through labels (i.e., the configuration of a resource ) which does not explicitly alter or impact the steps of the method (i.e., the association of configuration fields with patient scope fields) does not patentably distinguish the claimed invention from the prior art in terms of patentability. Therefore, it would have been obvious to a person of ordinary skill in the art at the time of invention to have the category of information” (i.e., patient scope field of Auer, Elenchin, and Scherrer be associated with a resource of the EHR that is configurable via user selection to one or more of read-access enabled, read-access disabled, white-access enabled, or write-access disabled because the association of the patient scope field does not functionally alter or relate to the steps of the method and merely labeling the patient scope field differently from that of the prior art does not patentably distinguish the claimed invention. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Auer, Woodlief and Elenchin to utilize the teachings of Scherrer since it would indicate which parties have permissions to modify the presented data.)
Response to Arguments
Applicant's arguments regarding claims rejected under 35 U.S.C. 101 have been fully considered but they are not persuasive. Applicant argues with substance:
Applicant argues that the claims are not directed to “Certain Methods of Organizing Human Activity” due to not reciting a human. This is not persuasive. The recitation of a “human” in the claims is not necessary to find that the claims fall under “Certain Methods of Organizing Human Activity”. As explained in the body of the rejection above, but for the recitation of generic computer elements, the claims describe the management of personal behavior, which falls within the “Certain Methods of Organizing Human Activity” grouping. Also see MPEP 2106.04(a)(2).II.C
Applicant argues that the previous Office Action is missing a Step 2B analysis. The Examiner respectfully disagrees, as a proper Step 2B analysis was indeed performed as evidenced by the previous rejections and current rejection above. See at least “The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using a “non-transitory computer readable medium”, “processors”, “code” and “API calls” to perform the steps amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.”, from the 101 rejection above, as well as the 101 rejection of the preceding action. Also see MPEP 2106.05(f).
Applicant's arguments regarding claims rejected under 35 U.S.C. 103 have been fully considered but are not persuasive. Applicant has presented arguments regarding features that do not appear in the current claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
“Database Administrator’s Guide for Oracle Essbase” indicates that artifacts are files related to databases
“What Are Artifacts” indicates that artifacts are related to anomalies in MRI imaging.
“The History of Evolution of APIs” indicates that APIs have been in use for decades.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KYLE G ROBINSON whose telephone number is (571)272-9261. The examiner can normally be reached Monday - Thursday, 7:00 - 4:30 EST; Friday 7:00-11:00 EST.
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, Kambiz Abdi can be reached on 571-272-6702. 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.
/KYLE G ROBINSON/Examiner, Art Unit 3685
/KAMBIZ ABDI/Supervisory Patent Examiner, Art Unit 3685
Prosecution Insights