DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 2/18/2026 has been entered.
Notice to Applicant
3. This communication is in response to the communication filed 2/18/2026. Claims 1, 10 and 15 are currently amended. Claims 1-20 are currently pending.
Claim Rejections - 35 USC § 103
4. 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.
4.1. Claims 1-4, 9-15, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Schoenberg (US 2012/0046969), in view of Strongwater (US 2015/0046190), and in view of Glaeske et al. (US 9772753), and in view of Huang et al. (US 2012/0323601).
CLAIM 1
Schoenberg teaches a system (Schoenberg: abstract) comprising:
a computer store containing data, defining a first plurality of interface components that correspond to the systems (Schoenberg: ¶¶ [0020] “Medical data records include a type of medical data that has been formatted to be presented to a user as a record”; FIGS. 1-5); and
a computer server configured to (Schoenberg: abstract; ¶¶ [0002]-[0004] “web server”; FIGS. 1-5):
receive a request based on one or more of the systems (Schoenberg: abstract; ¶¶ [0002]-[0004], [0020] “conversion module 117 to convert the medical data records from the medical data system format to the brokerage system format. When client device 132 sends to server 110 a request for exportation of the medical data records to client device 132, conversion module 117 converts the medical data records from the brokerage system format to the EMR format”; FIGS. 1-5);
retrieve the first plurality of interface components (Schoenberg: abstract; ¶¶ [0002]-[0004] “medical data records retrieved from an source external to the brokerage system and formatted in accordance with a first data format”, [0020]; FIGS. 1-5); and
convert the first plurality of interface components to a second plurality of interface components corresponding to the computer server, by at least transforming attributes of the first plurality of interface components to conform to a user interface associated with the computer server (Schoenberg: abstract; ¶¶ [0002]-[0004] “converting by the computer the medical data records retrieved from the source external to the brokerage system from the first data format to a second”, [0020]-[0022]; FIGS. 1-5).
Schoenberg does not appear to explicitly teach the following:
for each of a plurality of clinical systems, plurality of clinical systems;
visual attributes;
send the second plurality of interface components to a user device, wherein the second plurality of interface components are arranged based on a clinical role associated with the user device; and
template.
Strongwater, however, teaches the following:
visual attributes (Strongwater: abstract; ¶¶ [0049] The graphical user interface displays medical data (i.e., interface components) that can be configured with flagged and/or highlighted terms (i.e., visual attributes); FIGS. 1-13); and
for each of a plurality of clinical systems, plurality of clinical systems (Strongwater: abstract; ¶¶ [0002] “Medical information is provided in a plethora of formats and from many sources”, [0016]-[0017] “A plurality of data sources can be accessed for populating one or more databases of medical health information”, [0034], [0037]; FIGS. 1-13).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to include the medical data system and method with a plurality of clinical systems coupled thereto, as taught by Strongwater, with the system and method for converting medical data to a data format for exportation from a brokerage system, as taught by Schoenberg, with the motivation of facilitating the exchange of medical data (Strongwater: ¶¶ [0002]-[0004]).
Schoenberg and Strongwater do not appear to explicitly teach the following:
send the second plurality of interface components to a user device, wherein the second plurality of interface components are arranged based on a clinical role associated with the user device; and
template.
Glaeske, however, teaches the following:
send the second plurality of interface components to a user device, wherein the second plurality of interface components are arranged based on a clinical role associated with the user device (Glaeske: abstract; col. 1, lns. 45-54 “individual components can be selected and placed on the entity hub display based on the user’s role”, col. 4, lns. 4-15 “user 106 is provided with different information on a corresponding display 126, 128, or 130 based upon the particular role or roles that are assigned to user”; FIGS. 1-11; Claim 1).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to include the interface displaying different views of an entity based on a user’s role, as taught by Glaeske, with the medical data system and method with a plurality of clinical systems coupled thereto, as taught by Strongwater, with the system and method for converting medical data to a data format for exportation from a brokerage system, as taught by Schoenberg, with the motivation of visualizing data in a meaningful way for user’s with different roles (Glaeske: col. 1, lns. 5-54).
Schoenberg, Strongwater and Glaeske do not appear to explicitly teach the following:
template.
Huang, however, teaches a template (Huang: abstract; ¶¶ [0044] “the detail display interface engine 240 may be configured to initiate the display of the received detail patient data 206 based on initiating the display of the received detail patient data 206 by a browser client, based on a template format associated with the facility aggregation service”, [0085]; FIGS. 1-9).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to include the distributed sharing of electronic medical records using a conversion template, as taught by Huang, with the interface displaying different views of an entity based on a user’s role, as taught by Glaeske, with the medical data system and method with a plurality of clinical systems coupled thereto, as taught by Strongwater, with the system and method for converting medical data to a data format for exportation from a brokerage system, as taught by Schoenberg, with the motivation of facilitating the exchange of medical data (Huang: ¶¶ [0001]-[0005]).
CLAIM 2
Schoenberg, Strongwater and Glaeske do not appear to explicitly teach the system of claim 1, wherein the first plurality of interface components are converted to the second plurality of interface components based on a template of the computer server.
Huang, however, teaches wherein the first plurality of interface components are converted to the second plurality of interface components based on a template of the computer server (Huang: abstract; ¶¶ [0044] “the detail display interface engine 240 may be configured to initiate the display of the received detail patient data 206 based on initiating the display of the received detail patient data 206 by a browser client, based on a template format associated with the facility aggregation service”, [0085]; FIGS. 1-9).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to include the distributed sharing of electronic medical records using a conversion template, as taught by Huang, with the interface displaying different views of an entity based on a user’s role, as taught by Glaeske, with the medical data system and method with a plurality of clinical systems coupled thereto, as taught by Strongwater, with the system and method for converting medical data to a data format for exportation from a brokerage system, as taught by Schoenberg, with the motivation of facilitating the exchange of medical data (Huang: ¶¶ [0001]-[0005]).
CLAIM 3
Schoenberg does not appear to explicitly teach the system of claim 2, wherein the first plurality of interface components comprise an indicator, wherein the indicator is preserved in the conversion of the first plurality of interface components to the second plurality of interface components such that the indicator is present in the second plurality of interface components.
Strongwater, however, teaches wherein the first plurality of interface components comprise an indicator, wherein the indicator is preserved in the conversion of the first plurality of interface components to the second plurality of interface components such that the indicator is present in the second plurality of interface components (Strongwater: abstract; ¶¶ [0052]-[0056]; FIGS. 1-13; An indicator (e.g., graph, visualization, etc.) is merely non-functional descriptive language without any new and unobvious functional relationship and thus, the descriptive language is given no patentable weight.).
The motivation to include the teachings of Strongwater with the teachings of Schoenberg is the same as that of claim 1 above and is incorporated herein.
CLAIM 4
Schoenberg teaches the system of claim 1, wherein the first plurality of interface components are retrieved from each of the plurality of clinical systems in real-time (Schoenberg: abstract; ¶¶ [0002]-[0004], [0027] “Conversion module 117 exports medical data at various times, including, e.g., following receipt of a request, at scheduled times and/or time intervals, in real-time”; FIGS. 1-5).
CLAIM 9
Schoenberg does not appear to explicitly teach the system of claim 1, wherein the computer server is further configured to: receive patient data based on one of the second plurality of interface components, wherein the patient data is further based on one of the plurality of clinical systems; and cause the patient data to be stored in the one of the plurality of clinical systems.
Strongwater, however, teaches wherein the computer server is further configured to: receive patient data based on one of the second plurality of interface components, wherein the patient data is further based on one of the plurality of clinical systems; and cause the patient data to be stored in the one of the plurality of clinical systems (Strongwater: abstract; ¶¶ [0002], [0016]-[0017] “plurality of data sources can be accessed for populating one or more databases of medical health information”, [0034], [0037]; FIGS. 1-13).
The motivation to include the teachings of Strongwater with the teachings of Schoenberg is the same as that of claim 1 above and is incorporated herein.
CLAIM 10
Claim 10 repeats substantially the same limitations as those in claim 1. As such, claim 10 is rejected for substantially the same reasons given for claim 1 and are incorporated herein.
CLAIM 11
Claims 11 repeat substantially the same limitations as those in claims 2. As such, claims 11 are rejected for substantially the same reasons given for claims 2 and are incorporated herein.
CLAIM 12
Schoenberg does not appear to explicitly teach method of claim 11, wherein the template comprises one or more of a mathematical function, a condition, a logical function, a machine learning model, natural language processing, or image processing.
Strongwater, however, teaches wherein the template comprises one or more of a mathematical function, a condition, a logical function, a machine learning model, natural language processing, or image processing (Strongwater: abstract; ¶¶ [0027] “processing that occurs in step 302 can include converting from one format to another (e.g., image to text), and parsing a document for future comparison and/or analysis”; FIGS. 1-9).
The motivation to include the teachings of Strongwater with the teachings of Schoenberg, is the same as that of claim 1 above and is incorporated herein.
CLAIM 13
Schoenberg does not appear to explicitly teach method of claim 11, wherein the first plurality of interface components comprise an indicator, wherein the indicator is preserved in the conversion of the first plurality of interface components to the second plurality of interface components such that the indicator is present in the second plurality of interface components.
Strongwater, however, teaches wherein the first plurality of interface components comprise an indicator, wherein the indicator is preserved in the conversion of the first plurality of interface components to the second plurality of interface components such that the indicator is present in the second plurality of interface components (Strongwater: abstract; ¶¶ [0052]-[0056]; FIGS. 1-13; An indicator (e.g., graph, visualization, etc.) is merely non-functional descriptive language without any new and unobvious functional relationship and thus, the descriptive language is given no patentable weight.).
The motivation to include the teachings of Strongwater with the teachings of Schoenberg is the same as that of claim 1 above and is incorporated herein.
CLAIM 14
Schoenberg teaches method of claim 11, wherein the first plurality of interface components are retrieved from each of the plurality of clinical systems in real-time (Schoenberg: abstract; ¶¶ [0002]-[0004], [0027] “Conversion module 117 exports medical data at various times, including, e.g., following receipt of a request, at scheduled times and/or time intervals, in real-time”; FIGS. 1-5).
CLAIM 15
Schoenberg teaches a method (Schoenberg: abstract) comprising:
sending the second plurality of interface components for displaying the patient data in the clinical system (Schoenberg: abstract; ¶¶ [0002]-[0004], [0019]-[0022] “Conversion module 117 converts the medical data stored in database 118 from the brokerage system format to the EMR format, e.g., using techniques that are commonly known in the art. Conversion module 117 sends the medical data in accordance with the EMR format to client device”; FIGS. 1-5).
The remainder of Claim 15 repeats substantially the same limitations as those in claim 1. As such, the remainder of claim 15 is rejected for substantially the same reasons given for claim 1 and are incorporated herein.
CLAIM 19
Schoenberg teaches method of claim 15, further comprising: receiving, from a user device, a request for the second plurality of interface components (Schoenberg: abstract; ¶¶ [0002]-[0004], [0020] “When client device 132 sends to server 110 a request for exportation of the medical data records to client device 132, conversion module 117 converts the medical data records from the brokerage system format to the EMR format”; FIGS. 1-5).
CLAIM 20
Schoenberg teaches method of claim 15, wherein the first plurality of interface components are retrieved from each of the plurality of clinical systems in real-time (Schoenberg: abstract; ¶¶ [0002]-[0004], [0027] “Conversion module 117 exports medical data at various times, including, e.g., following receipt of a request, at scheduled times and/or time intervals, in real-time”; FIGS. 1-5).
4.2. Claims 5-8, 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Schoenberg (US 2012/0046969), in view of Strongwater (US 2015/0046190), in view of Glaeske et al. (US 9772753), in view of Huang et al. (US 2012/0323601), and further in view of Green et al. (US 2019/0205012).
CLAIM 5
Schoenberg, Strongwater, Glaeske and Huang do not appear to explicitly teach the system of claim 1, wherein the first plurality of interface components comprise patient data, wherein the patient data comprise structured data and unstructured data.
Green, however, teaches wherein the first plurality of interface components comprise patient data, wherein the patient data comprise structured data and unstructured data (Green: abstract; ¶¶ [002], [0022], [0036] “requests may be provided as structured or unstructured request messages, natural language questions, or any other suitable format for requesting an operation to be performed by the healthcare cognitive system”, [0047]-[0050] “structured and unstructured data are presented in one place at one time in the GUI”; FIGS. 1-7).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to include the graphical presentation of relevant information from electronic medical records including structured and unstructured data, as taught by Green, with the distributed sharing of electronic medical records using a conversion template, as taught by Huang, with the interface displaying different views of an entity based on a user’s role, as taught by Glaeske, with the medical data system and method with a plurality of clinical systems coupled thereto, as taught by Strongwater, with the system and method for converting medical data to a data format for exportation from a brokerage system, as taught by Schoenberg, with the motivation of facilitating the exchange of medical data (Green: ¶¶ [0001]-[0007]).
CLAIM 6
Schoenberg, Strongwater and Glaeske do not appear to explicitly teach the system of claim 5, wherein the unstructured data is based on an entry associated with the second plurality of interface components.
Green, however, teaches wherein the unstructured data is based on an entry associated with the second plurality of interface components (Green: abstract; ¶¶ [002], [0022], [0036], [0047]-[0050] “structured and unstructured data are presented in one place at one time in the GUI”; FIGS. 1-7).
The motivation to include the teachings of Green with the teachings of Schoenberg, Strongwater, Glaeske, and Huang is the same as that of claim 5 above and is incorporated herein.
CLAIM 7
Schoenberg does not appear to explicitly teach the system of claim 5, wherein the patient data comprise first data associated with a first clinical system of the plurality of clinical systems and second data associated with a second clinical system of the plurality of clinical systems.
Strongwater, however, teaches wherein the patient data comprise first data associated with a first clinical system of the plurality of clinical systems and second data associated with a second clinical system of the plurality of clinical systems (Strongwater: abstract; ¶¶ [0002], [0016]-[0017], [0034], [0037]; FIGS. 1-13).
The motivation to include the teachings of Strongwater with the teachings of Schoenberg is the same as that of claim 1 above and is incorporated herein.
CLAIM 8
Schoenberg, Strongwater and Glaeske do not appear to explicitly teach the system of claim 7, wherein the patient data is based on a questionnaire completed by a patient.
Green, however, teaches wherein the patient data is based on a questionnaire completed by a patient (Green: abstract; ¶¶ [0036]-[0037], [0076]; FIGS. 1-7).
The motivation to include the teachings of Green with the teachings of Schoenberg, Strongwater, Glaeske, and Huang is the same as that of claim 5 above and is incorporated herein.
CLAIM 16
Claim 16 repeats substantially the same limitations as those in claim 5. As such, claim 16 are rejected for substantially the same reasons given for claim 5 and are incorporated herein.
CLAIM 17
Schoenberg, Strongwater and Glaeske do not appear to explicitly teach method of claim 16, wherein the unstructured data is based on an entry associated with the second plurality of interface components.
Green, however, teaches wherein the unstructured data is based on an entry associated with the second plurality of interface components (Green: abstract; ¶¶ [002], [0022], [0036], [0047]-[0050]; FIGS. 1-7).
The motivation to include the teachings of Green with the teachings of Schoenberg, Strongwater, Glaeske, and Huang is the same as that of claim 5 above and is incorporated herein.
CLAIM 18
Schoenberg, Strongwater and Glaeske do not appear to explicitly teach method of claim 16, wherein the first plurality of interface components are converted to the second plurality of interface components using a machine learning model configured to determine the second plurality of interface components based on the unstructured data.
Green, however, teaches wherein the first plurality of interface components are converted to the second plurality of interface components using a machine learning model configured to determine the second plurality of interface components based on the unstructured data (Green: abstract; ¶¶ [0046], [0050, [0097]-[0100]; FIGS. 1-7]).
The motivation to include the teachings of Green with the teachings of Schoenberg, Strongwater, Glaeske, and Huang is the same as that of claim 5 above and is incorporated herein.
Response to Arguments
5. Applicant's arguments filed 2/18/2026 have been fully considered but they are not persuasive. Applicant’s arguments will be addressed hereinbelow in the order in which they appear in the response filed 2/18/2026.
5.1. Applicant argues, on pages 6-9 of the response, that the combination of references fails to teach or suggest “convent[ing] the first plurality of interface components to a second plurality of interface components…by at least transforming visual attributes of the first plurality of interface components to conform to a user interface template…” as recited in currently amended claim 1.
In response, it is noted that applicant’s application teaches “interface components may comprise borders, framing, infographics, summaries, analytics, indicia, personally identifiable information, and/or the like. The plurality of interface components may comprise patient data” (see, for example, applicant’s specification at ¶¶ [0030]-[0031]). It is also submitted that a “visual attribute”, under a broad and reasonable interpretation, is a property that defines the appearance, styling or state of a visual element such as color, shape, size, position, and the like. Here, the cited prior art references teach converting/formatting graphical user interface components for presentation on a graphical user interface (GUI) display. For example, Strongwater teaches formatting medical and patient data (i.e., interface component) for display via the GUI by highlighting and/or changing the color of medical data ()i.e., visual attribute) depending on the specific specialty, data source, and the like (See, for example, Strongwater: ¶¶ [0049]).
As such, it is respectfully submitted that the cited prior art teaches and/or suggests all the claim limitations under a broad and reasonable interpretation. Accordingly, the claims are rejected under 35 U.S.C. § 103.
5.2. Applicant argues, on pages 9-11 of the response, that the motivation to combine Schoenberg, Strongwater, and Glaeske is not supported; and these cited references are directed to fundamentally different problems and therefore, essentially nonanalogous art.
In response, examiner disagrees and respectfully reiterates that examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). According to MPEP § 2144, the motivation to combine references exists when a person of ordinary skill in the art would find a recognized advantage or "reason to combine" to solve a specific problem which can stem from prior art, common knowledge, or market forces, creating a predictable result. In this case, the motivation to combine the cited references is to facilitate the exchange of medical data by customizing graphical user interfaces for a particular user, as taught by Schoenberg, Strongwater, and Glaeske (See, for example, Strongwater: ¶¶ [0002]-[0008]). One of ordinary skill in the art would recognize that combining the teachings of the cited prior art references to create a medical/clinical system with a graphical user interface including customizable interface components would result in a cheaper, faster, more efficient, more effective and/or better system.
Furthermore, in response to applicant's argument that cited references are nonanalogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). Here, applicant’s pending application, teaches a clinical system that customizes a graphical user interface by configuring various interface components. Similarly, the cited prior art references are in the same field of the inventor’s endeavor, that is, medical systems that customize graphical user interfaces. For example, Schoenberg teaches converting medical data from one format to another that is viewable via a graphical user interface; Strongwater teaches converting medical records for display on a graphical user interface in accordance with a user profile; Glaeske teaches customizing a graphical user interface based on a user’s role and activities or tasks performed by a user in that role whereby different interface components are configured accordingly; and Huang teaches configuring an interface engine to manage patient data retrieval and presentation.
Moreover, it is noted that “[i]t is not necessary that the prior art suggest the combination to achieve the same advantage or result discovered by applicant. See, e.g., In re Kahn, 441 F.3d 977, 987, 78 USPQ2d 1329, 1336 (Fed. Cir. 2006) (motivation question arises in the context of the general problem confronting the inventor rather than the specific problem solved by the invention); Cross Med. Prods., Inc. v. Medtronic Sofamor Danek, Inc., 424 F.3d 1293, 1323, 76 USPQ2d 1662, 1685 (Fed. Cir. 2005) (“One of ordinary skill in the art need not see the identical problem addressed in a prior art reference to be motivated to apply its teachings.”); In re Lintner, 458 F.2d 1013, 173 USPQ 560 (CCPA 1972) (discussed below); In re Dillon, 919 F.2d 688, 16 USPQ2d 1897 (Fed. Cir. 1990), cert. denied, 500 U.S. 904 (1991).” See MPEP § 2144 IV.
Conclusion
6. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Michael Tomaszewski whose telephone number is (313)446-4863. The examiner can normally be reached M-F 5:30 am - 2:30 pm.
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, Peter H Choi can be reached at (469) 295-9171. 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.
/MICHAEL TOMASZEWSKI/Primary Examiner, Art Unit 3681