DETAILED ACTION
This action is made in response to the amendments/remarks filed on July 2, 2026. This action is made final.
Claims 1-29 are pending. Claims 1, 8, 13, 17, 21, 23, 24, 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 .
Response to Arguments
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.
Applicant’s amendments remove the additional elements which were determined to be directed to an improvement in technology. The claims no longer recite different devices having different communication protocol requirements. The claims, as amended, encompasses a person following rules or instructions to make and route a verified patient request and a 101 rejection has been applied.
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.
As to dependent claim 23, the claim recites “wherein the conditional logic is performed by a first translation board configured to perform a first set of translations designed to translate request formats for a first nurse call system and is hot-swapable with a second translation board configured to perform a second set of translations designed to translate requests formats for a second nurse call station”. However, while the specification describes “conditional logic” for determining if conditions are met to trigger a request (e.g., see [0033]) and further states that message content and/or the request format can be changed (e.g., see [0117], [0118]), the specification is silent as to the conditional logic being performed by a translation board. Furthermore, while the specification discloses a translation board and states various component may be “hot-swappable”, the specification fails to disclose “a first translation board configured to perform a first set of translations designed to translate request formats for a first nurse call system and is hot-swapable with a second translation board configured to perform a second set of translations designed to translate requests formats”.
As to dependent claim 24, the claim recites “wherein the conditional logic is performed by a first translation board and the conditional logic of the first translation board depends on information received from the server”. As stated with respect to claim 23, while the specification teaches “conditional logic” and a “translation board”; however, a review of specification is silent that the conditional logic is performed by a first translation board. Applicant states [0115] and [0116] provide support, however those paragraphs, at best, describe that the hub may transform the format of request received by a subsequent component, such as a translation board, but does not teach or suggest “wherein the conditional logic is performed by a first translation board and the conditional logic of the first translation board depends on information received from the server”.
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.
Appropriate correction is required.
Claim Rejections - 35 USC § 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-29 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1-7 recite a system for making a request, which is within the statutory class of a machine. Claims 8-16 recite a method of making a request, which is within the statutory category of a process. Claims 17-20 recites a device for making a request, which is within the statutory class of a machine. Claims 21-29 recites a system for making a request, which is within the statutory class of a machine
Claims are eligible for patent protection under § 101 if they are in one of the four statutory categories and not directed to a judicial exception to patentability. Alice Corp. v. CLS Bank Int'l, 573 U.S. ___ (2014). Claims 1-29, each considered as a whole and as an ordered combination, are directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
MPEP 2106 Step 2A – Prong 1:
The bolded limitations of:
Claims 1, 8, and 17 (claim 8 being representative)
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 with 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 conditional logic, a third request that corresponds to the second request and that comprises the information, wherein the third request included a second data format that is different from the first data format, and wherein the conditional logic is configured to evaluate one or more conditions associated with at least the second request; 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 21
a first medical facility device that is associated with the patient room; a server; a first hub located in the patient room and configured to be communicatively coupled with the server and the first medical facility device; and the first hub configured to: connect with the first medical facility device that is associated with the patient room; connect with the server; 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 represented using a first data format; generate, based on the first data format, conditional logic, second information that corresponds to the first information, wherein the second information includes a second data format that is different from the first data format, and wherein the conditional logic is configured to evaluate one or more conditions associated with at least the first information; and send the second information to the server using the second data format.
as presently drafted, under the broadest reasonable interpretation, covers a method of organizing human activity (i.e., managing personal behavior including following rules or instructions). For example, but for the computer and/or additional elements, the claim encompasses a person following rules or instructions to make and route a verified patient request. The examiner further notes that “methods of organizing human activity” includes a person’s interaction with a computer (see October 2019 Update: Subject Matter Eligibility at Pg. 5). If the claim limitation, under its broadest reasonable interpretation, covers managing persona behavior or interactions between people but for the recitation of generic computer components, then it falls within the “method of organizing human activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
MPEP 2106 Step 2A – Prong 2:
This judicial exception is not integrated into a practical application because there are no meaningful limitations that transform the exception into a patent eligible application. The additional elements merely amount to instructions to apply the exception using generic computer components (one or more processors; one or more memory; a server; a first/second device; and first/second communications interface—all recited at a high level of generality). Although they have and execute instructions to perform the abstract idea itself, this also does not serve to integrate the abstract idea into a practical application as it merely amounts to instructions to "apply it." (See MPEP 2106.04(d)(2) indicating mere instructions to apply an abstract idea does not amount to integrating the abstract idea into a practical application). Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose meaningful limits on practicing the abstract idea. Therefore, the claims are directed to an abstract idea.
The “nurse call system” and “hub” are not generic computer component; however it is recited at a high levels of generality and similarly amount to generally linking the abstract idea to a particular technological environment. (See MPEP 2106.04(d)(1) indicating generally linking an abstract idea to a particular technological environment does not amount to integrating the abstract idea into a practical application).
The claims only manipulate abstract data elements as part of performing the abstract idea. They do not set forth improvements to another technological field or the functioning of the computer itself and instead use computer elements as tools in a conventional way to improve the functioning of the abstract idea identified above. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation. None of the additional elements recited "offers a meaningful limitation beyond generally linking 'the use of the [method] to a particular technological environment,' that is, implementation via computers." Alice Corp., slip op. at 16 (citing Bilski v. Kappos, 561 U.S. 610, 611 (U.S. 2010)).
At the levels of abstraction described above, the claims do not readily lend themselves to a finding that they are directed to a nonabstract idea. Therefore, the analysis proceeds to step 2B. See BASCOM Global Internet v. AT&T Mobility LLC, 827 F.3d 1341, 1349 (Fed. Cir. 2016) ("The Enfish claims, understood in light of their specific limitations, were unambiguously directed to an improvement in computer capabilities. Here, in contrast, the claims and their specific limitations do not readily lend themselves to a step-one finding that they are directed to a nonabstract idea. We therefore defer our consideration of the specific claim limitations’ narrowing effect for step two.") (citations omitted).
MPEP 2106 Step 2B:
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception for the same reasons as presented in Step 2A Prong 2. Moreover, the additional elements recited are known and conventional generic computing elements (one or more processors; one or more memory; a server; a first/second device; and first/second communications interface—see Specification Fig. 2, [0028], [0045], [0050]-[0053], [0070] describing the various components as general purpose, common, standard, known to one of ordinary skill, and at a high level of generality, and in a manner that indicates that the additional elements are sufficiently well-known that the specification does not need to describe the particulars of such additional elements to satisfy the statutory disclosure requirements). Therefore, these additional elements amount to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept that amounts to significantly more. See MPEP 2106.05(f).
The Federal Circuit has recognized that "an invocation of already-available computers that are not themselves plausibly asserted to be an advance, for use in carrying out improved mathematical calculations, amounts to a recitation of what is 'well-understood, routine, [and] conventional.'" SAP Am., Inc. v. InvestPic, LLC, 890 F.3d 1016, 1023 (Fed. Cir. 2018) (alteration in original) (citing Mayo v. Prometheus, 566 U.S. 66, 73 (2012)). Apart from the instructions to implement the abstract idea, they only serve to perform well-understood functions (e.g., receiving, translating, and displaying data—see Specification above as well as Alice Corp.; Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307 (Fed. Cir. 2016); and Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015) covering the well-known nature of these computer functions).
Furthermore, as discussed above, the additional element of a “nurse call system” and “hub” is recited at high levels of generality and were determined to generally link the abstract idea into a particular technological environment or field of use. This additional element have been re-evaluated under step 2B and have also been found insufficient to provide significantly more. (See MPEP 2106.05(A) indicating generally linking an abstract idea to a particular technological environment does not amount to significantly more).
Dependent Claims
The limitations of dependent but for those addressed below merely set forth further refinements of the abstract idea without changing the analysis already presented. Claims 2, 3, 5-7, 9, 10, 12, 14, 15, 16, 20, 22-25, and 27-28 merely recites additional requests being made and various data associations, which covers a method of organizing human activity (i.e., managing personal behavior including following rules or instructions). Claims 4, 11, 13, 18, 19, and 26 include the additional elements of various devices such as a phone, television, hospital bed, etc., a mesh network, hardware modules, power over Ethernet, and the order of bits in transmission format. These additional elements are considered to “apply it” or “generally linking” under both the practical application and significantly more analysis, as detailed in the analysis above.
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, 20-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) and Ribble et al. (USPPN: 2020/0105422; hereinafter Ribble).
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 and the first data format, a third request that corresponds to the second request and that comprises the information (e.g., see 8:10-14, 10:10-26, 12:37-41 wherein the data is compressed depending on the format 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, Muhsin teaches determine, based on the room, an identifier associated with the hub.
In the same field of endeavor of communication systems, Muhsin teaches determine, based on the room, an identifier associated with the hub (e.g., see [0352]-[0353], [0362], [0369], [0402] 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, Muhsin additionally teaches sending a request to (ii) a second device that is associated with the patient room (e.g., see Fig. 17A, [0079], [0370]-[0372] wherein one or more devices in a patient’s room are communicatively coupled).
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 conditional logic, a third request, wherein the third request includes a second data format that is different from the first data format; 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 conditional logic, a third request, wherein the third request includes a second data format that is different from the first data format (e.g., see Fig. 24, [0150]-[0157], [0247]-[0249] wherein messages are generated based on the communication protocol/format, wherein the hub and other devices can be in different formats, as well as based on one or more rules); 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 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).
Muhsin additionally teaches generating a message based on the conditional logic Ballantyne-Muhsin fails to teach wherein the conditional logic is configured to evaluate one or more conditions associated with at least the second request.
However, in the same field of endeavor of patient monitoring, Ribble teaches wherein the conditional logic is configured to evaluate one or more conditions associated with at least the second request (e.g., see [0021], [0055], [0092], [0095[ wherein an alert (i.e., request) is generated based on an evaluation associated with data received from a request associated with the patient (i.e., first/second request)).
Accordingly, it would have been obvious to modify Ballantyne-Muhsin in view of Ribble before the Application’s effective date, with a reasonable expectation of success. One would have been motivated to make the modification in order to communicate alerts based on sensed/determined needs (e.g., see [0021] of Ribble).
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, Muhsin teaches receive, from the device, a connection request requesting a connection to the first device (e.g., see [0301]-[0302] wherein one or more devices can be paired or otherwise authenticated to the hub); determine the patient room based on the second device (e.g., see Fig. 17, [0352]-[0353], [0362], [0369], [0402] 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 Fig. 17, [0352]-[0353], [0362], [0369], [0402] wherein various devices are associated with a patient room); and establish the connection between the second device and the first device (e.g., see [0301]-[0305] wherein a connection is established).
Accordingly, it would have been obvious to modify Ballantyne 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 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 [0353] wherein a room location is provided).
Accordingly, it would have been obvious to modify Ballantyne 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 10, the rejection of claim 9 is incorporated. Ballantyne-Muhsin 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 see [0353] wherein a room location is provided).
Accordingly, it would have been obvious to modify Ballantyne 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 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. Ribble further teaches wherein the conditional logic is further configured to evaluate one or more conditions associated with the patient room or the patient (e.g., see [0021], [0055], [0092], [0095] wherein the condition is associated with the patient).
Accordingly, it would have been obvious to modify Ballantyne-Muhsin in view of Ribble before the Application’s effective date, with a reasonable expectation of success. One would have been motivated to make the modification in order to communicate alerts based on sensed/determined needs (e.g., see [0021] of Ribble).
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 [0353] wherein a room location is provided).
Accordingly, it would have been obvious to modify Ballantyne 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).
Ballantyne-Muhsin 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 [0353] of Muhsin 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 [0353] wherein a room location is provided).
Accordingly, it would have been obvious to modify Ballantyne 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 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 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).
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 conditional 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 conditional logic, second information, wherein the second information includes a second data format that is different from the first data format (e.g., see Fig. 24, [0150]-[0157], [0247]-[0249] wherein messages are generated based on the communication protocol/format, wherein the hub and other devices can be in different formats, as well as based on one or more rules); 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 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 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).
Muhsin additionally teaches generating a message based on the conditional logic; however Ballantyne-Muhsin fails to teach wherein the conditional logic is configured to evaluate one or more conditions associated with at least the second request.
However, in the same field of endeavor of patient monitoring, Ribble teaches wherein the conditional logic is configured to evaluate one or more conditions associated with at least the second request (e.g., see [0021], [0055], [0092], [0095[ wherein an alert (i.e., request) is generated based on an evaluation associated with data received from a request associated with the patient (i.e., first/second request)).
Accordingly, it would have been obvious to modify Ballantyne-Muhsin in view of Ribble before the Application’s effective date, with a reasonable expectation of success. One would have been motivated to make the modification in order to communicate alerts based on sensed/determined needs (e.g., see [0021] of Ribble).
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 conditional logic is performed by a first translation board configured to perform a first set of translations designed to translate request formats for a first nurse call system and is hot-swappable with a second translation board configured to perform a second set of translations designed to translate request formats for a second nurse call system (see 112 rejection above. See also [0150], [0356] teaching a translation module to translate data to be recognizable by the hubs and 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 conditional logic is performed by a first translation board and the conditional logic of the first translation board 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-Ribble further teaches wherein the second information is generated as a result of the conditional logic, 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 [0021], [0055], [0092], [0095[ of Ribble wherein an alert (i.e., request) is generated based on an evaluation associated with data received from a request associated with the patient (i.e., first/second request)).
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) 11 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ballantyne, Muhsin, and Ribble 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 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) 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ballantyne, Muhsin, and Ribble 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 (e.g., see [0079], [0151], [0424] teaching data being sent/retrieved in a serial format and translating to be recognizable by the different devices. Accordingly, Muhsin teaches the claimed limitation as argued by Applicant as “serial format” is recognizable by one of ordinary skill in the art as referring to the serial order of bits (see Remarks page 15)).
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
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 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