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 Update
Claims 1-15 were pending at the time of the action.
" Claims 1, 4, 5, 9-11, 13, and 15 have been amended herein.
" Claims 3, 12, and 14 have been canceled without prejudice or disclaimer.
" New claims 16-22 have been added.
" Claims 1-2, 4-11, 13, and 15-22 are pending for examination upon entry of the current
amendments, with claims 1, 13, and 16 being independent claims.
Respond to Arguments
Applicant’s arguments, see pages 9-15, filed date 12/01/2025, with respect to Claims 1-2, 4-11, 13, and 15-22, have been fully considered and are not persuasive. The 35 U.S.C. § 101 rejection is maintained.
The Applicant argues that the Office Action wrongly characterizes the claims as a “fundamental commercial interaction” and a “workflow for managing data between two parties,” asserting that “organizing human activity” is limited to the specific categories in MPEP § 2106.04(a)(2)II. Instead, the Applicant contends the claims are directed to integrating medical algorithm devices into a networked service that allows providers to securely transmit and process patient healthcare data, which is unrelated to commerce and therefore not a judicial exception under Step 2A Prong One.
The Examiner respectfully disagrees and sustains the rejection because although the claims do not recite a commercial financial practice, they clearly recite a standard administrative workflow that merely organizes the interaction between a clinician, a records database, and a remote processing service. This sequence of requesting, routing, and returning healthcare data mirrors a fundamental human-performable coordination process rather than a technical improvement to the computer itself. Consequently, the 35 U.S.C. § 101 prong one is not overcome and is sustained. Refer to MPEP 2106.04(a)(2)(II) (Organizing Human Activity includes managing interactions between parties), Applicant Specification- US20240404694A1 [0089]-[0090] (describing the operational "two roundtrips" transaction), and Claim 1 ("transmitting... healthcare data... receiving... result") and prong one analysis below.
Applicant asserts that, even if Prong One is maintained, the claims integrate the alleged abstract idea into a practical application because the additional elements allegedly improve the functioning of a computer or improves another technology or technical field, and specifically improve the functioning of medical algorithm devices and improve the technology of network based healthcare provider systems. Applicant relies on amended claim 1 recitations including establishing first/second secure channels, transmitting patient identifiers and data field identifiers, receiving patient-specific values, transmitting an algorithm identification and healthcare data, applying the algorithm, and transmitting the result.
Examiner respectfully disagrees and sustains the rejection because claim 1’ “first secure channel” and “second secure channel” limitations merely add generic secure networking to the abstract data-exchange workflow. Claim 1 does not recite any particular security mechanism or technique that achieves those results and instead broadly covers any secure channel used to transmit/receive data and results. MPEP § 2106.04(d)(1) requires that, if an improvement is relied upon, the claim itself must reflect the disclosed improvement by including the steps/components that provide it, which is not satisfied here. Accordingly, the § 101 (Step 2A, Prong Two) is sustained.
The Applicant asserts that the claims recite additional elements that amount to an inventive concept when viewed as an ordered combination, comparing the claims to the nonconventional arrangement found in Bascom. Specifically, the Applicant argues that the ordered combination provides a "new and specific way of controlling implementing, operating, and controlling medical algorithm devices, using secure retrieval and transmission of patent-specific healthcare data... to medical algorithm devices operating on separate systems" which constitutes a nonconventional and non-generic arrangement of known pieces.
The Examiner respectfully disagrees and sustains the rejection because the ordered combination of generic computing components merely forms a generic multi-tier client-server architecture. Because separate secured connections to a database tier and an application tier across different network boundaries is a highly conventional, expected design pattern for distributed enterprise environments. Consequently, the 35 U.S.C. § 101 rejection is sustained. Refer to MPEP § 2106.05(f) (using standard secure protocols does not supply an inventive concept), Applicant's Specification US20240404694A1
[0095]–[0096 “ TLS server authentication commonly being implemented by making use of an X.509” ] (detailing the use of standard TLS), and U.S. Patent No. 6,606,708 (demonstrating that double-firewalled multi-tier architectures with separate secured connections to distinct backend services are a known design for web-based data management). Refer to the Subject matter rejection below for further details.
Applicant’s arguments, see pages 15-19, filed 12/01/2025, with respect to amended Claims 1-2, 4-11, 13, and 15-22 have been fully considered and are not persuasive. The rejection 35 U.S.C. § 103 is maintained.
The Applicant asserts that the combination of Purusothaman in view of Szeko does not teach or suggest the core inventive concept of Independent Claim 1, specifically the use of two distinct secure channels for separate functions: one from the host device to a database for data retrieval, and a second from the host device to an algorithm service for processing.
The Examiner respectfully disagrees because the Applicant's interpretation of the prior art is unnecessarily narrow. Under the Broadest Reasonable Interpretation (BRI) mandated by MPEP 2111, Purusothaman’s disclosure of a "secured link" to a secondary physician (Paragraph [0015]) satisfies the requirement for a "second secure channel," separate from the initial interaction with the SHDMS database (Paragraph [0007]). Furthermore, the "identification of an algorithm" is explicitly provided by Szeto, who teaches sending a "GUID or name" to a remote server (Szeto [0062]). Per MPEP 2143, the combination of these known elements provides the "predictable result" of a secured, selectable remote processing system.
The Applicant argues that Independent Claims 13 (system) and 16 (host device) are not obvious for the same reasons as Claim 1, as they incorporate the same features of two separate secure channels for data retrieval and processing request/data transmission.
The Examiner respectfully sustains the 35 U.S.C. § 103 rejection, asserting the Applicant's arguments are not persuasive because they just point to the prior art references individually and lack supporting evidence (MPEP § 2145). The combination of Purusothaman (which teaches a secure, dual-channel data exchange) and Szeto (which teaches algorithm identification) renders the claimed invention obvious. Refer to at least par. Purusothaman, par. 0007, 0013, 0015, 0052, 0055, 0057, 0059, 0064, Szeto, par. 0062, MPEP 2145, 2143
A person of ordinary skill would have predictably combined these known elements to create a secured, selectable remote processing system (KSR; MPEP § 2143(D)). The system and device claims (13 and 16) are also found obvious as they merely implement the same method in a conventional hardware format.
The Applicant asserts these dependent claims are nonobvious due to their dependency on the supposedly allowable independent claims and the inclusion of additional specific features like the two-step graphical user interface (GUI) request/execution process in Claim 17.
The Examiner respectfully sustains the 35 U.S.C. § 103 rejection for the dependent claims (2, 4-11, 15, and submit new rejection 17-22), first because the argument for their allowability based on dependency fails as the independent claims (1, 13, and submitted new rejection 16) remain rejected. See below 35 U.S.C. § 103 Purusothaman 0007, 0052, 0058-0061, 0065, 0067, 0070, 0073, 0090; Szeto 0062; MPEP §§ 2143, 2145(I), 2145(IV), 707.07(f).
Claim Rejections — 35 U.S.C. § 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–2, 4–11, 13, 15–22 are rejected under 35 U.S.C. § 101 because the claimed subject matter is directed to a judicial exception (an abstract idea) without reciting elements that integrate the exception into a practical application or provide an inventive concept amounting to significantly more than the exception itself.
Step 1: Statutory Categories
Process (Claims 1–2, 4–11): The language reciting “A computer-implemented method of transferring healthcare data… the method including: establishing… transmitting… receiving… applying… and transmitting” defines a series of acts. MPEP § 2106.03.
Machine (Claims 13, 15): Claim 13 recites “A system comprising: a host device… and an algorithm service… configured to.” This describes a concrete thing consisting of parts configured to perform a function. MPEP § 2106.03.
Machine (Claims 16–22): Claim 16 recites “A host device, comprising: one or more processors; a network interface; and a non-transitory memory storing machine-executable instructions.” This describes a physical apparatus with structural components. MPEP § 2106.03.
Having confirmed statutory subject matter, the analysis proceeds to Step 2A, Prong One.
Step 2A, Prong One: Judicial Exception Identification
Step 2A, Prong One evaluates whether the claims recite a judicial exception. Under MPEP § 2106.04, a claim recites a judicial exception when the claim limitations, under their broadest reasonable interpretation, cover subject matter falling within one of the enumerated groupings of abstract ideas.
The invention relates to securely transferring healthcare data between a host device and a remote algorithm service through separate secure communication channels, where the host device retrieves patient-specific data from a database and forwards it along with a selected algorithm identifier to the algorithm service for processing. See the Abstract, Specification paragraphs [0002], [0005]–[0006], and FIG. 1.
Independent Claim 1 Recitation
A computer-implemented method of transferring healthcare data between a host device and an algorithm service, the host device residing within a first computer-network and the algorithm service residing within a second computer-network different to the first computer-network, the method including:
establishing, between the host device and a database, a first secure channel of communication;
transmitting, from the host device to the database through the first secure channel, an identification of a patient and one or more data field identifiers;
receiving, from the database and via the first secure channel, a patient specific value associated with each of the one or more data field identifiers;
establishing, between the host device and the algorithm service, a second secure channel of communication;
transmitting, from the host device to the algorithm service via the second secure channel of communication:
an identification of an algorithm to be applied to healthcare data held by the host device, and the healthcare data to which the identified algorithm is to be applied, the healthcare data including the patient specific value associated with each of the one or more data field identifiers;
receiving, at the algorithm service, the identification of the algorithm and the healthcare data;
applying the identified algorithm to the healthcare data to arrive at a result;
and transmitting, from the algorithm service to the host device via the second secure channel of communication, the result of applying the identified algorithm to the healthcare data.
Note: Applicant language was retrieved from US20240404694A1, and bold represent abstract idea and non-bold additional elements.
Abstract Idea Classification
Under their Broadest Reasonable Interpretation (MPEP § 2111), the abstract idea steps recite a coordinated sequence of requesting patient data from one source, forwarding that data with a processing request to a second source, having the data processed, and receiving the result. This process aligns with the following abstract idea category:
Certain Methods of Organizing Human Activity (MPEP § 2106.04(a)(2)(II)):
The sub-grouping “managing personal behavior or relationships or interactions between people” includes social activities, teaching, and following rules or instructions. The abstract idea steps describe a clinician-directed workflow: a clinician directs data retrieval from a records source, selects a processing algorithm, forwards the data for analysis, and receives the result. This organizes the clinician’s interactions with two service providers, a records repository and a processing service, for the purpose of coordinating a medical decision-support transaction.
The specification supports this characterization: the full calculation of the algorithm values in the context of a healthcare provider treating a patient… consists of two roundtrips within this networked service environment (Spec. [0090]). This describes the organizational logic of a two-roundtrip service interaction, first gathering data, then sending it for processing, which is the human activity the claims manage.
The abstract nature of the workflow is confirmed by its human-performable equivalent: a clinician contacts a records department, requests specific patient data fields, receives the values, then contacts an analysis laboratory, specifies which analysis to perform on the gathered data, and receives the results. The data-coordination workflow, request, gather, forward, process, return is one that healthcare professionals have performed without computers. The computer accelerates the scale and speed of this workflow but does not alter its fundamental organizational character.
Dependent Claims Analysis — Prong One
Claim 2 recites transmitting GUI instructions that cause generation of a graphical user interface selected based on the identified algorithm. This describes how the processing results are presented to the clinician organizing how the interaction’s results are displayed. (MPEP § 2106.04(a)(2)(II).)
Claim 4 recites authentication and/or encryption for the first secure channel. These are additional elements (security implementation details) evaluated in Prong Two.
Claims 5–7 recite a confirmation and revision workflow: transmitting confirmatory instructions (Claim 5), generating a pre-populated GUI showing the data and algorithm to be applied (Claim 6), and receiving change requests and transmitting them (Claim 7). The confirmation and revision cycle presenting a summary for approval and allowing edits before execution, extends the abstract organizational workflow. (MPEP § 2106.04(a)(2)(II).)
Claim 8 recites transforming the result or data before transmission. The specification describes this as conversion from one numerical format to another (Spec. [0026]). This numerical conversion falls within the “mathematical concepts” grouping (MPEP § 2106.04(a)(2)(I)) as a mathematical calculation, and also extends the abstract organizational workflow as a data-formatting step. The groupings are not mutually exclusive per MPEP § 2106.04(a)(2).
Claim 9 recites that the algorithm service includes an API and the host device includes an edge module in secure communication. The API and edge module labels are additional elements (architectural component naming) evaluated in Prong Two.
Claims 10–11 recite authentication (Claim 10) and encryption (Claim 11) for the second secure channel. These are additional elements evaluated in Prong Two.
Claim 15 recites the same authentication/encryption details as Claim 4, applied to the system of Claim 13. These are additional elements evaluated in Prong Two.
Claim 17 recites a two-step interaction: transmitting a pre-population request, receiving GUI instructions with algorithm input values, transmitting a second execution request, and receiving the result. This describes a preview-then-execute confirmation workflow extending the abstract organizational process. (MPEP § 2106.04(a)(2)(II).)
Claim 18 recites receiving a list of algorithms supported by the algorithm service. Receiving a service catalog is a data-gathering step within the organizational workflow.
Claim 19 recites transmitting an execution request in a separate transmission from the algorithm identification and healthcare data. This describes a procedural separation of approval from data submission within the transaction workflow.
Claims 20–21 recite receiving pre-populated GUI instructions (Claim 20) and a change-request/update cycle (Claim 21). These describe an iterative review-and-revise workflow extending the abstract organizational process.
Claim 22 recites the algorithm service storing patient-specific values and modifying them based on change requests. The modification-based-on-instructions extends the abstract organizational workflow. The storage function is an additional element evaluated in Prong Two.
Because all claims recite the abstract idea of organizing a data-processing transaction workflow, the analysis proceeds to Step 2A, Prong Two.
Step 2A, Prong Two: Integration into a Practical Application
Step 2A, Prong Two evaluates whether any additional element, or combination of additional elements, integrates the recited judicial exception into a practical application (MPEP § 2106.04(d)).
Independent Claims 1, 13, and 16 — Additional Elements
Host Device, Algorithm Service, and Database
The specification describes the host device as a computer, smartphone, tablet, or other personal computing device (Spec. [0017]) and the algorithm service as a computer, server, collection of computers, collection of servers, cloud computing environment, and/or virtualised machine (Spec. [0017]). The database resides within an IT service containing patient records (Spec. [0081]). These identify computing hardware performing generic functions—storing data, processing instructions, and communicating over a network. Under MPEP § 2106.05(f), reciting generic computing components that merely serve as tools to perform the abstract idea amounts to mere instructions to apply the exception. No claim limitation identifies a specific, non-generic hardware configuration that effects a technical improvement.
First and Second Computer-Networks
The specification explains the networks may each include, or be separated by, one or more firewalls and may have different security configurations (Spec. [0016]). Placing the host device and algorithm service in different networks describes a general computing environment in which parties operate across network boundaries. Under MPEP § 2106.05(h), specifying that the parties are in different networks links the abstract idea to a particular technological environment, a multi-network infrastructure, without imposing a meaningful limitation on the abstract idea itself.
First and Second Secure Channels of Communication
The specification describes the secure channels as using transport layer security protocol (TLS) version 1.3 (or version 1.2) (Spec. [0095]) and defines a secure channel as one providing both confidentiality as well as authenticity (Spec. [0092]). TLS is a standard, widely-deployed cryptographic protocol for securing network communications. The claims do not recite any modification to, or improvement of, TLS or any other protocol—they use TLS for its general purpose of securing communications between endpoints. Refer to 0098-0101
The dual-channel configuration determines which parties are connected by which TLS channel, this organizes the abstract workflow’s security topology but does not improve the channel security technology itself.
Under MPEP § 2106.05(f), applying generic security protocols to the data exchange amounts to instructions to implement the abstract idea in a secure computing environment.
Processors, Network Interface, and Non-Transitory Memory (Claim 16)
Claim 16 recites “one or more processors,” “a network interface,” and “a non-transitory memory storing machine-executable instructions.” The specification describes these as generic computing components: a central processing unit (CPU), input means, output means and data storage (Spec. [0106]) and non-transitory medium or media which can be read and accessed directly by a computer including RAM, ROM and flash memory (Spec. [0108]).
Claim 16’s stored instructions orchestrate operations across both the host device and the algorithm service via dual secure channels—including receiving operations at the algorithm service and transmitting results from the algorithm service back to the host device. The stored instructions direct the host device to perform standard network communication functions (send requests, receive responses) and instruct the algorithm service to perform standard data processing functions (receive data, execute algorithm, return result). The cross-device scope describes the extent of the abstract workflow’s execution environment, not a specific technical mechanism that improves how the processors, memory, or network interface operate. Under MPEP § 2106.05(f), this amounts to mere instructions to apply the exception on a computer.
Ordered Combination Analysis
When viewed as a whole, the combination of these elements—a host device in one network communicating with a database via a first secured channel and with an algorithm service in a different network via a second secured channel, forms a multi-tier client-server architecture. The specification confirms this arrangement: the edge module interacts with the API residing in the algorithm service environment for the purpose of requesting the execution of the algorithm device, and to retrieve the algorithm result values (Spec. [0089]). Multi-tier architectures in which a client establishes separate TLS-secured connections to distinct backend services (database tier and processing tier) across network boundaries are a generic design pattern for distributed service environments. This combination does not interact in an unconventional way that would amount to a practical application. The combination provides a generic computing environment for executing the abstract workflow.
Dependent Claims Analysis — Prong Two
Claim 2 adds GUI instructions for generating a graphical user interface. The specification describes these as a HTML document for rendering by a browser (Spec. [0022]). Transmitting display instructions is insignificant extra-solution activity that presents the results of the abstract workflow (MPEP § 2106.05(g)).
Claims 4 and 15 add authentication and encryption details for the secure channel to the database. These specify generic TLS security parameters (X.509 certificates as part of the TLS handshake, Spec. [0096]) without reciting any improvement to the protocol itself. This further defines the technological environment (MPEP § 2106.05(h)).
Claims 6–7 confirmatory GUI instructions with a pre-populated interface (Claim 6), and change request handling (Claim 7). Pre-populated web forms and editable input fields are standard web interface features. Under MPEP § 2106.05(g), these are insignificant extra-solution activities.
Claim 9 names the additional components “an API” and “an edge module” in secure communication (Spec. [0081]). Naming generic architectural components performing their basic functions merely further defines the technological environment (MPEP § 2106.05(h)).
Claims 10–11 add authentication (Claim 10) and encryption (Claim 11) for the second secure channel. Same analysis as Claims 4 and 15—generic security parameters that define the technological environment (MPEP § 2106.05(h)).
Claims 5, 8, 17, 18, and 19 narrow or extend the abstract organizational workflow without introducing additional elements beyond those already evaluated. These claims remain directed to the abstract idea for the same reasons as the independent claims.
Claims 20–21 add receiving pre-populated GUI instructions (Claim 20) and a change-request/update cycle (Claim 21). Standard web form interactions—insignificant extra-solution activities (MPEP § 2106.05(g)).
Claim 22 adds that the algorithm service stores and modifies patient values based on change requests. Storing data and modifying it upon instruction describes basic data management functions of a generic server. This amounts to mere instructions to apply the exception (MPEP § 2106.05(f)).
No additional element, individually or in combination, integrates the abstract idea into a practical application. The claims are directed to the abstract idea, and the analysis proceeds to Step 2B.
Step 2B: Inventive Concept Analysis
Step 2B evaluates whether the additional elements, viewed individually and as an ordered combination, provide an inventive concept that transforms the claim into a patent-eligible application (MPEP § 2106.05).
Independent Claims 1, 13, and 16 Additional Elements
Host Device, Algorithm Service, and Database
The specification defines these as generic hardware (Spec. [0017]). Each component performs its basic, expected function: the host device stores and transmits data, the database stores and retrieves records, the algorithm service processes data per instructions. The use of general-purpose computers to perform data retrieval and processing to carry out abstract processes does not supply an inventive concept.
First and Second Computer-Networks
Firewall-separated multi-network architectures are a fundamental feature of enterprise and healthcare IT environments. The specification describes this as a generic computing environment (Spec. [0016]). Under MPEP § 2106.05(h), specifying different networks merely links the abstract idea to a particular technological environment without adding an inventive concept.
First and Second Secure Channels of Communication
The specification describes the secure channels as implemented using standard TLS (Spec. [0095]–[0096 “ TLS server authentication commonly being implemented by making use of an X.509 server certificate”]). The use of TLS to secure client-server communications is a generic technology. See also U.S. Patent No. 6,606,708 (2003) , fig. 1, describing double-firewalled multi-tier architectures with separate secured connections to distinct backend services as a known design for web-based data management, “US7805377B2, fig. 1-> “firewall 2 and firewall 20”, abstract->“ access to a medical record of a patient hosted by at least one medical record repository, comprising a plurality of sub-records, each sub-record having an associated different patient-controlled access control criteria”, US8868768B2, fig. 7; describes a process where medical data requests are managed via an Access Device (AD) and a Health Information Provider (HIP), two different secure channels ,Col. 1 ll. 60 to Col. 2. Ll. 20 “accessing secure medical data using a HIP server… requesting access… first device… secure medical data… second ..device… transmitted to a HIP server…based on the request… “, Col. 24, col. 60-67 “communication...travel…internet…authenticated “ Col. 25, ll 50 – Col. 26, ll. 29 . The claims do not recite any modification, improvement, or unconventional application of TLS. Under MPEP § 2106.05(f), using standard secure protocols does not supply an inventive concept.
Processors, Network Interface, and Non-Transitory Memory (Claim 16)
The specification describes these as a generic central processing unit (CPU), input means, output means and data storage (Spec. [0106]) and lists memory types as RAM, ROM and flash memory (Spec. [0108]). Under MPEP § 2106.05(f), reciting generic hardware to execute stored instructions does not supply an inventive concept.
Ordered Combination Analysis
As a whole, the combination of a host device communicating with a database over a first TLS-secured channel and with an algorithm service over a second TLS-secured channel, across different networks, forms a standard multi-tier client-server architecture. Multi-tier architectures with separate secured connections to database and application tiers are generic practice in enterprise healthcare IT environments.
Dependent Claims Analysis — Step 2B
Claims narrowing the abstract idea without new additional elements: Claims 5, 8, 17, 18, and 19 narrow or extend the abstract organizational workflow without introducing additional elements beyond those already evaluated. These claims remain directed to the abstract idea for the same reasons as the independent claims, and the Step 2B analysis of the independent claim additional elements applies. They do not independently satisfy Step 2B.
The remaining dependent claims introduce additional elements evaluated below:
Claim 2 (GUI Instructions): HTML rendering in a browser is a standard computing function. Transmitting display instructions is insignificant extra-solution activity (MPEP § 2106.05(g)).
Claims 4 and 15 (Authentication/Encryption): TLS certificate-based authentication using an X.509 server certificate as part of the initial TLS handshake protocol (Spec. [0096]) is a generic security measure. See (MPEP § 2106.05(h)).
Claims 6–7 (Confirmatory GUI and Change Requests): Pre-populated web forms with editable fields (Spec. [0024]) are generic web interface features. Insignificant extra-solution activities (MPEP § 2106.05(g)).
Claim 9 (API and Edge Module): Generic client-server component naming performing basic functions (Spec. [0081]). Does not supply an inventive concept (MPEP § 2106.05(h)).
Claims 10–11 (Authentication/Encryption for Algorithm Service Channel): Same analysis as Claims 4 and 15 (MPEP § 2106.05(h)).
Claims 20–21 (Pre-populated GUI and Change Cycle): Same analysis as Claims 6–7 (MPEP § 2106.05(g)).
Claim 22 (Server-Side Storage and Modification): Storing data and modifying it per instruction is a basic database function. This amounts to mere instructions to apply the exception (MPEP § 2106.05(f)).
As a whole, the combination of dependent claim limitations adds standard web interface features, standard security protocol parameters, standard architectural component labels, and generic data management functions to the multi-tier system.
None of these, individually or in combination, introduces a non-conventional interplay or transforms the abstract idea into an inventive application.
The additional elements, whether viewed individually or as an ordered combination, do not supply an inventive concept that transforms the claims into a patent-eligible application. They offer no transformation beyond the implementation of the abstract data-exchange workflow on generic computing hardware using standard protocols.
Therefore, Claims 1–2, 4–11, 13, 15–22 are rejected under 35 U.S.C. § 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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) Claims 1-2, 4-11, 13, and 15-22 are rejected under 35 U.S.C. 103 as being unpatentable over US-20190057775- Purusothaman, and further in view of Szeto (US 2018/0018590 A1).
Claim 1.
Purusothaman teaches, A computer-implemented method of transferring healthcare data between a host device and an algorithm service, the host device residing within a first computer-network and the algorithm service residing within a second computer-network different to the first computer-network, the method including: (Purusothaman, [0004-0007], [0012-0013], [0040-0041])
Purusothaman describes a computer implemented method for transferring an EMR. This communication occurs between a primary physician using an infirmary management system (the host device on a first network) and a centralized healthcare management system 102 that connects secondary physicians for diagnosis (the algorithm service). The system is designed for distributed Health Systems where physicians practice at different healthcare institutions.
establishing, between the host device and a database, a first secure channel of communication;
(Purusothaman, See at least, a secure healthcare data management server SHDMS for secure communication of healthcare data related to a patient paragraph 0007, and The server includes a memory unit and a processor. The memory unit stores a database paragraph 0007, and verifying the one or more secondary physicians by communicating the patient data as a secured link paragraph 0015, and enabling one or more secondary physicians to access EMR through SHDMS when the secure link is accessed paragraph 0009, combination of both physician paragraph 0059 )
Purusothaman describes the structural components of a requesting device and a storage server along with the functional step of using a protected link to bridge them for data access. This interaction constitutes the creation of a protected communication path between the specified endpoints.
transmitting, from the host device to the database through the first secure channel, an identification of a patient and one or more data field identifiers;
( Purusothaman, See at least, The primary physicians may select a patient from the patient list 602 paragraph 0064, and The patient data selection module 406 selects at least one data from the list of the data to view the data of the at least one the data paragraph 0057, and The data may be stored along with a patient unique ID paragraph 0052, and may access the data by using an identification key unique to each patient paragraph 0055)
Purusothaman discloses the patient identification as a patient unique ID and an identification key unique to each patient, and discloses the data field identifiers as selecting at least one data from a list to view. Under broad reasonable reading, selecting a patient and selecting at least one data to view requires transmitting the patient identifier plus the selected data items to the database that stores data along the patient unique ID, so the database can return the corresponding patient data items.
receiving, from the database and via the first secure channel, a patient specific value associated with each of the one or more data field identifiers;
( Purusothaman, See at least, to view the data of the at least one the data paragraph 0057, and The data may be a patient related data paragraph 0042, and The patient data processing module 310 may include a separate memory allocation for the data of the one or more patients with the single source data including the unit and the data value paragraph 0052, The patient data link accessing module 412 enables access the link by requesting to the primary physician paragraph 0058)
Purusothaman enables a physician to obtain and view specific data values and units that are retrieved from the server memory. This retrieval provides the specific content requested via the protected communication link.
establishing, between the host device and the algorithm service, a second secure channel of communication; (Purusothaman, [0007-0009], [0013-0015], [0043], [0052-0055], [0057], [0059-0060], [0090])
Purusothaman discloses a separate communication pathway between the primary physician's device (host device) and the secondary physician diagnostic services (algorithm service), distinct from the host device's connection to the SHDMS database (the first secure channel). When transferring patient data for specialist consultation, the system generates a unique link that is a combination of both physician ids. This link is protected by verifying the one or more secondary physicians by communicating the patient data as a secured link before the primary physician can initiate a communication with the tagged one or more secondary physicians for diagnosis. This verified, physician-specific link constitutes a second secure channel of communication between the host device and the algorithm service.
These two channels are architecturally distinct: the first secure channel connects the physician's device directly to the SHDMS database for patient data retrieval, while the second secure channel connects the physician's device to the diagnostic service via a separately generated, physician-ID-based link.
transmitting, from the host device to the algorithm service via the second secure channel of communication:
an identification of an algorithm to be applied to healthcare data held by the host device; (Purusothaman, [0007], [0013], [0015], [0052-0055], [0057],[0059-0060], [0090])
Purusothaman identifies the transfer of patient information from a primary user to a secondary service via a verified digital link. This delivery of data across the protected pathway completes the communication requirement between the two entities.
and the healthcare data to which the identified algorithm is to be applied the healthcare data including the patient specific value associated with each of the one or more data field identifiers; (Purusothaman, [0007], [0052], [0060])
Purusothaman explicitly states that the data transmitted for analysis is the patient's electronic medical record (EMR). The system's patient data tagging module 414 tags the first set of data with the selected specialist, confirming that this specific EMR is the healthcare data to which the diagnostic algorithm is to be applied.
receiving, at the algorithm service, the identification of the algorithm and the healthcare data; (Purusothaman, [0013], [0015], [0058])
The workflow in Purusothaman requires the secondary physician (algorithm service) to click on the link and subsequently access the patient data sent by the primary physician. This access is granted for the purpose of a diagnosis based on the physician's field of expertise. This act of receiving and acting upon the shared link constitutes receiving both the healthcare data and the identification of the algorithm.
applying the identified algorithm to the healthcare data to arrive at a result; (Purusothaman, claim 1 [0007], [0062])
Purusothaman explicitly describes the secondary physician's role is to perform a Diagnosis, which involves identifying, by at least one tagged secondary physician, a disease or ailment of the first patient based on the EMR from the primary physician. This is a direct description of applying a diagnostic algorithm to the healthcare data to produce a result (the identified disease).
and transmitting, from the algorithm service to the host device via the second secure channel of communication, the result of applying the identified algorithm to the healthcare data. (Purusothaman, [0007], [0013], [0062], [0077], [0090])
Purusothaman identifies the generation of a diagnostic outcome by a secondary service and the subsequent delivery of that information back to the primary user device. This bidirectional flow through the secure communication system ensures the requester receives the processed results.
Obviousness Rationale:
Purusothaman teaches explained limitation above, however, Purusothaman does not teach transmitting an identification of an algorithm to be applied.
Szeto discloses the missing element by teaching a system for distributed machine learning where a host device transmits specific model instructions to a remote server to define the analysis to be performed. These instructions explicitly detail "which machine learning algorithm 295 is to be used" and can provide "a specific reference to the desired... algorithm, possibly by an identifier (e.g., number, name, GUID, etc.) and version number" (para. [0062]). This teaching of sending specific model instructions containing an identifier to select a desired algorithm is functionally and semantically equivalent to the claimed limitation of transmitting an identification of an algorithm to be applied.
A POSITA tasked with improving Purusothaman's system to support a catalog of distinct algorithms would naturally seek a solution for programmatically requesting a specific analysis. Szeto provides this exact solution in the analogous field of distributed machine learning (Title) to overcome challenges in accessing and utilizing sensitive, distributed data, teaching a system where a local device sends model instructions containing an identifier (para. [0062]) to tell the remote server precisely which algorithm to run.
Claim 2.
Purusothaman in combination with Szeto teaches, The computer-implemented method of claim 1, wherein the method further includes transmitting, from the algorithm service to the host device, GUI instructions which, when executed by the host device, cause the generation of a graphical user interface, the GUI instructions selected by the algorithm service based on the algorithm identified by the host device. (Purusothaman, [0024], [0026], [0065], [0073])
Purusothaman describes its system providing numerous user interfaces to the primary physician (host device) to facilitate the secure data exchange and consultation process. The centralized server (algorithm service) generates and transmits the data for these interfaces, such as the user interface view of a tag physicians and the subsequent EHR/EMR view. The content of these interfaces is directly dependent on the patient and the secondary physician selected for consultation, which functionally means the GUI is selected based on the healthcare data and the identified algorithm.
Claim 4.
Purusothaman in combination with Szeto teaches, The computer-implemented method of claim 1, wherein establishing the first secure channel of communication includes one or both of: the host device authenticating the identity of the database; (Purusothaman, [0015], [0043], [0047], [0053-0055], [0062], [0099])
Purusothaman describes a process for setting up a protected data exchange pathway that incorporates verification of a storage entity's legitimacy by an initiating system. Since Purusothaman describes an integration where the centralized system uses IAM and EMPI to handle unique identification and access before data exchange with databases, establishing secure links for patient information transmission. Since Purusothaman describes the infirmary system or physician device checking patient details in IAM to confirm database identity and avoid duplication, including authentication as part of the secure pathway setup.
and the host device and the database each encrypting messages to be sent between each other. (Purusothaman, [0007], [0015], [0043])
The use of a secured link to share... data... securely demonstrated that messages between the host device and the database be encrypted to protect patient confidentiality as mandated by HIPAA.
Claim 5.
Purusothaman in combination with Szeto teaches, The computer-implemented method of claim 1, the method further including, transmitting, from the algorithm service to the host device, confirmatory instructions indicating which algorithm is to be applied to what healthcare data. (Purusothaman, paragraphs [0058], [0067], [0070], [0017], [0025-0028], [0039])
Purusothaman describes a workflow where after the secondary physician (algorithm service) receives the data link, they must request access. This action triggers the system to send a notification to the primary physician (host device) stating that a specific secondary physician... is requesting for access. This notification, which requires an "approve/reject" action from the host, functions as confirmatory instructions.
Claim 6.
Purusothaman in combination with Szeto teaches, The computer-implemented method of claim 5, wherein the confirmatory instructions comprise confirmatory GUI instructions which cause the generation of a pre-populated graphical user interface illustrating the healthcare data provided and the algorithm to be applied. (Purusothaman, [0029], [0058], [0070-0072])
The confirmatory step in Purusothaman involves the central system (algorithm service) sending instructions that generate a user interface view of a request for approval on the primary physician's system (host device), which appears as a pop-up menu. This UI is a pre-populated graphical user interface because it is generated in the specific context of a secondary physician (identifying the algorithm) requesting access to a specific patient's data (the healthcare data), thereby illustrating the parameters of the pending action for confirmation.
Claim 7.
Purusothaman in combination with Szeto teaches, The computer-implemented method of claim 6, wherein the method further comprises receiving at the host device one or more change requests relating to the pre-populated graphical user interface; (Purusothaman, [0058], [0067], [0070])
Purusothaman's system allows a primary physician to modify data sharing parameters on a confirmation screen. The physician, using their infirmary management system, can approve, deny, or alter data sharing by selecting secondary providers. These modifications are sent to a central service, and the patient data management system 100 is updated upon approval, with primary physicians notified for approval/rejection. The final act of sharing data transmits permissions.
and transmitting these change requests to the algorithm service. (Purusothaman, [0058], [0067])
After the host device receives the change request (e.g., by the user denying a request and re-selecting different data), the primary physician's subsequent action of approving the new transaction transmits these changes. The act of confirming the modified request sends the updated data sharing permissions to the central system (algorithm service), which constitutes transmitting these change requests.
Claim 8.
Purusothaman in combination with Szeto teaches, The computer-implemented method of claim 1, further including a transforming the result of applying the algorithm to the healthcare data before transmitting it to the host device; (Purusothaman, [0051], [0052])
Purusothaman explicitly discloses a patient data processing module 310 that is responsible for standardizing the results received from physicians. The system consolidates or standardizes the diagnosis and recommendation (the "second set of data") received from secondary physicians before it is presented back to the primary physician.
and/or a step of transforming the healthcare data before transmitting it to the algorithm service. (Purusothaman, [0051], [0062])
Purusothaman explicitly discloses a patient data processing module 310 that is responsible for standardizing incoming patient data. The system standardizes incoming data (e.g., from a Fitbit), which it defines as the first set of data, before it is used for diagnosis.
Claim 9.
Purusothaman in combination with Szeto teaches, The computer-implemented method of claim 1, the algorithm service including an API; (Purusothaman, [0062])
Purusothaman explicitly discloses that its centralized healthcare management system 102 (the algorithm service) uses an Application Programming Interface (API Integration) for data exchange with EMR systems.
and the host device including an edge module, the API and edge module being in secure communication via the second secure channel of communication. (Purusothaman, [0015], [0056], [0057], [0062])
Purusothaman discloses that the infirmary management system (the host device) contains client-side software modules, such as the patient data link transferring module, that function as an edge module. This edge module communicates with the Application Programming Interface (API Integration) of the centralized system (the algorithm service) by communicating the patient data as a secured link.
Claim 10.
Purusothaman in combination with Szeto teaches, The computer-implemented method of claim 1, wherein establishing the second secure channel of communication includes the host device authenticating the identity of the algorithm service. (Purusothaman, [0053], [0054])
Purusothaman's system is designed for secure, authorized access. The centralized healthcare management system 102 (algorithm service) includes a separate identity management server that handles a unique identification and access management part. For the primary physician's system (host device) to securely transmit sensitive EMR data to this server, it must first interact with this identity management system. This interaction to ensure only an Authorized person may access the data functionally constitutes the host device authenticating the identity of the algorithm service to establish a legitimate and secure connection.
Claim 11.
Purusothaman in combination with Szeto teaches, The computer-implemented method of claim 1, wherein establishing the secure second channel of communication includes the host device and algorithm service each encrypting messages to be sent between each other. (Purusothaman, [0007], [0015], [0047], [0054-0055])
Purusothaman describes a system where both the host and service computers encode messages sent between them as an inherent function of establishing a secure connection for sensitive health data. The disclosure of a secure healthcare data management server (SHDMS) for secure communication, the use of a secured link, and the requirement for complying with the HIPAA... guidelines inherently necessitates the encryption of data in transit by both communicating parties to ensure confidentiality and integrity, a standard technical safeguard.
Note: Claims 13 and 16 are rejected with Claim 1 for being be very similar.
Claim 17.
Purusothaman in combination with Szeto teaches, The host device of claim 16, wherein transmitting the identification of the algorithm and the healthcare data to the algorithm service comprises transmitting a first prepopulation request for a graphical user interface to be generated by the algorithm service, the operations further comprising: receiving, by the host device and responsive to the first pre-population request, instructions for rendering a graphical user interface on the host device including algorithm input values; ( Purusothaman paragraph 0009, 0015, 0058, 0007, 0073)
Purusothaman discloses that when the primary physician shares the EMR data via the secured link (the first pre-population request), the centralized system authorizes the secure link by the one or more secondary physicians to access the patient data and, in response, the system transmits interface instructions that render the electronic health record/electronic medical record (EHR/EMR) view on the host device. This EHR/EMR view is pre-populated with the patient's clinical data values, which function as algorithm input values in the context of the identified specialist's diagnostic expertise.
transmitting, from the host device to the algorithm service, a second request for the identified algorithm to be applied by the algorithm service to the algorithm input values;( Purusothaman paragraph 0007, 0009, 0058, 0070, 0090, 0065, 0067)
After the pre-populated EHR/EMR view is rendered, the primary physician takes a separate action to authorize the diagnostic analysis. The secondary physician's request to proceed triggers the primary physician to provide an explicit approve action via a pop-up menu (0069- 0070), which in turn enables the physician to "initiate a communication with the tagged one or more secondary physicians for diagnosis" ( 0007). This approval, transmitted after the pre-populated data has been rendered and reviewed constitutes the second request for the identified algorithm to be applied to the displayed algorithm input values.
and receiving, by the host device and from the algorithm service, the result of applying the identified algorithm to the algorithm input values. (Purusothaman paragraph 0007, 0058-0062, 0077)
Following the approval, the secondary physician performs the diagnosis "identifying... a disease or ailment of the first patient based on the EMR" and the "diagnosis and recommendation... are uploaded" back through the system. The primary physician's device receives this diagnostic result, completing the pre-population → execution → result cycle.
Claim 18.
Purusothaman in combination with Szeto teaches, The host device of claim 16, the operations further comprising: receiving, from the algorithm service, a list of algorithms supported by the algorithm service, the list including the identified algorithm. (Purusothaman, See at least, paragraph 0090 the search algorithm of the system displays the list of all physicians associated with that patient and paragraph 0065 primary physicians 108A-N may search for the one or more secondary physicians, 0065, 0067)
Purusothaman describes a system that provides a searchable list and a dedicated tab for finding healthcare professionals based on their specific areas of knowledge. This list is delivered to the user side so the physician can see which experts are available to help with a case. Because these experts are identified by their specific medical abilities, such as cardiology or dental services, the list functions as a catalog of available expert procedures. When the physician searches and finds the right specialist from this displayed list, the device has received the directory containing the specific service that will be used, fulfilling the requirement for obtaining a menu of supported options.
Claim 19.
Purusothaman in combination with Szeto teaches, The host device of claim 16, the operations further comprising: transmitting, from the host device to the algorithm service via the second secure channel of communication, an execution request associated with the identified algorithm, wherein the execution request is transmitted in a separate transmission from the identified algorithm and the healthcare data. (Purusothaman's, par. 0058-0060, 0069-0070)
Purusothaman's workflow requires the primary physician to first share the EMR data and identify the specialist, then separately approve the secondary physician's access request through an approve/reject action on a pop-up menu. This approval constitutes an execution request transmitted separately and subsequently to the data and algorithm identification — because it is the distinct act that authorizes the diagnostic analysis to proceed.
Claim 20.
Purusothaman in combination with Szeto teaches, The host device of claim 16, the operations further comprising: receiving, from the algorithm service and based on the identified algorithm, instructions causing generation of a pre-populated graphical user interface on the host device. (Purusothaman, par. 0058, 0060, 0009, 0073, 0077)
Purusothaman discloses that after the secondary physician (algorithm service) receives and reviews the patient's EMR data via the secured link, the centralized system transmits interface data back to the primary physician's device. The system provides "a user interface view of an electronic health record/electronic medical record (EHR/EMR) view with one or more action" that is generated in the context of the specific secondary physician's field of expertise. Because this EHR/EMR view arrives at the host device pre-populated with the patient's clinical data and is generated based on the tagged specialist's area of knowledge (the identified algorithm), the transmitted interface instructions cause generation of a pre-populated graphical user interface on the host device.
Claim 21.
Purusothaman in combination with Szeto teaches, The host device of claim 20, wherein the pre-populated graphical user interface includes one or more input fields for receiving change requests associated with the prepopulated graphical user interface, the operations further comprising: receiving a change request to the pre-populated graphical user interface, via the one or more input fields; (Purusothaman, par. 0061, 0065,0067, 0073, 0044)
Purusothaman provides a user interface with search and data-sharing fields, which allows the host device to receive user-driven change requests that alter a pre-rendered list or data settings. This modification request is transmitted to the central server, which operates a feedback loop to synchronize the changes, such as consultation notes or physician selections, with the electronic medical record. This bidirectional exchange performs the required sequence of sending a modification and receiving a corrected visual interface while also modifying the stored patient-specific values.
transmitting the change request from the host device to the algorithm service; (Purusothaman, 0067, 0090)
When the physician modifies data or selections through the interface, the system transmits these changes to the centralized system. Purusothaman discloses the ability to "Sync the consultation notes or feedback to referred physician's EMR" (0090), confirming that modifications made at the host device are transmitted to the service.
and receiving, from the algorithm service and based on the change request, amended instructions causing generation of an updated pre-populated graphical user interface on the host device. (Purusothaman, 0065, 0090)
After the centralized system processes the transmitted changes, it returns updated content. The system updates the "list of all physicians associated with that patient" (0090) and refreshes the interface on the host device with current information. This delivery of amended interface data from the service to the host device completes the change-request cycle.
Claim 22.
Purusothaman in combination with Szeto teaches, The host device of claim 21, wherein the algorithm service is configured to: store the patient specific values associated with each of the one or more data field identifiers; (Purusothaman, par. 0041, 0052, 0061, 0065, , 0077, 0080, 0090)
Purusothaman describes a centralized system that serves as a primary repository for patient measurements. It specifically organizes memory so that each data value and its corresponding unit are allocated to a unique patient ID. By holding this digital content in memory for future processing, the system maintains the records over time. This architectural setup on the server side matches the requirement of keeping specific measurements linked to their field labels within the service's storage.
and modify one or more of the patient specific values, based on the change request received from the host device.(Purusothaman, par. 0046, 0090)
Purusothaman identifies a module that explicitly permits experts to edit clinical reports. When a user provides feedback or consultation notes, the system synchronizes these updates back to the electronic medical record. This capability to update and edit records ensures that clinical values are adjusted based on the input received from the terminal. This synchronization of user-driven feedback into the stored data performs the functional step of changing values in response to a request.
Conclusion
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 JOSHUA DAMIAN RUIZ whose telephone number is (571)272-0409. The examiner can normally be reached 0800-1800.
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, Shahid Merchant can be reached at (571) 270-1360. 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.
/JOSHUA DAMIAN RUIZ/Examiner, Art Unit 3684
/Shahid Merchant/Supervisory Patent Examiner, Art Unit 3684