DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1–20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1–20 are of U.S. Patent No. 12,394,298. Although the claims at issue are not identical, they are not patentably distinct from each other because they are obvious variants.
Instant claim 1 recites every limitation of patented claim 3 of US 12,394,298 (as it depends from patented claim 1) — determining by a cloud-based computing system that an emergency event is predicted to impact a customer premises at an upcoming time; responsive to the determining and before the upcoming time, causing one or more on-premises computing devices to collect and report context information; transmitting one or more messages interpretable by those devices to cause them to collect and report the context information; and the context information being selected from the group consisting of a number of people present at the customer premises and an operational status of one or more utilities or other systems at the customer premises — while omitting the further limitation of patented claim 1(ii) that the messages include "a set of program logic executable by the at least one on-premises computing device." Instant claim 1 is therefore a broader genus encompassing the patented species, and an applicant is not entitled to a second patent on a claim that is merely broader than one already patented.
The remaining instant claims correspond to the patented claims as follows, each being either identical in substance to, or a broader variant of, the corresponding patented claim. Instant claim 1 corresponds to patented claims 1 and 3, omitting the program-logic limitation of patented claim 1(ii). Instant claim 2 recites the same limitation as patented claim 2 taken with patented claim 3, and instant claim 3 recites the same limitation as patented claims 3 and 4, as does instant claim 4 with respect to patented claims 3 and 5. Instant claims 5 and 6 correspond to patented claims 3 and 6, the patented claim specifying times "defined in relation to the upcoming time," which encompasses times during and after the upcoming time. Instant claim 7 recites the same limitation as patented claims 3 and 7. Instant claim 8 corresponds to patented claims 1(ii) and 3, omitting the requirement that the program logic be included in the one or more messages. Instant claims 9, 10, and 11 correspond to patented claims 3 and 8, patented claim 8 reciting all three of the coordinating-device, capabilities-data, and device-indication limitations together, whereas each of the instant claims recites only a subset thereof.
As to the system claims, instant claim 12 corresponds to patented claims 9 and 12, omitting the program-logic limitation of patented claim 9(ii). Instant claim 13 recites the same limitation as patented claims 10 and 12; instant claim 14 the same limitation as patented claims 11 and 12; and instant claim 15 the same limitation as patented claims 12 and 13. Instant claim 16 corresponds to patented claims 12 and 14, reciting "during or after" in the alternative. Instant claim 17 recites the same limitation as patented claim 15. Instant claim 18 corresponds to patented claims 9(ii) and 12, omitting the requirement that the program logic be included in the messages. Instant claim 19 corresponds to patented claim 16, omitting the capabilities-data limitation. As to the medium claims, instant claim 20 corresponds to patented claims 17 and 18, omitting both the program-logic limitation of patented claim 17(ii) and the weather limitation.
Claims 1–20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1–20 of U.S. Patent No. 12,014,615. Although the claims at issue are not identical, they are not patentably distinct from each other because they are obvious variants.
Patented claim 1 of US 12,014,615, taken with patented claim 6, recites determining by a cloud-based computing system that an emergency event is predicted to impact a customer premises at an upcoming time, wherein there are multiple on-premises computing devices at the premises; responsive to that determining and before the upcoming time, causing one or more of those devices to collect and report context information selected from the group consisting of a number of people present at the customer premises and an operational status of one or more utilities or other systems at the customer premises; where the causing comprises selecting a given one of the multiple devices to be a coordinating device and causing the selected device to coordinate the collecting and reporting, including providing the selected device with an indication of one or more other on-premises computing devices to enable it to signal each and obtain the context information that device collected.
Instant claim 1 recites the same determining step, the same responsive-and-before causing step, and the same Markush group of context information, while omitting the coordinating-device limitations of patented claim 1(i) and 1(ii). Instant claim 1 is therefore a broader genus encompassing the patented species, and an applicant is not entitled to a second patent on a claim merely broader than one already patented. To the extent instant claim 1 further recites that the causing comprises "transmitting ... one or more messages interpretable by the one or more on-premises computing devices," that step is inherent in, or at minimum an obvious variant of, the patented claim's recited "providing the selected device with an indication of one or more other on-premises computing devices" and "causing ... the selected device to coordinate the collecting and reporting," each of which necessarily entails conveying to the device information the device can interpret and act upon.
Conversely, instant claims 9, 10, and 11 are substantially coextensive with patented claims 1 and 2. Instant claims 9 and 10 recite the coordinating-device selection, the causing of the selected device to coordinate, and the providing of an indication of one or more other on-premises computing devices to enable signaling therewith — the identical limitations recited in patented claim 1(i) and 1(ii). Instant claim 11 recites that the selection "is based on capabilities data of the given device," the identical limitation recited in patented claim 2. The differences, if any, reside solely in the additional recitation of interpretable messages carried in from instant claim 1, which for the reasons above is not a patentable distinction.
Instant claim 13 recites that the computing system is cloud-based and located remotely from the customer premises. Patented claim 1 recites determining "by a cloud-based computing system," and the further recitation that the system is located remotely from the premises is an obvious variant thereof.
The remaining instant claims correspond to the patented claims as follows, each being either coextensive with, or a broader variant of, the corresponding patented claim. Instant claim 2 recites the same weather and/or natural-disaster limitation as patented claim 5. Instant claim 3 recites a subset of the steps of patented claim 7, omitting the receiving-location and comparing steps thereof, and instant claim 4 recites the remainder of patented claim 7. Instant claims 5 and 6 correspond to patented claim 17, which specifies times "defined in relation to the upcoming time," encompassing times during and after; instant claim 7 recites the same before-and-after limitation as patented claim 18. Instant claim 8 recites the same program-logic limitation as patented claim 8. As to the system claims, instant claim 12 corresponds to patented claims 9 and 14, omitting the coordinating-device limitations of patented claim 9; instant claim 14 recites the same limitation as patented claim 13; instant claim 15 the same limitation as patented claim 15; instant claim 16 corresponds to patented claim 17, reciting "during or after" in the alternative; instant claim 17 recites the same limitation as patented claim 18; instant claim 18 the same limitation as patented claim 19; and instant claim 19 recites the coordinating-device and device-indication limitations of patented claim 9. As to the medium claims, instant claim 20 corresponds to patented claim 20 taken with patented claim 6, omitting the coordinating-device limitations of patented claim 20.
Claims 1–20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1–19 of U.S. Patent No. 11,763,656. Although the claims at issue are not identical, they are not patentably distinct from each other because they are obvious variants.
Instant claim 1 recites every limitation of patented claim 1 of US 11,763,656 — determining by a cloud-based computing system that an emergency event is predicted to impact a customer premises at an upcoming time; responsive to the determining and before the upcoming time, causing by the cloud-based computing system one or more on-premises computing devices at the customer premises to collect and report context information; transmitting from the cloud-based computing system to those devices one or more messages interpretable by them to cause them to collect and report the context information; and the context information comprising information selected from the group consisting of a number of people present at the customer premises and an operational status of one or more utilities or other systems at the customer premises — while omitting only the further limitation of patented claim 1(ii), namely "specifying in the one or more messages one or more times when the one or more on-premises computing devices should collect the context information, wherein each of the one or more times is defined in relation to the upcoming time when the emergency event is predicted to occur." Instant claim 1 is thus a broader genus wholly encompassing the patented species, and an applicant is not entitled to a second patent on a claim merely broader than one already patented. Instant independent claims 12 and 20 stand in the identical relationship to patented claims 11 and 19, respectively, each omitting only the corresponding "specifying ... times" limitation.
The dependent claims correspond substantially one-to-one. Instant claim 2 recites the same weather and/or natural-disaster limitation as patented claim 2; instant claim 3 the same two-step determining limitation as patented claim 3; and instant claim 4 the same receiving-and-comparing limitation as patented claim 4. Instant claims 5 and 6 each recite a single alternative of patented claim 5, which recites at least one collection time "during the upcoming time…or after the upcoming time," and instant claim 7 recites the same before-and-after limitation as patented claim 6. Instant claim 8 recites the same program-logic limitation as patented claim 7. Instant claim 9 recites the same coordinating-device selection and coordination limitations as patented claim 8; instant claim 10 the same device-indication and signaling limitation as patented claim 9; and instant claim 11 the same capabilities-data limitation as patented claim 10.
As to the system claims, instant claim 13 recites the same cloud-based-and-remote limitation as patented claim 12; instant claim 14 the same limitation as patented claim 13; instant claim 15 the same limitation as patented claim 14; instant claim 16 the same during-or-after limitation as patented claim 15; instant claim 17 the same before-and-after limitation as patented claim 16; instant claim 18 the same program-logic limitation as patented claim 17; and instant claim 19 the same coordinating-device, device-indication, and respective-signaling limitations as patented claim 18.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 18 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 18 recites "the at least one on-premises computing device," for which there is insufficient antecedent basis. Claim 12, from which claim 18 depends, recites "one or more on-premises computing devices" but does not recite "at least one on-premises computing device." It is further unclear whether the recited program logic is provided to, and executable by, all of the one or more on-premises computing devices or only a subset thereof. For purposes of examination, the limitation has been interpreted as reciting "at least one of the one or more on-premises computing devices," consistent with claim 8.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-3, 5-7, 12-17, 20 is/are rejected under 35 U.S.C. 102(a)(1) as anticipated by Vavrasek (US 2017/0352102 A1).
Regarding claim 1, Vavrasek discloses a method comprising:
determining by a cloud-based computing system (Vavrasek discloses at [0038]: "The prediction system 50 executes on one or more of the cloud-based server computers." See also [0028] ("remote, cloud-based server monitoring"); [0030] (servers/virtual servers 14 "running a 'cloud computing' paradigm"); [0112] (system 50 in cooperative relationship with business application servers 139a "in the cloud"); [0142] ("Servers interface to the sensor based state prediction system 50 via a cloud computing configuration"); [0131] ("external cloud based database").) that an emergency event is predicted to impact a customer premises at an upcoming time (Vavrasek discloses at [0115]: "The process 160 receives 162 an indication of an impending insurable event that may affect the physical premises." [0130]: "The computer analyzes the parsed indication according to the location of the physical premises to produce a likely prediction of damage to the physical premises." [0127] (indication received "from an external service or source such as a weather service"). [0131] ("potential for catastrophic damage"). Regarding "customer premises," see [0053]: "analyze historical and current sensor data records from one or more customer premises...expected for a customer site."); and
responsive to the determining and before the upcoming time (Vavrasek discloses at [0118]: "at a period of time prior to a likely occurrence of the insurable event." [0051]: the system "predicts if the premises will be in either a safe state or a drift state over a time period in the future," where "future" is "a defined window of time in the future, which is defined so that a response team has sufficient time to address a condition."), causing by the cloud-based computing system one or more on-premises computing devices (Vavrasek discloses at [0036]: sensor device 20 includes "a processor device 21a," "flash/persistent store 21b and volatile memory 21c," and "a network interface card 21d that interfaces the device 20 to the network 10." [0029]: "These sensor devices have a processor and memory...include a wireless network card." See also gateways 16 ([0031]) and intrusion panel 38 ([0037]), both located at the premises.) at the customer premises to collect (Vavrasek discloses at [0118]: "The process sends the commands that modify the operation of one or more sensors at the physical premises at a period of time prior to a likely occurrence of the insurable event." [0116]: "These commands cause the specific sensors to collect sensor information in a different manner that prior to execution of the command." [0117]: commands include "requesting a reading from a sensor that is in a periodic schedule mode, where a reading from the sensor is required more frequently than scheduled.") and report context information (Vavrasek discloses at [0005]: "collect sensor information from the plurality of sensor devices deployed at the premises, and store the sensor information in a remote persistent storage system." [0131]: "the computer produces a request to upload service and usage data from specific monitored units within the premises to an external cloud based database, by sending to the system at the physical premises the request to upload to the external database, the service and usage data."), wherein causing the one or more on-premises computing devices at the customer premises to collect and report context information comprises transmitting from the cloud-based computing system to the one or more on-premises computing devices one or more messages interpretable by the one or more on-premises computing devices to cause the one or more on-premises computing devices to collect and report the context information (Vavrasek discloses at [0115]: "The algorithm produces 166 one or more messages that are sent 168 to various sensors... These messages in the form of data packets including address information and a payload are parsed 170 at the sensors and provide commands 172 that modify operation of one or more specific sensors." [0116] gives the express message syntax: Command <address of device> <command> <data>.), and wherein the context information comprises information selected from the group consisting of (i) a number of people present at the customer premises and (ii) an operational status of one or more utilities or other systems at the customer premises (Vavrasek discloses at [0131]: "service and usage data from specific monitored units within the premises." [0103]: "operational conditions of the various systems within the premises. Examples of such systems include intrusion detection systems, fire alarm systems, public annunciation systems, burglar alarm systems, the sensors deployed at the premises, as well as other types of equipment, such as refrigeration equipment, stoves, and ovens." [0056]–[0062] and [0073]–[0075] report operational status expressly: "Outdoor security panel: Active, Kitchen Lights: On, Delivery Door: Shutdown." [0140]: "operational data that shows operational performance of the system/equipment ID before the event and after the event.").
Regarding claim 2, Vavrasek discloses the method of claim 1, wherein the emergency event comprises a weather and/or natural-disaster event (Vavrasek teaches that "the indication is a received indication from an external service or source such as a weather service" ([0127]), and that "the computer executes an algorithm that processes a weather-related event, when the indication is a received indication from an external service that indicates a weather-related event," which the computer "parse...to produce a representation of the indication that identifies the type of weather-related event" and then "analyzes...according to the location of the physical premises to produce a likely prediction of damage to the physical premises" ([0130]; see also [0009] and Vavrasek claim 9). Vavrasek further characterizes such events as involving "potential for catastrophic damage" ([0131]) and identifies the associated data streams as including "weather data, seismic data" ([0135]).).
Regarding claim 3, Vavrasek discloses the method of claim 1, wherein determining by the cloud-based computing system that the emergency event is predicted to impact the customer premises at the upcoming time comprises: receiving by the cloud-based computing system from an emergency-prediction system a notification that the emergency event is predicted to occur at a location (Vavrasek's cloud-based system "receives 162 an indication of an impending insurable event that may affect the physical premises" ([0115]), where "the indication is a received indication from an external service or source such as a weather service" ([0127]; "The message is received from an external service," [0008]). The system is instructed to "receive the indication from an external service, the indication being of the weather-related event, parse the received indication to produce a representation of the indication that identifies a type of weather-related event" ([0009]; [0130]; Vavrasek claim 9). The indication conveys the predicted event's location, as the system thereafter operates on "a location of the predicted event" ([0008]).); and determining by the cloud-based computing system that the location where the emergency event is predicted to occur corresponds with a location of the customer premises (Vavrasek's system "analyzes the parsed indication according to the location of the physical premises to produce a likely prediction of damage to the physical premises" ([0130]; [0009]), and correspondingly "determine[s] sensor devices that are in proximity to a location of the predicted event" based on "specific locations of the sensor devices" ([0008]). Vavrasek further resolves the correspondence at sub-premises granularity: "if the prediction predicts damage to a specific portion of the premises the sensors in that portion can have their operation modified" ([0130]).).
Regarding claim 5, Vavrasek discloses the method of claim 1, wherein the one or more messages cause the one or more on-premises computing devices to collect and report the context information during the upcoming time when the emergency event is predicted to occur (Vavrasek teaches that the messages sent before the predicted occurrence ([0118]) "cause the specific sensors to collect sensor information in a different manner that prior to execution of the command by the sensor" ([0116]), and the resulting collection spans a continuous window bracketing the event: "the increase in sensor data is controlled by the system to occur over a time period prior to and after a potential identified incident" ([0134]), capturing "sensor data, especially video data, from corresponding sensors, just prior to and following an identified incident" ([0003]) and "data that is specifically stored for a pre-set time before the incident and for a pre-set time after the incident" ([0135]). A single collection window running from before the event to after it necessarily encompasses the event itself. Vavrasek expressly confirms collection during the event, disclosing records of "the actual conditions of the premises as measured by the sensor data and the calculated states...showing the events before the insured event happened and possibly during the insured event," comprising "a set of records...for historical state transitions (several before and during and after event, if any)" ([0140]). The collected information is reported to and stored at the remote system ([0005]; [0131]).).
Regarding claim 6, Vavrasek discloses the method of claim 1, wherein the one or more messages cause the one or more on-premises computing devices to collect and report the context information after the upcoming time when the emergency event is predicted to occur (Vavrasek's stated object is to capture sensor data "from corresponding sensors, just prior to and following an identified incident" ([0003]), and the messages sent before the predicted occurrence ([0118]) accordingly cause collection over a window extending past the event: "the increase in sensor data is controlled by the system to occur over a time period prior to and after a potential identified incident" ([0134]), including "data that is specifically stored for a pre-set time before the incident and for a pre-set time after the incident" ([0135]). Vavrasek confirms that state records are captured on both sides of the event — "a set of records ... for historical state transitions (several before and during and after event, if any)" — and that the reported operational data "shows operational performance of the system/equipment ID before the event and after the event" ([0140]). Vavrasek further discloses reporting the post-event context information. Upon "an actual occurrence of the insurable event," the system requests and extracts "service and usage data for one or more monitored units within the premises" ([0128], [0138]) and reports it, populating the record with "the extracted operational data for each specific piece of equipment based upon service and usage records...and sensor states prior to and subsequent to the insured event" ([0139]; [0129]).).
Regarding claim 7, Vavrasek discloses the method of claim 1, wherein the context information comprises context information as of before the predicted emergency event impacts the customer premises and context information as of after the predicted emergency event impacts the customer premises (Vavrasek expressly collects and retains data on both sides of the event: the captured data includes "data that is specifically stored for a pre-set time before the incident and for a pre-set time after the incident" ([0135]), consistent with Vavrasek's object of capturing sensor data "just prior to and following an identified incident" ([0003]) over "a time period prior to and after a potential identified incident" ([0134]). The information so collected is the operational-status context information relied upon for claim 1. Vavrasek's records comprise "the extracted operational data that shows operational performance of the system/equipment ID before the event and after the event," together with "a set of records ... for historical state transitions (several before and during and after event, if any), sensor semantic records, and service records all pertaining to the specific ID equipment/system" ([0140]). Those records are populated with "sensor states prior to and subsequent to the insured event" ([0139]), and reflect "the actual conditions of the premises as measured by the sensor data and the calculated states" ([0140]) — the operational status of premises systems recited in claim 1 ([0060]–[0062], [0103]).).
Claim 12 is rejected under 35 U.S.C. 102(a)(1) as being anticipated by Vavrasek, for the same reasons set forth with respect to claim 1 above. Claim 12 is directed to a system comprising operations corresponding to the steps of claim 1, and further omits the "cloud-based" limitation of claim 1; the teachings of Vavrasek that anticipate claim 1 therefore likewise anticipate the recited operations of claim 12. As to the recited structure, Vavrasek discloses "a server computer comprising processor and memory, the server computer coupled to a network; a storage device storing a computer program product...comprising instructions to cause the server to" perform the operations (claim 13), where servers "include one or more processing devices (e.g., microprocessors), a network interface and a memory" ([0146]) and the network interface card "interfaces with the network to receive incoming signals" ([0149]). The data storage is non-transitory, being embodied in "tangible, physical hardware storage devices" ([0150]) including "all forms of non-volatile storage" ([0153]).
Regarding claim 13, Vavrasek discloses the computing system of claim 12, wherein the computing system is cloud-based and located remotely from the customer premises (Vavrasek's prediction system 50 "executes on one or more of the cloud-based server computers" ([0038]; see also [0028], [0112], [0142]), and those servers reside in "an upper tier or hierarchical level 12a of the network" ([0030]), remote from the middle-tier gateways 16 "located at central, convenient places inside individual buildings and structures" ([0031]) and from the lower-tier sensor devices deployed at the premises ([0032], [0037]). Vavrasek further discloses that the gateway devices "communicate with servers 14 in the upper tier whether the servers are stand-alone dedicated servers and/or cloud based servers running cloud applications" ([0031]), and that the system uploads premises data "to an external cloud based database" ([0131]).).
Claim 14 is rejected under 35 U.S.C. 102(a)(1) as being anticipated by Vavrasek. Claim 14 recites the same limitation as claim 2, differing only in depending from system claim 12 rather than method claim 1. Vavrasek discloses the computing system of claim 12 as set forth above, and anticipates the added limitation for the same reasons set forth with respect to claim 2.
Claim 15 is rejected under 35 U.S.C. 102(a)(1) as being anticipated by Vavrasek, for the same reasons set forth with respect to claim 3 above. Vavrasek discloses the computing system of claim 12 as set forth above. Claim 15 recites operations corresponding to the steps of claim 3, and further omits the "by the cloud-based computing system" recitations of claim 3; the teachings of Vavrasek that anticipate claim 3 therefore likewise anticipate the recited operations of claim 15.
Claim 16 is rejected under 35 U.S.C. 102(a)(1) as being anticipated by Vavrasek. Vavrasek discloses the computing system of claim 12 as set forth above. Claim 16 recites the limitations of claims 5 and 6 in the alternative — collection and reporting "during" or "after" the upcoming time — and is therefore satisfied by disclosure of either alternative. Vavrasek anticipates both alternatives for the reasons set forth with respect to claims 5 and 6 above.
Claim 17 is rejected under 35 U.S.C. 102(a)(1) as being anticipated by Vavrasek. Claim 17 recites the same limitation as claim 7, differing only in depending from system claim 12 rather than method claim 1. Vavrasek discloses the computing system of claim 12 as set forth above, and anticipates the added limitation for the same reasons set forth with respect to claim 7.
Claim 20 is rejected under 35 U.S.C. 102(a)(1) as being anticipated by Vavrasek, for the same reasons set forth with respect to claim 1 above. Claim 20 recites operations corresponding to the steps of claim 1, and further omits the "by the cloud-based computing system" recitations of claim 1 and the "through the network communication interface" recitation of claim 12; the teachings of Vavrasek that anticipate claim 1 therefore likewise anticipate the recited operations of claim 20. As to the recited article, Vavrasek discloses "A computer program product tangibly stored on a computer readable hardware storage device...the computer program product comprising instructions to cause a processor to" perform the recited operations (claim 1), the instructions being "tangibly embodied in one or more tangible, physical hardware storage devices that are computer and/or machine-readable storage devices" ([0150]) and encompassing "all forms of non-volatile storage...semiconductor storage area devices, e.g., EPROM, EEPROM, and flash storage area devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks" ([0153]).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vavrasek (US 2017/0352102 A1) in view of Moon (US 10,547,918 B1).
Regarding claim 4, Vavrasek discloses the method of claim 3, but does not expressly disclose the method further comprising (i) receiving by the cloud-based computing system, from at least one of the one or more on-premises computing devices at the customer premises, information indicating the location of the customer premises, wherein (ii) determining by the cloud-based computing system that the location where the emergency event is predicted to occur corresponds with a location of the customer premises comprises comparing by the cloud-based computing system the location where the emergency event is predicted to occur with the indicated location of the customer premises and thereby determining that the location of where the emergency event is predicted to occur overlaps with or is within a predefined short distance of the indicated location of the customer premises. Vavrasek teaches the method of claim 3 for the reasons set forth above, including comparing the predicted event location against the premises location: the system "analyzes the parsed indication according to the location of the physical premises to produce a likely prediction of damage to the physical premises" ([0130]; [0009]), and "determine sensor devices that are in proximity to a location of the predicted event" based on "specific locations of the sensor devices" ([0008]).
As to limitation (i), Moon's remote computing device 10 receives premises location data from an on-premises device. The central hub 14 "is typically located within the house" and "in certain embodiments comprises a smart home controller" (col. 4), and processing element 22 "may receive data from either the central hub 14 and/or the sensors 12" (col. 6) over "one or more radio links, via wireless communication or data transmission" (col. 17). That data expressly includes the premises' position: the location is "determined from a GPS coordinates within the second set of data (such as GPS location of a smart home controller, smart vehicle, or mobile device)" (col. 17; see also col. 19). As to limitation (ii), Moon compares that reported location against the predicted event area and determines overlap or proximity. Moon generates "a geographic boundary of an area associated with the insurance-related event, or an actual or forecast extent thereof" (col. 17), the boundary encompassing "areas that appear to be or are likely to be affected" and including "additional space along its borders to allow for errors in prediction, such as errors in predicting wind pattern and direction of storm movement" (col. 7; col. 11). Moon then "determine that a GPS location of a customer is within, or may be in proximity, to the geographic boundary or the event" (col. 17; col. 19), and "determine that the GPS location of the customer is within the geographic boundary for the area associated with the event" (col. 15–16; col. 18).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify Vavrasek so that the cloud-based system receives the premises location from an on-premises computing device and determines that the predicted event location overlaps with or is within a predefined short distance of that location, as taught by Moon, because Vavrasek already requires the premises location in order to "analyze the parsed indication according to the location of the physical premises" ([0130]) and to identify devices "in proximity to a location of the predicted event" ([0008]), and Moon teaches the conventional means of obtaining and applying that location — a GPS position reported by the premises' smart home controller (col. 17), compared against a forecast event boundary that expressly carries a margin "to allow for errors in prediction" (col. 7); a skilled artisan would have been motivated to adopt Moon's approach because Moon teaches that identifying the boundary "may permit identification of individual resident(s) in the area...who may need to be contacted regarding potential damage" (col. 7; col. 11–12), a benefit of direct significance in Vavrasek, whose cloud system serves "a large plurality of sensors deployed in various premises throughout an area" ([0039]) and must therefore determine which of many premises a predicted event will reach; and having the premises report its own position, rather than relying on static configuration (Vavrasek [0109]), yields the predictable benefit of location data that remains accurate without manual re-entry. The combination applies a known technique to improve a similar system in the same way, with a reasonable expectation of success given that both references describe a remote/cloud server that receives data from premises devices and commands them in anticipation of a predicted damaging event.
Claim(s) 8, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vavrasek (US 2017/0352102 A1) in view of Brown (US 2006/0259332 A1).
Regarding claim 8, Vavrasek discloses the method of claim 1, but does not expressly disclose wherein causing by the cloud-based computing system one or more on-premises computing devices at the customer premises to collect and report context information comprises providing at least one of the one or more on-premises computing devices with a set of program logic executable by the at least one on-premises computing device to cause the at least one on-premises computing device to collect and report the context information. Vavrasek teaches the cloud-based system causes on-premises computing devices to collect and report context information by transmitting messages that are "parsed at the sensors and provide commands" ([0115]) which "cause the specific sensors to collect sensor information in a different manner that prior to execution of the command by the sensor" ([0116]). Vavrasek's on-premises devices are programmable, each having a processor 21a and persistent store 21b ([0036]) and storing "program instructions" and "software components" executable thereon ([0145]–[0146]).
Brown discloses a server that provisions an on-premises apparatus with executable logic directed to collecting and reporting. Server 218 stores script programs 240, which "are executed by each apparatus e.g., 226/232, to...collect measurements 244, and to transmit responses 242 and measurements 244 to server 218," and "Each remotely programmable apparatus...is designed to execute assigned script programs 240 received from server 218" ([0091]). The measurements are of premises equipment: each monitored device "is also provided with a sensor 228...designed to produce measurements of a parameter associated with the operation of the power device," such as "room temperature, power consumption, and humidity" ([0090]), at sites including "a home in which many power devices (e.g., refrigerator, freezer, heating, air conditioning) are in constant or frequent use" ([0048]). Brown teaches both the provisioning step and device-side execution. "Server 218 transmits the assigned script program to the power device's remotely programmable apparatus through communication network 224" ([0114], step 518); the apparatus, "initially programmed with...the script interpreter used by microprocessor 276 to execute the script program," thereafter "receives from server 218 the script program assigned to the power device," which is "stored in memory 280" ([0116]; [0095]). The script itself contains the collect-and-report logic — Brown's script command set includes "COLLECT: device{LF} Collect measurements from the monitoring device specified in the COLLECT command" and "CONNECT: {LF} Perform a connection routine to establish a communication link to the server, transmit the...device measurements...to the server" ([0102], Table 1; [0104]). On execution, the apparatus "collects device measurements 244 from sensor 228" ([0119]) and "transmits the device measurements 244...to server 218" ([0121]). Brown further teaches generally that "program instructions may be downloaded from the clearinghouse server to adapt or reconfigure the microprocessor or the power device" ([0039]) and that memory is provided "that allows external programs (e.g., programs provided by clearinghouse 54) to be stored and executed" ([0085]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify Vavrasek so that the cloud-based system provides an on-premises computing device with a set of executable program logic to cause it to collect and report the context information, as taught by Brown, because Vavrasek must elicit differing collection behavior from heterogeneous premises devices depending on "specific locations of the sensor devices and specific types of the sensor devices" ([0008]) and on the type of predicted event ([0130]), and acknowledges its command vocabulary as open-ended — "Many other commands can be provided" ([0117]) — such that a skilled artisan would have been motivated to adopt Brown's approach of downloading the collection-and-reporting logic itself rather than pre-building every behavior into every device, obtaining Brown's predictable benefit that a device once provisioned with a script interpreter can thereafter execute any script the server assigns and, upon reporting, "receive and store a new script program" so that "the script interpreter is restarted, allowing the new script program to execute" ([0102]; [0121]), without reprogramming the device; and success would have been reasonably expected because Vavrasek's sensor devices already include a processor, persistent storage, and stored program instructions ([0036], [0145]–[0146]), and both references describe a remote server directing premises-located devices to collect sensor measurements concerning premises equipment and transmit them back.
Claim 18 is rejected under 35 U.S.C. 103 as unpatentable over Vavrasek (US 2017/0352102 A1) in view of Brown (US 2006/0259332 A1). Vavrasek discloses the computing system of claim 12 as set forth above. Claim 18 recites operations corresponding to the steps of claim 8, and the combination of Vavrasek and Brown teaches those operations for the reasons set forth with respect to claim 8 above. To the extent claim 18 recites providing the program logic to "the one or more on-premises computing devices" rather than to at least one of them, Brown teaches providing the script program to each of a plurality of premises apparatuses, disclosing that "Each remotely programmable apparatus, e.g., 226/232, is designed to execute assigned script programs 240 received from server 218" ([0091]) and that the server "to assign to each of the plurality of apparatuses at least one of the plurality of script programs" (claim 23; [0105]–[0106], [0111]).
Claim(s) 9, 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vavrasek (US 2017/0352102 A1) in view of Matsuoka (US 2016/0259307 A1).
Regarding claim 9, Vavrasek discloses the method of claim 1, wherein there are multiple on-premises computing devices at the customer premises (Vavrasek discloses "a plurality of sensor devices that collect sensor information at the physical premises" ([0005]), a plurality of detectors/sensors 20 "disbursed throughout the physical premises" ([0037]), and further on-premises equipment including gateways 16 "located at central, convenient places inside individual buildings and structures" ([0031]) and intrusion detection panel 38 ([0037]). Each sensor device 20 is a computing device having processor 21a, persistent store 21b, volatile memory 21c, and network interface card 21d ([0036]).).
However, Vavrasek does not expressly disclose the method further comprising: (i) selecting by the cloud-based computing system a given one of the multiple on-premises computing devices to be a coordinating device, and (ii) causing by the cloud-based computing system the selected device to coordinate the collecting and reporting of the context information. Vavrasek discloses the cloud system determines sensor devices that are in proximity to a location of the predicted event, determines modifications to sensor devices in proximity to the location, which modifications are based on the predicted event, specific locations of the sensor devices and specific types of the sensor devices, determines the commands based on the determined modifications and sends the commands to the one or more specific sensor devices ([0008]; see also [0004]). To do so the cloud system accesses "a stored computer representation (e.g., as a graph or the like) that provides a mapping of all sensors in a premises such that the computer determines what sensors to modify operation of and what the modifications would be" ([0122]).
Matsuoka discloses a premises management system 100 that includes multiple premises management devices (thermostats 120, hazard detectors 130, entry detectors 140, door handles 150), each having a processor 64 and memory 65 ([0018], [0028]). As to limitation (i), one such device is designated the "primary system processor" — a central "brain" that "may coordinate decision making across the system 100" and at which "data from different detectors converge" ([0021]). Matsuoka discloses the selecting act, in that a device's "capability of providing system-level work may be assessed" and "Based on the assessment, the device 60 may or may not be assigned" to that role ([0041]; FIG. 3, ops. 320–350), and further discloses that the role may reside in a single given device ([0049], [0056], [0060]). Matsuoka also discloses a cloud-based designating entity, teaching that the primary system processor may be "implemented at least in part by one or more processors in an external system" (claim 8), namely "a cloud-based reporting and/or analysis system" ([0069]). As to limitation (ii), Matsuoka teaches that "The management and coordination of such data from all premises management devices...is the function of the primary system processor" ([0037]), which "receive, aggregate, and/or analyze" sensor information ([0069]), and that those functions include "synthesizing, analyzing and reporting data from different sensor and processor components" ([0014]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify Vavrasek so that the device selected by its cloud-based system is designated a coordinating device that coordinates the collecting and reporting, as taught by Matsuoka, because Matsuoka teaches that this arrangement avoids "contention and race conditions among the interconnected devices" ([0021]) while "minimizing an amount of data transmission within the system" ([0045]) — benefits directly responsive to Vavrasek's acknowledged constraints, its devices having "a small-to-moderate amount of processing power and memory" and being battery powered ([0033]), and its stated goal being denser pre-event data with "a minimal increase in overall processing and network traffic" ([0134]); the cloud would perform the selection because Vavrasek already locates device selection there ([0008], [0122]) and Matsuoka expressly contemplates a cloud-based designating entity (claim 8; [0069]), so no relocation of that function is needed; and the combination is the use of a known technique to improve a similar system in the same way, with a reasonable expectation of success given that both references describe premises sensor networks communicating with a remote cloud system.
Regarding claim 11, Vavrasek in view of Matsuoka discloses the method of claim 9, wherein selecting the given device to be the coordinating device is based on capabilities data of the given device (Matsuoka teaches that the selection is capability-based: a device's "capability of providing system-level work may be assessed. Based on the assessment, the device 60 may or may not be assigned" to the primary system processor unit ([0041]). The device "submits specification and configuration data" ([0043]), which the system compares against that of the current devices to determine whether the new device is "qualified" for the role ([0044]); it "evaluates the capabilities of the new device, compares them against the present capabilities of thermostat 120, and determines whether the new device should be assigned" ([0050]). The enumerated factors are "respective levels of electrical power available, respective types of electrical power available, respective levels of computational power available, respective levels of network access, respective versions of operating system software" ([0045]; see also [0015]), directed to objectives including "increasing the speed/computational power" and "increasing the memory" ([0045]). Matsuoka's example selects the garage door opener "based on the availability of 120V AC power together with a high-capacity battery backup" ([0056]). See also Matsuoka claims 4, 5, 16, 22. These correspond to Applicant's definition of capabilities data — "the device's data storage capacity and processing speed" (PGPUB spec [0032]) and "storage capacity, processor speed, power type (e.g., whether the device has a backup power source)" (PGPUB spec [0061]). The rationale set forth in the rejection of claim 9 applies, and no further modification is required because capability-based selection is the manner in which Matsuoka performs the selection already relied upon; in any event, it would have been obvious to one of ordinary skill in the art before the effective filing date to select the coordinating device based on capabilities data, because Matsuoka teaches that suitability for the coordinating role turns on available power, computational capability, memory, and network access ([0015], [0045]), and that selecting on that basis advances the objectives of "increasing the speed/computational power," "increasing the memory," and "minimizing an amount of data transmission within the system" ([0045]) — considerations of direct significance in Vavrasek, whose premises devices include severely constrained nodes having "a small-to-moderate amount of processing power and memory" that are "often battery powered" ([0033]) with storage of "about a megabyte...or less" ([0036]), such that assigning the coordinating role without regard to capability risks assigning it to a device unable to perform it.).
Claim(s) 10, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vavrasek (US 2017/0352102 A1) in view of Matsuoka (US 2016/0259307 A1) and Bicket (US 2017/0164193 A1).
Regarding claim 10, Vavrasek discloses the method of claim 9, but does not expressly disclose wherein causing by the cloud-based computing system the selected device to coordinate the collecting and reporting of the context information comprises providing the selected device with an indication of one or more other on-premises computing devices at the customer premises, to enable the selected device to engage in signaling with each other indicated on-premises computing device to obtain context information collected by the indicated on-premises computing device. Vavrasek further teaches that the cloud-based system maintains "a mapping of all sensors in a premises" ([0122]) and addresses premises devices individually by "address of device" ([0116]); Matsuoka teaches that premises devices "may be configured to communicate with one another" ([0034]).
Bicket discloses a sensor network in which management server 140 is "a cloud based server operative to receive from one or more wireless sensing device...sensor measurements through one or more gateway devices," each gateway being "operative to connect with more than one wireless sensing device...tens (or hundreds)" of them ([0040]), grouped by location such that "devices from a same group may be located within a same room, a same warehouse" ([0073]) and monitoring "humidity and/or temperature at various locations within a room or a building" ([0098]). The server provides the gateway with the device roster: "the management server 140 transmits the wireless sensing device identifiers of the set of one or more of the wireless sensing devices to each of the gateway devices associated with the organization" ([0075], operation 706; see also [0077], operation716), the identifier being a "Media Access Control (MAC) address" ([0072]). The gateway uses that roster to signal each device and obtain its data: "the gateway device may receive from the management server 140 a list of identifiers of WSDs with which it can connect...it verifies that this identifier is included in the list of authorized wireless sensing devices and establishes a connection with the WSD 115" ([0042]; see also [0050], [0090]), whereupon "The WSD 115 may transmit any recorded sensor measurements to the gateway device" ([0043]; [0044]), which the gateway then "transmits...to the management server 140" ([0047]; [0050], blocks 240–270).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to further modify the Vavrasek/Matsuoka combination to provide the selected coordinating device with an indication of the other on-premises computing devices, as taught by Bicket, because a device assigned to coordinate collection must know which devices to collect from, and Bicket teaches the conventional mechanism for supplying that — a server-provided list of device identifiers the coordinator uses to connect to each device and offload its measurements ([0042], [0075]); Vavrasek already holds the necessary inventory in its cloud-side "mapping of all sensors in a premises" ([0122]), so distributing it to the coordinator is an extension of existing capability rather than a new one; and the skilled artisan would have recognized the predictable benefit Bicket identifies — allowing local offload to proceed and be buffered at the gateway when "there is not currently a secure communication channel...with the management server 140," and forwarded once connectivity returns ([0046]; [0050], blocks 260–270) — a benefit of particular value in Vavrasek, where the predicted event may sever the premises' WAN connection before the data can be reported. The combination uses a known technique to improve a similar system in the same way, with a reasonable expectation of success given that all three references describe the same three-tier architecture of premises sensing devices, a premises gateway, and a remote cloud server (Vavrasek [0030]–[0034] with Bicket [0038]–[0040]).
Claim 19 is rejected under 35 U.S.C. 103 as unpatentable over Vavrasek (US 2017/0352102 A1) in view of Matsuoka et al. (US 2016/0259307 A1) and further in view of Bicket et al. (US 2017/0164193 A1). Vavrasek discloses the computing system of claim 12 as set forth above. Claim 19 recites operations corresponding to the steps of claims 9 and 10 combined — selecting a given one of multiple on-premises computing devices to be a coordinating device and causing it to coordinate the collecting and reporting (claim 9), and providing the selected device with an indication of one or more other on-premises computing devices to enable it to signal each and obtain the context information that device collected (claim 10). Claim 19 further omits the "by the cloud-based computing system" recitations of claims 9 and 10. The combination of Vavrasek, Matsuoka, and Bicket teaches those operations, and the rationale for combining the references is set forth, for the reasons given with respect to claims 9 and 10 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAJSHEED O BLACK-CHILDRESS whose telephone number is (571)270-7838. The examiner can normally be reached M to F, 10am to 5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Quan-Zhen Wang can be reached at (571) 272-3114. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/RAJSHEED O BLACK-CHILDRESS/Examiner, Art Unit 2685
Prosecution Insights