DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Notice to Applicant
Claims 1-20 are pending and have been examined.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on October 27, 2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 5 and 14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The term “similar” in claim is a relative term which renders the claim indefinite. The term “similar” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. For the purposes of examination, Examiner will interpret the claims to instead read “wherein the first decentralized network is based on a first wireless protocol, and wherein the second decentralized network is based on a second wireless protocol that is the same as the first wireless protocol”, as supported by [0043] of Applicant specification: “In some embodiments, the decentralized network 102B used to share the record-identifying information 120 between the devices 110A, 110C can have a similar wireless protocol as the decentralized network 102A used to share the record-identifying information 120 between the devices 110A, 110B. As a non-limiting example, WiFi Direct can be used to share record-identifying information 120 in both instances.”
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.
Subject Matter Eligibility Criteria – Step 1:
The claims recite subject matter within a statutory category as a process and a machine
(claims 1-20). Accordingly, claims 1-20 are all within at least one of the four statutory categories.
Subject Matter Eligibility Criteria – Step 2A – Prong One:
Regarding Prong One of Step 2A of the Alice/Mayo test, the claim limitations are to be analyzed to determine whether, under their broadest reasonable interpretation they “recite” a judicial exception or in other words whether a judicial exception is “set forth” or “described” in the claims. MPEP §2106.04(II)(A)(1). An “abstract idea” judicial exception is subject matter that falls within at least one of the following groupings: a) certain methods of organizing human activity, b) mental processes, and /or c) mathematical concepts. MPEP §2106.04(a).
The Examiner has identified server Claim 21 as the claim that represents the claimed invention for analysis and is similar to method claim 10 and product claim 19.
Claim 1:
A server comprising:
a processor; and
a memory storing computer-executable instructions that, when executed by the processor, cause the processor to:
receive first patient data from a first device, wherein the first patient data was collected by the first device during a patient encounter;
receive, from the first device, record-identifying information of a second device that was associated with the patient encounter, wherein, during the patient encounter, the record-identifying information of the second device was shared with the first device;
generate a request for second patient data collected by the second device during the patient encounter;
send the request for the second patient data to the second device based on the record-identifying information of the second device;
receive the second patient data from the second device after sending the request for the second patient data to the second device; and
generate a record for the patient encounter based at least on the first patient data and the second patient data.
These above limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of organizing human activity under managing personal behaviors of people. The claim elements are directed towards generating a request for data, receiving data, and generating a record for a patient encounter based on the received data, which are typically human activities performed by medical providers for their patients during a patient encounter.
Accordingly, the claim recites at least one abstract idea.
Claims 10 and 19 are abstract for the same reasons as above.
Subject Matter Eligibility Criteria – Step 2A – Prong Two:
Regarding Prong Two of Step 2A of the Alice/Mayo test, it must be determined whether the claim as a whole integrates the idea into a practical application. As noted at MPEP §2106.04 (ID)(A)(2), it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.” MPEP §2106.05(I)(A).
Additional elements cited in the claims:
server (1-10,12,19); processor (1,3,19); memory (1); first device (1-4,7,10-13,16,19-20); second device (1-4,9-13,18-19); decentralized network (2,11); third device (3-4,12-13); first decentralized network (4-6,13-15); second decentralized network (4-6,13-15); wireless protocol (5-6,14-15); medical device (7-8,16-17,20); mobile device (7,16,20); defibrillator (8,17); patient monitor (8,17); centralized network (9,18); non-transitory computer-readable medium (19)
Any computing devices that would be able to perform the method (server, processor) and their associated additional elements (memory, non-transitory computer-readable medium) are taught at a high level of generality such that the claim elements amounts to no more than mere instructions to apply the exception using any generic component capable of performing the claim limitations. [0045] of Applicant specification recites: “ The server 310 includes a processor 312, a memory 314 coupled to the processor 312, and one or more transceivers 316 coupled to the processor 312. The memory 314 can be a non-transitory computer-readable medium that includes instructions 315 that are executable by the processor 312 to perform operations associated with the server 310.” No specific, technical improvements are being made to server devices as a generic server device is applied to perform the abstract idea of generating patient encounter records.
Networks (decentralized network, first decentralized network, second decentralized network, wireless protocol, centralized network) are taught at a high level of generality. [0021] of Application specification recites: “To illustrate, during the patient encounter, the first device and the second device can share record-identifying information using a decentralized network, such as WiFi Direct, Bluetooth, etc.” [0054] further recites: “The device 110C can communicate with the server 310 using a network 502 (e.g., a centralized network). For example, the device 110C can send data to the server 310 using the network 502, and the server 310 can send data to the device 110C using the network 502. According to one implementation, the network 502 is a WiFi network. According to one implementation, the network 502 is a cellular network, such as a PLMN. In some implementations, the network 502 is the same network as one of the networks 302, 402. In other implementations, the network 502 is a different network than the networks 302, 402.” No specific technical improvements are being made to networking technologies as known methods are simply applied to perform an insignificant extra-solution activity of transmitting data; MPEP 2106.05(g).
Devices (first device, second device, third device, medical device, mobile device, patient monitor) are also taught at a high level of generality. [0018] recites: “Different devices, such as medical devices and mobile devices, can be used during a patient encounter to provide medical treatment to a patient and/or collect patient data. As a non-limiting example, a defibrillator can be used to perform defibrillation operations on the patient, a patient monitoring device can be used to monitor vital signs of the patient, etc. Each device used during the patient encounter can collect different patient data. To illustrate, a first device (e.g., the defibrillator) can collect first patient data, such as cardiovascular information associated with the patient’s heartbeat. Additionally, a second device (e.g., the patient monitoring device) can be used collect second patient data, such as respiratory information associated with the patient’s breathing patterns.” No specific, technical improvements are made to devices as they are only applied to perform an insignificant extra-solution activity of data gathering; MPEP 2106.05(g).
Thus, taken alone, the additional elements do not integrate the at least one abstract idea into a practical application.
Looking at the additional elements as an ordered combination adds nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole with the limitations reciting the at least one abstract idea, reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, apply or use the above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole does not integrate the abstract idea into a practical application of the abstract idea. MPEP §2106.05(I)(A) and §2106.04(IID)(A)(2).
The remaining dependent claim limitations not addressed above fail to integrate the abstract idea into a practical application as set forth below:
Claims 2 and 11: These claims recite wherein the record-identifying information of the second device was shared using a decentralized network established between the first device and the second device; which teaches a decentralized network at a high level of generality, such that the network is only applied to perform the insignificant extra-solution activity of transmit data to facilitate the abstract idea of generating patient records.
Claims 3 and 12: These claims recite wherein the computer-executable instructions further cause the processor to: receive, from the first device or the second device, record-identifying information of a third device that was associated with the patient encounter, wherein, during the patient encounter, the record-identifying information of the third device was shared with at least one of the first device or the second device; generate a request for third patient data collected by the third device during the patient encounter; send the request for the third patient data to the third device based on the record-identifying information of the third device; and receive the third patient data from the third device after sending the request for the third patient data to the third device, wherein the record for the patient encounter is additionally generated based on the third patient data; which teaches an abstract idea of certain methods of organizing humanity as generating patient records. This claim teaches the third device at a high level of generality such that it is only applied to perform an insignificant extra-solution activity of gathering data.
Claims 4 and 13: These claims recite wherein the record-identifying information of the second device was shared using a first decentralized network established between the first device and the second device, and wherein the record-identifying information of the third device was shared using a second decentralized network established between the third device and at least one of the first device or the second device; which teaches a first and second decentralized network at a high level of generality such that they are only applied to perform an insignificant extra-solution activity of transmitting data.
Claims 5 and 14: These claims recite wherein the first decentralized network and the second decentralized network are based on a similar wireless protocol; which only serves to further limit the type of decentralized networks used.
Claims 6 and 15: These claims recite wherein the first decentralized network is based on a first wireless protocol, and wherein the second decentralized network is based on a second wireless protocol that is different from the first wireless protocol; which only serves to further limit the type of decentralized networks used.
Claims 7, 16, and 20: These claims recite wherein the first device corresponds to a medical device or a mobile device that is operable to collect patient data; which only serves to narrow the type of device from which data is gathered from.
Claims 8 and 17: These claims recite wherein the medical device includes a defibrillator or a patient monitor; which only serves to narrow the type of device from which data is gathered from.
Claims 9 and 18: These claims recite wherein the request for the second patient data is sent to the second device using a centralized network, and wherein the second patient data is received from the second device using the centralized network; which teaches a centralized network at a high level of generality such that they are only applied to perform an insignificant extra-solution activity of transmitting data
Subject Matter Eligibility Criteria – Step 2B:
Regarding Step 2B of the Alice/Mayo test, representative independent claims do not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for reasons the same as those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application.
These claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to discussion of integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply an exception, add insignificant extra-solution activity to the abstract idea, and generally link the abstract idea to a particular technological environment or field use. Additionally, the additional limitations, other than the abstract idea per se, amount to no more than limitations which:
Amount to elements that have been recognized as activities in particular fields (such as Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information), MPEP §2106.05(d)(II)(i);storing and retrieving information in memory, Versata Dev. Group, MPEP §2106.05(d)(II)(iv)).
Dependent claims recite additional subject matter which, as discussed above with respect to integration of the abstract idea into a practical application, amount to invoking computers as a tool to perform the abstract idea. Dependent claims recite additional subject matter which amount to limitations consistent additional subject matter which amount to limitations consistent with the additional elements in the independent claims (such as claims 2-9, 11-18, and 20 additional limitations which amount to elements that have been recognized as activities in particular fields, claims 2-9, 11-18, and 20, e.g., performing repetitive calculations, Flook, MPEP §2106.05(d)(II)(ii); claims 2-9, 11-18, and 20, e.g., storing and retrieving information in memory, Versata Dev. Group, MPEP §2106.05(d)(II)(iv). 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.
Therefore, whether taken individually or as an ordered combination, claims 1-20 are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-5, 7-14, and 16-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by White (US 20210304881).
Regarding claim 1, White teaches a server comprising: a processor; and a memory storing computer-executable instructions that, when executed by the processor ([0004], “The server includes at least one processor and memory to execute instructions for associating the one or more medical device case files.”), cause the processor to:
receive first patient data from a first device, wherein the first patient data was collected by the first device during a patient encounter ([0076], “The healthcare providers 118A located at the scene of the patient encounter may further be using their respective mobile computing devices to generate other information, such as creating log entries of notable events through a documentation tool and/or entering in patient information via a charting tool for ePCR. Such records may also be uploaded along with the other medical device case files to the central repository of the server(s) 108.”);
receive, from the first device, record-identifying information of a second device that was associated with the patient encounter, wherein, during the patient encounter, the record-identifying information of the second device was shared with the first device ([0063], “the healthcare provider may use his/her mobile computing device to acquire an identifier, or a representation thereof, of each of a plurality of medical devices used/located at the scene. The mobile device executing a patient encounter device association application may then associate each of the plurality of medical devices together using the identifying information, and transmit association information to a server system executing an encounter data source integration service, which can be one or more computing devices located at a remote location. This association information can include a variety of informational elements, such as a token that uniquely identifies the patent encounter, the identifiers of the medical devices, timestamp information associated with the patient encounter, geolocation information that identifies a geographical location of the patient encounter, and potentially other information associated with the patient encounter.”);
generate a request for second patient data collected by the second device during the patient encounter; send the request for the second patient data to the second device based on the record-identifying information of the second device ([0157], “the patient encounter data source integration service 130 may not communicate directly with these data stores for security purposes. In certain implementations, the patient encounter data source integration service 130 is conversant in multiple data formats and is able to interact with components of the medical device 102 and the mobile computing device 104 via a public API which can serve as a gatekeeper to resources provided by such devices” [0158], “In such case, the patient encounter data source integration service 130 may send the case API 126 a request for information that is stored in the medical device case data store 132... Any of these requests may include appropriate security credentials.” [0063], “a server system executing an encounter data source integration service”);
receive the second patient data from the second device after sending the request for the second patient data to the second device ([0158], “In such case, the patient encounter data source integration service 130 may send the case API 126 a request for information that is stored in the medical device case data store 132... Based on the security credentials, the case API 126, the ePCR API 128, and/or the event log API 144 may either grant or deny the request for information. If the respective interface grants the request for information, then the interface will retrieve the requested information from the appropriate data store.”); and
generate a record for the patient encounter based at least on the first patient data and the second patient data ([0158], “The patient encounter data source integration service 130 may perform one or more data merge operations according to one or more criteria identified by the patient encounter data source integration service 130. When the patient encounter data source integration service 130 completes the one or more data merge operations, the patient encounter data source integration service 130 may return the merged file (for example, a file that includes medical device data merged into patient charting data) to the case API 126 for storage in the medical device case data store 132.”).
Regarding claim 2, White teaches the server of claim 1. White further teaches wherein the record-identifying information of the second device was shared using a decentralized network established between the first device and the second device ([0105], “FIG. 20 illustrates another example medical environment 2000 that involves local personal area network (e.g., BLUETOOTH network) communication of patient data between one or more medical devices and the local computing device 1906, and also data communication with the remote computing devices 1914.”). Examiner notes that [0035] of Applicant specification defines a decentralized network as “a WiFi Direct network, a Bluetooth network, etc.”
Regarding claim 3, White teaches the server of claim 1. White further teaches wherein the computer-executable instructions further cause the processor to:
receive, from the first device or the second device, record-identifying information of a third device that was associated with the patient encounter, wherein, during the patient encounter, the record-identifying information of the third device was shared with at least one of the first device or the second device ([0063], “the healthcare provider may use his/her mobile computing device to acquire an identifier, or a representation thereof, of each of a plurality of medical devices used/located at the scene. The mobile device executing a patient encounter device association application may then associate each of the plurality of medical devices together using the identifying information, and transmit association information to a server system executing an encounter data source integration service, which can be one or more computing devices located at a remote location. This association information can include a variety of informational elements, such as a token that uniquely identifies the patent encounter, the identifiers of the medical devices, timestamp information associated with the patient encounter, geolocation information that identifies a geographical location of the patient encounter, and potentially other information associated with the patient encounter.” [0074], “As illustrated in FIG. 3A, other medical devices located at a scene sending continuous real-time data to the server(s) 108 for consolidation with other case files relevant to the patient encounter may include, for example, a ventilator 302C, an automated chest compressor 302A, and/or other medical devices.”). Examiner interpret the ventilator, automated chest compressor, or any other medical device to encompass at least a third device sharing information with the first medical device (mobile computing device).
generate a request for third patient data collected by the third device during the patient encounter; send the request for the third patient data to the third device based on the record-identifying information of the third device ([0157], “the patient encounter data source integration service 130 may not communicate directly with these data stores for security purposes. In certain implementations, the patient encounter data source integration service 130 is conversant in multiple data formats and is able to interact with components of the medical device 102 and the mobile computing device 104 via a public API which can serve as a gatekeeper to resources provided by such devices” [0158], “In such case, the patient encounter data source integration service 130 may send the case API 126 a request for information that is stored in the medical device case data store 132... Any of these requests may include appropriate security credentials.” [0063], “a server system executing an encounter data source integration service”); and
receive the third patient data from the third device after sending the request for the third patient data to the third device, wherein the record for the patient encounter is additionally generated based on the third patient data ([0158], “In such case, the patient encounter data source integration service 130 may send the case API 126 a request for information that is stored in the medical device case data store 132... Based on the security credentials, the case API 126, the ePCR API 128, and/or the event log API 144 may either grant or deny the request for information. If the respective interface grants the request for information, then the interface will retrieve the requested information from the appropriate data store.”).
Regarding claim 4, White teaches the server of claims 1 and 3. White further teaches wherein the record-identifying information of the second device was shared using a first decentralized network established between the first device and the second device ([0109], “In some examples, the defibrillator/monitor 1904 uses one or both of short-range and long-range communication to transfer medical data via the network 2102 to the remote computing devices 1914. Example short-range communication technologies include BLUETOOTH or WIFI while example long-range technologies include cellular communication.”), and
wherein the record-identifying information of the third device was shared using a second decentralized network established between the third device and at least one of the first device or the second device ([0127], “a small EMS agency that owns only one or a few medical devices, such as defibrillators, automated compression devices, ventilators, etc. and/or has only one or a few medical devices deployed simultaneously (e.g., for two concurrent emergencies or scheduled transports). In this case, the times may be sufficient to associate the medical device case files and the association information… if a long range communicative coupling such as WIFI or cellular is unavailable (e.g., in an interior space, a parking garage, an urban canyon, a remote location, etc.), the devices may only be able to communicate via a short range connection such as BLUETOOTH.” [0110], “the first server 2104 may be a centralized data server configured to receive medical data from a plurality of different medical devices operated by different hospital networks”). Examiner notes that [0035] of Applicant specification defines a decentralized network as “a WiFi Direct network, a Bluetooth network, etc.”
Regarding claim 5, White teaches the server of claims 1 and 3-4. White further teaches wherein the first decentralized network and the second decentralized network are based on a similar wireless protocol ([0105], “FIG. 20 illustrates another example medical environment 2000 that involves local personal area network (e.g., BLUETOOTH network) communication of patient data between one or more medical devices and the local computing device 1906, and also data communication with the remote computing devices 1914.” [0110], “the first server 2104 may be a centralized data server configured to receive medical data from a plurality of different medical devices operated by different hospital networks”).
Regarding claim 7, White teaches the server of claim 1. White further teaches wherein the first device corresponds to a medical device or a mobile device that is operable to collect patient data ([0076], “The healthcare providers 118A located at the scene of the patient encounter may further be using their respective mobile computing devices to generate other information, such as creating log entries of notable events through a documentation tool and/or entering in patient information via a charting tool for ePCR. Such records may also be uploaded along with the other medical device case files to the central repository of the server(s) 108.” [0073], “A portion or all of the information collected by the defibrillator/monitor 302B may be uploaded as it is acquired to one or more server(s) via a network (e.g., the server(s) 108 and network 112 of FIG. 1, continuously, regularly, and/or post-case), as medical device case files, which may be updated at periodic intervals.” [0063], “the healthcare provider may use his/her mobile computing device to acquire an identifier, or a representation thereof, of each of a plurality of medical devices used/located at the scene. The mobile device executing a patient encounter device association application may then associate each of the plurality of medical devices together using the identifying information, and transmit association information to a server system”). Examiner notes that the defibrillator/monitor is a medical device that corresponds to the first device, which the Examiner interprets to be a mobile computing device within the scope of White’s teachings, as the defibrillator/monitor is connected to and provides information to the mobile computing device.
Regarding claim 8, White teaches the server of claims 1 and 7. White further teaches wherein the medical device includes a defibrillator or a patient monitor ([0073], “A portion or all of the information collected by the defibrillator/monitor 302B may be uploaded as it is acquired to one or more server(s) via a network (e.g., the server(s) 108 and network 112 of FIG. 1, continuously, regularly, and/or post-case), as medical device case files, which may be updated at periodic intervals.”).
Regarding claim 9, White teaches the server of claim 1. White further teaches wherein the request for the second patient data is sent to the second device using a centralized network, and wherein the second patient data is received from the second device using the centralized network ([0154], “In some examples, the network 112 can include one or more communication networks through which the medical device 102, the mobile computing device 104, the remote computing device 106, and the server(s) 108 can send, receive, and/or exchange data. In various implementations, the network 112 can include a cellular communication network and/or a computer network. In some examples, the network 112 includes and supports wireless network and/or wired connections. For instance, in these examples, the network 112 may support one or more networking standards such as GSM, CMDA, USB, BLUETOOTH, CAN, ZigBee®, Wireless Ethernet, Ethernet, and TCP/IP, among others. The network 112 may include both private networks, such as local area networks, and public networks, such as the Internet.”). Examiner notes [0019] of Applicant specification defines a centralized network as “an Institute of Electrical and Electronics Engineers 802.11 (“WiFi”) network or a cellular network.”
Regarding claims 10 and 19, White further teaches a method and a non-transitory computer-readable medium comprising instructions that, when executed by a processor of a server, causes the processor to perform operations ([0028], “In at least one example, a non-transitory computer-readable storage medium is provided. The non-transitory computer-readable storage medium stores instructions configured to execute the computer implemented process described above.”).
Regarding claims 11, 12, 13, 14, 16, 17, 18, and 20, these claims are rejected for the same reasons as claims 2, 3, 4, 5, 7, 8, 9, and 7, respectively.
Claims 6 and 15 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by White (US 20210304881) as evidenced by Alhmiedat (Alhmiedat; Tareq, An improved decentralized approach for tracking multiple mobile targets through ZigBee WSNs, June 2013, International Journal of Wireless & Mobile Networks, Vol. 5, No. 3 (Year: 2013)).
Regarding claim 6, White teaches the server of claims 1 and 3-4. White further teaches wherein the first decentralized network is based on a first wireless protocol, and wherein the second decentralized network is based on a second wireless protocol that is different from the first wireless protocol ([0110], “the first server 2104 may be a centralized data server configured to receive medical data from a plurality of different medical devices operated by different hospital networks” [0277], “In some examples, the network 1912 includes and supports wireless network and/or wired connections. For instance, in these examples, the network 1912 may support one or more networking standards such as GSM, CMDA, USB, BLUETOOTH, CAN, ZigBee®, Wireless Ethernet, Ethernet, and TCP/IP, among others… However, in other examples, the network 1912 can involve only two endpoints that each have a network connection directly with the other.”). As White teaches different networks, which may utilize one or more wireless networking standards with no limitation on the different networks being required to use the same wireless protocol, Examiner interprets the teachings of White to encompass the claim limitation. Furthermore, ZigBee is another decentralized wireless networking protocol, as evidenced by Alhmiedat (pg. pg. 61, “Decentralized systems offer low power consumption when deployed to track a small number of mobile targets compared to the centralized tracking systems. However, in several applications, it is essential to position a large number of mobile targets. In such applications, decentralized systems offer high power consumption, since the location of each mobile target is required to be transmitted to a sink node, and this increases the power consumption for the whole WSN. In this paper, we propose a power efficient decentralized approach for tracking a large number of mobile targets while offering reasonable localization accuracy through ZigBee network.”).
Regarding claim 15, this claim is rejected for the same reasons as above as claim 6.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Automatic Patient to Medical Device Association (US 20240387038) teaches a patient management system for sharing patient data between and among devices. A first device of a patient management system may receive, from a second device, an indication of the presence of the second device. Based at least in part on sending a request for the patient identifier to a server for information related to the second device, the first device may receive the patient identifier. The first device may then receive, from a third device, a request for the patient identifier. Based on determining that the third device is within a threshold distance from the first device, the first device may send the patient identifier to the third device.
Controlled Data Access for Decentralized Clinical Trial Space (US 20250148125) teaches a system and method for controlling data access within a decentralized clinical trial space. In various embodiments of the present invention, a patient portal system may be interconnected with a clinical trial database, a patient device configured to access a patient portal application associated with the patient portal system, and an intermediary system having an intermediary database. Data transmitted from the patient device to the patient portal system may comprise obfuscated patient data. Such obfuscated patient data may be transmitted to the intermediary database which may be configured to access the identifying patient data from the obfuscated patient data through a private key stored therein. The patient portal system may enable a patient to perform a variety of functions relating to a clinical trial, such as ordering a sample collection kit, to be fulfilled by a supply system interconnected with the intermediary database.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAVID CHOI whose telephone number is (571)272-3931. The examiner can normally be reached M-Th: 8:30-5:30 ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shahid Merchant can be reached on (571)270-1360. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/D.C./Examiner, Art Unit 3684
/KAREN A HRANEK/Primary Examiner, Art Unit 3684
Prosecution Insights