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
This office action is in response to amendment/reconsideration filed 8/18/2025, the amendment/reconsideration has been considered. Claims 1, 3-16 and 18-22 are pending for examination, the rejection cited as stated below.
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: The applicant that the amended claims overcome the outstanding 112 rejections to the previous set of claims.
Examiner agrees that the amended claims overcome the outstanding 112 rejections to the previous set of claim, which have been withdrawn. However, the arguments are moot in light of the new ground of rejections set forth to the newly submitted claim 22.
(B) Rejection under 35 U.S.C. 103(a)
Issue: The applicant argues (on pages 10-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 and in the Examiner’s response in the previous office action, 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”.
Here, the limits/thresholds are equivalent to 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.
Applicant argues that the recited “analytical data” shall be interpreted using the disclosed scope in the specification.
In particular, Applicant (on pages 11-12) states that “the application discloses, at page 4, lines 13-16, the claim subject matter allows for the network and the data management to be segmented and partitioned. Different data processing can occur in different network locations. The result is a system that processes and forwards data more efficiently. In this system, it is not necessary to have a given node manage raw data and metadata, and also to generate analytical data. As explained at page 4, lines 26-29, analytical data is used in this application to refer to data that has been obtained previously from aggregated raw data and metadata and/or which has been extracted from larger amounts of data, such as previous aggregated raw data and metadata using algorithms. 1 Thus, the node may be configured to aggregate raw data from the at least one medical care device, but there is no need to analyze the aggregated raw data at the node because analytical data may be retrieved from another source. At the same time, the analytical data is not devoid of a relationship to the aggregated raw data and the metadata recited in the claim. That is, the analytical data has been obtained from the aggregated raw data and the metadata and/or extracted from larger amounts of data, such as by using algorithms. As such, the analytical data is not simply any data that has been analyzed, but is related to the data of the at least one medical care device that is transmitted through the system.”
Based on the above statement, Applicant further argues that “In this context, it is not clear why one of ordinary skill would configure Talal to retrieve analytical data in the first instance. That is, the allegedly corresponding device of Talal allegedly performs the aggregation step and the analysis. See for example, the argument at the middle of page 4 or page 9 of the May 16 Office Action. There is no motivation or suggestion to one of ordinary skill to obtain analytical data of any form from another source, let alone analytical data that is related to the aggregated raw data and metadata, such as previous aggregated data and metadata. That is, the allegedly corresponding device performs all of the allegedly corresponding actions, and then simply reports its results to a server”
Examiner respectfully disagrees, because the Applicant-cited disclosure does not contain a controlling definition for the claimed “analytical data” therefore the scope of the claimed term cannot be limited to the scope as exemplified in the specification.
As to Applicant’s argument “why one of ordinary skilled would configure Talal to retrieve analytical data in the first instance”, please see Examiner’s obviousness analysis in the rejection section. Specifically, 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 Examiner cited and explained in the rejection section and response to Applicant’s arguments in the previous action, the limits/thresholds are equivalent to analytical data that are combined with metadata (Patient ID) and raw data.
Applicant further argues (on page 12) that “Nor is it clear why the "limits/thresholds" are the allegedly corresponding analytical data. The analysis discussed in Talal relied upon in the May 16 Office Action regards to the comparison of allegedly corresponding aggregated raw data with the "limits/thresholds." It would appear instead that the results of the comparison are the allegedly corresponding analytical data because it is not at all clear how the limits and thresholds were derived or obtained from the allegedly corresponding aggregated raw data”.
Examiner respectfully disagree, because the claim does not require that the analytical data be a result of combining with the raw data at all. Instead, the claim recites “to retrieve analytical data… and…combine at least metadata and the analytical data with the aggregated raw data to generate processed data”.
Claim Rejections - 35 USC § 112
3. 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.
4. 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.
5. Claim 22 is 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. Claim 22 recites “the edge computing system of claim 1, wherein analytical data is data that has been obtained previously from aggregated raw data and metadata and/or which has been extracted from previously aggregated raw data and metadata using algorithms.”
First of all, it is unclear whether the recited “analytical data” refers to the same analytical data as recited in the parent claim 1, i.e., the analytical data retrieved from at least one of the remote central server device and the monitoring device, and combined together with metadata with the aggregated raw data to generate processed data to be transmitted to the monitoring device and/or to the remote central server device via the data connection, as recited in claim 1 , or instead refers to other analytical data. Applicant is required to clarify. For the sake of the examination, Examiner assumes any analytical data.
Secondly, it is unclear whether the recited “analytical data” is plurality pieces of data or single piece of datum, since the claim recites “analytical data is….” Applicant is required to clarify. For the sake of the examination, Examiner assumes either.
Thirdly, it is unclear whether the recited “aggregated raw data” refers to the same type of aggregated raw data as recited in the parent claim 1, i.e., by aggregating raw data from the at least one medical care device, or another type of aggregated raw data. Applicant is required to clarify. For the sake of the examination, Examiner assumes any type of aggregated raw data.
Fourthly, it is unclear whether the recited “metadata” refers to same type of meta data as recited in the parent claim 1, or another type of metadata. Applicant is required to clarify. For the sake of the examination, Examiner assumes any type of meta data.
Claim Rejections - 35 USC § 103
6. 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.
7. 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.
8. 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.
9. 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 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 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”).
10. 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”).
11. 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).
12. 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-Walczak. The suggestion/motivation would have been to share data between peers (Tkaczyk-Walczak, [0049]).
13. Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Talal-Sugla, as applied to claim 1 above, and further in view of Funk (US 2021/0389735).
As to claim 22. Talal-Sugla discloses the claimed invention substantially as discussed in claim 1, but does not expressly disclose wherein analytical data is data that has been obtained previously from aggregated raw data and metadata and/or which has been extracted from previously aggregated raw data and metadata using algorithms (see 112 rejection and Examiner’s interpretation therein). Funk discloses a concept for analytical data to be data that has been obtained previously from aggregated raw data and metadata ([0061]).
Before the effecvtive filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Talal-Sugla with Fund. The suggestion/motivation would have been to utilizing an initial user fitness profile (Funk, [0061]).
Conclusion
14. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUA FAN whose telephone number is (571)270-5311. The examiner can normally be reached on 9-6.
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, 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