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 .
Status of Claims
This action is in reply to the amendment filed on 05/13/26.
Claims 1-2 have been amended and are hereby entered.
Claims 3-6 have been added.
Claims 1-6 are currently pending and have been examined.
This action is made final.
Foreign Priority
Acknowledgment is made of Applicant's claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy of parent application no. JP2022130329, filed in Japan on 08/18/2022, was received on 11/19/24. Acknowledgement is made of this application’s status as a 371 national stage application of PCT/JP2023/029385, filed on 08/12/23. Accordingly, a priority date of 08/18/2022 has been given to the instant application.
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-6 are rejected under 35 U.S.C.101 because the claimed invention is directed to a judicial exception (an abstract idea) without significantly more.
Step 1
Claims 1-6 are drawn to a system, which is within the four statutory categories. Claims 1-6 are further directed to an abstract idea on the grounds set out in detail below.
Step 2A Prong 1
Claim 1 recites implementing the steps of:
generating a health record of a hospital by searching health record elements based on user input
selecting and combining the health record elements that are compatible with the hospital
setting an access authority to the health record elements for each occupation
(Examiner note: “elements” are interpreted as being “description items, sections, and document categories constituting a health record” per Applicant’s specification [0054] and as such have been included in the scope of the abstract idea), and
These steps amount to managing personal behavior or relationships or interactions
between people and therefore recite certain methods of organizing human activity. Generating health records by searching, selecting and combining health record elements (e.g., document sections and items) that are compatible with the hospital and setting access authorities to the health record elements based on occupation, are personal behaviors that may be performed by healthcare providers and/or administrators.
Claim 3 recites implementing the steps of:
generating a health record of the hospital by searching health record elements based on user input,
selecting and combining one or more of the support workflows, the health record elements that are compatible with the hospital and the selected one or more support workflows, and
setting an access authority to the health record elements for each occupation.
These steps amount to managing personal behavior or relationships or interactions
between people and therefore recite certain methods of organizing human activity. Generating health records based on selecting and combining health record elements (e.g., document sections and items) that are compatible with the hospital and support workflows, and setting access authorities to the health record elements based on occupation, are personal behaviors that may be performed by healthcare providers and/or administrators.
Claims 1 and 3 are therefore directed to an abstract idea.
Step 2A Prong 2
This judicial exception is not integrated into a practical application because the additional
elements within the claims only amount to:
A. Instructions to Implement the Judicial Exception. MPEP 2106.05(f)
The independent claims additionally recite:
a plurality of support modules, each specific to a respective occupation in medical and nursing care (Claim 1)
electronic health record / electronic health record elements as a means of implementing health records and health record elements (documentation sections, items, etc.) on a computer, e.g., in electronic format (Claims 1 and 3)
a hospital server of a hospital in communication with the electronic health record element database as implementing the steps of the abstract idea (Claims 1 and 3)
an electronic health record element database which includes a plurality of support modules, each support module is specific to a respective occupation in medical and nursing care, which further includes interoperable data that is useable by each one of the support modules (Claim 3)
The broad recitation of the above-mentioned general purpose computing elements at a high level of generality only amounts to mere instructions to implement the abstract idea using computing components as tools.
Regarding ”support modules”, per para. [0016], [0017] and [0020], this is understood to be software modularized for different occupations (e.g., nurse software vs. doctor software) used in an EHR workflow. No particulars of the modules are provided, and as such, it amounts to mere instructions to apply the abstract idea on a computer, e.g., using a computer to generate workflows specific to different occupations.
Regarding the “electronic health record”, recitation of an “electronic” system only amounts to applying a health record system using computers; Para. [0032] discloses “An electronic health record system according to the present invention includes a server device, a database, and a terminal”; where para. [0033] discloses “The server device is a known computer device, and includes an arithmetic device, a main storage device, an auxiliary storage device, an input device, an output device, and a communication device”; para. [0045] discloses “The database stores information handled by the electronic health record system”; and para. [0051] discloses “The terminals are a group of devices such as PCs, tablets, and smartphones”. All of these components (server device, database, and terminal) are understood to be general purpose computing elements functioning in their ordinary capacities to apply the abstract idea.
Regarding the hospital server of a hospital, this is understood to be a general purpose server per [0033], “The server device is a known computer device, and includes an arithmetic device, a main storage device, an auxiliary storage device, an input device, an output device, and a communication device” and subsequent paras. [0034]-[0042].
Regarding the “database”, no structure or particulars appear to be provided. Para. [0045] discloses “The database stores information handled by the electronic health record system” and para. [0054] discloses “database, which is also on the cloud, registers/manages elements, such as description items, sections, and document categories”. Para. [0062] discloses that document data can be managed “centrally in a relational database”. Therefore, the database is understood to amount to an electronic means of storing/managing data, and as such, it amounts to mere instructions to apply the abstract idea on a computer.
B. Insignificant Extra-Solution Activity. MPEP 2106.05(g)
Claims 1 and 3 additionally recite
an electronic health record element database that stores each of the support modules, the electronic health record element database is configured to record electronic health record elements that comprise respective definitions of the support modules, documents created by the support modules, data that is input into input areas of the documents, and description items used in the documents.
This element only amounts to insignificant extra-solution activity. As stated in MPEP 2106.05(g), "[t]he term "extra-solution activity" can be understood as activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim." In the present claim, the element of an electronic health record element database that stores each of the support modules… is only nominally or tangentially related to the process of generating health records specific to the needs of an occupation/hospital, and accordingly constitutes insignificant extra-solution activity.
These elements are therefore not sufficient to integrate the abstract idea into a practical application. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually.
The above claims, as a whole, are therefore directed to an abstract idea.
Step 2B
The present claims do not include additional elements that are sufficient to amount to
more than the abstract idea because the additional elements or combination of elements amount to no more than a recitation of:
A. Instructions to Implement the Judicial Exception. MPEP 2106.05(f)
As explained above, claim 1 and 3 only recite the aforementioned computing elements as tools for performing the steps of the abstract idea, and mere instructions to perform the abstract idea using a computer is not sufficient to amount to significantly more than the abstract idea. MPEP 2106.05(f).
B. Insignificant Extra-Solution Activity. MPEP 2106.05(g)
Likewise, as explained above, the element of an electronic health record element database that stores each of the support modules, the electronic health record element database is configured to record electronic health record elements that comprise respective definitions of the support modules, documents created by the support modules, data that is input into input areas of the documents, and description items used in the documents, only amounts to insignificant extra-solution activity.
C. Well-Understood, Routine and Conventional Activities. MPEP 2106.05(d)
In addition to amounting to insignificant extra-solution activity, the elements in Section B above constitute well-understood, routine and conventional activity. The element of an electronic health record element database that stores each of the support modules, the electronic health record element database is configured to record electronic health record elements that comprise respective definitions of the support modules, documents created by the support modules, data that is input into input areas of the documents, and description items used in the documents only amounts to storing/retrieving data in memory, which has been previously held to be well-understood, routine and conventional when claimed at a high level of generality or as insignificant extra-solution activity. See MPEP 2106.05(d)(II).
Thus, taken alone, the additional elements do not amount to significantly more than the
above-identified judicial exception. Looking at the limitations as an ordered combination adds
nothing that is not already present when looking at the elements taken individually. Their
collective functions merely provide conventional computer implementation.
Depending Claim
Dependent claims 2 and 4 recites “wherein the electronic health record system enables an electronic health record element corrected or newly created in a medica and nursing care facility to be registered in the electronic health record element database”, which comprises an additional element in the form of insignificant extra-solution activity. As explained above, Claim 1 and 3, from which Claim 2 and 4 respectively depend, are directed to an abstract idea in the form of generating a medical record for a medical or nursing facility based on a provider occupation and hospital. As stated in MPEP 2106.05(g), "[t]he term "extra-solution activity" can be understood as activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim." In the present claim, the function of “registering”, interpreted as “storing”, a corrected or newly created health record element in a database is only nominally or tangentially related to the process of generating a medical record based on a provider occupation and hospital, and accordingly constitutes insignificant extra-solution activity.
In addition to amounting to insignificant extra-solution activity, the above limitations also
constitutes well-understood, routine and conventional activity in the form of storing/retrieving information in memory. These types of activities have been recognized by the courts as well-understood, routine and conventional activity when claimed as insignificant extra-solution activity. See MPEP 2106.05(d).
Dependent Claims 5 and 6 recite wherein the electronic health record element database comprises a relational database, which only narrows the scope of the respective parent claims. The specification merely discloses (para. [0062]) that document data can be managed “centrally in a relational database”). No particulars of the database are provided. This element is understood to be a general purpose computing element functioning in its ordinary capacity. This is not sufficient to integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Dependent claims 2, 4-6, when analyzed as a whole, are held to be patent ineligible under 35 U.S.C. 101 because the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea without significantly more. The claims fail to remedy the deficiencies of the independent claims above, and is therefore rejected for at least the same rationale as applied to the parent claims above, and incorporated herein.
For the reasons stated, Claims 1-6 fail the Subject Matter Eligibility Test and are consequently 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 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.
Claim(s) 1-4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Higbie et. al. (US Publication 20120109686A1) in view of Reicher et. al. (US Publication 20170039350A1).
An electronic health record system ([0004], an electronic medical record system) comprising a plurality of [support software for occupation-based customizable templates] ([0099] teaches on the EMR system including a workstation (computer/tablet) and “method software package”; [0034] teaches on customizing templates for inputting patient information so that entirely new categories can be added; the EMR system permits the user to create new templates; [0034] teaches on a template builder which allows a provider to “add vitals pertinent to the practice”, e.g., number of toes or teeth; the example of customizing a template to add additional tests related to a “skin exam” – enabling a user to customize a template so that it can be tailored to include patient information “pertinent to the practice” – e.g., related to teeth, toes or skin is interpreted as creating documents for a respective occupations medical and nursing care; [0090]-[0097] teach on using the EHR system; step (d) with respect to creating a new customizable template, includes “setting template properties including providing a name for the template and linking the template with other templates”; [0098] teaches on once a template has been created, the information it contains can be searched along with the information in standard templates – also interpreted as the EHR system “referencing” documents created by the support modules, where [0063] teaches on patient data being able to be measured against data from physicians or “other users” of the system – interpreted as occupations associated with support modules (software) using the system),
an electronic health record element [storage] that stores [the customizable templates], the electronic health record [storage] is configured to record electronic health record elements that comprise respective definitions of the [customizable templates] (paras. [0222]-[0234] teach on a user accessing the Practice Manager, which gives access to “template editor”; the user can select “template/queries” and “open the desired template for editing, select which common items make up the template” (DD/EE at [0223]-[0224]); subordinate templates may be added (II at [0228]), the user can create a new template from among several categories such as welcome, problem review, family history, health screen, labs/orders, procedures, allergies, social history, etc. (KK at [0230]) – Examiner interprets all of the different sections/common items to read on EHR “elements”; if the user “opens a template for editing” and can add items/sections, it is interpreted as an EHR element “storage” as the system enables the user to retrieve existing templates for editing as well as create new templates from existing categories/sections); [0090]-[0097] teach on using the EHR system; step (d) with respect to creating a new customizable template, includes “setting template properties including providing a name for the template and linking the template with other templates; defining a template panel by providing a name for the template panel and a number of columns for the template; and defining fields or line items in the template and defining the type of data in the fields or items (EHR elements that comprise respective definitions”), documents created by the support modules ([0225] teaches on a user accessing the EMR system and selecting templates/queries on the left which enables the user to edit, delete, or create a template; the user can select a panel title to add an item to the panel or edit the panel of a currently opened template – interpreted as teaching that documents (templates) previously created by the support modules (software) have been recorded in the EHR database as they can be selected and subsequently used/modified/deleted), data that is input into input areas of the documents ([0034] teaches on a template builder, in which a practitioner can add vitals pertinent to the practice, e.g., height, weight temperature, pulse, number of toes/teeth; for example, for a skin exam, user can customize a template to add additional test common to the practice/market; for example, for a template on “social history” (social history is the “section being input”), user can select items to enter, e.g., exercise, work, living arrangement (data related to the section of social history); similarly [0226] teaches on editing/creating an available template including a drop down menu for available data types), and description items used in the documents ([0299]-[0300] teach on use of patient name to locate saved records; see Fig. 15A showing name “Abraham Lincoln” and birthdate shown at top of medical record; patient name and birthdate are interpreted to be “description items” per Applicant’s specification para. [0067]/Fig. 3).
Higbie does not explicitly disclose, but Reicher, which is directed to a system and method of providing dynamic and customizable medical examination forms, teaches:
a plurality of support modules, each support module is specific to a respective occupation in medical and nursing care ([0040] teaches on medical examination forms being predefined based on a series of rules that take into account attributes of the user, e.g., aspects of the form presented to a user may be dependent on the user’s role within the organization; a technologist may see specific portions of the exam form while a doctor may be presented with other portions of the form; an exam form may have multiple views based on a similar template, but each importing/displaying/exporting different data; e.g., physician view, nurse view, technologist view – all interpreted as “support modules” specific to a respective occupation in medical and nursing care; [0047] teaches on selecting a dynamic examination template based on specified criteria which may include attributes related to the user of the form including general attributes such as specialty or user role (synonymous with “occupation”); [0099]-[0100] further teach on a user interface for medical examination forms to be set up, created, copied, saved, modified and designed; tabs displayed and user interface may be dependent on the user’s role, e.g., a clerical employee may not have permission to use certain functionality/forms in the system whereas a medical doctor could have extensive permission and be able to view tabs not presented to other users – the functions are interpreted as being employed by support modules “by occupation” if they enable different user types to have different permissions, e.g., the clerical employee and the medical doctor).
an electronic health record element database that stores each of the support modules ([0033] teaches on a dynamic examination form template database which stores created examination form templates that have been created by the dynamic examination form software; per [0047], the templates are understood to be selectable based on criteria such as attributes of physician, e.g., specialty, and attributes related to the user for the form such as specialty or user role)
a hospital server of a hospital in communication with the electronic health record element database ([0033] teaches on a PACS database server being in communication with a dynamic examination form template database which may be present in a different server, for example a server accessible on the local LAN or via the internet; the template database stores examination form templates that have been created by the dynamic examination form software), the hospital server is configured to generate an electronic health record of the hospital by searching the electronic health record element database based on user input, and select and combine the electronic health record elements obtained from the electronic health record element database that are compatible with the hospital [0008] broadly teaches, “The method includes receiving a request from a user for an examination form, the request comprising data indicative of selection criteria. The method further includes identifying one or more medical examination forms from a collection of medical examination forms based at least in part on the data indicative of the selection criteria. One or more of the medical examination forms are selected from the identified examinations forms, and an instance of the selected form is generated for display to the user. The method further includes receiving a plurality of data inputs into the medical examination form and automatically exporting the plurality of the data inputs”; [0045] teaches on using a template creation module to generate an examination form; [0047] teaches on selection of form templates based on specific criteria including “facility at which the exam is conducted” – interpreted as indicating that the elements are “compatible” with the hospital for which the form is selected; the “specified criteria” are interpreted as the user input; [0048] teaches on once an appropriate template has been selected, a dynamic medical examination form may be generated based on the selected template; [0049] teaches on the exam form being created and then accessed and filled out by an appropriate user; once the examination form has been completed, the data may be exported to other systems for archiving or storage; [0055] further teaches on a user making a selection (input) indicating a desire to create a new form based on a template; the template selection module retrieving examination features related to the location (e.g., compatible with hospital) for which the template will be used), the hospital server is further configured to set an access authority to the electronic health record elements for each occupation ([0100] teaches on a user interface for creating a medical exam form; the interface displays tabs to the user for selection; the tabs displayed may be dependent on identity or role of the user, e.g., a clerical user may not have permission to see certain functionality and forms included in the system in which case those tabs are hidden from the clerical user; a medical doctor on the other hand may have extensive permissions and therefore may be shown additional tabs not presented to other users)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify Higbie with these teachings of Reicher, to implement the electronic health record element system as a database, with the motivation of storing templates in a way that they can be accessed remotely via the internet (Reicher [0033]) and to utilize software supporting creation of documents for each of a plurality of occupations in medical care, with the motivation of allowing multiple users having different roles in the clinical process to collaborate and contribute to a medical examination report (Reicher [0023]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to incorporate a hospital server to generate an EHR of the patient based on user input and by selecting/combining the EHR elements compatible with the hospital, with the motivation of generating a template that suits the need of the user (Reicher [0054]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify Higbie with Reicher to set an access authority to health record elements based on occupation, because different users and participants in the medical documentation process often play radically different roles in the information gathering and evaluation process (Reicher [0040]).
Regarding Claim 2, Higbie/Reicher teach the limitations of Claim 1. Higbie further discloses wherein the electronic health record system enables an electronic health record element corrected or newly created in a medical or nursing care facility to be registered in the electronic health record element database ([0222]-[0232] teaches on using the template editor to select common items to make up the template – different practices see patients with different issues so items can easily be added or removed from the list; selecting Templates/Queries enables the user to edit or create new templates; after a template has been edited or used as a basis for creating a new template, user selects “Save As” to save the new template – interpreted as “registering” a newly created or edited (“corrected”) document in the EHR element database of Higbie/Reicher).
Regarding Claim 3, Higbie/Reicher teach the limitations of Claim 1. Claim 3 recites limitations that are the same or substantially similar as Claim 1, and the discussion above with respect to Claim 1 is equally applicable to Claim 3. Examiner notes that Claim 3. Claim 3 recites the following additional limitation which is also taught by Reicher:
the electronic health record element database further includes interoperable data that is useable by each one of the support modules ([0107] teaches on plurality of data fields can be automatically imported to a medical form, such as patient name, examination type, patient birth date, date of examination; [0108] teaches on sections of examination form including additional drop-down menus or text fields).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify Higbie with these teachings of Reicher to include interoperable data that may be useable by each of the support modules with the motivation of serving different users of medical examination forms who must collaborate to collect relevant clinical data and compile the data (Reicher [0005]).
Regarding Claim 4, Higbie/Reicher teach the limitations of Claim 2. Claim 4 recites limitations that are the same or substantially similar as Claim 2, and the discussion above with respect to Claim 2 is equally applicable to Claim 4.
Claim(s) 5-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Higbie et. al. (US Publication 20120109686A1) in view of Reicher et. al. (US Publication 20170039350A1) as applied to Claims 1 and 3 above, respectively, and further in view of Brem (US Publication 20060116904A1).
Regarding Claim 5 and Claim 6, Higbie/Reicher teach the limitations of Claims 1 and 3, respectively but do not teach the following. Brem, which is directed to an electronic medical record system, teaches: wherein the electronic health record database comprises a relational database ([0051] teaches on using relational databases for EMR data).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify Higbie/Reicher with these teachings of Reicher to use a relational database for the EHR element database, with the motivation of ensuring integrity of the stored data (Brem [0051]).
Response to Applicant’s Remarks/Arguments
Please note: When referencing page numbers of Applicant’s response, references are to page numbers as printed.
35 USC 112(b) Rejections
The rejections of Claims 1 and 2 for being indefinite are withdrawn in view of Applicant’s amendments to the claims to clarify the claim language.
35 USC 101 Rejections
Applicant’s arguments have been fully considered but are not persuasive. At pages 6-7, Applicant traverses the rejection and summarizes features of amended Claim 1.
Applicant argues:
Applicant submits that the support modules being specific to a respective occupation in medical and nursing care, and their storage in an electronic health record element database along with the other recited data recite more than organizing human activity, and recites a practical application.
Regarding (A), the Examiner respectfully disagrees. The various support modules only amount to mere instructions to apply the abstract idea on a computer as discussed above in the main 101 analysis section, e.g., using a computer with occupation-specific documentation elements. Storage in an EHR element database only amounts to insignificant extra-solution activity in the form of storing/retrieving data in memory, which has been previously held to be well-understood, routine and conventional when claimed at a high level of generality or as insignificant extra-solution activity. See MPEP 2106.05(d)(II).
Regarding “practical application”: MPEP 2106.04(d)(1) states that a practical application may be present where the claimed invention improves the functioning of a computer. See also MPEP 2106.05(a)(I). The technological environment of Applicant’s claim is a general-purpose computer (see Spec. Para. [0030], “the server device is a known computer device”; [0046], “The terminal according to the present invention has a hardware configuration of a known computer similarly to the server device”; see also paras. [0034]-[0042], broadly teaching on system architecture). Applicant has not identified nor can the Examiner locate any physical improvement to the functioning of the computer that results from the implementation of Applicant’s claim. There is no indication that the computer is made to run faster, more efficiently, or utilize less power.
MPEP 2106.04(d)(1) further states that a practical application may be present where the claimed invention improves another technology. See also MPEP 2106.05(a)(II). Applicant’s claim is confined to a general-purpose computer (see Spec. Paras. [0030], [0034]-[0042], [0046] as discussed in preceding paragraph) and does not recite “another technology.” Because no other technology is recited in the claim, the claim cannot improve another technology (see, e.g., MPEP 2106.05(I)(A)(i) describing an example of an improvement to another technology where the abstract idea implemented on a computer improved the claimed additional element of a rubber molding machine). While Applicant’s claim recites additional elements to implement the steps of the abstract idea (e.g., a server), there is no indication that these additional elements operate in a manner different than they normally operate. Operating a device (e.g., the hospital server of Claims 1 and 3) in the manner it normally operates is insufficient to improve another technology.
Because there is no improvement to the functioning of the computer or to another technology, a practical application is not present.
These arguments are not persuasive.
In addition, the hospital server being configured to generate an electronic health record of the hospital by searching the electronic health record element database based on user input, and the hospital server being configured to set an access authority to the electronic health record elements for each occupation, are more than organizing human activity and recite a practical application.
Regarding (B), the Examiner respectfully disagrees. Regarding remarks to “recite a practical application”, please see remarks above in response to (A). MPEP 2106. 04(a)(2)(II) states that a claimed invention is directed to certain methods of organizing human activity if the identified claim elements contain limitations that encompass fundamental economic principles or practices, commercial or legal interactions, or managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). The Examiner submits that the identified claim elements represent a series of personal behaviors (or rules or instructions) that a person or persons, with or without the aid of a computer, would follow to generate a health record document specific to an occupation and hospital. As such, the claimed invention is directed to an abstract idea.
Regarding “generate an electronic healthcare record by searching the electronic health record element database based on user input”, this only amounts to mere instructions to apply the abstract idea on a computer, e.g., using a computer to create a record by searching for health record elements (sections, items, etc.) from a collection of elements. Regarding “set an access authority”, Examiner submits that this falls within the scope of the abstract idea, as a healthcare administrator could set access authorities for different health care record elements based on the user’s occupation, e.g., physician may have access to more or different health record elements (sections, items, descriptions) than a nurse.
These arguments are not persuasive.
Configuring an electronic health record by having a user select and combining the electronic health record element compatible with their own hospital based on user input, and by setting access authority for each document category for each occupation, is a practical application.
Regarding (C), the Examiner respectfully disagrees. Regarding remarks to “practical application”, please see remarks above in response to (A). Examiner submits that configuring, e.g., creating a health record based on a user’s selections and hospital compatibility falls within the scope of the abstract idea. As such, any purported improvements (e.g., a more customized health record to a specific facility/user) may be an improvement to the abstract idea itself. Regarding integration of a judicial exception into a practical application, please see 2106.04(d)(II) which states, “The analysis under Step 2A Prong Two is the same for all claims reciting a judicial exception, whether the exception is an abstract idea, a law of nature, or a natural phenomenon (including products of nature). Examiners evaluate integration into a practical application by: (1) identifying whether there are any additional elements recited in the claim beyond the judicial exception(s); and (2) evaluating those additional elements individually and in combination to determine whether they integrate the exception into a practical application, using one or more of the considerations introduced in subsection I supra, and discussed in more detail in MPEP §§ 2106.04(d)(1), 2106.04(d)(2), 2106.05(a) through (c) and 2106.05(e) through (h)”, and please see also, MPEP 2106.05(a) which states, “It is important to note, the judicial exception alone cannot provide the improvement. The improvement can be provided by one or more additional elements.” Applicant has not provided, nor can Examiner find evidence of, how any of the additional elements identified above in main 101 analysis section are providing an improvement over prior art systems. The additional elements identified above are understood to be computing components functioning in their normal operating capacity, which is not sufficient to integrate the judicial exception into a practical application.
As discussed above with respect to (B), setting access authority for each document based on occupation falls within the scope of the abstract idea and does not represent a technological improvement for the reasons discussed with respect to (B) and (C).
These arguments are not persuasive.
By combining the electronic health record element based on user input, it becomes possible for each hospital to configure its own unique electronic health record. Furthermore, by setting access authority for each document category according to occupation, each hospital is enabled to construct an electronic health record of its own hospital tailored to its specific needs.
Regarding (D), the Examiner respectfully disagrees. As discussed above in main 101 analysis section and here with respect to arguments (A), (B), and (C), an “electronic” health record only amounts to mere instructions to apply the abstract idea on a general purpose computer, e.g., implementing electronic health records in electronic format. Enabling a hospital to configure its own unique EHR may be an improvement to the abstract idea (e.g., an improved way of constructing health records that are tailored to specific needs of an occupation/hospital), however, an improvement to the abstract idea is not sufficient to integrate the judicial exception into a practical application per MPEP 2106.05(a) as discussed with respect to (C).
These arguments are not persuasive.
The rejections of Claims 1-2 under 35 USC 101 are maintained. New claims 3-6 are rejected under 35 USC 101.
35 USC 103 Rejections
Applicant’s remarks have been fully considered but are not persuasive. Examiner has provided new citations to relevant portions of Higbie and Reicher to address the broadest reasonable interpretations of the amended limitations; for example, Reicher teaches on PACS server (interpreted as a hospital server) in communication with the electronic health record database (at para. [0033]); paras. [0008], [0045]-[0048] and [0055] teach on the amended limitations pertaining to generating an EHR by searching the EHR element database based on user input and selecting/combining elements that are compatible with the hospital. Reicher further teaches on the server setting access authorities to EHR elements for different occupations (para. [0100]). New grounds of rejection have been necessitated by amendments to the claims.
The rejections of all claims under 35 USC 103 are maintained.
Conclusion
Examiner respectfully requests that Applicant provides citations to relevant paragraphs of specification for support for amendments in future correspondence.
The following relevant prior art not cited is made of record:
WO2018125280A1, teaching on role-based navigation interface systems and methods for medical workflows
US20210174915A1, teaching on a bi-directional documentation building system for medical documentation
US20170300634A1, teaching on systems and methods for managing electronic healthcare information including role-based customizable documents
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANNE-MARIE K ALDERSON whose telephone number is (571)272-3370. The examiner can normally be reached on Mon-Fri 9:00am-5:00pm EST, and generally schedules interviews in the timeframe of 2:00-5:00pm 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, Fonya Long, can be reached on 571-270-5096. 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.
/ANNE-MARIE K ALDERSON/Primary Examiner, Art Unit 3682
Prosecution Insights