Patent Application 18558520 - EDGE COMPUTING SYSTEM FOR LOCALLY PROCESSING

Title: EDGE COMPUTING SYSTEM FOR LOCALLY PROCESSING DATA IN A CLINICAL NETWORK
Application Information

Invention Title: EDGE COMPUTING SYSTEM FOR LOCALLY PROCESSING DATA IN A CLINICAL NETWORK
Application Number: 18558520
Submission Date: 2025-05-16T00:00:00.000Z
Effective Filing Date: 2023-11-01T00:00:00.000Z
Filing Date: 2023-11-01T00:00:00.000Z
National Class: 709
National Sub-Class: 217000
Examiner Employee Number: 84977
Art Unit: 2458
Tech Center: 2400
Rejection Summary

102 Rejections: 0
103 Rejections: 4
Cited Patents

The following patents were cited in the rejection:
Office Action Text



    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 .
DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), filed on 2/21/2025 in this application after final rejection.  Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114.  Applicant's submission filed on 2/21/2025 has been entered.  Claims 1 and 3-21 are pending.  
Response to Arguments
2.	Applicant's arguments have been fully considered but they are not persuasive. The applicant argues the following issues.
(A)	Rejection under 35 U.S.C. 112(a)
Issue 1: The applicant argues (on page 9) with respect to claim 3 that the claimed limitations are supported by the originally filed application because “the fact that the specification does not provide written description of the subject matter, simply that it does not provide in haec verba support”.
Examiner respectfully disagrees.  The originally filed application merely discloses combine the analytical data into the processed data, and  transmit the processed data to the monitoring device and/or to the remote central server device via the data connection. The analytical data can be, for example, received from the remote central server device, the first edge-node, the further first edge-node, or the computing resource.”  There is nowhere in the speciation that discloses combining analytical data from different sources together as recited by the claim language.  On the contrary to the Applicant’s assertation, the general statements do not support the specific limitations.
Issue 2: The applicant argues (on page 10, paragraph 1) with respect to claim 6 that the claimed limitations are supported by the originally filed application because the specification provides a general statement.
Examiner respectfully disagrees, because general statement do not support specified limitations. 
Issue 3: The applicant argues (on page 10, paragraph 3) with respect to claim 3 that the claimed limitations are definite, based on the similar argument presented for Issue 1 above.
Examiner respectfully disagrees. See Examiner’s response in Issue 1 above.
Issue 4: The applicant argues (on page 10, paragraph 4) with respect to claim 5 that the amended limitations overcome the current 112(b) rejection.
The respective 112(b) rejection to claim 5 has been withdrawn in light of the amended limitations.
Issue 5: The applicant argues (on page 11, paragraph 1) with respect to claim 6 that the claimed limitations are definite, based on the similar argument presented for Issue 2 above.
Examiner respectfully disagrees. See Examiner’s response in Issue 2 above.
Issue 6: The applicant argues (on page 11, paragraph 2) with respect to claim 15 that the amended limitations overcome the current 112(b) rejection.
The respective 112(b) rejection to claim 15 has been withdrawn in light of the amended limitations.
(B)	Rejection under 35 U.S.C. 103(a) 
Issue: The applicant argues (on page 12) with respect to independent claims such as claim 1 that  Talal in view of Sugla fails to teach the claimed limitations “The at least one first edge-node also includes a processing module configured to (i) aggregate raw data from the at least one medical care device, (ii) combine at least metadata and the analytical data with the aggregated raw data to generate processed data, and (iii) transmit the processed data to the monitoring device and/or to the remote central server device via the data connection.”.
Examiner respectfully disagrees.  AS explained in the rejection section below, Talall discloses at paragraphs 30, left column, "heart rate device to CHCS message format", with page 30, left column, second paragraph, "The device then reformats the Data as Colom separated value format (CSV) to prepare it to send to the Centralized Healthcare Server (CHCS). The message format below consists of six fields, the first four used to identify the heartrate reader device to the CHCS, and the last two fields are the patient ID and heart rate value"; page 30, “The device analyses the analog data if it is between 97 (36.1) to 99 (37.2) it considers that this is a normal situation and set the alarm state to (0) otherwise it set the alarms state to (1)”; page 31, “the glucose in blood concentration in a safe range between 54 mg/dL and 120 mg/dL… Our proposed simulated device lied under the above limits it tests the blood glucose if it is under the lower limit or above the upper limit it alarms the server that there is a critical health situation for this patient”. 
As explained in the rejection section, the limits/thresholds are analytical data that is combined with metadata (Patient ID) and raw data by using the limits/thresholds (analytical data) to compare/filter the raw data of the patient to generate processed data to notify the server. 
It is to be noted that the claim limitation does not require a specific way to combine the analytical data with metadata and raw data, nor does the claim require that the generated processed data contains the analytical data. As cited and explained, the thresholds (analytical data) are combined with the aggregated raw data for the specific patient (indicated by patient ID) to generate processed data indicating whether normal situations for the patent.
Claim Rejections - 35 USC § 112
3.	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.

4.	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.

5.	Claim 3 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA  35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 3 recites “combine, in (ii), the analytical data from the computing resource and the analytical data from at least one of the remote central server device and the monitoring device with the aggregate raw data and the metadata into the processed data” which is not supported by the originally filed application. The originally filed application only discloses combining analytic data received from one source with the aggregate raw data and metadata data, without disclosing combining analytic data from multiple sources together with the aggregate raw data and meta data.  All new matters shall be deleted from the claim.  
6.	Claim 6 recites “combine the analytical data from the at least one first edge-node and from the at least one of the remote central server device and the monitoring device with the processed data to generate further processed data” which is not supported by the originally filed application. The originally filed application only discloses combining analytic data received from one source with the aggregate raw data and metadata data, without disclosing combining analytic data from multiple sources together with the aggregate raw data and meta data.  All new matters shall be deleted from the claim.
7.	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.

8.	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.

9.	Claims 3, 5-9 and 15 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.
a) Claim 3 recites “combine, in (ii), the analytical data from the computing resource and the analytical data from at least one of the remote central server device and the monitoring device with the aggregate raw data and the metadata into the processed data” which is inconsistent with the disclosure of the specification.  The specification discloses that analytical data from either the computing resource or the analytical data from at least one of the remote central server device and the monitoring device, but not both, are combined with the aggregated raw data and meta data.  Due to the inconsistency, the scope of this claim cannot be definitively determined.  Applicant is required to clarify.  For the sake of the examination, Examiner interprets in light of the specification that either analytical data from either the computing resource or the analytical data from at least one of the remote central server device and the monitoring device, but not both, are combined with the aggregated raw data and meta data.  
b) Claim 6 recites “combine the analytical data from the at least one first edge-node and from the at least one of the remote central server device and the monitoring device with the processed data to generate further processed data” which is inconsistent with the disclosure of the specification.  The specification discloses that analytical data from either the computing resource or the analytical data from at least one of the remote central server device and the monitoring device, but not both, are combined with the aggregated raw data and meta data.  Due to the inconsistency, the scope of this claim cannot be definitively determined.  Applicant is required to clarify.  For the sake of the examination, Examiner interprets in light of the specification that either analytical data from either the computing resource or the analytical data from at least one of the remote central server device and the monitoring device, but not both, are combined with the aggregated raw data and meta data to generate the processed data, and that the further processed data are the processed data. 
Claim Rejections - 35 USC § 103
10.	In the event the determination of the status of the application as subject to AIA  35 U.S.C. 102 and 103 (or as subject to pre-AIA  35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.  
11.	The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains.  Patentability shall not be negated by the manner in which the invention was made.

12.	The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
13.	Claims 1, 3-6, 8-9, 11-12, 14-16, 18-19 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Talal (“IoT/IoE Smart Health Care System using Fog Computing Features”, submitted by IDS) in view of Sugla et al (US 2016/0228050).
As to claim 1, Talal discloses an edge computing system for locally processing data in a clinical network administered by a remote central server device (page 29, "Ill. The proposed health care system architecture" section, Fig. 1), comprising:
at least one medical care device (Fig. 1; page 29, right column "A. The loT Layer: It is the bottommost layer that encompasses smart mobile or fixed end-users' objects such as sensors placed on the patient's body to collect the patient's vitals”), 
at least one first edge-node (any one out of the four examples, i.e., page 29, right column, last paragraph, "Heart rate recorder"; page 30, “Body Temperature Meter”, “Peripheral oxygen saturation meter (SO2)”; page 31, “Blood Sugar meter”), and 
a monitoring device assigned to the at least one medical care device (Fig. 10, "doctor phone”), the at least one first edge-node comprising:
a connection interface configured to establish a data connection with the at least one medical care device, and with at least one of the remote central server device and the monitoring device (page 30, left column, paragraph 1, “The analog input reads the heart rate from the patient”; second paragraph, "The Heart rate device uses the wireless interface to send the produced message to the CHCS (Centralized Health Server)", also see Fig. 2, "analog input", "digital input slot” and page 30, left col, wherein it is disclosed that the heart rate recorder read data from sensors. See also page 31, left column, “these values are analyzed and then sent as an accumulated message to the CHCS wirelessly… if it is under the lower limit or above the upper limit it alarms the server that there is a critical health situation for this patient”); and
a processing module configured to:
(i) aggregate raw data from the at least one medical care device (page 30, left column, first paragraph, "The analog input reads the heart rate from the patient"; page 29, right col. “analyses the raw data locally for immediate alarm displayed on the monitor and reformats the data in CSV format to be appropriate for transmission”),
(ii) combine at least metadata and analytical data with the aggregated raw data to generate processed data (p. 30, left column, "heart rate device to CHCS message format", with page 30, left column, second paragraph, "The device then reformats the Data as Colom separated value format (CSV) to prepare it to send to the Centralized Healthcare Server (CHCS). The message format below consists of six fields, the first four used to identify the heartrate reader device to the CHCS, and the last two fields are the patient ID and heart rate value"; page 30, “The device analyses the analog data if it is between 97 (36.1) to 99 (37.2) it considers that this is a normal situation and set the alarm state to (0) otherwise it set the alarms state to (1)”; page 31, “the glucose in blood concentration in a safe range between 54 mg/dL and 120 mg/dL… Our proposed simulated device lied under the above limits it tests the blood glucose if it is under the lower limit or above the upper limit it alarms the server that there is a critical health situation for this patient”. Here, the limits/thresholds are analytical data that is combined with metadata (Patient ID) and raw data by using the limits/thresholds (analytical data) to compare/filter the raw data of the patient to generate processed data to notify the server. It is to be noted that the claim limitation does not require a specific way to combine the analytical data with metadata and raw data, nor does the claim require that the generated processed data contains the analytical data), and
(iii) transmit the processed data to the monitoring device and/or to the remote central server device via the data connection (page 30, left column, second paragraph, "The device then reformats the Data as Colom separated value format (CSV) to prepare it to send to the Centralized Healthcare Server (CHCS)”)” and page 31, the Clustered Healthcare Control Server” fog node transmits the processed to the monitoring device).
	However, Talal does not expressly disclose retrieving analytical data (thresholds) from at
least one of the remote central server device and the monitoring device.  Sugla discloses a concept of retrieving analytical data (threshold setting) from at least one of a remote central server device and a monitoring device ([0070], “The local controller 318 is designed to work with the Analytics Engine 113 and can download and store threshold settings that can be used to generate local notifications and improve response times”; [0052], “The Alerts and Notifications module 209 is a repository of alert thresholds and actions that have been recommended by the Analytics Engine 113 but which may be superseded by the Caregiver 108 via User Interface module 206”).
	Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Talal with Sugla.  The suggestion/motivation of the combination would have been to enable the local controller to send notifications according to the threshold setting preferred by the Caregiver (Sugla, [0070]; [0052]).
As to claim 14, see similar rejection to claim 1.
As to claim 3, Talal- Sugla discloses the edge computing system of claim 1, further comprising a computing resource, wherein the connection interface is further configured to establish a data connection with the computing resource, and to retrieve analytical data from the computing resource, and the processing module is configured to combine in (ii), the analytical data combine, in (ii), the analytical data from the computing resource and the analytical data from at least one of the remote central server device and the monitoring device with the aggregate raw data and the metadata into the processed data  (see 112 rejection and Examiner’s interpretation there.  See citation in rejection to claim 1, e.g., . Talal, page 30, left column, "heart rate device to CHCS message format", with page 30, left column, second paragraph, "The device then reformats the Data as Colom separated value format (CSV) to prepare it to send to the Centralized Healthcare Server (CHCS). The message format below consists of six fields, the first four used to identify the heartrate reader device to the CHCS, and the last two fields are the patient ID and heart rate value".  See also page 31, wherein the Clustered Healthcare Control Server” fog node combines thresholds (analytical data) with metadata (Patient ID) and raw data) by using the thresholds (analytical data) to process/filter the raw data that corresponds to the patient ID to generate processed data to notify the doctor. It is to be noted that the claim limitation does not require a specific way to combine the analytical data with metadata and raw data, nor does not require that the generated processed data contains the analytical data.  See Sugla, [0070], “The local controller 318 is designed to work with the Analytics Engine 113 and can download and store threshold settings that can be used to generate local notifications and improve response times”; [0052], “The Alerts and Notifications module 209 is a repository of alert thresholds and actions that have been recommended by the Analytics Engine 113 but which may be superseded by the Caregiver 108 via User Interface module 206”, wherein the repository of alert thresholds is a computer resource).
As to claim 4, Talal-Sugla discloses the edge computing system of claim 1, further comprising a further first edge-node, wherein the connection interface of the at least one first edge-node is further configured to establish a data connection with the further first edge-node, wherein the further first edge-node is in communication with at least one further medical care device (Talal, page 29, right col, multiple sensors; pages 29-31, another one in the set of Heart rate recorder, Blood sugar meter, etc..), and wherein the processing module of the at least one first edge-node is further configured to transmit the processed data to the further first edge-node (See Talal, page 29, right column, "A. The loT layer[ ... ] Components from this layer communicate with other elements in the same layer using the above layer as well as to connect with loT services implemented in both network and Cloud layers”).
As to claim 5, Talal-Sugla discloses the edge computing system of claim 1, further comprising at least a second edge-node (page 31, right column, “It also contains the Fog Nodes (FN) which sresponsible for making real-time smart decisions by using the data achieved by sensors to change the status of the actuators…we name the FN that responsible for collecting the data from medical devices as Cluster Health Control Server (CHCS)”), comprising:
a connection interface configured to establish a data connection with the at least one first edge-node, and with at least one of the remote central server device and the monitoring device (Talal, page 29, right column, "A. The loT layer[ ... ] Components from this layer communicate with other elements in the same layer using the above layer as well as to connect with loT services implemented in both network and Cloud layers”), and
a processing module configured to (i) receive the processed data from the at least one first edge-node or (ii) receive the processed data from the at least one first edge-node and then transmit the processed data received from the at least one first edge-node (Talal, pages 29-31,wherein the CFog Nodes (FN) names as the Cluster Healthcare Control Server (CHCS) receives processed data from a first edge node such as a Heart Rate Recorder, a Body temperature meter, a Peripheral oxygen saturation meter, or a Blood sugar meter).
As to claim 6, Talal-Sugla discloses the edge computing system of claim 5, wherein the connection interface of the second edge-node is further configured to:
receive analytical data from the at least one first edge-node and from at least one of the remote central server device and the monitoring device (Talal, pages 29-31, wherein the processed data received by the CHCS from the first edge node (e.g., Blood sugar meter) contains alarm status reflecting limits/thresholds which are analytical data.  See Sugla, [0070], “The local controller 318 is designed to work with the Analytics Engine 113 and can download and store threshold settings that can be used to generate local notifications and improve response times”; [0052], “The Alerts and Notifications module 209 is a repository of alert thresholds and actions that have been recommended by the Analytics Engine 113 but which may be superseded by the Caregiver 108 via User Interface module 206”); and 
the processing module of the second edge-node is further configured to:
combine the analytical data from the at least one first edge-node and from the at least one of the remote central server device and the monitoring device with the processed data to generate further processed data (see 112 rejection and Examiner’s interpretation therein.  See Talal, page 29, right column, "A. The loT layer[ ... ] Components from this layer communicate with other elements in the same layer using the above layer as well as to connect with loT services implemented in both network and Cloud layers”; see page 31, wherein the Clustered Healthcare Control Server” fog node combines thresholds (analytical data) with metadata (Patient ID) and raw data by using the thresholds (analytical data) to process/filter the received message (raw data) that corresponds to the patient ID (metadata) to generate further processed data to notify the doctor. It is to be noted that the claim limitation does not require a specific way to combine the analytical data with metadata and raw data, nor does the claim require that the generated processed data contains the analytical data; See Sugla, [0070], “The local controller 318 is designed to work with the Analytics Engine 113 and can download and store threshold settings that can be used to generate local notifications and improve response times”; [0052], “The Alerts and Notifications module 209 is a repository of alert thresholds and actions that have been recommended by the Analytics Engine 113 but which may be superseded by the Caregiver 108 via User Interface module 206”); and
transmit the further processed data to the monitoring device and/or to the remote central server device via the data connection (see 112 rejection and Examiner’s interpretation therein regarding “further processed data”.  See Talal, page 31, the CHCS sends the processed data to the doctor).
As to claim 8, Talal-Sugla discloses the edge computing system of claim 5, wherein at least one third or higher level edge-node, is arranged between the second edge-node and the remote central server device (Talal, Page 29, right column, "A. The loT layer[ ... ] Components from this layer communicate with other elements in the same layer using the above layer as well as to connect with loT services implemented in both network and Cloud layers”; page 32, “The second functionality of the CHCS is to export the data to the Centralized Fog Server”; page29, “switches and routers”).
As to claim 9, Talal-Sugla discloses the edge computing system of claim 8, wherein the at least one third edge-node is assigned to a hospital building and/or to a hospital (Talal, page 29, left column, “implemented over two locations: Site 'A' located at the patient's home and site 'B' located at the smart hospital”).
As to claim 11, Talal-Sugla discloses the edge computing system of claim 1, wherein the at least one medical care device is at least one of an infusion device and a patient monitoring device (Talal, page 29 and 30, heart rate recorder is a heart rate monitoring device).
As to claim 12, Talal-Sugla discloses the edge computing system of claim 1, wherein the connection interface of the at least one first edge-node is configured to connect to the at least one medical care device via a wireless connection (Talal, page 30, right column, “The SPO2 is a small device that clips to the body (typically a finger) and transfers its readings to a reading meter by wire or wirelessly.”).
As to claim 15, Talal-Sugla discloses the method of claim 14, further comprising:
(i) receiving the processed data from the at least one first edge-node or (ii) receiving and sending the processed data received from the at least one first edge-node (Talal, page 29, right column, "A. The loT layer[ ... ] Components from this layer communicate with other elements in the same layer using the above layer as well as to connect with loT services implemented in both network and Cloud layers.  See Sugla, [0070], “The local controller 318 is designed to work with the Analytics Engine 113 and can download and store threshold settings that can be used to generate local notifications and improve response times”; [0052], “The Alerts and Notifications module 209 is a repository of alert thresholds and actions that have been recommended by the Analytics Engine 113 but which may be superseded by the Caregiver 108 via User Interface module 206”).
As to claim 16, Talal-Sugla discloses the method of claim 14, further comprising:
sending the processed data to at least one second edge-node, and establishing the second edge-node a data connection with at least one of a further first edge-node, the remote central server device and the monitoring device (See Talal, page 29, right column, "A. The loT layer[ ... ] Components from this layer communicate with other elements in the same layer using the above layer as well as to connect with loT services implemented in both network and Cloud layers”; Talal, pages 29-31, wherein the processed data are sent from the first edge node (e.g., Blood sugar meter) to the CHCS, wherein the CHCS further processes and connect to the monitoring device/doctor).
As to claim 18, Talal-Sugla discloses the edge computing system of claim 3, wherein the computing resource comprises a software library (See Sugla, [0070], “The local controller 318 is designed to work with the Analytics Engine 113 and can download and store threshold settings that can be used to generate local notifications and improve response times”; [0052], “The Alerts and Notifications module 209 is a repository of alert thresholds and actions that have been recommended by the Analytics Engine 113 but which may be superseded by the Caregiver 108 via User Interface module 206”, wherein the repository of alert thresholds is a software library).
As to claim 19, Talal-Sugla discloses the edge computing system of claim 8, wherein the at least one third edge-node comprises a plurality of further higher level edge nodes (Talal, Page 29, right column, "A. The loT layer[ ... ] Components from this layer communicate with other elements in the same layer using the above layer as well as to connect with loT services implemented in both network and Cloud layers”; page 32, “The second functionality of the CHCS is to export the data to the Centralized Fog Server”; page29, “switches and routers”).

14.	Claims 7, 10, 13 are rejected under 35 U.S.C. 103 as being unpatentable over Talal-Sugla, as applied to claim above, and further in view of Amir et al (“Exploiting smart e-Health gateways at the edge of healthcare Internet-of-Things: A fog computing approach”, submitted by IDS).
As to claim 7, Talal-Sugla discloses the edge computing system of claim 5, wherein the first edge-node is assigned to a patient (Talal, page 29, left column, “implemented over two locations: Site 'A' located at the patient's home and site 'B' located at the smart hospital”), and the second edge-node is assigned to a hospital (page 29, left column, “implemented over two locations: Site 'A' located at the patient's home and site 'B' located at the smart hospital”), or the first edge-node is assigned to a hospital patient-room, and the second edge-node is assigned to a hospital ward, but does not expressly disclose that the second location at the smart hospital is a patent-room.  Amir discloses the concept of a second location for patient monitoring being a patient-room at a hospital (figure 3; page 644).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Talal-Sugla with Amir. The suggestion/motivation of the combination would have been to record environmental signals at the room (Amir, page 653, left col, last two paragraphs).
As to claim 10, Talal-Sugla-Amir discloses the edge computing system of claim 4, wherein the at least one medical care device is configured to disconnect the data connection with the at least one first edge-node when moving out of a range of the at least one first edge-node and to establish a data connection with the further first edge-node when moving into a range of the further first edge-node (Amir, figure 5, “Node mobility in fog computing”, wherein different gateways correspond to covered areas).
As to claim 13, Talal-Sugla-Amir discloses the edge computing system of claim 5, wherein the connection interface of the at least one first edge-node and/or of the at least one second edge-node is configured to be operable with a communications network according to EN ISO 11073, and/or according to a Fast Healthcare Interoperability Resources (FHIR) standard, and/or a Health Level Seven (HL7) standard (Amir, page 647, left column, "In addition to network level protocols, medical data is formatted in a specific format. Data in any of the Electronic Health Record (EHR) standards, such as HL7”).
15.	Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Talal-Sugla, as applied to claim 12 above, and further in view of Hull (US 2005/0113655).
As to claim 20, Talal-Sugla discloses the claimed invention substantially as discussed in claim 12, but does not expressly disclose that the wireless connection is a Wireless LAN connection.  Hull discloses that the wireless connection is a Wireless Lan connection ([0022]; figures 1-2).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Talal-Sugla with Hull.  The suggestion/motivation would have been to utilize known protocol such as Wireless Lan to collect/transmit medical data (Hull, [0022]; figures 1-2).
15.	Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Talal-Sugla, as applied to claim 4 above, and further in view of Tkaczyk-Walczak et al (US 2019/0227880).
As to claim 21, Talal-Sugla discloses the edge computing system of claim 4, wherein the further first edge node comprises a processing module configured to (i) aggregate raw data from the at least one further medical care device and (ii) combine at least metadata with the aggregated raw data from the at least one further medical care device to generate processed data (see citation and rejection to claim 1, e.g., Talal, pages 29-31, wherein another one of the set of edge nodes, such as Blood Sugar meter, or Peripheral oxygen saturation meter, etc. has the similar functionality as explained in the rejection to claim 1, that performs the function of aggregate raw data from the at least one further medical care device (i.e., the respective sensors) and combine at least metadata with the aggregated raw data from the at least one further medical care device (the respective sensors) to generate processed data), and wherein the processing module of the at least one first edge-node is further configured to communicate with the further first edge-node (Talal, Page 29, right column, "A. The loT layer[ ... ] Components from this layer communicate with other elements in the same layer using the above layer as well as to connect with loT services implemented in both network and Cloud layers”).
However, Talal dies not expressly disclose that communicating with other elements in the same layer comprises receiving the processed data. Tkaczyk-Walczak discloses a concept of sharing data between peer devices ([0049], “The third GPS device 102″ again comprises a heart rate monitor or HRM. The sensor devices 102, 102′, 102″ exchange data in a peer-to-peer fashion as is illustrated in FIG. 1.”).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Talal-Sugla with Tkaczyk-Walc
zak.  The suggestion/motivation would have been to share data between peers (Tkaczyk-Walczak, [0049]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUA FAN whose telephone number is (571)270-5311.  The examiner can normally be reached on 9-6.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Umar Cheema can be reached at 571-270-3037.  The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system.  Status information for published applications may be obtained from either Private PAIR or Public PAIR.  Status information for unpublished applications is available through Private PAIR only.  For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.




/HUA FAN/Primary Examiner, Art Unit 2458