DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
2. Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Continued Examination Under 37 CFR 1.114
3. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed 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 03/17/2026 has been entered.
Response to Amendment
4. Receipt of Applicant’s Amendment filed on 03/17/2026 is acknowledged. The amendment includes the amending of claims 1, 15, and 18, and the cancellation of claim 10.
Information Disclosure Statement
5. The information disclosure statement (IDS) submitted on 03/17/2026 has been received, entered into the record, and considered. The submission 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
6. 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.
7. 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.
8. Claim 11 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.
Specifically, claim 11 depends on cancelled claim 10.
Claim Rejections - 35 USC § 103
9. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
10. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
11. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
12. Claims 15 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Nath et al. (U.S. PGPUB 2008/0247313), in view of Bone et al. (U.S. PGPUB 2016/0232116), and further in view of Bhaya et al. (U.S. PGPUB 2018/0191596), and further in view of Mangan et al. (U.S. PGPUB 2016/0154864).
13. Regarding claim 15, Nath teaches a system comprising:
A) a memory store having memory locations (Paragraphs 27, 30, and 33, Figure 1);
B) wherein each memory location stores values of one or more attributes associated with one or more devices (Paragraphs 27, 30, and 33, Figure 1);
D) wherein the device attributes comprise at least a first attribute (Paragraphs 30 and 35);
E) the first attribute having an expiry time or duration (Abstract, Paragraphs 30, 32, and 35);
G) a device manager configured to: receive requests for the value of the first attribute of a first device (Paragraphs 30-31 and 35-36); and
H) if the stored value of the first attribute has expired then receiving the value of the first attribute from the first device and providing the received value of the first attribute in response to the request (Paragraphs 35 and 36);
J) further wherein the device attributes further comprise a second attribute (Paragraphs 27, 30, and 33, Figure 1).
The examiner notes that Nath teaches “a memory store having memory locations” as “The queries contain requests for sensor data from sensors in distributed sensor networks. The server 102 processes the queries by employing a sensor index maintained locally or on a remote storage device 108 that is accessible over the network 106. After processing, the server 102 returns results to the client devices 104” (Paragraph 27), “The UI 116 allows users to specify spatial regions and a particular expiry time to identify a collection of sensors from which they wish to receive readings expiring after the particular expiry time. The sensors may be of any type including, for example, temperature sensors, video cameras, humidity sensors, wind sensors, traffic sensors, parking sensors, security sensors, and so on. In FIG. 1, representative sensors include a temperature sensor 118-1, a camera 118-2, a video camera 118-3, and any other sensors 118-4 (collectively referred to as sensors 118)” (Paragraph 30), and “The database 122 stores an index of the sensors, and the index maintains metadata describing the attributes of the sensors and cached sensor readings. The server 102 has an indexing module 124 stored in the system memory 112 and executable on the processor(s) 110 to create such index structures. In one implementation, the index is structured as a data tree having plural nodes arranged in layers. The plural nodes include leaf nodes coupled with the sensors to collect and store sensor readings and their respective expiry times. The plural nodes also include non-leaf nodes or internal nodes that have caches for caching the sensor data. The caches have multiple cache slots for storing sensor data having different expiry time and cache slots analogous to each other in various layers have similar expiry time. The sensor data cached in a cache slot at a non-leaf node at a layer may be obtained by aggregating corresponding sensor data stored at a preceding layer. The corresponding sensor data can be sensor data stored in corresponding cache slots of internal nodes and/or sensor data stored with leaf nodes at the preceding layer” (Paragraph 33). The examiner further notes that sensor data from various sensors is stored in system memory 112 locally at server 102 or at a remote data store 108. Such stored sensor data is stored at multiple memory locations (such as the example cache slots). The examiner further notes that Nath teaches “wherein each memory location stores values of one or more attributes associated with one or more devices” as “The queries contain requests for sensor data from sensors in distributed sensor networks. The server 102 processes the queries by employing a sensor index maintained locally or on a remote storage device 108 that is accessible over the network 106. After processing, the server 102 returns results to the client devices 104” (Paragraph 27), “The UI 116 allows users to specify spatial regions and a particular expiry time to identify a collection of sensors from which they wish to receive readings expiring after the particular expiry time. The sensors may be of any type including, for example, temperature sensors, video cameras, humidity sensors, wind sensors, traffic sensors, parking sensors, security sensors, and so on. In FIG. 1, representative sensors include a temperature sensor 118-1, a camera 118-2, a video camera 118-3, and any other sensors 118-4 (collectively referred to as sensors 118)” (Paragraph 30), and “The database 122 stores an index of the sensors, and the index maintains metadata describing the attributes of the sensors and cached sensor readings. The server 102 has an indexing module 124 stored in the system memory 112 and executable on the processor(s) 110 to create such index structures. In one implementation, the index is structured as a data tree having plural nodes arranged in layers. The plural nodes include leaf nodes coupled with the sensors to collect and store sensor readings and their respective expiry times. The plural nodes also include non-leaf nodes or internal nodes that have caches for caching the sensor data. The caches have multiple cache slots for storing sensor data having different expiry time and cache slots analogous to each other in various layers have similar expiry time. The sensor data cached in a cache slot at a non-leaf node at a layer may be obtained by aggregating corresponding sensor data stored at a preceding layer. The corresponding sensor data can be sensor data stored in corresponding cache slots of internal nodes and/or sensor data stored with leaf nodes at the preceding layer” (Paragraph 33). The examiner further notes that sensor data (i.e. the claimed one or more attributes) from various sensors (i.e. the claimed one or more devices) is stored in system memory 112 locally at server 102 or at a remote data store 108. Such stored sensor data is stored at multiple memory locations (such as the example cache slots). The examiner further notes that Nath teaches “wherein the device attributes comprise at least a first attribute” as “The UI 116 allows users to specify spatial regions and a particular expiry time to identify a collection of sensors from which they wish to receive readings expiring after the particular expiry time. The sensors may be of any type including, for example, temperature sensors, video cameras, humidity sensors, wind sensors, traffic sensors, parking sensors, security sensors, and so on. In FIG. 1, representative sensors include a temperature sensor 118-1, a camera 118-2, a video camera 118-3, and any other sensors 118-4 (collectively referred to as sensors 118)” (Paragraph 30), and “Suppose a user at the client device 104-1 wants to know a recent temperature at a specific geographic location. The user submits a query for the recent temperature at the target location along with a time constraint, such as a specified expiry time for the recent temperature, using the UI 116 rendered on the client device 104-1” (Paragraph 35). The examiner further notes that sensor data (such as temperature data) from sensors 118 teach the claimed at least a first attribute. The examiner further notes that Nath teaches “the first attribute having an expiry time or duration” as “Techniques for collecting and displaying sensor data captured by a spatially and temporally representative sample of sensors requested in a search query are described. The sensors are represented in an index structure (e.g., a data tree) having a plurality of leaf nodes and internal nodes. The leaf nodes are associated with sensors and the internal nodes are allotted with caches having cache slots for storing sensor data with various expiry times” (Abstract), “The UI 116 allows users to specify spatial regions and a particular expiry time to identify a collection of sensors from which they wish to receive readings expiring after the particular expiry time. The sensors may be of any type including, for example, temperature sensors, video cameras, humidity sensors, wind sensors, traffic sensors, parking sensors, security sensors, and so on. In FIG. 1, representative sensors include a temperature sensor 118-1, a camera 118-2, a video camera 118-3, and any other sensors 118-4 (collectively referred to as sensors 118)” (Paragraph 30), “information regarding the expiry time of sensor data collected by the sensors may be stored in a database 122, which is illustrated as being stored in the remote storage device 108 (although it may be stored in other locations, such as within the system memory 112)” (Paragraph 32), and “Suppose a user at the client device 104-1 wants to know a recent temperature at a specific geographic location. The user submits a query for the recent temperature at the target location along with a time constraint, such as a specified expiry time for the recent temperature, using the UI 116 rendered on the client device 104-1” (Paragraph 35). The examiner further notes that sensor data (such as temperature data) from sensors 118 include stored expiry times that teaches the claimed expiry time. The examiner further notes that Nath teaches “a device manager configured to: receive requests for the value of the first attribute of a first device” as “The UI 116 allows users to specify spatial regions and a particular expiry time to identify a collection of sensors from which they wish to receive readings expiring after the particular expiry time. The sensors may be of any type including, for example, temperature sensors, video cameras, humidity sensors, wind sensors, traffic sensors, parking sensors, security sensors, and so on. In FIG. 1, representative sensors include a temperature sensor 118-1, a camera 118-2, a video camera 118-3, and any other sensors 118-4 (collectively referred to as sensors 118)” (Paragraph 30), “Upon receiving a query submitted by the client device 104, the server 102 analyzes and translates the query into a sequence of declarative queries that may be used to identify a set of sensors that can contribute to the sensor data requested by the user. The server 102 implements a query processing module 120, which is stored in the system memory 112 and executed by the processor(s) 110. To aid in identifying the appropriate set of sensors to respond to the user's query, the query processing module 120 discovers attributes of the set of sensors. The attributes may include, for example, sensor location in terms of latitude and longitude, type of sensor, schemas for sensor readings, expiry times of sensor readings, and so on” (Paragraph 31), “Suppose a user at the client device 104-1 wants to know a recent temperature at a specific geographic location. The user submits a query for the recent temperature at the target location along with a time constraint, such as a specified expiry time for the recent temperature, using the UI 116 rendered on the client device 104-1” (Paragraph 35), and “The server 102 receives the query and the query processing module 120 examines the query to determine the latitude and longitude of the target location. Subsequent to examination, the query processing module 120 reviews the data tree stored in the database 122 to identify a set of sensors having latitudes and longitudes within the target location and capable of providing sensor data that satisfies the time constraint. If the sensor data stored in the cache slots of the nodes associated with the set of sensors satisfy the time constraint, the sensor data may be presented to the user. Else, if the sensor data do not satisfy the time constraint, the query processing module 120 probes the set of sensors to obtain updated sensor readings, including temperature data. The updated sensor data is then formatted and presented to the user through the UI 116” (Paragraph 36). The examiner further notes that received user queries for sensor data (i.e. the claimed value of the first attribute) (such as the example temperature data) teaches the claimed receiving of requests. The examiner further notes that Nath teaches “if the stored value of the first attribute has expired then receiving the value of the first attribute from the first device and providing the received value of the first attribute in response to the request” as “Suppose a user at the client device 104-1 wants to know a recent temperature at a specific geographic location. The user submits a query for the recent temperature at the target location along with a time constraint, such as a specified expiry time for the recent temperature, using the UI 116 rendered on the client device 104-1” (Paragraph 35) and “The server 102 receives the query and the query processing module 120 examines the query to determine the latitude and longitude of the target location. Subsequent to examination, the query processing module 120 reviews the data tree stored in the database 122 to identify a set of sensors having latitudes and longitudes within the target location and capable of providing sensor data that satisfies the time constraint. If the sensor data stored in the cache slots of the nodes associated with the set of sensors satisfy the time constraint, the sensor data may be presented to the user. Else, if the sensor data do not satisfy the time constraint, the query processing module 120 probes the set of sensors to obtain updated sensor readings, including temperature data. The updated sensor data is then formatted and presented to the user through the UI 116” (Paragraph 36). The examiner further notes that received user queries for sensor data (i.e. the claimed value of the first attribute) can include a time constraint which is subsequently used to ascertain whether the stored collected sensor data (i.e. the claimed value of the first attribute (such as a temperature value)) is expired relative to that user-specified time constraint. If such stored sensor data has expired, then sensors (i.e. the claimed one or more devices) are probed to collect updated sensor data corresponding to the user query for subsequent presentation to the user. The examiner notes that Nath teaches “further wherein the device attributes further comprise a second attribute” as “The queries contain requests for sensor data from sensors in distributed sensor networks. The server 102 processes the queries by employing a sensor index maintained locally or on a remote storage device 108 that is accessible over the network 106. After processing, the server 102 returns results to the client devices 104” (Paragraph 27), “The UI 116 allows users to specify spatial regions and a particular expiry time to identify a collection of sensors from which they wish to receive readings expiring after the particular expiry time. The sensors may be of any type including, for example, temperature sensors, video cameras, humidity sensors, wind sensors, traffic sensors, parking sensors, security sensors, and so on. In FIG. 1, representative sensors include a temperature sensor 118-1, a camera 118-2, a video camera 118-3, and any other sensors 118-4 (collectively referred to as sensors 118)” (Paragraph 30), and “The database 122 stores an index of the sensors, and the index maintains metadata describing the attributes of the sensors and cached sensor readings. The server 102 has an indexing module 124 stored in the system memory 112 and executable on the processor(s) 110 to create such index structures. In one implementation, the index is structured as a data tree having plural nodes arranged in layers. The plural nodes include leaf nodes coupled with the sensors to collect and store sensor readings and their respective expiry times. The plural nodes also include non-leaf nodes or internal nodes that have caches for caching the sensor data. The caches have multiple cache slots for storing sensor data having different expiry time and cache slots analogous to each other in various layers have similar expiry time. The sensor data cached in a cache slot at a non-leaf node at a layer may be obtained by aggregating corresponding sensor data stored at a preceding layer. The corresponding sensor data can be sensor data stored in corresponding cache slots of internal nodes and/or sensor data stored with leaf nodes at the preceding layer” (Paragraph 33). The examiner further notes that sensor data such as wind (i.e. an example of the claimed second attribute) from various sensors 118 can be stored at a sensor index which can be stored locally at a server 102 or remote data store 108.
Nath does not explicitly teach:
C) a synchroniser configured to maintain synchronisation of the one or more values at intervals between the attributes stored in the memory store and the corresponding attributes associated with the devices;
E) the first attribute having a first synchronisation interval;
F) wherein the duration is shorter than the first synchronisation interval;
I) wherein the synchroniser is further configured to synchronise the one or more values between the attributes stored in the memory store and the corresponding attributes associated with the devices at intervals and the first attribute has a first synchronisation interval; and
K) the second attribute having a second synchronisation interval shorter than the first synchronisation interval;
O) wherein the first device has a first state, which is a low power state, and a second state, which is a high power state;
P) wherein the first device draws a higher power when in the high power state than when in the low power state.
Bone, however, teaches “a synchroniser configured to maintain synchronisation of the one or more values at intervals between the attributes stored in the memory store and the corresponding attributes associated with the devices” as “a synchroniser configured to maintain synchronisation between the attributes stored in the memory store and the attributes associated with the devices” (Paragraph 9) and “the synchroniser may be further configured to operate at intervals. The intervals may be defined by a schedule (e.g. contact device A at time X, device B at time Y, etc.) or particular devices or groups of devices may be synchronised at a particular time interval (e.g. every X minutes). The interval or specified times may be pre-determined or dynamically set based on other criteria. For example, these times or intervals may be based on current network load and/or requirements for particular devices (certain groups of devices may then be synchronised more often than others—e.g. heart monitors). The intervals may be defined and stored as data or metadata either or both on the devices or within the device manager, for example. The synchroniser may also operate continuously” (Paragraph 17), “the first attribute having a first synchronisation interval” as “a synchroniser configured to maintain synchronisation between the attributes stored in the memory store and the attributes associated with the devices” (Paragraph 9) and “the synchroniser may be further configured to operate at intervals. The intervals may be defined by a schedule (e.g. contact device A at time X, device B at time Y, etc.) or particular devices or groups of devices may be synchronised at a particular time interval (e.g. every X minutes). The interval or specified times may be pre-determined or dynamically set based on other criteria. For example, these times or intervals may be based on current network load and/or requirements for particular devices (certain groups of devices may then be synchronised more often than others—e.g. heart monitors). The intervals may be defined and stored as data or metadata either or both on the devices or within the device manager, for example. The synchroniser may also operate continuously” (Paragraph 17), “wherein the duration is shorter than the first synchronisation interval” as “a synchroniser configured to maintain synchronisation between the attributes stored in the memory store and the attributes associated with the devices” (Paragraph 9) and “the synchroniser may be further configured to operate at intervals. The intervals may be defined by a schedule (e.g. contact device A at time X, device B at time Y, etc.) or particular devices or groups of devices may be synchronised at a particular time interval (e.g. every X minutes). The interval or specified times may be pre-determined or dynamically set based on other criteria. For example, these times or intervals may be based on current network load and/or requirements for particular devices (certain groups of devices may then be synchronised more often than others—e.g. heart monitors). The intervals may be defined and stored as data or metadata either or both on the devices or within the device manager, for example. The synchroniser may also operate continuously” (Paragraph 17), “wherein the synchroniser is further configured to synchronise the one or more values between the attributes stored in the memory store and the corresponding attributes associated with the devices at intervals and the first attribute has a first synchronisation interval” as “a synchroniser configured to maintain synchronisation between the attributes stored in the memory store and the attributes associated with the devices” (Paragraph 9) and “the synchroniser may be further configured to operate at intervals. The intervals may be defined by a schedule (e.g. contact device A at time X, device B at time Y, etc.) or particular devices or groups of devices may be synchronised at a particular time interval (e.g. every X minutes). The interval or specified times may be pre-determined or dynamically set based on other criteria. For example, these times or intervals may be based on current network load and/or requirements for particular devices (certain groups of devices may then be synchronised more often than others—e.g. heart monitors). The intervals may be defined and stored as data or metadata either or both on the devices or within the device manager, for example. The synchroniser may also operate continuously” (Paragraph 17), “the second attribute having a second synchronisation interval shorter than the first synchronisation interval” as “a synchroniser configured to maintain synchronisation between the attributes stored in the memory store and the attributes associated with the devices” (Paragraph 9) and “the synchroniser may be further configured to operate at intervals. The intervals may be defined by a schedule (e.g. contact device A at time X, device B at time Y, etc.) or particular devices or groups of devices may be synchronised at a particular time interval (e.g. every X minutes). The interval or specified times may be pre-determined or dynamically set based on other criteria. For example, these times or intervals may be based on current network load and/or requirements for particular devices (certain groups of devices may then be synchronised more often than others—e.g. heart monitors). The intervals may be defined and stored as data or metadata either or both on the devices or within the device manager, for example. The synchroniser may also operate continuously” (Paragraph 17), “wherein the first device has a first state, which is a low power state, and a second state, which is a high power state” as “the synchroniser may be further configured to initiate a communication with the one or more devices when no communication with the one or more devices over the interface is available. Initiation of such a communication (e.g. a channel or interface) may be made. For example, a wake-up message may be sent to one or more devices. This may be over a different interface or channel, such as an SMS, fixed-line or over a mobile network, for example” (Paragraph 16) and “Wakeups—This is the mechanism used to wake-up an identified device and cause it to establish communications with the DM Server. The M2M platform security model may only allow Device wakeup to be triggered from the DM server using an SMS-MT. This has the advantage that devices can only be triggered to perform operations via the M2M platform environment (with its enforced P2P restriction mechanism)” (Paragraph 375), and “wherein the first device draws a higher power when in the high power state than when in the low power state” as “the synchroniser may be further configured to initiate a communication with the one or more devices when no communication with the one or more devices over the interface is available. Initiation of such a communication (e.g. a channel or interface) may be made. For example, a wake-up message may be sent to one or more devices. This may be over a different interface or channel, such as an SMS, fixed-line or over a mobile network, for example” (Paragraph 16) and “Wakeups—This is the mechanism used to wake-up an identified device and cause it to establish communications with the DM Server. The M2M platform security model may only allow Device wakeup to be triggered from the DM server using an SMS-MT. This has the advantage that devices can only be triggered to perform operations via the M2M platform environment (with its enforced P2P restriction mechanism)” (Paragraph 375).
The examiner further notes that although the primary reference of Nath clearly teaches the synchronization of attribute values (See Paragraph 22), there is no explicit teaching of the use of intervals when performing such synchronization. Nevertheless, the secondary reference of Bone (which is from the same assignee as the instant application (i.e. Vodafone)) teaches the concept of synchronizing device attributes and stored attributes via the use of intervals (including the use of different intervals for different attributes). Such different intervals entails that one interval is shorter than the other. Moreover, because such intervals are defined, then as a result they can be defined for any time (including a time that is longer than the expiry time of Nath). The combination would result in the use of such intervals when performing the synchronization of Nath. The examiner further wishes to refer to the instant application which states “If required, an attempt can be made to “wake up” the device by using SMS functionality or another direct communications channel, to prompt the device to supply the data more quickly (i.e. change from a low power state where the communications interface 210 is not in operation to a high power state when it is)” (Page 14, lines 8-11). Thus, just as the instant specification defines a first state that is low-power to be in a non-awaken state and a second state that is a higher-power to be in an awaken state, Bone (which is from the same assignee as the instant application (i.e. Vodafone)) also teaches the concept of sending a message (via SMS for example) on a different channel to change the state of a remote device (See example of changing the state of a device from a nonawake state to an awaken state). Such an awaken state (i.e. the claimed high power state) in Bone draws more power than a non-awaken state (i.e. the claimed low power state). The combination would result in allowing for the remote sensors of Nath to be awoken via messages.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Bone’s would have allowed Nath’s to provide a method for managing devices more effectively, as noted by Bone (Paragraph 9).
Nath and Bone do not explicitly teach:
L) further wherein receiving the value of the first attribute when the value of the first attribute has expired further comprises: at the time of a synchronisation for the second attribute, receiving the value of the first attribute and the value of the second attribute and providing the value of the first attribute in response to the request.
Bhaya, however, teaches “further wherein receiving the value of the first attribute when the value of the first attribute has expired further comprises: at the time of a synchronisation for the second attribute, receiving the value of the first attribute and the value of the second attribute and providing the value of the first attribute in response to the request” as “A selective sensor polling system for a voice activated data packet based computer network environment is provided. A system can receive audio signals detected by a microphone of a device. The system can parse the audio signal to identify trigger keyword and request. The system can select a template for an action data structure with a plurality of fields. The system can determine to poll a first sensor for data for the first field. The system can determine to obtain data in memory previously collected by the second sensor. The system can generate and transmit the action data structure with the data from the sensor and memory, and transmit the action data structure to a third party device” (Abstract) and “having a first sensor detect a first environmental condition (e.g., location, speed, temperature, ambient light, ambient sound, etc.), while retrieving, from memory, a second environmental condition that was previously detected by a second sensor. Rather than instruct the second sensor to go online or activate to detect the environmental condition, the sensor management component 120 can retrieve the previously detected value from memory to reduce resource utilization. For example, the sensor management component can poll a first sensor for data corresponding to the first field, while obtaining data from memory of the computing device 104 that corresponds to the second field. The second data can be stored in the memory of the computing device 104 prior to the data processing system 102 requesting the second data. The sensor management component 120 may not poll the second sensor 134 responsive to the request for data from the second sensor received from the direct action API 116. The sensor management component 120 can determine to poll the first sensor for data corresponding to the first field, but not to poll the second sensor for data corresponding to the second field. The sensor management component 120 can use a policy, logic, of set of rules to determine whether or not to poll one or more sensors. For example, the policy, logic, or set of rules can include, or be based, on conditional rules, if/then conditions, trigger events, tolerances, thresholds, time interval, location, geographical fencing, or type of activity. For example, the sensor management component 120 can determine to poll the first sensor for location information because the last location data received by the data processing system 102 may have expired based on a time interval (e.g., 10 seconds, 5 seconds, 20 seconds, 30 seconds, 1 minute or more). The data processing system 102 can obtain data from memory for the second sensor because the second sensor may be a temperature sensor and the data processing system 102 may determine that the timestamp of when the last temperature measurement was detected and stored in memory may satisfy a time interval (e.g., 1 minute, 2 minutes, 3 minutes, 5 minutes, 10 minutes, 20 minutes, 30 minutes or more)” (Paragraph 62).
The examiner further notes that the secondary reference of Bhaya teaches the concept of obtaining a different sensor value (a first attribute value) while obtaining another sensor value (i.e. the claimed second attribute value) for subsequent providing. The combination would result in obtaining the first attribute values of Nath and Bone (which has its own interval) when performing synchronization for the second attribute values of Nath and Bone (which has a shorter interval).
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Bhaya’s would have allowed Nath’s to provide a method for reducing utilization, as noted by Bhaya (Paragraphs 1 and 62).
Nath, Bone, and Bhaya do not explicitly teach:
M) wherein receiving the value of the first attribute from the device further comprises: adding the request to a queue; and
N) the first device receiving the request from the queue when the first device is available to provide the value of the first attribute;
O) wherein the first device has a first state, where it is unable to provide the value of the first attribute and a second state, where it is able to provide the value of the first attribute.
Mangan, however, teaches “wherein receiving the value of the first attribute from the device further comprises: adding the request to a queue” as “once the indexes of ESI content are built on or from the local endpoint computing devices, the agents can communicate with the agent manager module 120 to confirm they are ready to accept queries. The credentialed user 102 can then interact with the memory and file processing computing system 108 via their computing device 104. Through this interaction, queries can be submitted to one of more agents 134, 136, 138 or to the index representation associated to the agents in the cloud, 168. Such queries can be any suitable type of query, such as using keywords, time parameters, file parameters, predictive coding, conceptual search, Boolean expressions, natural language processing (NLP) queries and so forth. The agent manager module 120 can provide the query to one or more (including all) of the agents 134, 136, 138. If any of the computing devices 128, 130, 132 are off-line at the time of the query, the query can be queued for transmission at a later point in time” (Paragraph 38), “the first device receiving the request from the queue when the first device is available to provide the value of the first attribute” as “once the indexes of ESI content are built on or from the local endpoint computing devices, the agents can communicate with the agent manager module 120 to confirm they are ready to accept queries. The credentialed user 102 can then interact with the memory and file processing computing system 108 via their computing device 104. Through this interaction, queries can be submitted to one of more agents 134, 136, 138 or to the index representation associated to the agents in the cloud, 168. Such queries can be any suitable type of query, such as using keywords, time parameters, file parameters, predictive coding, conceptual search, Boolean expressions, natural language processing (NLP) queries and so forth. The agent manager module 120 can provide the query to one or more (including all) of the agents 134, 136, 138. If any of the computing devices 128, 130, 132 are off-line at the time of the query, the query can be queued for transmission at a later point in time” (Paragraph 38), and “wherein the first device has a first state, where it is unable to provide the value of the first attribute and a second state, where it is able to provide the value of the first attribute” as “once the indexes of ESI content are built on or from the local endpoint computing devices, the agents can communicate with the agent manager module 120 to confirm they are ready to accept queries. The credentialed user 102 can then interact with the memory and file processing computing system 108 via their computing device 104. Through this interaction, queries can be submitted to one of more agents 134, 136, 138 or to the index representation associated to the agents in the cloud, 168. Such queries can be any suitable type of query, such as using keywords, time parameters, file parameters, predictive coding, conceptual search, Boolean expressions, natural language processing (NLP) queries and so forth. The agent manager module 120 can provide the query to one or more (including all) of the agents 134, 136, 138. If any of the computing devices 128, 130, 132 are off-line at the time of the query, the query can be queued for transmission at a later point in time. Upon receiving the query, the agents 134, 136, 138 can query its index to identify any memory and file data 146, 152, 158 that satisfies the query (such memory and file data may be referred to as “identified ESI or malware”, which is a subset of the data stored locally on the device). The results of this identification step can then be provided by each agent 134, 136, 138 to the memory and file processing computing system 108. In some embodiments, copies of the identified memory and file data are provided to the memory and file processing computing system 108 over the network connection” (Paragraph 38).
The examiner further notes that the secondary reference of Mangan teaches the concept of initially queuing query requests directed towards devices that are off-line (i.e. are unavailable) before transmitting such queued query requests at a later point in time when those devices are ready to accept queries via agents. The combination would result in queuing the user queries of Nath for unavailable devices. Furthermore, although Bone clearly teaches a first state that is lower-power and a second state that is higher power for devices, it does not teach the queuing of requests for unavailable devices at a first state until those devices are available at a second state. Nevertheless, Mangan teaches the concept of initially queuing query requests directed towards devices that are off-line (i.e. the claimed first state) before transmitting such queued query requests at a later point in time when those devices are ready (i.e. at a second state) to accept queries via agents. The combination would result in queuing (via Mangan) the user queries (of Nath) for unavailable devices (of Mangan) that are low-power (of Bone) until those devices are available (of Mangan) and of higher-power (of Bone).
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Mangan’s would have allowed Nath’s, Bone’s, and Bhaya’s to provide a method for reducing the costs in locating data, as noted by Mangan (Paragraph 5).
Regarding claim 17, Nath further teaches a system comprising:
A) wherein the request includes data indicating an expiration time of the requested value and the device manager is further configured to determine if the value of the first attribute has expired by determining if a current time is not earlier than the expiration time of the requested value (Paragraphs 35-36 and 39).
The examiner notes that Nath teaches “wherein the request includes data indicating an expiration time of the requested value and the device manager is further configured to determine if the value of the first attribute has expired by determining if a current time is not earlier than the expiration time of the requested value” as “Suppose a user at the client device 104-1 wants to know a recent temperature at a specific geographic location. The user submits a query for the recent temperature at the target location along with a time constraint, such as a specified expiry time for the recent temperature, using the UI 116 rendered on the client device 104-1” (Paragraph 35), “The server 102 receives the query and the query processing module 120 examines the query to determine the latitude and longitude of the target location. Subsequent to examination, the query processing module 120 reviews the data tree stored in the database 122 to identify a set of sensors having latitudes and longitudes within the target location and capable of providing sensor data that satisfies the time constraint. If the sensor data stored in the cache slots of the nodes associated with the set of sensors satisfy the time constraint, the sensor data may be presented to the user. Else, if the sensor data do not satisfy the time constraint, the query processing module 120 probes the set of sensors to obtain updated sensor readings, including temperature data. The updated sensor data is then formatted and presented to the user through the UI 116” (Paragraph 36), and “The UI 116 further enables the user to specify freshness constraints/or time constraints of the sensor data in terms of how stale (or how recent) the sensor data is to be acceptable. For example, the user may specify that sensor data older than a particular time period (e.g., 10 minutes, 1 hour, 1 day, etc.) may not be acceptable. Thus, the user can obtain the latest sensor readings from all the locations” (Paragraph 39). The examiner further notes that received user queries (i.e. requests) for sensor data (i.e. the claimed value of the first attribute) can include a time constraint (i.e. the claimed expiration time) for requested sensor data (i.e. the claimed requested value). Such a time constraint can be specified as a time period which entails determining if the current time is earlier (or not) than the expiry time of the stored sensor data.
14. Claims 1-2, 5-6, 11, 13-14, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Nath et al. (U.S. PGPUB 2008/0247313), in view of Bone et al. (U.S. PGPUB 2016/0232116), and further in view of Bhaya et al. (U.S. PGPUB 2018/0191596), and further in view of Mangan et al. (U.S. PGPUB 2016/0154864) as applied to claims 15 and 17 above, and further in view of Chen et al. (CN 104469310A (Machine Translation Provided)).
15. Regarding claims 1 and 18, Nath teaches a method and non-transitory computer storage medium comprising:
A) receiving from one or more devices values of one or more attributes (Paragraphs 27, 30, and 33, Figure 1);
B) storing the values of the one or more attributes associated with the one or more devices in a memory store (Paragraph 27, 30, and 33, Figure 1);
C) maintaining synchronisation of the one or more values between the attributes stored in the memory store and the corresponding attributes associated with the devices (Paragraphs 22, 27, 30, and 33, Figure 1);
D) wherein the device attributes comprise at least a first attribute having an expiry time or duration (Abstract, Paragraphs 30, 32, and 35);
E) receiving a request for the value of the first attribute of a first device (Paragraphs 30-31 and 35-36);
F) determining if the value of the first attribute has expired (Paragraphs 35-36);
G) if the stored value of the first attribute has expired then receiving the value of the first attribute from the first device and providing the received value of the first attribute in response to the request (Paragraphs 35 and 36);
I) further wherein the device attributes further comprise a second attribute (Paragraphs 27, 30, and 33, Figure 1).
The examiner notes that Nath teaches “receiving from one or more devices values of one or more attributes” as “The queries contain requests for sensor data from sensors in distributed sensor networks. The server 102 processes the queries by employing a sensor index maintained locally or on a remote storage device 108 that is accessible over the network 106. After processing, the server 102 returns results to the client devices 104” (Paragraph 27), “The UI 116 allows users to specify spatial regions and a particular expiry time to identify a collection of sensors from which they wish to receive readings expiring after the particular expiry time. The sensors may be of any type including, for example, temperature sensors, video cameras, humidity sensors, wind sensors, traffic sensors, parking sensors, security sensors, and so on. In FIG. 1, representative sensors include a temperature sensor 118-1, a camera 118-2, a video camera 118-3, and any other sensors 118-4 (collectively referred to as sensors 118)” (Paragraph 30), and “The database 122 stores an index of the sensors, and the index maintains metadata describing the attributes of the sensors and cached sensor readings. The server 102 has an indexing module 124 stored in the system memory 112 and executable on the processor(s) 110 to create such index structures. In one implementation, the index is structured as a data tree having plural nodes arranged in layers. The plural nodes include leaf nodes coupled with the sensors to collect and store sensor readings and their respective expiry times. The plural nodes also include non-leaf nodes or internal nodes that have caches for caching the sensor data. The caches have multiple cache slots for storing sensor data having different expiry time and cache slots analogous to each other in various layers have similar expiry time. The sensor data cached in a cache slot at a non-leaf node at a layer may be obtained by aggregating corresponding sensor data stored at a preceding layer. The corresponding sensor data can be sensor data stored in corresponding cache slots of internal nodes and/or sensor data stored with leaf nodes at the preceding layer” (Paragraph 33). The examiner further notes that sensor data (i.e. the claimed one or more attributes) from various sensors 118 (i.e. the claimed one or more devices) entails collecting such sensor data in the first place. Such collected sensor data can be stored at a sensor index which can be stored locally at a server 102 or remote data store 108. The examiner further notes that Nath teaches “storing the values of the one or more attributes associated with the one or more devices in a memory store” as “The queries contain requests for sensor data from sensors in distributed sensor networks. The server 102 processes the queries by employing a sensor index maintained locally or on a remote storage device 108 that is accessible over the network 106. After processing, the server 102 returns results to the client devices 104” (Paragraph 27), “The UI 116 allows users to specify spatial regions and a particular expiry time to identify a collection of sensors from which they wish to receive readings expiring after the particular expiry time. The sensors may be of any type including, for example, temperature sensors, video cameras, humidity sensors, wind sensors, traffic sensors, parking sensors, security sensors, and so on. In FIG. 1, representative sensors include a temperature sensor 118-1, a camera 118-2, a video camera 118-3, and any other sensors 118-4 (collectively referred to as sensors 118)” (Paragraph 30), and “The database 122 stores an index of the sensors, and the index maintains metadata describing the attributes of the sensors and cached sensor readings. The server 102 has an indexing module 124 stored in the system memory 112 and executable on the processor(s) 110 to create such index structures. In one implementation, the index is structured as a data tree having plural nodes arranged in layers. The plural nodes include leaf nodes coupled with the sensors to collect and store sensor readings and their respective expiry times. The plural nodes also include non-leaf nodes or internal nodes that have caches for caching the sensor data. The caches have multiple cache slots for storing sensor data having different expiry time and cache slots analogous to each other in various layers have similar expiry time. The sensor data cached in a cache slot at a non-leaf node at a layer may be obtained by aggregating corresponding sensor data stored at a preceding layer. The corresponding sensor data can be sensor data stored in corresponding cache slots of internal nodes and/or sensor data stored with leaf nodes at the preceding layer” (Paragraph 33). The examiner further notes that sensor data (i.e. the claimed one or more attributes) from various sensors (i.e. the claimed one or more devices) is stored in system memory 112 locally at server 102 or at a remote data store 108. The examiner further notes that Nath teaches “maintaining synchronisation of the one or more values between the attributes stored in the memory store and the corresponding attributes associated with the devices” as “the backend database may routinely poll sensors as data in the cache slots become stale. This polling may occur responsive to a search query or as part of a separate process. The polling is thus conducted in a manner transparent to the user, as the user merely submits a query and receives results from the web portal” (Paragraph 22), “The queries contain requests for sensor data from sensors in distributed sensor networks. The server 102 processes the queries by employing a sensor index maintained locally or on a remote storage device 108 that is accessible over the network 106. After processing, the server 102 returns results to the client devices 104” (Paragraph 27), “The UI 116 allows users to specify spatial regions and a particular expiry time to identify a collection of sensors from which they wish to receive readings expiring after the particular expiry time. The sensors may be of any type including, for example, temperature sensors, video cameras, humidity sensors, wind sensors, traffic sensors, parking sensors, security sensors, and so on. In FIG. 1, representative sensors include a temperature sensor 118-1, a camera 118-2, a video camera 118-3, and any other sensors 118-4 (collectively referred to as sensors 118)” (Paragraph 30), and “The database 122 stores an index of the sensors, and the index maintains metadata describing the attributes of the sensors and cached sensor readings. The server 102 has an indexing module 124 stored in the system memory 112 and executable on the processor(s) 110 to create such index structures. In one implementation, the index is structured as a data tree having plural nodes arranged in layers. The plural nodes include leaf nodes coupled with the sensors to collect and store sensor readings and their respective expiry times. The plural nodes also include non-leaf nodes or internal nodes that have caches for caching the sensor data. The caches have multiple cache slots for storing sensor data having different expiry time and cache slots analogous to each other in various layers have similar expiry time. The sensor data cached in a cache slot at a non-leaf node at a layer may be obtained by aggregating corresponding sensor data stored at a preceding layer. The corresponding sensor data can be sensor data stored in corresponding cache slots of internal nodes and/or sensor data stored with leaf nodes at the preceding layer” (Paragraph 33). The examiner further notes that the routine polling of remote sensor devices to update stale stored sensor data (which is stored at either server 102 or remote store 108) teaches the claimed maintaining. The examiner further notes that Nath teaches “wherein the device attributes comprise at least a first attribute having an expiry time or duration” as “Techniques for collecting and displaying sensor data captured by a spatially and temporally representative sample of sensors requested in a search query are described. The sensors are represented in an index structure (e.g., a data tree) having a plurality of leaf nodes and internal nodes. The leaf nodes are associated with sensors and the internal nodes are allotted with caches having cache slots for storing sensor data with various expiry times” (Abstract), “The UI 116 allows users to specify spatial regions and a particular expiry time to identify a collection of sensors from which they wish to receive readings expiring after the particular expiry time. The sensors may be of any type including, for example, temperature sensors, video cameras, humidity sensors, wind sensors, traffic sensors, parking sensors, security sensors, and so on. In FIG. 1, representative sensors include a temperature sensor 118-1, a camera 118-2, a video camera 118-3, and any other sensors 118-4 (collectively referred to as sensors 118)” (Paragraph 30), “information regarding the expiry time of sensor data collected by the sensors may be stored in a database 122, which is illustrated as being stored in the remote storage device 108 (although it may be stored in other locations, such as within the system memory 112)” (Paragraph 32), and “Suppose a user at the client device 104-1 wants to know a recent temperature at a specific geographic location. The user submits a query for the recent temperature at the target location along with a time constraint, such as a specified expiry time for the recent temperature, using the UI 116 rendered on the client device 104-1” (Paragraph 35). The examiner further notes that sensor data (such as temperature data) from sensors 118 include stored expiry times that teaches the claimed expiry time. The examiner further notes that Nath teaches “receiving a request for the value of the first attribute of a first device” as “The UI 116 allows users to specify spatial regions and a particular expiry time to identify a collection of sensors from which they wish to receive readings expiring after the particular expiry time. The sensors may be of any type including, for example, temperature sensors, video cameras, humidity sensors, wind sensors, traffic sensors, parking sensors, security sensors, and so on. In FIG. 1, representative sensors include a temperature sensor 118-1, a camera 118-2, a video camera 118-3, and any other sensors 118-4 (collectively referred to as sensors 118)” (Paragraph 30), “Upon receiving a query submitted by the client device 104, the server 102 analyzes and translates the query into a sequence of declarative queries that may be used to identify a set of sensors that can contribute to the sensor data requested by the user. The server 102 implements a query processing module 120, which is stored in the system memory 112 and executed by the processor(s) 110. To aid in identifying the appropriate set of sensors to respond to the user's query, the query processing module 120 discovers attributes of the set of sensors. The attributes may include, for example, sensor location in terms of latitude and longitude, type of sensor, schemas for sensor readings, expiry times of sensor readings, and so on” (Paragraph 31), “Suppose a user at the client device 104-1 wants to know a recent temperature at a specific geographic location. The user submits a query for the recent temperature at the target location along with a time constraint, such as a specified expiry time for the recent temperature, using the UI 116 rendered on the client device 104-1” (Paragraph 35), and “The server 102 receives the query and the query processing module 120 examines the query to determine the latitude and longitude of the target location. Subsequent to examination, the query processing module 120 reviews the data tree stored in the database 122 to identify a set of sensors having latitudes and longitudes within the target location and capable of providing sensor data that satisfies the time constraint. If the sensor data stored in the cache slots of the nodes associated with the set of sensors satisfy the time constraint, the sensor data may be presented to the user. Else, if the sensor data do not satisfy the time constraint, the query processing module 120 probes the set of sensors to obtain updated sensor readings, including temperature data. The updated sensor data is then formatted and presented to the user through the UI 116” (Paragraph 36). The examiner further notes that received user queries for sensor data (i.e. the claimed value of the first attribute) (such as the example temperature data) teaches the claimed receiving of a request. The examiner further notes that Nath teaches “determining if the value of the first attribute has expired” as “Suppose a user at the client device 104-1 wants to know a recent temperature at a specific geographic location. The user submits a query for the recent temperature at the target location along with a time constraint, such as a specified expiry time for the recent temperature, using the UI 116 rendered on the client device 104-1” (Paragraph 35) and “The server 102 receives the query and the query processing module 120 examines the query to determine the latitude and longitude of the target location. Subsequent to examination, the query processing module 120 reviews the data tree stored in the database 122 to identify a set of sensors having latitudes and longitudes within the target location and capable of providing sensor data that satisfies the time constraint. If the sensor data stored in the cache slots of the nodes associated with the set of sensors satisfy the time constraint, the sensor data may be presented to the user. Else, if the sensor data do not satisfy the time constraint, the query processing module 120 probes the set of sensors to obtain updated sensor readings, including temperature data. The updated sensor data is then formatted and presented to the user through the UI 116” (Paragraph 36). The examiner further notes that received user queries for sensor data (i.e. the claimed value of the first attribute) can include a time constraint which is subsequently used to ascertain whether the stored collected sensor data (i.e. the claimed value of the first attribute (such as a temperature value)) is expired relative to that user-specified time constraint. The examiner further notes that Nath teaches “if the stored value of the first attribute has expired then receiving the value of the first attribute from the first device and providing the received value of the first attribute in response to the request” as “Suppose a user at the client device 104-1 wants to know a recent temperature at a specific geographic location. The user submits a query for the recent temperature at the target location along with a time constraint, such as a specified expiry time for the recent temperature, using the UI 116 rendered on the client device 104-1” (Paragraph 35) and “The server 102 receives the query and the query processing module 120 examines the query to determine the latitude and longitude of the target location. Subsequent to examination, the query processing module 120 reviews the data tree stored in the database 122 to identify a set of sensors having latitudes and longitudes within the target location and capable of providing sensor data that satisfies the time constraint. If the sensor data stored in the cache slots of the nodes associated with the set of sensors satisfy the time constraint, the sensor data may be presented to the user. Else, if the sensor data do not satisfy the time constraint, the query processing module 120 probes the set of sensors to obtain updated sensor readings, including temperature data. The updated sensor data is then formatted and presented to the user through the UI 116” (Paragraph 36). The examiner further notes that received user queries for sensor data (i.e. the claimed value of the first attribute) can include a time constraint which is subsequently used to ascertain whether the stored collected sensor data (i.e. the claimed value of the first attribute (such as a temperature value)) is expired relative to that user-specified time constraint. If such stored sensor data has expired, then sensors (i.e. the claimed first device) are probed to collect updated sensor data corresponding to the user query for subsequent presentation to the user. The examiner notes that Nath teaches “further wherein the device attributes further comprise a second attribute” as “The queries contain requests for sensor data from sensors in distributed sensor networks. The server 102 processes the queries by employing a sensor index maintained locally or on a remote storage device 108 that is accessible over the network 106. After processing, the server 102 returns results to the client devices 104” (Paragraph 27), “The UI 116 allows users to specify spatial regions and a particular expiry time to identify a collection of sensors from which they wish to receive readings expiring after the particular expiry time. The sensors may be of any type including, for example, temperature sensors, video cameras, humidity sensors, wind sensors, traffic sensors, parking sensors, security sensors, and so on. In FIG. 1, representative sensors include a temperature sensor 118-1, a camera 118-2, a video camera 118-3, and any other sensors 118-4 (collectively referred to as sensors 118)” (Paragraph 30), and “The database 122 stores an index of the sensors, and the index maintains metadata describing the attributes of the sensors and cached sensor readings. The server 102 has an indexing module 124 stored in the system memory 112 and executable on the processor(s) 110 to create such index structures. In one implementation, the index is structured as a data tree having plural nodes arranged in layers. The plural nodes include leaf nodes coupled with the sensors to collect and store sensor readings and their respective expiry times. The plural nodes also include non-leaf nodes or internal nodes that have caches for caching the sensor data. The caches have multiple cache slots for storing sensor data having different expiry time and cache slots analogous to each other in various layers have similar expiry time. The sensor data cached in a cache slot at a non-leaf node at a layer may be obtained by aggregating corresponding sensor data stored at a preceding layer. The corresponding sensor data can be sensor data stored in corresponding cache slots of internal nodes and/or sensor data stored with leaf nodes at the preceding layer” (Paragraph 33). The examiner further notes that sensor data such as wind (i.e. an example of the claimed second attribute) from various sensors 118 can be stored at a sensor index which can be stored locally at a server 102 or remote data store 108.
Nath does not explicitly teach:
H) wherein the synchronisation of the one or more values between the attributes stored in the memory store and the corresponding attributes associated with the devices is maintained at intervals and the first attribute has a first synchronisation interval wherein the expiry time or duration is shorter than the first synchronisation interval;
J) the second attribute having a second synchronisation interval shorter than the first synchronisation interval;
N) wherein the first device has a first state, which is a low power state, and a second state, which is a high power state;
O) wherein the first device draws a higher power when in the high power state than when in the low power state.
Bone, however, teaches “wherein the synchronisation of the one or more values between the attributes stored in the memory store and the corresponding attributes associated with the devices is maintained at intervals and the first attribute has a first synchronisation interval wherein the expiry time or duration is shorter than the first synchronisation interval” as “a synchroniser configured to maintain synchronisation between the attributes stored in the memory store and the attributes associated with the devices” (Paragraph 9) and “the synchroniser may be further configured to operate at intervals. The intervals may be defined by a schedule (e.g. contact device A at time X, device B at time Y, etc.) or particular devices or groups of devices may be synchronised at a particular time interval (e.g. every X minutes). The interval or specified times may be pre-determined or dynamically set based on other criteria. For example, these times or intervals may be based on current network load and/or requirements for particular devices (certain groups of devices may then be synchronised more often than others—e.g. heart monitors). The intervals may be defined and stored as data or metadata either or both on the devices or within the device manager, for example. The synchroniser may also operate continuously” (Paragraph 17), “the second attribute having a second synchronisation interval shorter than the first synchronisation interval” as “a synchroniser configured to maintain synchronisation between the attributes stored in the memory store and the attributes associated with the devices” (Paragraph 9) and “the synchroniser may be further configured to operate at intervals. The intervals may be defined by a schedule (e.g. contact device A at time X, device B at time Y, etc.) or particular devices or groups of devices may be synchronised at a particular time interval (e.g. every X minutes). The interval or specified times may be pre-determined or dynamically set based on other criteria. For example, these times or intervals may be based on current network load and/or requirements for particular devices (certain groups of devices may then be synchronised more often than others—e.g. heart monitors). The intervals may be defined and stored as data or metadata either or both on the devices or within the device manager, for example. The synchroniser may also operate continuously” (Paragraph 17), “wherein the first device has a first state, which is a low power state, and a second state, which is a high power state” as “the synchroniser may be further configured to initiate a communication with the one or more devices when no communication with the one or more devices over the interface is available. Initiation of such a communication (e.g. a channel or interface) may be made. For example, a wake-up message may be sent to one or more devices. This may be over a different interface or channel, such as an SMS, fixed-line or over a mobile network, for example” (Paragraph 16) and “Wakeups—This is the mechanism used to wake-up an identified device and cause it to establish communications with the DM Server. The M2M platform security model may only allow Device wakeup to be triggered from the DM server using an SMS-MT. This has the advantage that devices can only be triggered to perform operations via the M2M platform environment (with its enforced P2P restriction mechanism)” (Paragraph 375), and “wherein the first device draws a higher power when in the high power state than when in the low power state” as “the synchroniser may be further configured to initiate a communication with the one or more devices when no communication with the one or more devices over the interface is available. Initiation of such a communication (e.g. a channel or interface) may be made. For example, a wake-up message may be sent to one or more devices. This may be over a different interface or channel, such as an SMS, fixed-line or over a mobile network, for example” (Paragraph 16) and “Wakeups—This is the mechanism used to wake-up an identified device and cause it to establish communications with the DM Server. The M2M platform security model may only allow Device wakeup to be triggered from the DM server using an SMS-MT. This has the advantage that devices can only be triggered to perform operations via the M2M platform environment (with its enforced P2P restriction mechanism)” (Paragraph 375).
The examiner further notes that although the primary reference of Nath clearly teaches the synchronization of attribute values (See Paragraph 22), there is no explicit teaching of the use of intervals when performing such synchronization. Nevertheless, the secondary reference of Bone (which is from the same assignee as the instant application (i.e. Vodafone)) teaches the concept of synchronizing device attributes and stored attributes via the use of intervals (including the use of different intervals for different attributes). Such different intervals entails that one interval is shorter than the other. Moreover, because such intervals are defined, then as a result they can be defined for any time (including a time that is longer than the expiry time of Nath). The combination would result in the use of such intervals when performing the synchronization of Nath. The examiner further wishes to refer to the instant application which states “If required, an attempt can be made to “wake up” the device by using SMS functionality or another direct communications channel, to prompt the device to supply the data more quickly (i.e. change from a low power state where the communications interface 210 is not in operation to a high power state when it is)” (Page 14, lines 8-11). Thus, just as the instant specification defines a first state that is low-power to be in a non-awaken state and a second state that is a higher-power to be in an awaken state, Bone (which is from the same assignee as the instant application (i.e. Vodafone)) also teaches the concept of sending a message (via SMS for example) on a different channel to change the state of a remote device (See example of changing the state of a device from a nonawake state to an awaken state). Such an awaken state (i.e. the claimed high power state) in Bone draws more power than a non-awaken state (i.e. the claimed low power state). The combination would result in allowing for the remote sensors of Nath to be awoken via messages.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Bone’s would have allowed Nath’s to provide a method for managing devices more effectively, as noted by Bone (Paragraph 9).
Nath and Bone do not explicitly teach:
K) further wherein the step of receiving the value of the first attribute when the value of the first attribute has expired further comprises the steps of: at the time of a synchronisation for the second attribute, receiving the value of the first attribute and the value of the second attribute and providing the value of the first attribute in response to the request.
Bhaya, however, teaches “further wherein the step of receiving the value of the first attribute when the value of the first attribute has expired further comprises the steps of: at the time of a synchronisation for the second attribute, receiving the value of the first attribute and the value of the second attribute and providing the value of the first attribute in response to the request” as “A selective sensor polling system for a voice activated data packet based computer network environment is provided. A system can receive audio signals detected by a microphone of a device. The system can parse the audio signal to identify trigger keyword and request. The system can select a template for an action data structure with a plurality of fields. The system can determine to poll a first sensor for data for the first field. The system can determine to obtain data in memory previously collected by the second sensor. The system can generate and transmit the action data structure with the data from the sensor and memory, and transmit the action data structure to a third party device” (Abstract) and “having a first sensor detect a first environmental condition (e.g., location, speed, temperature, ambient light, ambient sound, etc.), while retrieving, from memory, a second environmental condition that was previously detected by a second sensor. Rather than instruct the second sensor to go online or activate to detect the environmental condition, the sensor management component 120 can retrieve the previously detected value from memory to reduce resource utilization. For example, the sensor management component can poll a first sensor for data corresponding to the first field, while obtaining data from memory of the computing device 104 that corresponds to the second field. The second data can be stored in the memory of the computing device 104 prior to the data processing system 102 requesting the second data. The sensor management component 120 may not poll the second sensor 134 responsive to the request for data from the second sensor received from the direct action API 116. The sensor management component 120 can determine to poll the first sensor for data corresponding to the first field, but not to poll the second sensor for data corresponding to the second field. The sensor management component 120 can use a policy, logic, of set of rules to determine whether or not to poll one or more sensors. For example, the policy, logic, or set of rules can include, or be based, on conditional rules, if/then conditions, trigger events, tolerances, thresholds, time interval, location, geographical fencing, or type of activity. For example, the sensor management component 120 can determine to poll the first sensor for location information because the last location data received by the data processing system 102 may have expired based on a time interval (e.g., 10 seconds, 5 seconds, 20 seconds, 30 seconds, 1 minute or more). The data processing system 102 can obtain data from memory for the second sensor because the second sensor may be a temperature sensor and the data processing system 102 may determine that the timestamp of when the last temperature measurement was detected and stored in memory may satisfy a time interval (e.g., 1 minute, 2 minutes, 3 minutes, 5 minutes, 10 minutes, 20 minutes, 30 minutes or more)” (Paragraph 62).
The examiner further notes that the secondary reference of Bhaya teaches the concept of obtaining a different sensor value (a first attribute value) while obtaining another sensor value (i.e. the claimed second attribute value) for subsequent providing. The combination would result in obtaining the first attribute values of Nath and Bone (which has its own interval) when performing synchronization for the second attribute values of Nath and Bone (which has a shorter interval).
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Bhaya’s would have allowed Nath’s to provide a method for reducing utilization, as noted by Bhaya (Paragraphs 1 and 62).
Nath, Bone, and Bhaya do not explicitly teach:
L) wherein receiving the value of the first attribute from the device further comprises the steps of: adding the request to a queue; and
M) the first device receiving the request from the queue when the first device is available to provide the value of the first attribute;
N) wherein the first device has a first state, where it is unable to provide the value of the first attribute and a second state, where it is able to provide the value of the first attribute.
Mangan, however, teaches “wherein receiving the value of the first attribute from the device further comprises the steps of: adding the request to a queue” as “once the indexes of ESI content are built on or from the local endpoint computing devices, the agents can communicate with the agent manager module 120 to confirm they are ready to accept queries. The credentialed user 102 can then interact with the memory and file processing computing system 108 via their computing device 104. Through this interaction, queries can be submitted to one of more agents 134, 136, 138 or to the index representation associated to the agents in the cloud, 168. Such queries can be any suitable type of query, such as using keywords, time parameters, file parameters, predictive coding, conceptual search, Boolean expressions, natural language processing (NLP) queries and so forth. The agent manager module 120 can provide the query to one or more (including all) of the agents 134, 136, 138. If any of the computing devices 128, 130, 132 are off-line at the time of the query, the query can be queued for transmission at a later point in time” (Paragraph 38), “the first device receiving the request from the queue when the first device is available to provide the value of the first attribute” as “once the indexes of ESI content are built on or from the local endpoint computing devices, the agents can communicate with the agent manager module 120 to confirm they are ready to accept queries. The credentialed user 102 can then interact with the memory and file processing computing system 108 via their computing device 104. Through this interaction, queries can be submitted to one of more agents 134, 136, 138 or to the index representation associated to the agents in the cloud, 168. Such queries can be any suitable type of query, such as using keywords, time parameters, file parameters, predictive coding, conceptual search, Boolean expressions, natural language processing (NLP) queries and so forth. The agent manager module 120 can provide the query to one or more (including all) of the agents 134, 136, 138. If any of the computing devices 128, 130, 132 are off-line at the time of the query, the query can be queued for transmission at a later point in time” (Paragraph 38), and “wherein the first device has a first state, where it is unable to provide the value of the first attribute and a second state, where it is able to provide the value of the first attribute” as “once the indexes of ESI content are built on or from the local endpoint computing devices, the agents can communicate with the agent manager module 120 to confirm they are ready to accept queries. The credentialed user 102 can then interact with the memory and file processing computing system 108 via their computing device 104. Through this interaction, queries can be submitted to one of more agents 134, 136, 138 or to the index representation associated to the agents in the cloud, 168. Such queries can be any suitable type of query, such as using keywords, time parameters, file parameters, predictive coding, conceptual search, Boolean expressions, natural language processing (NLP) queries and so forth. The agent manager module 120 can provide the query to one or more (including all) of the agents 134, 136, 138. If any of the computing devices 128, 130, 132 are off-line at the time of the query, the query can be queued for transmission at a later point in time. Upon receiving the query, the agents 134, 136, 138 can query its index to identify any memory and file data 146, 152, 158 that satisfies the query (such memory and file data may be referred to as “identified ESI or malware”, which is a subset of the data stored locally on the device). The results of this identification step can then be provided by each agent 134, 136, 138 to the memory and file processing computing system 108. In some embodiments, copies of the identified memory and file data are provided to the memory and file processing computing system 108 over the network connection” (Paragraph 38).
The examiner further notes that the secondary reference of Mangan teaches the concept of initially queuing query requests directed towards devices that are off-line (i.e. are unavailable) before transmitting such queued query requests at a later point in time when those devices are ready to accept queries via agents. The combination would result in queuing the user queries of Nath for unavailable devices. Furthermore, although Bone clearly teaches a first state that is lower-power and a second state that is higher power for devices, it does not teach the queuing of requests for unavailable devices at a first state until those devices are available at a second state. Nevertheless, Mangan teaches the concept of initially queuing query requests directed towards devices that are off-line (i.e. the claimed first state) before transmitting such queued query requests at a later point in time when those devices are ready (i.e. at a second state) to accept queries via agents. The combination would result in queuing (via Mangan) the user queries (of Nath) for unavailable devices (of Mangan) that are low-power (of Bone) until those devices are available (of Mangan) and of higher-power (of Bone).
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Mangan’s would have allowed Nath’s, Bone’s, and Bhaya’s to provide a method for reducing the costs in locating data, as noted by Mangan (Paragraph 5).
Nath, Bone, Bhaya, and Mangan do not explicitly teach:
F) determining if the value of the first attribute has expired, comprising the expiry time or duration with a time period since the value was synchronised and/or stored in the memory store.
Chen, however, teaches “determining if the value of the first attribute has expired, comprising the expiry time or duration with a time period since the value was synchronised and/or stored in the memory store” as “calculating the overdue time of the front terminal device storing the video data from the storage volume of the front end device distributes scanning identifying the expiration data, and deleting the stale data, the idle memory space of the storage volume of the front end device is distributed in time recovery to the corresponding storage array. wherein, the stale data is the storage time is earlier than the expiration time point of the video data. by deleting the stale data in time” (Paragraph 175).
The examiner further notes that the secondary reference of Chen teaches the concept of comparing an expiration time of data to a storage time for subsequent determination of staleness. The combination would result in performing such a comparison to determine the staleness of the data Nath (which already determines if a value of a first attribute has expired).
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Chen’s would have allowed Nath’s, Bone’s, Bhaya’s, and Mangan’s to provide a method for reducing system costs and improving system utilization, as noted by Chen (Paragraph 175).
Regarding claim 2, Nath further teaches a method comprising:
A) wherein if the value of the first attribute has not expired then retrieving from the memory store the stored value of the first attribute and providing the retrieved value of the first attribute in response to the request (Paragraphs 35-36).
The examiner notes that Nath teaches “wherein if the value of the first attribute has not expired then retrieving from the memory store the stored value of the first attribute and providing the retrieved value of the first attribute in response to the request” as “Suppose a user at the client device 104-1 wants to know a recent temperature at a specific geographic location. The user submits a query for the recent temperature at the target location along with a time constraint, such as a specified expiry time for the recent temperature, using the UI 116 rendered on the client device 104-1” (Paragraph 35) and “The server 102 receives the query and the query processing module 120 examines the query to determine the latitude and longitude of the target location. Subsequent to examination, the query processing module 120 reviews the data tree stored in the database 122 to identify a set of sensors having latitudes and longitudes within the target location and capable of providing sensor data that satisfies the time constraint. If the sensor data stored in the cache slots of the nodes associated with the set of sensors satisfy the time constraint, the sensor data may be presented to the user. Else, if the sensor data do not satisfy the time constraint, the query processing module 120 probes the set of sensors to obtain updated sensor readings, including temperature data. The updated sensor data is then formatted and presented to the user through the UI 116” (Paragraph 36). The examiner further notes that stored sensor data (such as temperature data) (i.e. the claimed value of the first attribute) can be returned to a querying user in response to a user query (with a specified time constraint) if such stored sensor data has not been deemed to be expired in comparison to the specified time constraint.
Regarding claim 5, Nath does not explicitly teach a method comprising:
A) wherein receiving the value of the first attribute from the first device further comprises the steps of: sending a message to the first device; and in response to the message, the first device changing from the first state to the second state.
Bone, however, teaches “wherein receiving the value of the first attribute from the first device further comprises the steps of: sending a message to the first device; and in response to the message, the first device changing from the first state to the second state” as “the synchroniser may be further configured to initiate a communication with the one or more devices when no communication with the one or more devices over the interface is available. Initiation of such a communication (e.g. a channel or interface) may be made. For example, a wake-up message may be sent to one or more devices. This may be over a different interface or channel, such as an SMS, fixed-line or over a mobile network, for example” (Paragraph 16) and “Wakeups—This is the mechanism used to wake-up an identified device and cause it to establish communications with the DM Server. The M2M platform security model may only allow Device wakeup to be triggered from the DM server using an SMS-MT. This has the advantage that devices can only be triggered to perform operations via the M2M platform environment (with its enforced P2P restriction mechanism)” (Paragraph 375).
The examiner further notes that the secondary reference of Bone teaches the concept of sending a message (via SMS for example) on a different channel to change the state of a remote device (See example of changing the state of a device from a nonawake state to an awaken state). The combination would result in allowing for the remote sensors of Nath to be awoken via messages.
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Bone’s would have allowed Nath’s to provide a method for managing devices more effectively, as noted by Bone (Paragraph 9).
Regarding claim 6, Nath does not explicitly teach a method comprising:
A) wherein the message is sent to the first device over a first communications channel and the value of the first attribute is received from the first device over a second communications channel different to the first communications channel.
Bone, however, teaches “wherein the message is sent to the first device over a first communications channel and the value of the first attribute is received from the first device over a second communications channel different to the first communications channel” as “Optionally, the device manager may be further configured to communicate with each device over a first interface of the one or more interfaces. Either or both the device and the device manager may initiate communication. For example, the device may request data (e.g. updates) or the device manager may request data from the device. Data or metadata may be sent to and/or stored on the device to define how and when communications are to take place, for example. The interfaces may be of different forms including but not limited to WiFi, cellular, zigbee, Bluetooth, WiMax, for example” (Paragraph 14), “the synchroniser may be further configured to initiate a communication with the one or more devices when no communication with the one or more devices over the interface is available. Initiation of such a communication (e.g. a channel or interface) may be made. For example, a wake-up message may be sent to one or more devices. This may be over a different interface or channel, such as an SMS, fixed-line or over a mobile network, for example” (Paragraph 16), and “Wakeups—This is the mechanism used to wake-up an identified device and cause it to establish communications with the DM Server. The M2M platform security model may only allow Device wakeup to be triggered from the DM server using an SMS-MT. This has the advantage that devices can only be triggered to perform operations via the M2M platform environment (with its enforced P2P restriction mechanism)” (Paragraph 375).
The examiner further notes that the secondary reference of Bone teaches the concept of sending a message (via SMS for example) on a channel to change the state of a remote device (See example of changing the state of a device from a nonawake state to an awaken state) vs a different channel to obtain data from a device (such as WiFI, Bluetooth, etc).
It would have been obvious to one of ordinary skill in the art before the effective filing date of instant invention to combine the teachings of the cited references because teaching Bone’s would have allowed Nath’s to provide a method for managing devices more effectively, as noted by Bone (Paragraph 9).
Regarding claim 11, Nath further teaches a method comprising:
A) wherein the expiry time or duration is determined from information received with the request for the value of the first attribute (Paragraphs 35-36).
The examiner notes that Nath teaches “wherein the expiry time or duration is determined from information received with the request for the value of the first attribute” as “Suppose a user at the client device 104-1 wants to know a recent temperature at a specific geographic location. The user submits a query for the recent temperature at the target location along with a time constraint, such as a specified expiry time for the recent temperature, using the UI 116 rendered on the client device 104-1” (Paragraph 35) and “The server 102 receives the query and the query processing module 120 examines the query to determine the latitude and longitude of the target location. Subsequent to examination, the query processing module 120 reviews the data tree stored in the database 122 to identify a set of sensors having latitudes and longitudes within the target location and capable of providing sensor data that satisfies the time constraint. If the sensor data stored in the cache slots of the nodes associated with the set of sensors satisfy the time constraint, the sensor data may be presented to the user. Else, if the sensor data do not satisfy the time constraint, the query processing module 120 probes the set of sensors to obtain updated sensor readings, including temperature data. The updated sensor data is then formatted and presented to the user through the UI 116” (Paragraph 36). The examiner further notes that received user queries for sensor data (i.e. the claimed value of the first attribute) can include a time constraint that determines the claimed expiry time.
Regarding claim 12, Nath further teaches a method comprising:
A) wherein the request is associated with a particular device of the one or more devices (Paragraphs 30 and 35-36).
The examiner notes that Nath teaches “wherein the request is associated with a particular device of the one or more devices” as “The UI 116 allows users to specify spatial regions and a particular expiry time to identify a collection of sensors from which they wish to receive readings expiring after the particular expiry time. The sensors may be of any type including, for example, temperature sensors, video cameras, humidity sensors, wind sensors, traffic sensors, parking sensors, security sensors, and so on. In FIG. 1, representative sensors include a temperature sensor 118-1, a camera 118-2, a video camera 118-3, and any other sensors 118-4 (collectively referred to as sensors 118)” (Paragraph 30), “Suppose a user at the client device 104-1 wants to know a recent temperature at a specific geographic location. The user submits a query for the recent temperature at the target location along with a time constraint, such as a specified expiry time for the recent temperature, using the UI 116 rendered on the client device 104-1” (Paragraph 35), and “The server 102 receives the query and the query processing module 120 examines the query to determine the latitude and longitude of the target location. Subsequent to examination, the query processing module 120 reviews the data tree stored in the database 122 to identify a set of sensors having latitudes and longitudes within the target location and capable of providing sensor data that satisfies the time constraint. If the sensor data stored in the cache slots of the nodes associated with the set of sensors satisfy the time constraint, the sensor data may be presented to the user. Else, if the sensor data do not satisfy the time constraint, the query processing module 120 probes the set of sensors to obtain updated sensor readings, including temperature data. The updated sensor data is then formatted and presented to the user through the UI 116” (Paragraph 36). The examiner further notes that received user queries for sensor data (such a temperature data) is “associated” with temperature sensor 118-1 for example.
Regarding claim 13, Nath further teaches a method comprising:
A) wherein the request includes data indicating an expiration time of the requested value (Paragraphs 35-36).
The examiner notes that Nath teaches “wherein the request includes data indicating an expiration time of the requested value” as “Suppose a user at the client device 104-1 wants to know a recent temperature at a specific geographic location. The user submits a query for the recent temperature at the target location along with a time constraint, such as a specified expiry time for the recent temperature, using the UI 116 rendered on the client device 104-1” (Paragraph 35) and “The server 102 receives the query and the query processing module 120 examines the query to determine the latitude and longitude of the target location. Subsequent to examination, the query processing module 120 reviews the data tree stored in the database 122 to identify a set of sensors having latitudes and longitudes within the target location and capable of providing sensor data that satisfies the time constraint. If the sensor data stored in the cache slots of the nodes associated with the set of sensors satisfy the time constraint, the sensor data may be presented to the user. Else, if the sensor data do not satisfy the time constraint, the query processing module 120 probes the set of sensors to obtain updated sensor readings, including temperature data. The updated sensor data is then formatted and presented to the user through the UI 116” (Paragraph 36). The examiner further notes that received user queries for sensor data (i.e. the claimed value of the first attribute) can include a time constraint (i.e. the claimed expiration time) for requested sensor data (i.e. the claimed requested value).
Regarding claim 14, Nath further teaches a method comprising:
A) wherein the step of determining if the value of the first attribute has expired further comprises determining if a current time is not earlier than the expiration time of the requested value (Paragraphs 35-36 and 39).
The examiner notes that Nath teaches “wherein the step of determining if the value of the first attribute has expired further comprises determining if a current time is not earlier than the expiration time of the requested value” as “Suppose a user at the client device 104-1 wants to know a recent temperature at a specific geographic location. The user submits a query for the recent temperature at the target location along with a time constraint, such as a specified expiry time for the recent temperature, using the UI 116 rendered on the client device 104-1” (Paragraph 35), “The server 102 receives the query and the query processing module 120 examines the query to determine the latitude and longitude of the target location. Subsequent to examination, the query processing module 120 reviews the data tree stored in the database 122 to identify a set of sensors having latitudes and longitudes within the target location and capable of providing sensor data that satisfies the time constraint. If the sensor data stored in the cache slots of the nodes associated with the set of sensors satisfy the time constraint, the sensor data may be presented to the user. Else, if the sensor data do not satisfy the time constraint, the query processing module 120 probes the set of sensors to obtain updated sensor readings, including temperature data. The updated sensor data is then formatted and presented to the user through the UI 116” (Paragraph 36), and “The UI 116 further enables the user to specify freshness constraints/or time constraints of the sensor data in terms of how stale (or how recent) the sensor data is to be acceptable. For example, the user may specify that sensor data older than a particular time period (e.g., 10 minutes, 1 hour, 1 day, etc.) may not be acceptable. Thus, the user can obtain the latest sensor readings from all the locations” (Paragraph 39). The examiner further notes that received user queries for sensor data (i.e. the claimed value of the first attribute) can include a time constraint (i.e. the claimed expiration time) for requested sensor data (i.e. the claimed requested value). Such a time constraint can be specified as a time period which entails determining if the current time is earlier (or not) than the expiry time of the stored sensor data.
Response to Arguments
16. Applicant's arguments filed 03/17/2026 have been fully considered but they are not persuasive.
Applicants argue on Page 10 that “Applicant argued in previous Office Action responses that, while Mangan and Bone may each disclose some features of previously pending claims 4 and 7 that have been added to the independent claims, there is no teaching in either which would allow the skilled person to combine the teachings of Mangan and Bone without inventive effort”. However, in response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, the cited motivation of reducing the costs in locating data provides a motivation for the combination of the secondary references of Bone and Magnon. Specifically, the examiner provided detailed rational underpinning with a cited motivation in the obviousness rejection. Indeed, as explained thoroughly above, although Bone clearly teaches a first state that is lower-power and a second state that is higher power for devices, it does not teach the queuing of requests for unavailable devices at a first state until those devices are available at a second state. Nevertheless, Mangan teaches the concept of initially queuing query requests directed towards devices that are off-line (i.e. the claimed first state) before transmitting such queued query requests at a later point in time when those devices are ready (i.e. at a second state) to accept queries via agents. The combination would result in queuing (via Mangan) the user queries (of Nath) for unavailable devices (of Mangan) that are low-power (of Bone) until those devices are available (of Mangan) and of higher-power (of Bone).
Applicants argue on Pages 10-11 that “the Examiner continues to rely on paragraph [0375] of Bone, which discusses sending a wake-up message to a device. The Examiner considers the awake state to be the high-power state and the non-awake state to be the low-power state. However, as has been previously argued, the non-awake state of Bone is not a state where the device is "unable to provide the value", as required by the claimed invention”. However, the examiner wishes to refer to Bone which states “the synchroniser may be further configured to initiate a communication with the one or more devices when no communication with the one or more devices over the interface is available. Initiation of such a communication (e.g. a channel or interface) may be made. For example, a wake-up message may be sent to one or more devices. This may be over a different interface or channel, such as an SMS, fixed-line or over a mobile network, for example” (Paragraph 16) and “Wakeups—This is the mechanism used to wake-up an identified device and cause it to establish communications with the DM Server. The M2M platform security model may only allow Device wakeup to be triggered from the DM server using an SMS-MT. This has the advantage that devices can only be triggered to perform operations via the M2M platform environment (with its enforced P2P restriction mechanism)” (Paragraph 375). Specifically, Bone is used to teach the concept of a device having a first state that is in a lower-power mode versus a second state that is in a higher-power mode. Moreover, the examiner further wishes to refer to the instant application which states “If required, an attempt can be made to “wake up” the device by using SMS functionality or another direct communications channel, to prompt the device to supply the data more quickly (i.e. change from a low power state where the communications interface 210 is not in operation to a high power state when it is)” (Page 14, lines 8-11). Thus, just as the instant specification defines a first state that is low-power to be in a non-awaken state and a second state that is a higher-power to be in an awaken state, Bone (which is from the same assignee as the instant application (i.e. Vodafone)) also teaches the concept of sending a message (via SMS for example) on a different channel to change the state of a remote device (See example of changing the state of a device from a nonawake state to an awaken state). Such an awaken state (i.e. the claimed high power state) in Bone draws more power than a non-awaken state (i.e. the claimed low power state).
Additionally, the examiner wishes to refer to Magnon which states “once the indexes of ESI content are built on or from the local endpoint computing devices, the agents can communicate with the agent manager module 120 to confirm they are ready to accept queries. The credentialed user 102 can then interact with the memory and file processing computing system 108 via their computing device 104. Through this interaction, queries can be submitted to one of more agents 134, 136, 138 or to the index representation associated to the agents in the cloud, 168. Such queries can be any suitable type of query, such as using keywords, time parameters, file parameters, predictive coding, conceptual search, Boolean expressions, natural language processing (NLP) queries and so forth. The agent manager module 120 can provide the query to one or more (including all) of the agents 134, 136, 138. If any of the computing devices 128, 130, 132 are off-line at the time of the query, the query can be queued for transmission at a later point in time. Upon receiving the query, the agents 134, 136, 138 can query its index to identify any memory and file data 146, 152, 158 that satisfies the query (such memory and file data may be referred to as “identified ESI or malware”, which is a subset of the data stored locally on the device). The results of this identification step can then be provided by each agent 134, 136, 138 to the memory and file processing computing system 108. In some embodiments, copies of the identified memory and file data are provided to the memory and file processing computing system 108 over the network connection” (Paragraph 38). The examiner further notes that although Bone clearly teaches a first state that is lower-power and a second state that is higher power for devices, it does not teach the queuing of requests for unavailable devices at a first state until those devices are available at a second state. Nevertheless, Mangan teaches the concept of initially queuing query requests directed towards devices that are off-line (i.e. the claimed first state) before transmitting such queued query requests at a later point in time when those devices are ready (i.e. at a second state) to accept queries via agents. The combination would result in queuing (via Mangan) the user queries (of Nath) for unavailable devices (of Mangan) that are low-power (of Bone) until those devices are available (of Mangan) and of higher-power (of Bone).
Applicants argue on Page 11 that “Applicant further notes that in relation to the feature of: " at the time of a synchronisation for the second attribute, receiving the value of the first attribute and the value of the second attribute and providing the value of the first attribute in response to the request the Office Action cites paragraph [0062] of Bhaya. Applicant notes, however, that Bhaya does not disclose this feature. Paragraph [0062] of Bhaya specifies that, when polling sensors for their values, if the value of one of the sensors has not expired, the sensor should not be polled, and the value should be retrieved from memory instead”. However, the examiner wishes to refer to Bhaya which states “A selective sensor polling system for a voice activated data packet based computer network environment is provided. A system can receive audio signals detected by a microphone of a device. The system can parse the audio signal to identify trigger keyword and request. The system can select a template for an action data structure with a plurality of fields. The system can determine to poll a first sensor for data for the first field. The system can determine to obtain data in memory previously collected by the second sensor. The system can generate and transmit the action data structure with the data from the sensor and memory, and transmit the action data structure to a third party device” (Abstract) and “having a first sensor detect a first environmental condition (e.g., location, speed, temperature, ambient light, ambient sound, etc.), while retrieving, from memory, a second environmental condition that was previously detected by a second sensor. Rather than instruct the second sensor to go online or activate to detect the environmental condition, the sensor management component 120 can retrieve the previously detected value from memory to reduce resource utilization. For example, the sensor management component can poll a first sensor for data corresponding to the first field, while obtaining data from memory of the computing device 104 that corresponds to the second field. The second data can be stored in the memory of the computing device 104 prior to the data processing system 102 requesting the second data. The sensor management component 120 may not poll the second sensor 134 responsive to the request for data from the second sensor received from the direct action API 116. The sensor management component 120 can determine to poll the first sensor for data corresponding to the first field, but not to poll the second sensor for data corresponding to the second field. The sensor management component 120 can use a policy, logic, of set of rules to determine whether or not to poll one or more sensors. For example, the policy, logic, or set of rules can include, or be based, on conditional rules, if/then conditions, trigger events, tolerances, thresholds, time interval, location, geographical fencing, or type of activity. For example, the sensor management component 120 can determine to poll the first sensor for location information because the last location data received by the data processing system 102 may have expired based on a time interval (e.g., 10 seconds, 5 seconds, 20 seconds, 30 seconds, 1 minute or more). The data processing system 102 can obtain data from memory for the second sensor because the second sensor may be a temperature sensor and the data processing system 102 may determine that the timestamp of when the last temperature measurement was detected and stored in memory may satisfy a time interval (e.g., 1 minute, 2 minutes, 3 minutes, 5 minutes, 10 minutes, 20 minutes, 30 minutes or more)” (Paragraph 62). The examiner further notes that Bhaya teaches the concept of obtaining a different sensor value (a first attribute value) while obtaining another sensor value (i.e. the claimed second attribute value) for subsequent providing. Indeed, the independent claims merely require “further wherein the step of receiving the value of the first attribute when the value of the first attribute has expired further comprises the steps of: at the time of a synchronisation for the second attribute, receiving the value of the first attribute and the value of the second attribute and providing the value of the first attribute in response to the request”. There is no preclusion of receiving the value from the memory store in Bhaya. The combination would result in obtaining the first attribute values of Nath and Bone (which has its own interval) when performing synchronization for the second attribute values of Nath and Bone (which has a shorter interval).
Applicants argue on Page 11 that “In contrast, the present claimed invention specifies that, if data of a second attribute is being synchronized between the expiry of the first attribute and the time for synchronizing the first attribute, the first attribute can be synchronised before it would otherwise be done so (when the second attribute is synchronized). While this requires more data to be acquired during this event (and some data will be synchronized early), it means that the device can save energy (e.g., battery power) by avoiding the need to power on a second time”. However, the examiner wishes to refer to Chen which states “calculating the overdue time of the front terminal device storing the video data from the storage volume of the front end device distributes scanning identifying the expiration data, and deleting the stale data, the idle memory space of the storage volume of the front end device is distributed in time recovery to the corresponding storage array. wherein, the stale data is the storage time is earlier than the expiration time point of the video data. by deleting the stale data in time” (Paragraph 175). The examiner further notes that Chen teaches the concept of comparing an expiration time of data to a storage time for subsequent determination of staleness. The combination would result in performing such a comparison to determine the staleness of the data Nath (which already determines if a value of a first attribute has expired).
Applicants argue on Page 11 that “the independent claims now specify that: i. the first attribute has an expiry time or duration, and ii. the duration is shorter than the synchronisation interval of the first attribute. Applicant submits that the combination of the cited references fails to teach or suggest the amendments made herein”. However, the examiner wishes to refer to Nath which states “Techniques for collecting and displaying sensor data captured by a spatially and temporally representative sample of sensors requested in a search query are described. The sensors are represented in an index structure (e.g., a data tree) having a plurality of leaf nodes and internal nodes. The leaf nodes are associated with sensors and the internal nodes are allotted with caches having cache slots for storing sensor data with various expiry times” (Abstract), “The UI 116 allows users to specify spatial regions and a particular expiry time to identify a collection of sensors from which they wish to receive readings expiring after the particular expiry time. The sensors may be of any type including, for example, temperature sensors, video cameras, humidity sensors, wind sensors, traffic sensors, parking sensors, security sensors, and so on. In FIG. 1, representative sensors include a temperature sensor 118-1, a camera 118-2, a video camera 118-3, and any other sensors 118-4 (collectively referred to as sensors 118)” (Paragraph 30), “information regarding the expiry time of sensor data collected by the sensors may be stored in a database 122, which is illustrated as being stored in the remote storage device 108 (although it may be stored in other locations, such as within the system memory 112)” (Paragraph 32), and “Suppose a user at the client device 104-1 wants to know a recent temperature at a specific geographic location. The user submits a query for the recent temperature at the target location along with a time constraint, such as a specified expiry time for the recent temperature, using the UI 116 rendered on the client device 104-1” (Paragraph 35). The examiner further notes that sensor data (such as temperature data) from sensors 118 include stored expiry times that teaches the claimed expiry time.
Moreover, the examiner wishes to refer to Bone which states “a synchroniser configured to maintain synchronisation between the attributes stored in the memory store and the attributes associated with the devices” (Paragraph 9) and “the synchroniser may be further configured to operate at intervals. The intervals may be defined by a schedule (e.g. contact device A at time X, device B at time Y, etc.) or particular devices or groups of devices may be synchronised at a particular time interval (e.g. every X minutes). The interval or specified times may be pre-determined or dynamically set based on other criteria. For example, these times or intervals may be based on current network load and/or requirements for particular devices (certain groups of devices may then be synchronised more often than others—e.g. heart monitors). The intervals may be defined and stored as data or metadata either or both on the devices or within the device manager, for example. The synchroniser may also operate continuously” (Paragraph 17). The examiner further wishes to state that Bone (which is from the same assignee as the instant application (i.e. Vodafone)) teaches the concept of synchronizing device attributes and stored attributes via the use of intervals (including the use of different intervals for different attributes). Such different intervals entails that one interval is shorter than the other. Moreover, because such intervals are defined, then as a result they can be defined for any time (including a time that is longer than the expiry time of Nath). The combination would result in the use of such intervals when performing the synchronization of Nath.
Conclusion
17. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent 8,695,058 issued to Batchu et al. on 08 April 2014. The subject matter disclosed therein is pertinent to that of claims 1-2, 5-6, 11, 13-15, and 17-18 (e.g., methods to poll mobile devices for attribute data).
U.S. PGPUB 2015/0153810 issued to Sasidharan et al. on 04 June 2015. The subject matter disclosed therein is pertinent to that of claims 1-2, 5-6, 11, 13-15, and 17-18 (e.g., methods to poll mobile devices for attribute data).
Contact Information
18. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mahesh Dwivedi whose telephone number is (571) 272-2731. The examiner can normally be reached on Monday to Friday 8:20 am – 4:40 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Charles Rones can be reached (571) 272-4085. The fax 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).
Mahesh Dwivedi
Primary Examiner
Art Unit 2168
May 19, 2026
/MAHESH H DWIVEDI/Primary Examiner, Art Unit 2168
Prosecution Insights