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 .
Applicant’s Response
In Applicant’s response dated 12/30/2025, Applicant amended Claims 1, 7, 11 and 17; and argued against all rejection s previously set forth in the Office Action dated 09/30/2025.
In light of Applicant’s amendments and remarks, the previously set forth rejections under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, are withdrawn.
Status of the Claims
Claim(s) 1, 2, 5 – 8, 11, 12 and 15 – 18 are rejected under 35 U.S.C. 102(a)(1)/102(a)(2) and Claim(s) 3, 4, 9, 10, 13, 14, 19 and 20 are rejected under 35 U.S.C. 103.
Examiner Note
The Examiner cites particular columns, line numbers and/or paragraph numbers in the references as applied to the claims below for the convenience of the Applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Claim Rejections - 35 USC § 102
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.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 2, 5 – 8, 11, 12 and 15 – 18 are rejected under 35 U.S.C. 102(a)(1)/102(a)(2) as being anticipated by Schwartz et al. (US 2022/0070014) (hereinafter, Schwartz) (Cited in IDS dated 01/05/2024).
Regarding Claim 1, Schwartz teaches an access controller of a communications network (See Schwartz’ Abstract), the access controller comprising a processor (Schwartz in par 0024, teaches a “user device” refers to any device having a central processing unit (“CPU”) capable of performing computing functions and having the ability to communicate with other devices either through a wireless communication system or a wired communication system such as: smartphones, tablet computers, smart watches, laptop computers, desktop computers, or other similar devices) configured to:
send a smart-device access request to a network server of the communications network (Schwartz in par 0027, teaches that each system may be configured to communicate over any suitable communication network 110 with one or more of the other systems. An infrastructure control system 108 may be configured to control and manage each connected system. Schwartz in par 034 and Fig. 2, further teaches that a user device 114 may read a NFC tag 210 on the controllable smart device 300 having an assigned URI, device identifier (“ID”), and a set of action information. The URI causes the mobile software application 112 on the user device 114 to open. The device ID and action information are passed to the mobile software application 112, which validates whether the user device 114 (e.g., resident, guest, or property manager) has the authorization to control or monitor that particular smart device 300);
receive a smart-device access advertisement (Schwartz in par 0047 and Fig(s). 4 – 5, further teaches that the first step of the transaction is for a community controllable smart device 300 to broadcast a unique device ID through a Bluetooth Low Energy (BLE) advertisement (402). The mobile software application 112 provides the user device 114 with a list of known device IDs with which it is allowed to communicate. The user device 114 may repeatedly scan for all device IDs and display to the user (e.g., via graphic user interface (“GUI”) of the mobile software application 112) if the community controllable smart device 300 matches one of the device IDs in the list of all permitted community controllable smart devices) based at least in part on:
the network server receiving the smart-device access request (Schwartz in par 0047, further teaches that once the user has selected the desired community controllable smart device 300, the user device 114 starts a near-field communication (NFC) scan. The user presents the user device 114 to the community controllable smart device 300 and the user device 114 reads the NFC tag 210 presented by the community controllable smart device 300. Schwartz in par 0075, further teaches that the infrastructure control system 108 may comprise a server-based software platform that provides the following core service: manage signals going to and from individual smart devices and sensors at a property); and
the network server, responsive to the network server making a determination that the processor is within an access area, transmitting or authorizing a transmission of the smart-device access advertisement (Schwartz in par 0034, further teaches that a user device 114 may read a NFC tag 210 on the controllable smart device 300 having an assigned URI, device identifier (“ID”), and a set of action information. The URI causes the mobile software application 112 on the user device 114 to open. The device ID and action information are passed to the mobile software application 112, which validates whether the user device 114 (e.g., resident, guest, or property manager) has the authorization to control or monitor that particular smart device 300. Schwartz in par 0038, further teaches that NFC as used with the present technology provides a security advantage when used in combination with BLE because NFC requires very close proximity (0-3 cm) which makes it difficult for man-in-the-middle (“MITM”) attacks to which BLE may be susceptible given its range of up to several meters. Schwartz in par 0047, further teaches that once the user has selected the desired community controllable smart device 300, the user device 114 starts a near-field communication (NFC) scan. The user presents the user device 114 to the community controllable smart device 300 and the user device 114 reads the NFC tag 210 presented by the community controllable smart device 300); and
use the smart-device access advertisement to establish access between the processor and a smart-device of the communications network (Schwartz in par 0033, further teaches that the access control system 104 may assign each NFC tag 210 with a unique identification code or tag along with a specified action that allows the user device 114 to authenticate the user's ability to interact with a given smart device or sensor 300. For example, the NFC tag 210 may comprise a uniform resource identifier (“URI”) to prompt the mobile software application 112 to activate or otherwise respond to a set of information that is passed to the mobile software application 112 for an action. In response, the user device 114 may perform an authentication against the user, residence, and multi-unit property. If the authentication is approved, then a secure API request is made to the infrastructure control system 108 to allow the user device 114 to interact with that smart device or sensor 300); and
subsequent to establishing the access between the processor and the smart-device, communicate with the smart-device whether or not the processor is within the access area (Schwartz in par 0029, further teaches that a home controller 206 may be communicatively linked to each smart device and sensor within the unit and be configured respond to commands initiated from the mobile software application 112 on the user device 114. Commands from the user device 114 may be communicated through the infrastructure control system 108 and transmitted to the home controller 206. Commands from the user device 114 may be communicated directly from the user device 114 to the home controller 206 when the user device 114 is located within the resident's unit. The home controller 206 may also be responsive to signals received from the resident controllable smart devices and sensors and be configured to communicate the signals to the user device 114 via the infrastructure control system 108).
Regarding Claim 2, Schwartz teaches the limitations contained in parent Claim 1. Schwartz further teaches:
wherein the determination by the network server that the processor is within the access area is based at least in part on a determination that the smart-device is registered with the network server (Schwartz in par 0034, further teaches that a user device 114 may read a NFC tag 210 on the controllable smart device 300 having an assigned URI, device identifier (“ID”), and a set of action information. The URI causes the mobile software application 112 on the user device 114 to open. The device ID and action information are passed to the mobile software application 112, which validates whether the user device 114 (e.g., resident, guest, or property manager) has the authorization to control or monitor that particular smart device 300. Schwartz in par 0075, further teaches that the infrastructure control system 108 may comprise a server-based software platform that provides the following core services: manage information about individual multiple unit dwelling properties and their residents; manage information about smart devices, smart sensors, and controllers associated with the property or with individual residential units within that property).
Regarding Claim 5, Schwartz teaches the limitations contained in parent Claim 1. Schwartz further teaches:
wherein:
the smart-device comprises a smoke detector (Schwartz in par 0029, further teaches that each smart home system 102 may comprise one or more resident controllable smart devices and smart sensors such as a front door lock 202, a thermostat 204, light bulb, light switch, security system, sensors (e.g., smoke, motion, carbon monoxide, water, etc.), or any number of other objects installed within a resident's unit that may be accessed or controlled remotely);
the processor is housed in mobile smartphone (Schwartz in par 0024, teaches a “user device” refers to any device having a central processing unit (“CPU”) capable of performing computing functions and having the ability to communicate with other devices either through a wireless communication system or a wired communication system such as: smartphones, tablet computers, smart watches, laptop computers, desktop computers, or other similar devices); and
subsequent to establishing the access between the processor and the smoke detector, the processor receives alerts from the smoke detector (Schwartz in par 0028, further teaches that the mobile software application 112 comprises a software application including a digital interface for users to interact with the smart home system 102, the access control system 104, and the smart community system 106 through the user device 114. As part of smart home system 102, residents may control the resident controllable smart devices in their residential unit and can enable or disable alerts from any resident controllable smart sensors).
Regarding Claim 6, Schwartz teaches the limitations contained in parent Claim 1. Schwartz further teaches:
wherein: the smart-device comprises an indoor air quality detector (Schwartz in par 0029, further teaches that each smart home system 102 may comprise one or more resident controllable smart devices and smart sensors such as a front door lock 202, a thermostat 204, light bulb, light switch, security system, sensors (e.g., smoke, motion, carbon monoxide, water, etc.), or any number of other objects installed within a resident's unit that may be accessed or controlled remotely);
the processor is housed in mobile smartphone (Schwartz in par 0024, teaches a “user device” refers to any device having a central processing unit (“CPU”) capable of performing computing functions and having the ability to communicate with other devices either through a wireless communication system or a wired communication system such as: smartphones, tablet computers, smart watches, laptop computers, desktop computers, or other similar devices); and
subsequent to establishing the access between the processor and the indoor air quality detector, the processor receives alerts from the indoor air quality detector (Schwartz in par 0028, further teaches that the mobile software application 112 comprises a software application including a digital interface for users to interact with the smart home system 102, the access control system 104, and the smart community system 106 through the user device 114. As part of smart home system 102, residents may control the resident controllable smart devices in their residential unit and can enable or disable alerts from any resident controllable smart sensors).
Regarding Claim 7, Schwartz teaches the limitations contained in parent Claim 1. Schwartz further teaches:
wherein the smart-device access advertisement is configured to be used by the processor to establish access between the processor and an additional smart-device of the communications network (Schwartz in par 0029, further teaches that each smart home system 102 may comprise one or more resident controllable smart devices and smart sensors such as a front door lock 202, a thermostat 204, light bulb, light switch, security system, sensors (e.g., smoke, motion, carbon monoxide, water, etc.), or any number of other objects installed within a resident's unit that may be accessed or controlled remotely. A home controller 206 may be communicatively linked to each smart device and sensor within the unit and be configured respond to commands initiated from the mobile software application 112 on the user device 114. Commands from the user device 114 may be communicated through the infrastructure control system 108 and transmitted to the home controller 206).
Regarding Claim 8, Schwartz teaches the limitations contained in parent Claim 7. Schwartz further teaches:
wherein the access between the processor and the additional smart-device of the communications network requires that the network server receives additional authorization (Schwartz in par 0047, further teaches that the mobile software application 112 provides the user device 114 with a list of known device IDs with which it is allowed to communicate. The user device 114 may repeatedly scan for all device IDs and display to the user (e.g., via graphic user interface (“GUI”) of the mobile software application 112) if the community controllable smart device 300 matches one of the device IDs in the list of all permitted community controllable smart devices. Once a user has selected the desired community controllable smart device 300, the user device 114 starts an NFC scan. The user presents the user device 114 to the community controllable smart device 300 and the user device 114 reads the NFC tag 210 presented by the community controllable smart device 300).
Regarding Claim 11, this Claim merely recites a computer-implemented method of operating an access controller of a communications network, the method comprising instructions as similarly recited in Claim 1. Accordingly, Schwartz discloses/teaches every limitation of Claim 11 as indicated in the above rejection of Claim 1.
Regarding Claim 12, this Claim merely recites a computer-implemented method of operating an access controller of a communications network, the method comprising instructions as similarly recited in Claim 2. Accordingly, Schwartz discloses/teaches every limitation of Claim 12 as indicated in the above rejection of Claim 2.
Regarding Claim 15, this Claim merely recites a computer-implemented method of operating an access controller of a communications network, the method comprising instructions as similarly recited in Claim 5. Accordingly, Schwartz discloses/teaches every limitation of Claim 15 as indicated in the above rejection of Claim 5.
Regarding Claim 16, this Claim merely recites a computer-implemented method of operating an access controller of a communications network, the method comprising instructions as similarly recited in Claim 6. Accordingly, Schwartz discloses/teaches every limitation of Claim 16 as indicated in the above rejection of Claim 6.
Regarding Claim 17, this Claim merely recites a computer-implemented method of operating an access controller of a communications network, the method comprising instructions as similarly recited in Claim 7. Accordingly, Schwartz discloses/teaches every limitation of Claim 17 as indicated in the above rejection of Claim 7.
Regarding Claim 18, this Claim merely recites a computer-implemented method of operating an access controller of a communications network, the method comprising instructions as similarly recited in Claim 8. Accordingly, Schwartz discloses/teaches every limitation of Claim 18 as indicated in the above rejection of Claim 8.
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) 3, 4, 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Schwartz in view of Abu-Hakima et al. (US 2012/0190325) (hereinafter, Abu-Hakima).
Regarding Claim 3, Schwartz teaches the limitations contained in parent Claim 1. Schwartz further teaches:
Schwartz in par 0029, further teaches that a home controller 206 may be communicatively linked to each smart device and sensor within the unit and be configured respond to commands initiated from the mobile software application 112 on the user device 114. Commands from the user device 114 may be communicated through the infrastructure control system 108 and transmitted to the home controller 206. Commands from the user device 114 may be communicated directly from the user device 114 to the home controller 206 when the user device 114 is located within the resident's unit. The home controller 206 may also be responsive to signals received from the resident controllable smart devices and sensors and be configured to communicate the signals to the user device 114 via the infrastructure control system 108).
However, Schwartz does not specifically disclose wherein the determination by the network server that the processor is within the access area is based at least in part on the processor providing the network server with information of a router that is within the access area.
Abu-Hakima teaches a method for communicating alert messages to target communication devices in a target physical location (See Abu-Hakima’s Abstract). Abu-Hakima in par 0049 and Fig. 7, teaches that a system 710 may interface one or more network sources 770 (e.g. communications nodes, network wired/wireless switches and routers, and wired or wireless access points) and one or more external directories 780 (e.g. databases used to identify personnel and network-attached device identities in an enterprise/campus network, telephone directories, directories of client computer hostnames configured in a network domain, or distribution lists). The system 710 further communicates with a plurality of target communications devices 790. Abu-Hakima in par 0104, further teaches that where the network source 770 is a router, switch, or DHCP server, then the recipient discovery module 886 may query the source for a list of recipient communications devices connected via this source (or set of cascaded sources) to each of the list of targeted domains, subnets, and/or VLANS provided.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to utilize the teachings as in Abu-Hakima with the teaching as in Schwartz to provide Schwartz with a router to provide access to a communication network as disclosed in Abu-Hakima. The motivation for doing so would have been to having received an alert message from a sensor, detects nearby devices in the target physical location and communicating the alert message to the target device thus increasing safety in the physical location (See Abu-Hakima’s Abstract).
Regarding Claim 4, Schwartz in view of Abu-Hakima teaches the limitations contained in parent Claim 3. Abu-Hakima further teaches:
wherein the smart-device communicates with the network server through the router (Abu-Hakima teaches a method for communicating alert messages to target communication devices in a target physical location (See Abu-Hakima’s Abstract). Abu-Hakima in par 0049 and Fig. 7, teaches that a system 710 may interface one or more network sources 770 (e.g. communications nodes, network wired/wireless switches and routers, and wired or wireless access points) and one or more external directories 780 (e.g. databases used to identify personnel and network-attached device identities in an enterprise/campus network, telephone directories, directories of client computer hostnames configured in a network domain, or distribution lists). The system 710 further communicates with a plurality of target communications devices 790. Abu-Hakima in par 0104, further teaches that where the network source 770 is a router, switch, or DHCP server, then the recipient discovery module 886 may query the source for a list of recipient communications devices connected via this source (or set of cascaded sources) to each of the list of targeted domains, subnets, and/or VLANS provided).
Regarding Claim 13, this Claim merely recites a computer-implemented method of operating an access controller of a communications network, the method comprising instructions as similarly recited in Claim 3. Accordingly, Schwartz in view of Abu-Hakima discloses/teaches every limitation of Claim 13 as indicated in the above rejection of Claim 3.
Regarding Claim 14, this Claim merely recites a computer-implemented method of operating an access controller of a communications network, the method comprising instructions as similarly recited in Claim 4. Accordingly, Schwartz in view of Abu-Hakima discloses/teaches every limitation of Claim 14 as indicated in the above rejection of Claim 4.
Claim(s) 9, 10, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Schwartz in view of P et al. (US 2022/0335799) (hereinafter, P).
Regarding Claim 9, Schwartz teaches the limitations contained in parent Claim 1. Schwartz further teaches:
Schwartz in par 0075, teaches that the infrastructure control system 108 may comprise a server-based software platform that provides the following core services: manage information about individual multiple unit dwelling properties and their residents; manage information about smart devices, smart sensors, and controllers associated with the property or with individual residential units within that property).
However, Schwartz does not specifically disclose wherein the network server comprises a cloud server.
P teaches notifying a user of a fire system event, comprising detecting an event in a building through an event detection device and transmitting information about at least one of the event or the event detection device to a remote server and to a first computing device (See P’s Abstract). P in par 0028, further teaches that a control panel 104 can be a fire control panel that can receive information from event devices 106 and determine whether a hazard event is occurring or has occurred. The control panel may be configured to transmit information about the hazard event to the computing device 108 and to the cloud 118. P in par 0032 – 0033, further teaches that a gateway device 110 of an alarm system 102 at a facility (building) reports event alarm signals to one or more central monitoring servers. These servers may be on premise (within the facility) or, as shown in the example of FIG. 1, off premise (at a remote location from the alarm system components including the gateway device). From there, the event alarm signals are reported to the appropriate central monitoring station. This is done through the computing device 108. For example, a fire event would need a fire-based response that would likely include alerting a fire station to send trucks and contacting medical personnel, if injuries seem likely. For a security issue, security personnel and/or the police would be contacted. For an issue relating to the operation of an alarm system device 106, a technician would be contacted and directed to the location of the faulty alarm system device 106. The central monitoring servers are connected back to one or more alarm systems on site and/or remote (cloud) servers, such as alarm system 102 and remote server 118.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to utilize the teachings as in P with the teachings as in Schwartz to connect the smart devices of Schwartz to remote servers (Cloud) as disclosed in P. The motivation for doing so would have been to effectively increase building security by notifying the appropriate central monitoring station based on the detected event (See P’s par 0033).
Regarding Claim 10, Schwartz teaches the limitations contained in parent Claim 1. Schwartz further teaches:
wherein: the communications network includes a building-safety control (BSC) system (Schwartz in par 0024, further teaches that a control system for managing smart devices in a multi-unit property environment may be configured to work with any number or type of controllable smart devices. Some controllable smart devices may be associated with a particular resident or unit within the property. For example, a residence within an apartment complex may include one or more individual resident controllable smart devices and sensors such as: light bulbs, light switches, fans, in-home electronic assistants, thermostats, door locks, appliances, window coverings, security cameras, monitoring sensors, and the like. Other community controllable devices may be associated with the entire multi-unit property and comprise devices such as: locks located at entry doors or gates, audio/video communication portals, motion sensors, video surveillance cameras, and the like);
the processor is incorporated within a mobile smartphone (Schwartz in par 0024, teaches a “user device” refers to any device having a central processing unit (“CPU”) capable of performing computing functions and having the ability to communicate with other devices either through a wireless communication system or a wired communication system such as: smartphones, tablet computers, smart watches, laptop computers, desktop computers, or other similar devices);
the smart-device comprises a smoke detector or an indoor air quality detector (Schwartz in par 0029, further teaches that each smart home system 102 may comprise one or more resident controllable smart devices and smart sensors such as a front door lock 202, a thermostat 204, light bulb, light switch, security system, sensors (e.g., smoke, motion, carbon monoxide, water, etc.), or any number of other objects installed within a resident's unit that may be accessed or controlled remotely); and
the access area comprises a building or a predetermined region within the building (Schwartz in par 0038, further teaches that NFC as used with the present technology provides a security advantage when used in combination with BLE because NFC requires very close proximity (0-3 cm) which makes it difficult for man-in-the-middle (“MITM”) attacks to which BLE may be susceptible given its range of up to several meters. Schwartz in par 0047, further teaches that once the user has selected the desired community controllable smart device 300, the user device 114 starts a near-field communication (NFC) scan. The user presents the user device 114 to the community controllable smart device 300 and the user device 114 reads the NFC tag 210 presented by the community controllable smart device 300).
However, Schwartz does not specifically disclose that the network server comprises a cloud server.
P in par 0032 – 0033, further teaches that a gateway device 110 of an alarm system 102 at a facility (building) reports event alarm signals to one or more central monitoring servers. These servers may be on premise (within the facility) or, as shown in the example of FIG. 1, off premise (at a remote location from the alarm system components including the gateway device). From there, the event alarm signals are reported to the appropriate central monitoring station. This is done through the computing device 108. For example, a fire event would need a fire-based response that would likely include alerting a fire station to send trucks and contacting medical personnel, if injuries seem likely. For a security issue, security personnel and/or the police would be contacted. For an issue relating to the operation of an alarm system device 106, a technician would be contacted and directed to the location of the faulty alarm system device 106. The central monitoring servers are connected back to one or more alarm systems on site and/or remote (cloud) servers, such as alarm system 102 and remote server 118.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to utilize the teachings as in P with the teachings as in Schwartz to connect the smart devices of Schwartz to remote servers (Cloud) as disclosed in P. The motivation for doing so would have been to effectively increase building security by notifying the appropriate central monitoring station based on the detected event (See P’s par 0033).
Regarding Claim 19, this Claim merely recites a computer-implemented method of operating an access controller of a communications network, the method comprising instructions as similarly recited in Claim 9. Accordingly, Schwartz in view of P discloses/teaches every limitation of Claim 19 as indicated in the above rejection of Claim 9.
Regarding Claim 20, this Claim merely recites a computer-implemented method of operating an access controller of a communications network, the method comprising instructions as similarly recited in Claim 10. Accordingly, Schwartz in view of P discloses/teaches every limitation of Claim 20 as indicated in the above rejection of Claim 10.
Response to Arguments
Applicant's arguments filed 12/30/2025 have been fully considered but they are not persuasive.
(1) Applicant argues: that Schwartz's proximity check is implemented at the device edge using NFC's close-range requirement, not by a server decision that the processor is within an access area, and the BLE advertisement originates from the smart device, not from the server. Accordingly, Schwartz lacks the claimed server-side determination gating the advertisement transmission and the use of that server-conditioned advertisement to establish access. Amended claim 1 now even more explicitly recites that the processor receives a smart-device access advertisement based at least in part on the network server receiving the access request and the network server, responsive to making a determination that the processor is within an access area, transmitting or authorizing a transmission of the advertisement. This language frames both the location determination and the advertisement transmission as server-driven events, which are not taught or suggested by Schwartz's device-originated BLE advertisements and NFC edge authentication. The amendments also make even more explicit that the processor uses that advertisement to establish access and then, subsequent to establishing the access, communicates with the smart device whether or not within the access area. These clarifications further highlight the server-centric gating and transmission flow that is absent from Schwartz and thereby further distance the claims from Schwartz's device- centric sequences.
The examiner respectfully disagrees.
As correctly indicated by the Applicant Schwartz the “advertisement” is initiated by the smart device itself as a BLE broadcast of a device ID.
However, Schwartz in par 0075, further teaches
Schwartz in par 0075, that the infrastructure control system 108 may comprise a server-based software platform that provides the following core services: manage information about individual multiple unit dwelling properties and their residents; manage information about smart devices, smart sensors, and controllers associated with the property or with individual residential units within that property; manage information about the access configuration, access points, and intercom system 810 stations at a property; manage data associated with the smart home system 102, the access control system 104, and the smart community system 106; manage signals going to and from individual smart devices and sensors at a property; manage signals going to and from the user-facing mobile software application 112 and web portal 116 digital interfaces via user devices 114 or other computers; manage interactions or integrations within any third-party platforms or tools; and log details of all interactions in real time as they happen.
Accordingly, Schwartz teaches a resident, a guest or a property manager sending a request access over the network to control or monitor a particular smart device. The server based system is managing signals to and from individual smart devices. Thus, contrary to applicant’s argument Schwartz is not lacking the claimed server-side determination gating the advertisement transmission and the use of that server-conditioned advertisement to establish access.
Furthermore, Schwartz in par 0029, further teaches that a home controller 206 may be communicatively linked to each smart device and sensor within the unit and be configured respond to commands initiated from the mobile software application 112 on the user device 114. Commands from the user device 114 may be communicated through the infrastructure control system 108 and transmitted to the home controller 206. Commands from the user device 114 may be communicated directly from the user device 114 to the home controller 206 when the user device 114 is located within the resident's unit. The home controller 206 may also be responsive to signals received from the resident controllable smart devices and sensors and be configured to communicate the signals to the user device 114 via the infrastructure control system 108.
Accordingly, Schwartz clearly discloses that the commands may be communicated through the infrastructure control system 108 which server-based software platform.
Therefore, the examiner maintains that Schwartz discloses claim 1 as claimed.
(2) Applicant argues: that regarding claims 2 and 12, the cited art relies on device -edge NFC and BLW proximity or on a generic server data management, not on a server-side registration state as the predicate for a within-access-area determination that gates an access advertisement to the processor. This server-registration gating mechanism is neither taught nor suggested and provides a nonobvious distinction.
The examiner respectfully disagrees.
Claim 2 recites “wherein the determination by the network server that the processor is within the access area is based at least in part on a determination that the smart-device is registered with the network server”
Schwartz in par 0029, further teaches that a home controller 206 may be communicatively linked to each smart device and sensor within the unit and be configured respond to commands initiated from the mobile software application 112 on the user device 114. Commands from the user device 114 may be communicated through the infrastructure control system 108 and transmitted to the home controller 206. Schwartz in par 0038, further teaches that NFC as used with the present technology provides a security advantage when used in combination with BLE because NFC requires very close proximity (0-3 cm) which makes it difficult for man-in-the-middle (“MITM”) attacks to which BLE may be susceptible given its range of up to several meters.
As indicated above (1) Accordingly, Schwartz teaches a resident, a guest or a property manager sending a request access over the network to control or monitor a particular smart device. The server based system is managing signals to and from individual smart devices. Wherein the control system provides managing of the devices and managing of the information and access configuration.
Thus, the examiner maintain that Schwartz discloses claim 2 as claimed.
(3) Regarding Claim 3, applicant argues that the cited art does not disclose a processor-originated router identifier being used by a server specifically to determine the processor’s presence in an access area as a condition for transmitting an access advertisement. That processor to server router signaling, and its use for server-side access-area determination, supplies a separate, nonobvious limitation.
The examiner respectfully disagrees.
Claim 3 recites wherein the determination by the network server that the processor is within the access area is based at least in part on the processor providing the network server with information of a router that is within the access area. Based on the broadest reasonable interpretation, the claim is not using the router information to determine the server access area, the claim is providing the server with information of a router within the access area.
As indicated above, Schwartz teaches the network server.
Furthermore, Abu-Hakima in par 0049 and Fig. 7, teaches that a system 710 may interface one or more network sources 770 (e.g. communications nodes, network wired/wireless switches and routers, and wired or wireless access points). The system 710 further communicates with a plurality of target communications devices 790. Abu-Hakima in par 0104, further teaches that where the network source 770 is a router, switch, or DHCP server, then the recipient discovery module 886 may query the source for a list of recipient communications devices connected via this source (or set of cascaded sources) to each of the list of targeted domains, subnets, and/or VLANS provided.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to utilize the teachings as in Abu-Hakima with the teaching as in Schwartz to provide Schwartz with a router to provide access to a communication network as disclosed in Abu-Hakima. The motivation for doing so would have been to having received an alert message from a sensor, detects nearby devices in the target physical location and communicating the alert message to the target device thus increasing safety in the physical location (See Abu-Hakima’s Abstract).
Thus, the examiner maintain that Schwartz discloses claim 3 as claimed.
(4) Regarding Claim 7, applicant argues that the cited art describes device -originated BLE advertisements used in a single device transaction. It does not teach or suggest a server-conditioned advertisement that can be used to establish access to multiple smart devices, which is a distinct functional capability that is not addressed by the combinations relied upon.
The examiner respectfully disagrees.
Schwartz teaches a resident, a guest or a property manager sending a request access over the network to control or monitor a particular smart device. The server based system is managing signals to and from individual smart devices. Thus, contrary to applicant’s argument Schwartz is not lacking the claimed server-side determination gating the advertisement transmission and the use of that server-conditioned advertisement to establish access.
Furthermore, Schwartz in par 0029, further teaches that each smart home system 102 may comprise one or more resident controllable smart devices and smart sensors such as a front door lock 202, a thermostat 204, light bulb, light switch, security system, sensors (e.g., smoke, motion, carbon monoxide, water, etc.), or any number of other objects installed within a resident's unit that may be accessed or controlled remotely. A home controller 206 may be communicatively linked to each smart device and sensor within the unit and be configured respond to commands initiated from the mobile software application 112 on the user device 114. Commands from the user device 114 may be communicated through the infrastructure control system 108 and transmitted to the home controller 206.
Thus, a plurality of devices are connected to the control system which comprises a server-based software platform.
Thus, the examiner maintain that Schwartz discloses claim 7 as claimed.
(5), Regarding claim 10, applicant argues that the prior art does not disclose integrating the server-conditioned access advertisement and server-side access-area determination with a building-safety control context and these particular smart devices. This integration provides a separate, nonobvious constraint on the claimed system that is not remedied by the other references.
The examiner respectfully disagrees.
Claim 10 recites that “the access area comprises a building or a predetermined region within the building” The claim does not specifically require the predetermined region within the building, based on the broadest reasonable interpretation the claim requires that the access area comprises a building.
As indicated above Schwartz teaches a resident, a guest or a property manager sending a request access over the network to control or monitor a particular smart device. The server based system is managing signals to and from individual smart devices.
Furthermore, Schwartz in par 0029, further teaches that each smart home system 102 may comprise one or more resident controllable smart devices and smart sensors such as a front door lock 202, a thermostat 204, light bulb, light switch, security system, sensors (e.g., smoke, motion, carbon monoxide, water, etc.), or any number of other objects installed within a resident's unit that may be accessed or controlled remotely. Schwartz in par 0047, further teaches that once the user has selected the desired community controllable smart device 300, the user device 114 starts a near-field communication (NFC) scan. The user presents the user device 114 to the community controllable smart device 300 and the user device 114 reads the NFC tag 210 presented by the community controllable smart device 300.
Accordingly, Schwartz teaches a plurality of devices associated with building safety control context and allow the control of the devices in a server-based software platform in a building.
Thus, the examiner maintain that Schwartz discloses claim 10 as claimed.
Applicant's remaining arguments with respect to claims are substantially encompassed in the arguments above, therefore examiner responds with the same rationale.
For at least the foregoing reasons, Examiner maintains prior art rejections.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARIEL MERCADO VARGAS whose telephone number is (571)270-1701. The examiner can normally be reached M-F 8:00am - 4:00pm.
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, Scott Baderman can be reached at 571-272-3644. 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.
/ARIEL MERCADO-VARGAS/ Primary Examiner, Art Unit 2118
Prosecution Insights