DETAILED ACTION
In view of the Appeal Brief filed on 2/2/2026, PROSECUTION IS HEREBY REOPENED. A new ground of rejection is set forth below.
To avoid abandonment of the application, appellant must exercise one of the following two options:
(1) file a reply under 37 CFR 1.111 (if this Office action is non-final) or a reply under 37 CFR 1.113 (if this Office action is final); or,
(2) initiate a new appeal by filing a notice of appeal under 37 CFR 41.31 followed by an appeal brief under 37 CFR 41.37. The previously paid notice of appeal fee and appeal brief fee can be applied to the new appeal. If, however, the appeal fees set forth in 37 CFR 41.20 have been increased since they were previously paid, then appellant must pay the difference between the increased fees and the amount previously paid.
Notice of Pre-AIA or AIA Status
2. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
3. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 of this title, 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.
5. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
6. Claims 23-24 and 26-28 are rejected under 35 U.S.C. 103 as being unpatentable over Perez et al. (US 10,542,004) hereinafter Perez in view of Martin et al. (US 2022/0020490) hereinafter Martin.
Claims 1-22 (Canceled)
In claim 23, Perez discloses “A non-transitory computer-readable medium containing instructions which, when executed, cause a processor to:
retrieve an application for a user device, wherein the application is configured to communicate with a facility application server and the user device and a user associated with the user device are located in a hospital setting ((45) col. 11 lines 13-33, The medical care facility 110 can be a hospital, users (e.g., patients, doctors, etc.) may utilize the one or more components 106 and/or the one or more user devices 108 to generate such medical-related data. For example, the hospital may include, as one of its components, an Mill machine. A technician (e.g., a user) may collect one or more Mill images of a patient using the Mill machine at the hospital. These MM images, a form of medical-related data, can be stored locally, and a copy of the file can be provided to the transformative integration engine 102, which can coordinate storage and later retrieval of the information for use by one or more others of the one or more components 106 of the one or more user devices 108, (52) col. 12 lines 40-45, the medical care professional utilizes some of the one or more user devices 108 to send medical-related data to, and/or receive from, the transformative integration engine 102, medical-related data. In this manner, the medical care professional can receive updates, statuses, progress, and the like relating to patients (53) col. 12 lines 47-54, the one or more users can include a patient. The patient can be a patient of the medical care facility 110, the first responder, and/or the medical care professional. The patient can include one that has expressly or implicitly authorized the medical care facility 110, the first responder and/or the medical care professional to access and record medical-related data pertaining to services provided to the patient);
communicate user information, via the application, to the facility application server so that the facility application server can authenticate the user device, wherein the communication occurs over a secure connection and the authentication is based on a first information about a patient in the hospital setting ((51) col. 12 lines 17-26, the one or more user devices 108 may operate according to a private and/or proprietary network or protocols, the transformative integration engine 102 can have access to the one or more components and can communicate with them via a public, private and/or proprietary network or protocols. The use of one or more private and/or proprietary protocols can promote secure transfer of medical-related data ((109) col. 26 line 63-col. 27 line 4, a user desiring access to medical-related data provides certain identifying information and the authentication access engine 604 authenticates an identity of the user. For example, suppose the user is a doctor and the access is to medical charts for one of the doctors patients. To authenticate the doctor's identity, he or she provides identifying information and once validated can be granted access to elements of the medical provider network where such information may be stored, ((110) col. 27 lines 5-20, The login engine 606 evaluates the rules and conditions under which users are able to log in to the medical provider network or access applications associated with the medical provider network. These rules and conditions may be user-defined (e.g., by an administrator), learned over time, and also may be dynamically updated and/or evaluated based on characteristics of the user or the user's device attempting to access the medical provider network. Thus, while the authentication access engine 604 evaluates the rules to determine which users may access the medical provider network, the login engine 606 evaluates the particular credentials, profiles, etc. of the users. For example, the login engine 606 can confirm that an entered username (e.g., and password), provided biometric data or code or identifier in a scanned tag or badge matches that in an authorized user data structure)”.
Perez does not appear to explicitly disclose however, Martin discloses “pair the user device with an endpoint device, wherein pairing the user device with an endpoint device is based on a second information about the patient in the hospital setting ([0167] The communications engine 1104 may be configured for auto-pairing (e.g. for transports that support pairing, the engine 1104 uses rules specific to the transport to automatically create and maintain pairings with medical devices depending on configuration and user preference) and/or for auto-discovery (e.g. for transports that support discovery, the engine 1104 may be configured to automatically find new medical devices and enter them into the known device list));
upon authentication, display control icons on a display of the user device ([0114] A “back of ambulance” (“BOA”) device 104 receives, organizes, stores, and displays data from each device 108, 110, 112 to further enhance the usefulness of each device 108, 110, 112 and to make it much easier for the EMS technician 114 to perform certain tasks that would normally require the EMS technician 114 to divert visual and manual attention to each device 108, 110, 112 separately, the BOA device centralizes and organizes information that would normally be de-centralized and disorganized [0358] FIG. 62 illustrates examples of such mobile devices communicably coupled to BOA device 104, including a lead medic mobile device 620, drug medic mobile device 622, airway medic mobile device 624, and CPR medic mobile device 626 [0359] a start screen for a role-based EMS technician mobile device 620 in communication with a BOA device 104. The software instructions contained on the mobile device render this start screen to permit the medic to identify the IP Address, send port, receive port, medic name, and medic role. FIG. 47 illustrates a role selection screen for a role-based EMS technician mobile device in communication with a BOA device. A checkmark next to the “Medic-Lead” listing indicates that the user of the mobile device is the lead medic. According to embodiments of the present invention, a password or other authentication may be required in order to restrict role based on identity); and
send one or more commands from the user device to the facility application server so that the facility application server can forward the one or more commands to the endpoint device to cause the endpoint device to perform an action based on the one or more commands ([0389] an external device (e.g. BOA 104 and/or patient charting device 108) can use a discovery protocol, for example mDNS/DNS-SD, to probe a local system 631 to determine which data services it provides. The external device would then form a TCP/IP connection to that service on the communication interface system 631. Each communication interface system 631 has a unique IP socket address. Both the communication interface system 631 and the external device would then authenticate each other to permit bi-directional commands, responses, and data flow. This data flow may occur in XML format over a TCP/IP protocol, for example. This discovery protocol could also operate in reverse, such that the communications interface device 631 could probe external devices (e.g. BOA 104) and connect to services on those devices. In these ways, external devices may be connected to and receive streaming data from device 631 over a wireless local area network (e.g. a Wi-Fi network))”.
Hence, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine Perez and Martin, the suggestion/motivation for doing so would have been to provide an improved method for collecting, organizing, and communicating of patient information between various devices (Abstract).
Claim 24 is essentially same as claim 23 except that it recites claimed invention as a method and is rejected for the same reasons as applied hereinabove.
Claim 25 (Canceled)
In claim 26, Martin teaches
The computer-readable medium of claim 23, wherein the one or more endpoint devices includes one or more of: a standard television, a smart television, a bedside terminal, a smart tablet, a smart phone, and a digital white board terminal ([0113] The patient charting device 108 may also be used to record biographic and/or demographic and/or historical information about a patient, for example the patient's name, identification number, height, weight, and/or medical history. The patient charting device 108 is a tablet PC, such as for example the TabletPCR component of the RescueNet® ePCR Suite available from Zoll Data Systems of Broomfield, Colo. The patient charting device 108 is a wristband or smart-phone such as an Apple iPhone or iPad with interactive data entry interface such as a touch screen or voice recognition data entry that may be communicably connected to the BOA device 104 and tapped to indicate what was done with the patient 116 and when it was done).
In claim 27, Martin teaches
The computer-readable medium of claim 23, wherein the processor is further configured to communicate, via the application, information not directly related to display on the end point device to the facility application server in order to cause a record related to the patient to be stored and/or modified based on the information ([0169] a pipe may be a combination of transport, medical device, and storage configurations which represent a medical device from which the user has indicated data will be received, and which allows communications to occur. Pipes may be configured by the user and/or may be predefined. For example, a pipe may specify Transport Serial Port with configuration (COM1, Baud=9600), Medical Device E/M Series ZOLLModem (Any Medical Device) and Storage (Local File System). This configuration would accept data assets from any device connected to COM1 at 9600 baud and store them to the local file system [0170] a pipe may specify Transport Bluetooth (Baud=115200, Auto-Pair), Medical Device E/M Series ZOLLModem (Any Device). This configuration would cause Bluetooth to automatically pair with any medical device found during periodic discovery and accept any data assets from any paired device and store them via all loaded and enabled storage plug-ins. As yet another example, a pipe may specify Transport TCP/IP (LocalIP=192.168.1.20, Port=7743), Medical Device E/M Series DUN (Any Device), Storage (Asset Management). This configuration would cause the engine 1104 to start listening on the specified IP address and port for DUN traffic and store it via Asset Management (e.g. by sending it to mobile asset management module 1106 and/or enterprise asset management module 1118) [0172] the mobile asset management module 1106 receives medical device data from the device adapter and communications interface 1104. The mobile asset management module 1106 performs the secure storage, retrieval and management of medical device data together with asynchronous events informing other applications of the storage or modification of these data assets. The mobile asset management module 1106 supports local or remote service oriented API to store, retrieve and modify medical device data, and provides local or remote asynchronous message-based notification of events to applications which subscribe for them. These events may include notification of the arrival of medical device data).
Claim 28 is essentially same as claim 27 except that it recites claimed invention as a method and is rejected for the same reasons as applied hereinabove.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUAWEN A PENG whose telephone number is (571)270-5215. The examiner can normally be reached Mon thru Fri 9 am to 5 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, Sherief Badawi can be reached at 571-272-9782. 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.
/HUAWEN A PENG/Primary Examiner, Art Unit 2169
Prosecution Insights