DETAILED ACTION
This action is made in response to the amendments/remarks filed on July 14, 2025. This action is made final.
Claims 1-20 are pending. Claims 1, 11, and 16 have been amended. Claims 1, 11, and 16 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 arguments with respect to the 101 rejection have been fully considered but are not persuasive.
Applicant asserts the claim provides an improvement to communication between devices and solve the technical problem of facilitating usage of data from numerous devices having unique functionalities and communication protocol requirements. However, the examiner respectfully disagrees.
MPEP 2106.04(d)(1) and MPEP 2106.05(a) indicates that a practical application may be present where the claimed invention provides a technical solution to a technical problem. See, e.g., DDR Holdings, LLC. v. Hotels.com, L.P., 773 F.3d 1245, 1259 (Fed. Cir. 2014) (finding that claiming a website that retained the “look and feel” of a host webpage provided a technological solution to the problem of retention of website visitors by utilizing a website descriptor that emulated the “look and feel” of the host webpage, where the problem arose out of the internet and was thus a technical problem). Here, while Applicant’s argued problem may be a technical problem, there is no nexus between the argued problem and the argued solution because there is no indication that the claimed invention actually solves this problem. The Applicant argues the technical problem of facilitating usage of numerous devices having distinct functionalities, required inputs, available outputs, and communication protocol requirements; however, there is no indication that the claim actually solves this problem. The claim does not recite unique devices having unique functionalities, required inputs, available outputs, and communication protocol requirements, nor does it explain the details of an unconventional solution. That is, the claim must include the components or steps of the invention that provide any purported improvement described in the specification. Because the claim does not explicitly solve this technical problem, a practical application is not present.
Applicant further argues the claims are an improvement to a computer network. However, the examiner respectfully disagrees. As stated above, even if a technical problem exists with integration of disparate devices, the claims, themselves, do not reflect any purported improvement in a technology or a computer network, as alleged by applicant. That is, the claim must include the components or steps of the invention that provide the improvement supported in the specification. Furthermore, Applicant is remined that in determining whether a claim improves technology is the extent to which the claim covers a particular solution to a problem or a particular way to achieve a desired outcome, as opposed to merely claiming or arguing the idea of a solution or outcome. Furthermore, the addition of general purpose computers added post-hoc to an abstract idea does not amount to an improvement, but rather, a specific implementation of a solution to a problem must be recited (see MPEP 2106.05(a)). Here, the claims describe steps a person or persons would take to determine patient requests and route/forward them to a recipient. The additional elements such as the processor, server, memory, device, and communication interfaces merely amount to instructions to apply the exception using generic computer components and do not serve to integrate the abstract idea into a practical application or significantly more as it merely amounts to instructions to "apply it." Furthermore, the “nurse call interface”, “nurse call system”, and “hub” are not generic computer component; however are recited at a high levels of generality and similarly amount to generally linking the abstract idea to a particular technological environment and do not serve to integrate the abstract idea into a practical application or significantly more.
Insomuch as the Applicant asserts the claims are analogous to example 40, the present claims are distinguishable from those of example 40 in that they do not recite the combination of additional elements of collecting at least one of a network delay, packet loss, or jitter relating to the network traffic passing through the network appliance, and collecting additional Netflow protocol data relating to the network traffic when the collected network delay packet loss, or jitter is greater than the predefined threshold nor do the present claim limit collection of additional Netflow protocol data to when the initially collected data reflects an abnormal condition, which avoids excess traffic volume on the network and hindrance of network performance, wherein the collected data can then be used to analyze the cause of the abnormal condition, thus resulting in improved network monitoring.
Applicant’s argument that the claims are necessarily rooted in computer technology and reliance of examples 1-36, the guidance has been superseded and/or encapsulated by new USPTO guidance and MPEP 2106.05. Accordingly, see examiner’s response above in that, even if a technical problem exists, the claims do not reflect any purported improvement in technology.
Applicant further argues the examiner has not shown that the additional elements recited in the claims are well-understood, routine, and conventional. However, the examiner respectfully disagrees. As previously stated, the totality of the claim limitations was determined to be subsumed within the abstract idea of organizing human activity, but for the recitation the additional elements such as the processor, server, memory, device, which are 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." Furthermore, Applicant’s own specification, in at least Fig. 1, [0025], [0031], [0038], [0060] describe 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, the “nurse call system/interface” and “hub” are not generic computer component; however they are 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) and 2106.05(A) indicating generally linking an abstract idea to a particular technological environment does not amount to integrating the abstract idea into a practical application nor is it indicative of an inventive concept).
Applicant’s arguments with respect to claim 1 have been fully considered and are persuasive, but are moot in light of the new grounds of rejection.
Applicant’s argument with respect to claim 5 has been fully considered but is not persuasive. Applicant argues Ballantyne fails to teach “a monitor located outside the room and configured to be connected to the device directly or to be connected to the device indirectly via the server”. However, the examiner respectfully disagrees.
Ballantyne teaches a system for the distribution and administration of medical services, entertainment services, electronic medical records, educational information, etc. to a patient’s individual station, wherein the system can be connected to a remote monitor (e.g., see Abstract, Figs. 1, 4, 6). While the claim further recites the monitor is located outside the room, as previously stated, the precise location of the monitor (i.e., outside the room) is interpreted as an intended use statement. Applicant is remined that, typically, no patentable distinction is made by an intended use 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 use generally does not impart a patentable distinction if it merely states an intention or is a description of how the claimed apparatus is to be used. (See MPEP 2111.05). In the present case, Ballantyne having taught a monitor that can be provided remotely from the server, therefore, teaches the limitation). As such, Ballantyne teaches the claimed limitation.
Applicant’s argument with respect to claim 8 has been fully considered but is not persuasive. Applicant argues Ballantyne fails to teach sending “a room identifier of the room directly to the device”. However, the examiner respectfully disagrees.
As a first matter, insomuch as Applicant argues the prior art is not configured to send data directed to one of the devices outside the hospital boundary, it is noted the claims do not require the devices to be outside the hospital boundary. Furthermore as stated, Ballantyne teaches tracking and maintaining the patient location such that the data can be sent to the respective devices in the appropriate room (e.g., see 11:5-11, 12:5-7). Furthermore, Dhir was further relied upon for teaching send a room identifier of the 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 such, Ballantyne-Dhir teach the claimed limitation.
Applicant’s argument with respect to claim 18 has been fully considered but is not persuasive. Applicant argues Ballantyne fails to teach “wherein the second hardware module is configured according to a model of the nurse call system”. However, the examiner respectfully disagrees.
The broadest reasonable interpretation (BRI) of “configured” is set up for operation in a particular way and the BRI of “model” includes a version or type (see Merriam Webster Dictionary). Accordingly, where the prior art teaches a hardware module that is set up to work with at least one nurse call system, then it meets the claimed limitation. Ballantyne teaches a medical information network with all related hardware and software components to provide communication between the master library, communication interconnection system, the distributed processing nursing station, individual patient care stations and integrated PDA devices. Accordingly, Ballantyne teaches a plurality of hardware modules set up for operation (i.e., configured) with a nursing station (i.e., a model of the nurse call system) and, therefore, meets the claimed limitation.
Accordingly, for at least the above stated reasons and those below, the previous grounds of rejection are maintained.
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, 11, 16, 18, and 19 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-3, 8, and 17-19 of copending Application No. 18/334,635 (hereinafter ‘635). Although the claims at issue are not identical, they are not patentably distinct from each other.
Instant Application
Co-Pending ‘635
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 the second communications interface, the third request to the nurse call system via the nurse call interface.
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;
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 at least one of: (i) the nurse call system or (ii) the second device that is associated with the patient room
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 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 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 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 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 second communications interface of the hub and a nurse call interface in the room.
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; 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 at least one of: (i) the nurse call system or (ii) the second device that is associated with the patient room.
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 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 of the hub, a 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, 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 at least one of: (i) the nurse call system or (ii) the second device.
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 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 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, 8, and 17-19 of the instant application contain all the limitations of Claims 1-3, 11, 16, 18, and 19 of the ‘635 application. While the presently examined claims recite sending the request to the nurse call system “via the nurse call interface”, the broadest reasonable interpretation of a “interface” is a boundary where two systems/programs meet (see Merriam Webster Dictionary), accordingly, it would have been obvious, if not necessary that an interface exists between two communicating systems. Furthermore, the present claims recites a first/second communications interface of the hub, which is taught in Collins (e.g., see Fig. 1, [0063], [0064] teaching a hub having multiple receiver and transceiver modules for sending and receiving data). Accordingly, it would have been obvious to modify the co-pending application 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).
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
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-20 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-10 recite a system for making a request, which is within the statutory class of a machine. Claims 11-15 recite a method of making a request, which is within the statutory category of a process. Claims 16-20 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-20, 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, 11, and 16 (claim 11 being representative)
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 station 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 with a hub located in the 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 the first communications interface of the hub, the hub is caused to send the information to the nurse call system via second communications interface of the hub and a nurse call interface in the room.
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 noted computer and/or additional elements, the claim encompasses a person following rules or instructions to route a verified patient request in the manner described in the abstract idea. 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 device; a first communications interface; a 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/interface” 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 into another form. 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 device; an interface; a first communications interface; a second communications interface—see Specification Fig. 1, [0025], [0031], [0035], [0038], [0054], [0060] 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, 8, 9, 13, 14, 15, 17, and 20 merely recites an 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-7, 10, 12, 18, and 19 include the additional elements of a monitor, a mesh network, a device, hardware modules, and power over Ethernet. 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-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 Collins et al. (USPPN: 2014/0297310; hereinafter Collins).
As to claim 1, Ballantyne teaches A system (e.g., see Fig. 1) 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 (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 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 (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 device or the 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 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 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 the nurse call system via the nurse call interface (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).
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; and send via a send communications interface of the hub.
However, in the same field of endeavor of communication systems, Collins teaches receive, using a first communications interface of the hub; and send via a send communications interface of the hub (e.g., see Fig. 1, [0063], [0064] teaching a hub having multiple receiver and transceiver modules for sending and receiving data).
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).
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 and via the nurse call interface, a fourth request associated with at least one of the room or 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);
generate a fifth request that corresponds to the fourth request based on a format usable by the 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 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 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 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 further comprising: a monitor located outside the room and configured to be connected to the hub directly or to be connected to the hub indirectly via the server (e.g., see Figs. 1, 4, 6 teaching a connected monitored, wherein the monitor can be remote from the hub. Notably, the precise location of the monitor (i.e., outside the room) is interpreted as an intended use statement. Applicant is remined that, typically, no patentable distinction is made by an intended use 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 use generally does not impart a patentable distinction if it merely states an intention or is a description of how the claimed apparatus is to be used. (See MPEP 2111.05). In the present case, Ballantyne having taught a monitor that can be provided remotely from the hub located within a patient’s room, therefore, teaches the limitation).
As to claim 5, the rejection of claim 1 is incorporated. Ballantyne further teaches further comprising: a monitor located outside the room and configured to be connected to the device directly or to be connected to the device indirectly via the server (e.g., see Figs. 1, 4, 6 teaching a connected monitored, wherein the monitor can be remote from the server. Notably, the precise location of the monitor (i.e., outside the room) is interpreted as an intended use statement. Applicant is remined that, typically, no patentable distinction is made by an intended use 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 use generally does not impart a patentable distinction if it merely states an intention or is a description of how the claimed apparatus is to be used. (See MPEP 2111.05). In the present case, Ballantyne having taught a monitor that can be provided remotely from the server, therefore, teaches the limitation).
As to claim 6, the rejection of claim 1 is incorporated. Ballantyne further teaches further comprising: wherein the server is further configured to: determine the room based on the connection request (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, based on the room, the device (e.g., see Fig. 1, 9:54-55, 10:10-26 wherein each bedside station has an associated monitor/TV output device).
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 the monitor configured to: send, to the server, a connection request requesting a connection to the device; and establish the connection between the device and the monitor.
However, in the same field of endeavor of communication systems, Dhir teaches send, to the server, a connection request requesting a connection to the 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); and establish the connection between the device and the monitor (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 7, the rejection of claim 1 is incorporated. Ballantyne further teaches further comprising: a monitor located outside the room (e.g., see Figs. 1, 4, 6 teaching a connected monitored, wherein the monitor can be remote from the hub. Notably, the precise location of the monitor (i.e., outside the room) is interpreted as an intended use statement. Applicant is remined that, typically, no patentable distinction is made by an intended use 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 use generally does not impart a patentable distinction if it merely states an intention or is a description of how the claimed apparatus is to be used. (See MPEP 2111.05). In the present case, Ballantyne having taught