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 .
Notice to Applicant
2. This communication is in response to the communication filed 6/25/2026. Claims 1, 10 and 15 are currently amended. Claims 1-20 are currently pending.
Claim Rejections - 35 USC § 103
3. 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.
3.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 Starkey et al. (US 2002/0059327).
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 the user interface (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;
based on a user interface template associated with the computer server;
visual attributes;
template; and
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.
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:
based on a user interface template associated with the computer server;
template; and
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, 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:
based on a user interface template associated with the computer server; and
template.
Starkey, however, teaches based on a user interface template associated with the computer server and a template (Starkey: abstract; ¶¶ [0014] “The template manager selects one of the templates in the template store according to a template name and selection criteria from the application manager, the application manager producing a representation of a web page in response to the body of each selected template that the interface converts into a form that is compatible with the user's web browser”; FIGS. 1-3).
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 method and system for generating web pages from templates, as taught by Starkey, 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 web browser compatibility (Starkey: ¶¶ [0001]-[0014]).
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.
Starkey, 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 (Starkey: abstract; ¶¶ [0014] “The template manager selects one of the templates in the template store according to a template name and selection criteria from the application manager, the application manager producing a representation of a web page in response to the body of each selected template that the interface converts into a form that is compatible with the user's web browser”; FIGS. 1-3).
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 method and system for generating web pages from templates, as taught by Starkey, 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 web browser compatibility (Starkey: ¶¶ [0001]-[0014]).
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).
3.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 Starkey et al. (US 2002/0059327), and further in view of Green et al. (US 2019/0205012).
CLAIM 5
Schoenberg, Strongwater, Glaeske and Starkey 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 include the method and system for generating web pages from templates, as taught by Starkey, 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, Glaeske and Starkey 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 Starkey 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, Glaeske and Starkey 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 Starkey 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, Glaeske and Starkey 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 Starkey is the same as that of claim 5 above and is incorporated herein.
CLAIM 18
Schoenberg, Strongwater, Glaeske and Starkey 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 Starkey is the same as that of claim 5 above and is incorporated herein.
Response to Arguments
4. Applicant's arguments filed 6/25/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 6/25/2026.
4.1. Applicant argues, on pages 6-11 of the response, that the combination of references fails to teach or suggest “convert[ing] the first plurality of interface components to a second plurality of interface components…based on a user interface template…”; the motivation to combine is not supported.; and the proposed combination relies on impermissible hindsight.
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.
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
With regard to applicant’s other arguments, it is submitted that new prior art has been applied to the amended features of the claims. As such, applicant's remarks are addressed in the Office Action above and in previous office actions and incorporated herein; and 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.
Relevant Non-Cited Prior Art
5. The following discovered prior art was not cited in this rejection but may be relevant:
Su et al. (US 2007/0106935) – 2007/0106935 – Apparatus And Method For Implementing Flexible Page Layout – converting template compatible with user terminal
Soffer et al. (US 2016/0188183) – Declarative User Interface Representation Conversion Via Hierarchical Templates – User interface converted using templates
Conclusion
6. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights