DETAILED ACTION
This action is made in response to the request for continued examination filed on December 29, 2025. This action is made non-final.
Claims 1-29 are pending. Claims 1, 8, 17, 18, 21, 23, 24, 26 and 28 have been amended. Claims 1, 8, 17, and 21 are independent claims.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on December 29, 2025 has been entered.
Response to Arguments
Applicant’s amendments/arguments with respect to the 101 rejection have been fully considered and the previous 101 rejection is withdrawn. The claims integrate the judicial exception into a practical application as they are directed to an improvement in technology. Specifically, the claims permit various devices with different functionalities and communication protocol requirements to effectively communicate and work in tandem with existing nurse call systems (see [0024], [0032]).
Applicant’s argument with respect to the previous art rejection has been fully considered but is moot in light of the new grounds of rejection.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-3, 8, and 17-19 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-3, 11, 16, 18, and 19 of copending Application No. 18/179,113 (hereinafter ‘113) in view of Mushin et al. (USPPN: 2018/0317826). Although the claims at issue are not identical, they are not patentably distinct from each other.
Instant Application
Co-Pending ‘113
Claim 1.
A server-based control system of a patient room in a hospital, the server-based control system comprising:
a first device associated with the patient room;
a hub located in the patient room and configured to be communicatively coupled with a nurse call system of the hospital and the first device; and
a server configured to:
receive a first request of the first device, the first request associated with at least one of the patient room or a patient in the patient room, information about the first request to be sent to at least one of: (i) the nurse call system, or (ii) a second device that is associated with the patient room;
determine a permission to make the first request by determining that at least one of a user of the first device or the first device itself is permitted to make the first request;
determine, upon the permission, the patient room based on the first request;
determine, based on the patient room, an identifier associated with the hub; and
send, to the hub based on the identifier, a second request that corresponds to the first request;
wherein the hub is further configured to:
receive, using a first communications interface, the second request including a first data format;
generate, based on the nurse call system, the first data format, and translation logic, a third request that corresponds to the second request and that comprises the information, wherein the third request includes a second data format that is different from the first data format, and wherein the translation logic depends on at least a model of the nurse call system or the second device the third request is sent to; and
send, using a second communications interface, the third request to at least one of: (i) the nurse call system or (ii) the second device that is associated with the patient room
Claim 1.
A system comprising:
a hub located in a room of a hospital and configured to be connected, via a nurse call interface in the room, with a nurse call system of the hospital; and
a server configured to:
receive a first request of a device associated with the room, the first request associated with at least one of the room or a patient in the room, information about the first request to be sent to the nurse call system;
determine a permission to make the first request by determining that at least one of a user of the device or the device itself is permitted to make the first request;
determine, upon the permission, the room based on the first request;
determine, based on the room, an identifier associated with the hub; and
send, to the hub based on the identifier, a second request that corresponds to the first request;
wherein the hub is further configured to:
receive, using a first communications interface, the second request;
generate, based on the nurse call system, a third request that corresponds to the second request and that comprises the information; and
send, using a second communications interface, the third request to the nurse call system via the nurse call interface.
Claim 2.
The system of claim 1, wherein the hub is further configured to: receive, from the nurse call system, a fourth request associated with at least one of: (i) the patient room or (ii) the patient, second information about the fourth request to be sent to the first device;
generate a fifth request that corresponds to the fourth request based on a format usable by the first device; and
send the fifth request to the server.
Claim 2.
The system of claim 1, wherein the hub is further configured to: receive, from the nurse call system and via the nurse call interface, a fourth request associated with at least one of: (i) the patient room or (ii) the patient, second information about the fourth request to be sent to the first device;
generate a fifth request that corresponds to the fourth request based on a format usable by the first device; and
send the fifth request to the server.
Claim 3.
The system of claim 2, wherein the server is further configured to: receive the fifth request;
determine the patient room based on the identifier associated with the hub;
determine the first device based on the patient room; and
send, to the first device, a sixth request that corresponds to the fifth request and that comprises the second information.
Claim 3.
The system of claim 2, wherein the server is further configured to: receive the fifth request;
determine the room based on the identifier associated with the hub;
determine the device based on the patient room; and
send, to the first device, a sixth request that corresponds to the fifth request and that comprises the second information.
Claim 8.
A method implemented by a server of a server-based control system of a patient room in a hospital, the method comprising:
receiving, from a first device, a first request associated with at least one of the patient room or a patient in the patient room, information about the first request to be sent to at least one of: (i) a nurse call system or (ii) a second device that is associated with the patient room;
determining a permission to make the first request by determining that at least one of a user of the first device or the first device itself is permitted to make the first request;
determining, upon the permission, the patient room based on the first request;
determining, based on the patient room, an identifier associated a hub located in the patient room; and
sending, to the hub based on the identifier, a second request that corresponds to the first request, the second request causing the hub to: receive, using a first communications interface, the second request including a first data format;
generate, based on the nurse call system, the first data format, and translation logic, a third request that corresponds to the second request and that comprises the information, wherein the third request includes a second data format that is different from the first data format, and wherein the translation logic depends on at least a model of the nurse call system or the second device the third request is sent to; and send, using a second communications interface, the third request to at least one of: (i) the nurse call system or (ii) the second device that is associated with the patient room.
Claim 11.
A method implemented by a server of a hospital, the method comprising:
receiving, from a device associated with a room of the hospital, a first request associated with at least one of the room or a patient in the room, information about the first request to be sent to a nurse call system of the hospital;
determining a permission to make the first request by determining that at least one of a user of the device or the device itself is permitted to make the first request;
determining, upon the permission, the room based on the first request;
determining, based on the room, an identifier associated a hub located in the patient room; and
sending, to the hub based on the identifier, a second request that corresponds to the first request, wherein after the second request is received by a first communications interface of the hub, the hub is caused to send the information to the nurse call system via a second communications interface of the hub and a nurse call interface in the room.
Claim 17.
A hub installable in a patient room of a hospital, the hub comprising:
one or more processors; and
one or more memory storing instructions that, upon execution by the one or more processors, configure the hub to:
connect with at least one of: (i) a nurse call system of the hospital or (ii) a second device that is associated with the patient room;
connect with a server;
receive, from the server and using a first communications interface, a second request including a first data format and the second request associated with at least one of: (i) the patient room or (ii) a patient in the patient room, information about the second request to be sent to at least one of: (i) the nurse call system or (ii) the second device, wherein:
the second request corresponds to a first request from a first device, and
the second request is received based on a permission of the first device or a user of the first device to make the first request and a mapping between an identifier associated with the hub and the patient room;
generate, based on the nurse call system, the first data format, and translation logic, a third request that corresponds to the second request and that comprises the information, wherein the third request includes a second data format that is different from the first data format, and wherein the translation logic depends on at least a model of the nurse call system or the second device the third request is sent to;
send, using a second communications interface, the third request to at least one of: (i) the nurse call system or (ii) the second device.
Claim 16.
A hub installable in a room of a hospital, the hub comprising:
one or more processors; and
one or more memory storing instructions that, upon execution by the one or more processors, configure the hub to:
connect with a nurse call system of the hospital via a nurse call interface located in a room of the hospital;
connect with a server;
receive, from the server and using a first communications interface of the hub, a second request associated with at least one of: the room or a patient in the room, information about the second request to be sent to the nurse call system, wherein:
the second request corresponds to a first request from a device associated the room to the server, and
the second request is received based on a permission of the device or a user of the device to make the first request and a mapping between an identifier associated with the hub and the patient room;
generate, based on the nurse call system, a third request that corresponds to the second request and that comprises the information; and
send the third request to the nurse call system via a second communications interface of the hub and the nurse call interface.
Claim 18.
The hub of claim 17, further comprising: at least a first hardware module that communicatively couples the hub with the server; at least a second hardware module that communicatively couples the hub with nurse call system, wherein the second hardware module is configured according to a model of the nurse call system; and one or more data lines between the first hardware module and the second hardware module.
Claim 18.
The hub of claim 16, further comprising: at least a first hardware module that communicatively couples the hub with the server; at least a second hardware module that communicatively couples the hub with nurse call system via the nurse call interface, wherein the second hardware module is configured according to a model of the nurse call system; and one or more data lines between the first hardware module and the second hardware module.
Claim 19.
The hub of claim 18, further comprising: a power over ethernet unit configured to provide power to the first device via a cable that couples the hub and the first device and to provide the first device with data connectivity to a data network via the cable or via wireless communication path between the hub and the first device.
Claim 19.
The hub of claim 18, further comprising: a power over ethernet unit configured to provide power to the first device via a cable that couples the hub and the first device and to provide the first device with data connectivity to a data network via the cable or via wireless communication path between the hub and the first device.
As can be seen from the table above, Claims 1-3, 11, 16, 18, and 19 contain all the limitations of Claims 1-3, 8, and 17-19 of the ‘113 application. While the presently examined claims recite “at least one of: (i) a nurse call system or (ii) a second device that is associated with the patient room”, the claims only require one of the nurse call system or the second device and all the limitations, therefore, are recited in the ‘113 application. Furthermore, Mushin teaches receive, using a first communications interface, the second request including a first data format; generate, based on the nurse call system, the first data format, and translation logic, a third request that corresponds to the second request and that comprises the information, wherein the third request includes a second data format that is different from the first data format, and wherein the translation logic depends on at least a model of the nurse call system or the second device the third request is sent to (e.g., see Fig. 24, [0150]-[0157] teaching a translation module that can translate data in a format readable by the hub or other devices, wherein the hub and other devices can be in different formats). Accordingly, it would have been obvious to modify Ballantyne-Dhir in view of Muhsin before the Application’s effective date, with a reasonable expectation of success. One would have been motivated to make the modification to provide for a patient monitoring hub that is easily expandable to various medical devices (e.g., see [0073] of Muhsin).
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-29 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
As to independent claims 1, 8, 17, and 21, the claims recite a “translation logic”. However, while the specification refers to logic operations and conditions, the specification fails to explicitly refer to a “translation logic”.
As to dependent claim 23, the claim recites “wherein the translation logic is performed by a first translation board configured to perform a first set of translations and is hot-swapable with a second translation board configured to perform a second set of translations”. However, while the specification discloses a translation board and states various component may be “hot-swappable”, the specification fails to disclose “wherein the translation logic is performed by a first translation board configured to perform a first set of translations and is hot-swapable with a second translation board configured to perform a second set of translations”.
As to dependent claim 24, the claim recites “wherein the translation logic depends on information received from the server”. However a review of specification is silent as to the source of the translation logic.
As to dependent claim 26, the claim recites “wherein an order of bits is different between the first data format and the second data format”; however, a review of the specification fails to disclose any ordering of the data bits nor that they are different from one another. Insomuch as Applicant asserts the disclosure of a “serial format” and the reformatting thereof is sufficient for supporting the different order of bits, the same rationale will be applied in the rejection of prior art.
Dependent claims 22-25 and 27-29 fail to resolve the 112 deficiency of their parent claim and are similarly rejected. Appropriate correction is required.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
Claim(s) 1-10, 12-18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ballantyne et al. (USPN: 5,867,821; hereinafter Ballantyne) in further view of Dhir et al. (USPPN: 2014/0095207; hereinafter Dhir) and Muhsin et al. (USPPN: 2018/0317826; hereinafter Muhsin).
As to claim 1, Ballantyne teaches A server-based control system of a patient room in a hospital (e.g., see Fig. 1) the server-based control system comprising:
a first device associated with the patient room;
a hub located in a room and configured to be communicatively coupled with a nurse call system of the hospital and the first device (e.g., see Fig. 1, 3: 60-67, 9:1-15, 9:60-10:9 teaching a medical information network system configured to provided communication between a distributed nursing station, individual beside patient care stations (PCS), personal digital assistants, and other data sources); and
a server (e.g., see Fig. 1) configured to:
receive a first request of the first device, the first request associated with at least one of the patient room or a patient in the patient room, information about the first request to be sent to at least one of: (i) the nurse call system, or (ii) a second device that is associated with the patient room (e.g., see Figs. 1, 4, 10, 9:9-15, 32-40, 9:61-10:27, 15:6-44 teaching an entry device for making a request associated with the room or the patient in the room, wherein the request can be sent to the nursing station);
determine a permission to make the first request by determining that at least one of a user of the first device or the first device itself is permitted to make the first request (e.g., see Figs. 9, 12, 8:20-31, 9:55-56 wherein user identification and authorization are determined for the request);
determine, upon the permission, the patient room based on the first request (e.g., see 9:1-3, 11:1-10, 12:5-18 wherein the room associated with the request of patient data is always maintained);
determine, based on the patient room, an identifier associated with the hub (e.g., see 11:1-26, 12:5-18 wherein the bedside PCS is always maintained); and
send, to the hub based on the identifier, a second request that corresponds to the first request (e.g., see 9:40-53, 12:35-37 wherein the initial data request is transmitted in a compressed format (i.e., second request corresponding to first request) to the appropriate PCS);
wherein the hub is further configured to:
receive the second request (e.g., see Fig. 1, 10:10-26, 12:35-41, 14:26-35 wherein the PCS receives requests);
generate, based on the nurse call system, a third request that corresponds to the second request and that comprises the information (e.g., see 10:10-26, 12:37-41 wherein the data is compressed and transferred to the appropriate nursing station); and
send the third request to at least one of: (i) the nurse call system or (ii) the second device that is associated with the patient room (e.g., see Fig. 1, 13:42-14:5, 14:26-40 wherein the nursing system sends and receives data requests).
While Ballantyne teaches sending/receiving data to/from a device wherein the device, which can be remote from the patient, is associated with a particular patient and identifies their location, should the recited features upon which the examiner relies not provide sufficient support, Dhir determine, based on the room, an identifier associated with the hub.
In the same field of endeavor of communication systems, Dhir teaches determine, based on the room, an identifier associated with the hub (e.g., see [0040], [0056]-[0058] wherein various devices are associated with a patient room).
It is further noted, while the claims recite the request to be sent to “at least one of: (i) the nurse call system, or (ii) a second device associated with the patient room” and is, therefore, taught by Ballantyne, Dhir additionally teaches sending a request to (ii) a second device that is associated with the patient room (e.g., see [0024] wherein one or more devices in a patient’s room are communicatively coupled).
Accordingly, it would have been obvious to modify Ballantyne in view of Dhir with a reasonable expectation of success. One would have been motivated to make the modification to easily permit a patient to access information in a quick and convenient manner, thereby increasing user experience and satisfaction (e.g., see [0004] of Dhir).
While Ballantyne teaches a system that receives and sends data, Ballantyne fails to explicitly teach receive, using a first communications interface of the hub, including a first data format; generate based on the first data format, and translation logic, a third request, wherein the third request includes a second data format that is different from the first data format, and wherein the translation logic depends on at least a model of the nurse call system or the second device the third request is sent to; and send via a send communications interface of the hub.
However, in the same field of endeavor of systems for medical monitoring data, Muhsin teaches receive, using a first communications interface of the hub, including a first data format (e.g., see Fig. 24, [0083], [0150]-[0157] teaching a hub with a plurality of communication modules receiving data in a first format); generate based on the first data format, and translation logic, a third request, wherein the third request includes a second data format that is different from the first data format, and wherein the translation logic depends on at least a model of the nurse call system or the second device the third request is sent to (e.g., see Fig. 24, [0150]-[0157] teaching a translation module that can translate data in a format readable by the hub or other devices, wherein the hub and other devices can be in different formats); and send via a send communications interface of the hub (e.g., see Fig. 24, [0083] wherein the hub can have a plurality of communication modules).
Accordingly, it would have been obvious to modify Ballantyne-Dhir in view of Muhsin before the Application’s effective date, with a reasonable expectation of success. One would have been motivated to make the modification to provide for a patient monitoring hub that is easily expandable to various medical devices (e.g., see [0073] of Muhsin).
As to claim 2, the rejection of claim 1 is incorporated. Ballantyne further teaches wherein the hub is further configured to: receive, from the nurse call system a fourth request associated with at least one of: (i) the patient room or (ii) the patient, second information about the fourth request to be sent to the device (e.g., see Figs. 1, 12, 13:42-14:5, 14:26-40 wherein the nursing system sends and receives data requests in compressed formats to/from the patient/patient room);
generate a fifth request that corresponds to the fourth request based on a format usable by the first device (e.g., see 8:11-12, 9:40-47, 13:29-31 teaching different compressions (i.e., requests) based on format of the data, wherein each device can have pre-established formats); and
send the fifth request to the server (e.g., see Fig. 1, 3: 60-67 teaching a medical information network system wherein requests are communicated between a distributed nursing station, individual beside patient care stations (PCS), personal digital assistants, and other external data sources).
As to claim 3, the rejection of claim 2 is incorporated. Ballantyne further teaches wherein the server is further configured to:
receive the fifth request (e.g., see Fig. 1, 3: 60-67 teaching a medical information network system wherein requests are communicated between a distributed nursing station, individual beside patient care stations (PCS), personal digital assistants, and other external data sources);
determine the patient room based on the identifier associated with the hub (e.g., see 9:1-3, 11:1-10, 12:5-8 wherein each patient and/or room are associated with their respective PCS (i.e., hub));
determine the first device based on the room (e.g., see Fig. 1, 9:54-55, 10:10-26 wherein each bedside station has an associated monitor/TV output device); and
send, to the first device, a sixth request that corresponds to the fifth request and that comprises the second information (e.g., see Fig. 10, 9:60-10:27 wherein the requested information is received by the requesting device).
As to claim 4, the rejection of claim 1 is incorporated. Ballantyne further teaches wherein the first device is a patient device, a patient care team device, or another device associated with a friend or family member of the patient, and the second device is a television, a hospital bed, a pump, a light, a window shade, a camera, a heart rate monitor, a tablet, a hall monitor, a pressure sensor, a pillowcase, a portable electronic device (PED), or a phone, and wherein the first device and the second devices are configured to be connected to the hub indirectly via the server and/or indirectly (e.g., see Figs. 1, 4, 6, 9:9-15, 9:32-40, 11:17-22 wherein the system permits communication between multiple devices, including a patient/medical staff devices such as personal data assistants and a tv/monitor and external health care monitoring equipment).
While Ballantyne teaches the above cited limitation, it is noted additionally cited Dhir further teaches multiple devices that are connected including patient devices, television, monitors, tablets (e.g., see [0023], [0024] wherein multiple devices may be paired including mobile phones, personal computing devices and may further be used/paired to control audio visual systems, patient beds, and the like).
As to claim 5, the rejection of claim 1 is incorporated. Ballantyne further teaches wherein the hub is further configured to: receive, from the first device, a seventh request associated with at least one of: (i) the patient room, (ii) the patient, (iii) the first device, or (iv) the user of the first device, a third information about the seventh request to be sent to the hub (e.g., see Figs. 1, 4, 10, 9:9-15, 32-40, 9:61-10:27, 15:6-44 teaching an entry device for making a request associated with the room or the patient in the room. See also MPEP 2144.04 wherein the duplication of parts is obvious).
As to claim 6, the rejection of claim 5 is incorporated. Ballantyne further teaches wherein the hub is further configured to: generate an eighth request that corresponds to the seventh request based on a format usable by the server and that comprises the third information; (e.g., see 8:11-12, 9:40-47, 13:29-31 teaching different compressions (i.e., requests) based on format of the data, wherein each device can have pre-established formats. See also MPEP 2144.04 wherein the duplication of parts is obvious); and
send the eighth request to the server (e.g., see Fig. 1, 3: 60-67 teaching a medical information network system wherein requests are communicated between a distributed nursing station, individual beside patient care stations (PCS), personal digital assistants, and other external data sources. See also MPEP 2144.04 wherein the duplication of parts is obvious).
As to claim 7, the rejection of claim 1 is incorporated. While Ballantyne teaches sending/receiving data to/from a device/monitor wherein the device/monitor, which can be remote from the patient, is associated with a particular patient and identifies their location, Ballantyne fails to teach receive, from the device, a connection request requesting a connection to the first device; determine the patient room based on the second device; determine, based on the patient room, a second identifier associated with the first device; and establish a connection between the second device and the first device.
However, in the same field of endeavor of communication systems, Dhir teaches receive, from the device, a connection request requesting a connection to the first device (e.g., see [0056]-[0058] wherein a connection request is sent to a server, pairing a device to another device, such as a monitor); determine the patient room based on the second device (e.g., see [0040], [0056]-[0058] wherein various devices are associated with a patient room); determine, based on the patient room, a second identifier associated with the first device (e.g., see [0040], [0056]-[0058] wherein various devices are associated with a patient room); and establish the connection between the second device and the first device (e.g., see [0056]-[0058] wherein a connection is established).
Accordingly, it would have been obvious to modify Ballantyne in view of Dhir with a reasonable expectation of success. One would have been motivated to make the modification to easily permit a patient to access information in a quick and convenient manner, thereby increasing user experience and satisfaction (e.g., see [0004] of Dhir).
As to claim 8, the claim is directed to the method implemented by the system of claim 1 and is similarly rejected.
As to claim 9, the rejection of claim 8 is incorporated. Ballantyne teaches wherein the hub is further configured to send a room identifier of the patient room directly to the first device (e.g., see 11:5-11, 12:5-7 teaching tracking and maintaining the patient location such that the data is sent to the respective device in the appropriate room). However, for the purposes of compact prosecution and in the same field of endeavor of communication systems, Dhir teaches send a room identifier of the patient room directly to the first device (e.g., see [0041], [0045], [0058] wherein a room/bed location and/or IP address is provided).
Accordingly, it would have been obvious to modify Ballantyne in view of Dhir with a reasonable expectation of success. One would have been motivated to make the modification to easily permit a patient to access information in a quick and convenient manner, thereby increasing user experience and satisfaction (e.g., see [0004] of Dhir).
As to claim 10, the rejection of claim 9 is incorporated. Ballantyne-Dhir further teach wherein the server is further configured to: receive the room identifier from the first device in association with the first request; and determine that the first device is located in the patient room based on the room identifier (e.g., see 11:5-11, 12:5-7 of Ballantyne teaching tracking and maintaining the patient location such that the data is sent to the respective device in the appropriate room. See also Fig. 8, [0040]-[0044] of Dhir wherein a data request is sent which includes room/bed information).
Accordingly, it would have been obvious to modify Ballantyne in view of Dhir with a reasonable expectation of success. One would have been motivated to make the modification to easily permit a patient to access information in a quick and convenient manner, thereby increasing user experience and satisfaction (e.g., see [0004] of Dhir).
As to claim 12, the rejection of claim 8 is incorporated. Ballantyne further teaches wherein the hub sends the information to the nurse call system via nurse call system interface (e.g., see Figs. 2, 4, 5:2-10 wherein the system communicates with a nurse call system via an interface).
As to claim 13, the rejection of claim 12 is incorporated. Ballantyne further teaches wherein the nurse call system interface is contained within a housing of the hub (e.g., see Fig. 1, 9:5-6 wherein the system communicates with a nurse call system via an interface within the patient care system).
As to claim 14, the rejection of claim 13 is incorporated. Ballantyne further teaches receiving, from the hub, a fourth request associated with at least one of the patient room or the patient, wherein the fourth request is based on a fifth call request of the nurse call system (e.g., see Figs. 1, 12, 13:42-14:5, 14:26-40 wherein the nursing system sends and receives data requests in compressed formats to/from the patient/patient room)
determining the patient room based on the identifier associated with the hub (e.g., see 9:1-3, 11:1-10, 12:5-8 wherein each patient and/or room are associated with their respective PCS (i.e., hub));
determining the first device based on the patient room (e.g., see Fig. 1, 9:54-55, 10:10-26 wherein each bedside station has an associated monitor/TV output device); and
sending, to the first device, a sixth request that corresponds to the fourth request (e.g., see Fig. 10, 9:60-10:27 wherein the requested information is received by the requesting device).
As to claim 15, the rejection of claim 13 is incorporated. Ballantyne further teaches storing, based on a set-up of the device, a first association between the patient room and the identifier associated with the user, the patient, or the first device (e.g., see Figs. 11, 12, 9:1-3, 11:1-10 wherein a patient and/or a healthcare provider and their device, and patient location and their respective PCS are maintained);
Ballantyne teaches a set-up of the hub (e.g., see Fig. 8), Ballantyne fails to explicitly teach storing, a second association between the patient room the identifier associated with the hub
However, in the same field of endeavor of communication systems, Dhir teaches storing, a second association between the patient room the identifier associated with the hub (e.g., see [0041], [0045], [0058] wherein a room/bed location and/or IP address is provided).
Accordingly, it would have been obvious to modify Ballantyne in view of Dhir with a reasonable expectation of success. One would have been motivated to make the modification to easily permit a patient to access information in a quick and convenient manner, thereby increasing user experience and satisfaction (e.g., see [0004] of Dhir).
Ballantyne-Dhir further teach looking up associations that include the first association and the second association in response to the first request (e.g., see Fig. 10 of Ballantyne wherein the request includes determining the type of user and their authorization. See also [0056] of Dhir wherein the request further includes determining the room identifier).
As to claim 16, the rejection of claim 15 is incorporated. Ballantyne further teaches wherein the first association associates the first device identifier of the first device with a room identifier of the patient room where the device is located (e.g., see Figs. 11, 12, 9:1-3, 11:1-10 wherein a patient and/or a healthcare provider and their device, and patient location and their respective PCS are maintained).
Ballantyne Ballantyne fails to explicitly teach wherein the second association associates a second device identifier of the hub with at least one of the room identifier or a bed identifier of a bed within the patient room
However, in the same field of endeavor of communication systems, Dhir teaches wherein the second association associates a second device identifier of the hub with at least one of the room identifier or a bed identifier of a bed within the patient room (e.g., see [0041], [0045], [0058] wherein a room/bed location and/or IP address is provided).
Accordingly, it would have been obvious to modify Ballantyne in view of Dhir with a reasonable expectation of success. One would have been motivated to make the modification to easily permit a patient to access information in a quick and convenient manner, thereby increasing user experience and satisfaction (e.g., see [0004] of Dhir).
As to claim 17, the claim is directed to the hub implemented in the system of claim 1 and is similarly rejected.
As to claim 18, the rejection of claim 16 is incorporated. Ballantyne further teaches at least a first hardware module that communicatively couples the hub with the server, at least a second hardware module that communicatively couples the hub with nurse call system, wherein the second hardware module is configured according to a model of the nurse call system; and one or more data lines between the first hardware module and the second hardware module (e.g., see Fig. 1, 3:60-67 teaching a medical information network system configured to provided communication between a distributed nursing station, individual beside patient care stations (PCS), personal digital assistants, and other data sources, the various components having corresponding hardware components and network communication).
While Ballantyne teaches the modules are configured to different components, Muhsin further teaches wherein the second hardware is configured according to a first configuration from a plurality of configurations, wherein each one of the plurality of configurations is specific to a different nurse call system model, and wherein the first configuration is specific to a nurse call system model of the nurse call system according to the model of the nurse call system (e.g., see [0081], [0153], [0155] wherein the system is adaptable to devices that may be configured for different protocols).
Accordingly, it would have been obvious to modify Ballantyne-Dhir in view of Muhsin before the Application’s effective date, with a reasonable expectation of success. One would have been motivated to make the modification to provide for a patient monitoring hub that is easily expandable to various medical devices (e.g., see [0073] of Muhsin).
As to claim 20, the rejection of claim 17 is incorporated. Ballantyne further teaches wherein a format of the third request is determined based on a component the third request is being sent to (e.g., see 8:11-12, 9:40-47, 13:29-31 teaching different compressions (i.e., requests) based on format of the data, wherein each device can have pre-established formats).
Claim(s) 11 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ballantyne, Dhir, and Muhsin, as applied above, and in further view of Collins et al. (USPPN: 2014/0297310; hereinafter Collins).
As to claim 11, the rejection of claim 1 is incorporated. Ballantyne teaches wherein the hub is a first hub and further comprising: a second hub (e.g., see Fig. 1 illustrating a plurality of hubs).
Ballantyne fails to teach wherein the first hub and the second hub belong to a mesh network, wherein the first hub is configured as a primary node of the mesh network to communicate with the server, and wherein the second hub is configured as a secondary node of the mesh network to communicate with the server via the primary node.
However, in the same field of endeavor of communication systems, Collins
teaches wherein the first hub and the second hub belong to a mesh network, wherein the first hub is configured as a primary node of the mesh network to communicate with the server, and wherein the second hub is configured as a secondary node of the mesh network to communicate with the server via the primary node (e.g., see [0073] teaching the plurality of hubs configured as a mesh network wherein modules outside the range can route their data to one or more modules within range).
Accordingly, it would have been obvious to modify Ballantyne in view of Collins with a reasonable expectation of success. One would have been motivated to make the modification in order to efficiently route data between devices (e.g., see [0073] of Collins).
As to claim 19, the rejection of claim 18 is incorporated. Ballantyne teaches connecting via Ethernet (e.g., see 4:67). Ballantyne fails to explicitly teach a power over Ethernet unit configured to provide power to the device via a cable that couples the hub and the device and to provide the device with data connectivity to a data network via the cable or via wireless communication path between the hub and the device. Notably, the power Ethernet providing power and data connectivity to the device to which it is coupled is interpreted as an intended result statements. Applicant is remined that, typically, no patentable distinction is made by an intended result unless some structural difference is imposed by the use or result on the structure or material recited in the claim, or some manipulative difference is imposed by the use or result on the action recited in the claim. An intended result is a description of what necessarily happens as a result of the structure or actions recited in the claims. (See MPEP 2111.05).
However, in the same field of endeavor of communication systems, Collins teaches a power over Ethernet unit configured to provide power to the device via a cable that couples the hub and the device and to provide the device with data connectivity to a data network via the cable or via wireless communication path between the hub and the device (e.g., see [0129] teaching the use of power over Ethernet for providing power and data connectivity).
Accordingly, it would have been obvious to modify Ballantyne-Dhir in view of Collins with a reasonable expectation of success. One would have been motivated to make the modification in order to efficiently route data between devices (e.g., see [0073] of Collins).
Claim(s) 21-25 and 27-29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ballantyne et al. (USPN: 5,867,821; hereinafter Ballantyne) in further view of Muhsin et al. (USPPN: 2018/0317826; hereinafter Muhsin).
As to claim 21, Ballantyne teaches A control system of a patient room in a medical facility (e.g., see Abstract, Fig. 1), the control system comprising:
a first medical facility device that is associated with the patient room (e.g., see Fig. 1);
a server (e.g., see Fig. 1);
a first hub located in the patient room and configured to be communicatively coupled with the server and the first medical facility device (e.g., see Fig. 1); and
the first hub configured to:
connect with the first medical facility device that is associated with the patient room (e.g., see Fig. 1, 3:60-67, 9:1-15, 9:60-10:9 teaching a medical information network system configured to provide communication between a distributed nursing station, individual beside care stations (PCS), personal digital assistants, and other data sources);
connect with the server (e.g., see Fig. 1);
receive from the first medical facility device, first information associated with at least one of: (i) the patient room or (ii) a patient in the patient room, the first information having a first format (e.g., see Figs. 1, 4, 10, 8:11-12, 9:9-15, 32-47, 9:61-10:27, 13:29-31, 15:6-44 teaching an entry device for making a request associated with the room or the patient in the room, wherein the requests have different compressions based on format of the data, wherein each device can have pre-established formats);
generate second information that corresponds to the first information (e.g., see 9:40-53, 12:35-37 wherein the initial data request is transmitted in a compressed format (i.e., second request corresponding to first request); and
send the second information to the server (e.g., see Fig. 1, 3: 60-67 teaching a medical information network system wherein requests are communicated between a distributed nursing station, individual beside patient care stations (PCS), personal digital assistants, and other external data sources).
While Ballantyne teaches a system that receives and sends data, Ballantyne fails to explicitly teach the first information represented using a first data format; generate, based on the first data format, and translation logic, second information, wherein the second information includes a second data format that is different from the first data format; and send using a second data format using the second data format.
However, in the same field of endeavor of systems for medical monitoring data, Muhsin teaches represented using a first data format (e.g., see Fig. 24, [0083], [0150]-[0157] teaching a hub with a plurality of communication modules receiving data in a first format); generate based on the first data format, and translation logic, second information, wherein the second information includes a second data format that is different from the first data format, and wherein the translation logic depends on at least a model of the server the second information is sent to (e.g., see Fig. 24, [0150]-[0157] teaching a translation module that can translate data in a format readable by the hub or other devices, wherein the hub and other devices can be in different formats); and send using a second data format using the second data format (e.g., see Fig. 24, [0150]-[0157] teaching sending/receiving data that has been translated by a translation module to a format readable by the hub or other devices, wherein the hub and other devices can be in different formats).
Accordingly, it would have been obvious to modify Ballantyne-Dhir in view of Muhsin before the Application’s effective date, with a reasonable expectation of success. One would have been motivated to make the modification to provide for a patient monitoring hub that is easily expandable to various medical devices (e.g., see [0073] of Muhsin).
As to claim 22, the rejection of claim 21 is incorporated. Ballantyne further teaches wherein the server is further configured to: receive the second information; and determine whether to at least: store data included within the second information, or send the second information to the first hub, a second hub, a third party system, or a nurse call system (e.g., see Figs. 1, 10, 9:60-10:27, 12:35-41, wherein the data is received and can either be stored or routed to the appropriate destination).
As to claim 23, the rejection of claim 21 is incorporated. Muhsin further teaches wherein the translation logic is performed by a first translation board configured to perform a first set of translations and is hot-swappable with a second translation board configured to perform a second set of translations (see 112 rejection above. See also [0356] wherein components may be hot swapped without interrupting data transmissions).
As to claim 24, the rejection of claim 21 is incorporated. Ballantyne further teaches wherein the translation logic depends on information received from the server (see 112 rejection. e.g., see [0241] wherein the translation rules can be stored locally or externally on a device communicatively coupled to the translation module).
As to claim 25, the rejection of claim 21 is incorporated. Ballantyne further teaches wherein the first hub is further configured to: determine at least one of: (i) a second medical facility device or (ii) a nurse call system to send the second information to; and send the second information to at least one of: (i) the second medical facility device or (ii) the nurse call system (e.g., see Figs. 1, 10, 9:60-10:27, wherein the data is received and routed to the appropriate destination).
As to claim 27, the rejection of claim 21 is incorporated. Ballantyne further teaches wherein the second information is identical to the first information (e.g., see 8:11-12, 9:40-47, 13:29-31 wherein the request data is compressed in accordance with the device format; however, the request itself is nonetheless the same).
As to claim 28, the rejection of claim 21 is incorporated. Ballantyne-Muhsin further teaches wherein the second information is generated as a result of the translation logic condition, the translation logic condition dependent on at least the first information, and a third information (e.g., see 12:48-13:4 of Ballantyne wherein the data can further be transmitted/stored based on determining whether the user is authorized. See also [0150]-[0157], [0244] of Muhsin wherein the data is formatted in accordance with the translation rules).
As to claim 29, the rejection of claim 28 is incorporated. Ballantyne further teaches wherein the third information is received from a second hub, a second medical facility device, the first medical facility device, or the server (e.g., see Figs. 1, 9, 8:20-46, 12:48-13:4 wherein the list authorized users are maintained and compared by the system).
Claim(s) 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ballantyne and Muhsin, as applied above, as evidenced by He (“Byte and Bit Order Dissection”, [online], September 2003, retrieved from the internet: <URL: https://www.linuxjournal.com/article/6788> and also [online], April 2005, retrieved https://web.archive.org/web/20050421171007/http://www.linuxjournal.com/article/6788; hereinafter He).
As to claim 26, the rejection of claim 21 is incorporated. Muhsin teaches wherein an order of bits is different between the first data format and the second data format (See 112 rejection above. e.g., see [0079], [0424] teaching data being sent/retrieved in a serial format).
While Muhsin teaches reformatting data using serial format, which Applicant asserts refers to a serial order of bits, and therefore reads upon the claimed limitation, for the purposes of compact prosecution, He teaches wherein an order of bits is different between the first data format and the second data format. However, it is noted that transmission protocols can have different bit orders as further evidenced by He.
He teaches wherein an order of bits is different between the first transmission format and the second transmission format (e.g., see “Endianness of Network Protocols” paragraph, teaching different bit orders for different network protocols).
It is noted that any citation to specific pages, columns, lines, or figures in the prior art references and any interpretation of the references should not be considered to be limiting in any way. “The use of patents as references is not limited to what the patentees describe as their own inventions or to the problems with which they are concerned. They are part of the literature of the art, relevant for all they contain.” In re Heck, 699 F.2d 1331, 1332-33, 216 USPQ 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275, 277 (CCPA 1968)). Further, a reference may be relied upon for all that it would have reasonably suggested to one having ordinary skill the art, including nonpreferred embodiments. Merck & Co. v. Biocraft Laboratories, 874 F.2d 804, 10 USPQ2d 1843 (Fed. Cir.), cert. denied, 493 U.S. 975 (1989). See also Upsher-Smith Labs. v. Pamlab, LLC, 412 F.3d 1319, 1323, 75 USPQ2d 1213, 1215 (Fed. Cir. 2005); Celeritas Technologies Ltd. v. Rockwell International Corp., 150 F.3d 1354, 1361, 47 USPQ2d 1516, 1522-23 (Fed. Cir. 1998).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STELLA HIGGS whose telephone number is (571)270-5891. The examiner can normally be reached Monday-Friday: 9-5PM.
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 Choi can be reached on (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.
/STELLA HIGGS/Primary Examiner, Art Unit 3681
Prosecution Insights