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 .
This communication is in response to the amendment received on 05/24/2026. Claims 1-15 and 20-24 remain pending in this application.
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-15 and 20-24 are 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.
The added material which is not supported by the original disclosure is as follows: The newly added recitation of “storing, in a plurality of network-based devices having health data, information in a standardized concept-code format relating to a patient condition of the patient, the standardized concept-code format comprising a code roll-up in an ontology;”, “wherein the updated information is provided by the user in a non-standardized format that is dependent on a hardware and software platform of a local device of the user; converting, by a concept service, the updated information from the non-standardized format into the standardized concept-code format to produce converted information; storing the converted information in the health data in the standardized concept-code format;”, “initiating workflow genesis based on the code being contained in the concept code, wherein initiating the workflow genesis is performed automatically by the one or more hardware processors without user intervention”, “automatically generating, by the concept service whenever the converted information has been stored, a notification containing the updated information, and transmitting the notification over the network via the set of patient and personnel APIs to destinations selected from a group comprising the patient portal and the care-team devices in real time, so that the patient and each member of the care team has immediate access to up-to-date patient information regardless of the hardware and software platform of the local device of the user” within claims 1, 8 and 15 appears to constitute new matter.
In particular, Applicant does not point to, nor was the Examiner able to find, any support for the features of “standardized concept-code format”, “converting, by a concept service, the updated information from the non-standardized format into the standardized concept-code format”, “initiating workflow genesis based on the code being contained in the concept code”, “automatically generating, by the concept service whenever the converted information has been stored, a notification containing the updated information, and transmitting the notification over the network via the set of patient and personnel APIs to destinations selected from a group comprising the patient portal and the care-team devices in real time” within the specification as originally filed. As such, Applicant is respectfully requested to clarify the above issues and to specifically point out support for the newly added limitations in the originally filed specification and claims.
Applicant is required to cancel the new matter in the reply to this Office action.
Claims 2-14 and 20-24 incorporate the deficiencies of independent claims 1, 8 and 15, through dependency, and are also rejected.
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-15, 20-24 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claims 1-7, 21-24 are drawn to a non-transitory media which is within the four statutory categories (i.e. manufacture). Claims 8-14 are drawn to a system which is within the four statutory categories (i.e. machine). Claims 15, 20 are drawn to a method which is within the four statutory categories (i.e. process).
Step 2A, Prong 1:
Claims 1-15 and 20-24 are provided below with markings separating abstract elements from the additional limitations, wherein the bolded style represents the additional limitations beyond abstract idea, and remaining limitations are directed to the abstract idea as discussed below.
“1. (Currently Amended) One or more non-transitory media having instructions that, when executed by one or more hardware processors, cause the one or more hardware processors to perform a plurality of operations, the operations comprising:
selecting, via at least one processor of the one or more hardware processors associated with one or both of a user device and an interface for a longitudinal plan system, a plan template from a plurality of plan templates associated with the longitudinal plan system, the plurality of plan templates searchable via the interface at the user device for a particular health concept that corresponds to a health concern, a social concern, a goal, and/or an activity associated with a patient, wherein a patient identifier corresponding to the patient is attached to or included in the plan template;
storing, in a plurality of network-based devices having health data, information in a standardized concept-code format relating to a patient condition of the patient, the standardized concept-code format comprising a code roll-up in an ontology;
providing, via a set of patient and personnel application programmable interfaces (APIs), remote access over a network to (a) the patient via a patient portal and (b) members of a care team via respective care-team devices, so that any user, of a set of users comprising the patient and the members of the care team, can generate updated information about the patient condition in the health data in real time through a graphical user interface, wherein the updated information is provided by the user in a non-standardized format that is dependent on a hardware and software platform of a local device of the user;
converting, by a concept service, the updated information from the non-standardized format into the standardized concept-code format to produce converted information;
storing the converted information in the health data in the standardized concept-code format;
determining, via the one or more hardware processors, that a code, in the converted information, corresponding to a problem documented in an electronic medical record (EMR) of the patient is contained in a concept code for a health concern identified by the particular health concept;
initiating workflow genesis based on the code being contained in the concept code, wherein initiating the workflow genesis is performed automatically by the one or more hardware processors without user intervention and comprises:
(a) generating a health concern data item, corresponding to the health concern, for the patient;
(b) writing information corresponding to the health concern in the EMR of the patient; and
(c) generating clinician workflow operations associated with the health concern; and
(d) embedding the clinician workflow operations associated with the health concern, in the EMR of the patient;
automatically generating, by the concept service whenever the converted information has been stored, a notification containing the updated information, and transmitting the notification over the network via the set of patient and personnel APIs to destinations selected from a group comprising the patient portal and the care-team devices in real time, so that the patient and each member of the care team has immediate access to up-to-date patient information regardless of the hardware and software platform of the local device of the user; and
initiating, via the one or more hardware processors and the set of patient and personnel APIs, a modification of one or several information elements, selected from a group comprising the updated information, the EMR of the patient, and the clinician workflow operations, based at least partially on data associated with the patient identifier.
2. (Previously Presented) The one or more non-transitory media of claim 1, wherein the modification is initiated by the at least one processor at the user device.
3. (Currently Amended) The one or more non-transitory media of claim 1, wherein the operations further comprise creating an electronic access, by a set of provider care- team devices, to enable modifying of the EMR of the patient by any one of the set of provider care-team devices.
4. (Previously Presented) The one or more non-transitory media of claim 3, wherein the set of provider care-team devices includes the user device.
5. (Currently Amended) The one or more non-transitory media of claim 3, wherein the additional electronic access further enables modifying of the clinician workflow of the clinician operations.
6. (Currently Amended) The one or more non-transitory media of claim 1, wherein the electronic access comprises a second electronic access, and wherein a first operations further comprise creating an electronic access is created to enable modifying by provider care-team devices of one or more information elements selected from the group comprising the updated information, the EMR of the patient, and the clinician workflow of the clinician operations.
7. (Currently Amended) The one or more non-transitory media of claim 6, wherein the first electronic access enables modifying, by the provider care-team devices and via at least one of the interface and a personnel API, of the one or more information elements.
Claims 8-14 repeat the similar limitations of claims 1-7 and therefore recite the same abstract idea and additional elements.
Claims 15, 20 repeat the similar limitations of claims 1, 7 and therefore recite the same abstract idea and additional elements.
21. (New) The one or more non-transitory media of claim 1, wherein the problem documented in the EMR of the patient corresponds to a particular health concern, of the patient, that is being actively treated or managed, and wherein the operations further comprise: determining that the code is contained in a second code; and in response to determining that the code is contained in the second code, creating the health concern data item and storing the health concern data item in the EMR of the patient.
22. (New) The one or more non-transitory media of claim 1, wherein the operations further comprise: determining that the code is contained in a particular code roll-up that comprises a plurality of concept codes that represent a particular health concern in a plurality of codings used by different medical records systems; and in response to determining that the code is contained in the particular code roll-up, generating a health concern data item.
23. (New) The one or more non-transitory media of claim 1, wherein the operations further comprise determining that the problem documented in the EMR of the patient corresponds to a health concept code of an ontology, and generating first and second electronic accesses, by a patient communication device via a patient API and by a set of care-team communication devices via a personnel API, to enable modifying by the patient communication device and by the set of care-team communication devices, respectively, of one or more information elements corresponding to the health concept code of the ontology.
24. (New) The one or more non-transitory media of claim 1, wherein the automatically generating and transmitting of the notification comprises propagating the updated information to the patient portal and to the care-team devices through the set of patient and personnel APIs in real time.
The limitations of “selecting, via at least one processor of a set of hardware processors associated with one or both of a user device and an interface for a longitudinal plan system, a plan template from a plurality of plan templates associated with the longitudinal plan system…”, “determining, via the set of hardware processors, that a code in the converted information, corresponding to a problem documented in an electronic medical record (EMR) of the patient is contained in a concept code for a health concern identified by the particular health concept” correspond to an abstract idea of “certain methods of organizing human activity” with a recitation of generic hardware processors. This is a method of managing interactions between people, such as user following rules and instructions. The mere nominal recitation of a generic processor and generic network devices does not take the claim out of the methods of organizing human interactions grouping. Thus, the claims recite an abstract idea.
The current specification recites “The system comprises: a processor; and a computer storage medium storing computer-usable instructions that, when used by the processor, cause the processor to: enable a clinician to select a plan template from a plurality of plan templates; attach the plan template to a patient identifier corresponding to the patient; integrate the plan template with a wellness plan of the patient; and enable the patient to update the wellness plan via a portal.” in [0028] and “The remote computers 108 might be personal computers, servers, routers, network PCs, peer devices, other common network nodes, or the like and might comprise some or all of the elements described above in relation to the control server 102. The devices can be personal digital assistants or other like devices.” in [0034]. Therefore, the processor recited in the claims is directed to a generic computing component.
Claims 2-7, 9-14 and 16-24 are ultimately dependent from claims 1, 8, 15 and include all the limitations of claims 1, 8, 15. Therefore, claims 2-7, 9-14 and 16-24 recite the same abstract idea. Claims 2-7, 9-14 and 16-24 describe a further limitation regarding the basis for determining a code corresponding to a problem is contained in the medical record of the patient. These are all just further describing the abstract idea recited in claims 1, 8, 15, without adding significantly more.
Step 2A, Prong 2:
This judicial exception is not integrated into a practical application. In particular, claims recite the additional elements that are shown in bolded style shown in the section above.
Thes additional elements are directed to are hardware and software elements, these limitations are not enough to qualify as “practical application” being recited in the claims along with the abstract idea since these elements are merely invoked as a tool to apply instructions of the abstract idea in a particular technological environment, and mere instructions to apply/implement/automate an abstract idea in a particular technological environment and merely limiting the use of an abstract idea to a particular field or technological environment do not provide practical application for an abstract idea (MPEP 2106.05(f) & (h)).
The processor in the claim steps is recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of determining a code corresponding to a problem, creating, writing and modifying data in the EMR) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Accordingly, these 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. The claims are directed to an abstract idea.
Step 2B:
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 element of using a processor to perform determining, creating, converting, accessing, embedding, modifying steps amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.
Claims have been amended to recite “converting, by the concept service”, the updated information from the non-standardized format into the standardized concept-code format to produce converted information” and “automatically generating, by the concept service whenever the converted information has been stored, a notification containing the updated information, and transmitting the notification over the network via the set of patient and personnel APIs to destinations selected from a group comprising the patient portal and the care-team devices in real time, so that the patient and each member of the care team has immediate access to up-to-date patient information regardless of the hardware and software platform of the local device of the user”.
These features have been found to be well-understood, routine and conventional activities in the field, as evidenced by Makaron et al. (hereinafter Makaron) (US 2026/0106034 A1). In particular, Makaron teaches “The data normalization module may transform clinical data from heterogeneous source formats into a unified presentation format. When clinical data is retrieved from an underlying electronic health record system, the data may be in a format specific to that system. The data normalization module may receive this source-specific data and may apply transformation rules to convert it to a standardized format. The standardized format may be designed to support consistent presentation across all data sources regardless of their native formats.” in [0524] and “The data normalization module 1930 may include a presentation layer interface. The presentation layer interface may transmit normalized data to presentation components for rendering. .. The presentation layer interface may support real-time streaming of normalized data as it becomes available.” in [641].
The well-understood, routine and conventional activities are not sufficient to amount to significantly more than the judicial exception.
The claims are not patent eligible.
Response to Arguments
Applicant's arguments filed 05/15/2026 have been fully considered but they are not persuasive. Applicant’s arguments will be addressed in the order in which they appear.
Applicant argues that claim 1 has been amended to recite elements aligning with elements of Example 42 of the USPTO SME Guidance, by integrating the judicial exception into a practical application, since claims recite a specific improvement over prior art systems by allowing remote users to share information in real time in a standardized format in which the information was input by the user.
In response, Examiner submits that there is no support for this feature in the current specification as indicated in the 35 USC 112(a) rejection above. Additionally, as indicated in the 35 USC 101 rejection above, the newly added features of “converting, by the concept service”, the updated information from the non-standardized format into the standardized concept-code format to produce converted information” and “automatically generating, by the concept service whenever the converted information has been stored, a notification containing the updated information, and transmitting the notification over the network via the set of patient and personnel APIs to destinations selected from a group comprising the patient portal and the care-team devices in real time, so that the patient and each member of the care team has immediate access to up-to-date patient information regardless of the hardware and software platform of the local device of the user” have found to be well-understood, routine and conventional activities as evidenced by Makaron (see the rejection above). Therefore, these elements and functions are not beyond the recognized in the art and they are directed to mere instructions to apply/implement/automate an abstract idea in a particular technological environment.
Applicant argues that claim 1 recite limitations that provides a technical improvement for converting data and transform the presentation of data so that heterogeneously codified information from different platforms can be reconciled and shared.
In response, Examiner submits that these claim features found to be well-understood, routine and conventional activities as evidenced by Makaron, as indicated in the rejection above. In particular, claims have been amended to recite automatically generating, by the concept service whenever the converted information has been stored, a notification containing the updated information, and transmitting the notification over the network via the set of patient and personnel APIs to destinations selected from a group comprising the patient portal and the care-team devices in real time, so that the patient and each member of the care team has immediate access to up-to-date patient information regardless of the hardware and software platform of the local device of the user” and Makaron teaches “The data normalization module may transform clinical data from heterogeneous source formats into a unified presentation format. When clinical data is retrieved from an underlying electronic health record system, the data may be in a format specific to that system. The data normalization module may receive this source-specific data and may apply transformation rules to convert it to a standardized format. The standardized format may be designed to support consistent presentation across all data sources regardless of their native formats.” in [0524] and “The data normalization module 1930 may include a presentation layer interface. The presentation layer interface may transmit normalized data to presentation components for rendering. .. The presentation layer interface may support real-time streaming of normalized data as it becomes available.” in [641]. The well-understood, routine and conventional activities are not sufficient to amount to significantly more than the judicial exception.
Therefore, the arguments are not persuasive and claims are rejected under 35 U.S.C. §101 as being directed to non-statutory subject matter.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DILEK B COBANOGLU whose telephone number is (571)272-8295. The examiner can normally be reached 8:30-5:00 ET.
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, Obeid Mamon can be reached at (571) 270-1813. 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.
/DILEK B COBANOGLU/Primary Examiner, Art Unit 3687
Prosecution Insights