Patent Description:
One conventional solution providing ESD protection for the camera includes sealing the lens retainer with a plastic cover, but this approach may include high cost, larger product size, and may impact optical performance due to an additional object being in front of the camera. Another conventional solution includes using a grounding structure to tie the metal retainer to the ground of the camera board, but because the lens retainer is an adjustable (e.g., movable) part during focus tuning, challenges arise in attempting to ground a moving part. Accordingly, camera tuning and focusing performance may be impacted due to the extra force from the grounding structure. Another conventional solution includes adding ESD protection components (e.g., transient-voltage-suppression (TVS) diodes) to protect the susceptible signals and components in the camera board, but this approach may require high component cost, more printed circuit board (PCB) space, and extensive trial-and-error to adjust the protection during failure analysis, which can significantly lengthen the development cycle and time-to-market. <CIT> describes a camera module for a vehicle, comprising a housing having a rear body, a front body coupled to the rear body, and a receiving space surrounded by the rear body and the front body; a lens assembly coupled to the front body to penetrate the front body; a substrate installed in the receiving space; and an image sensor installed on the substrate to receive light incident through the lens assembly and convert the light into an electrical signal. The front body includes a front body cap connected to the rear body and a front body frame having a front body through hole into which the lens assembly can be inserted, coupled with the front body cap to be surrounded by the rear body and the front body cap, and made of a material having strength greater than strength of the front body cap. <CIT>, <CIT> and <CIT> are further examples for ESD bridge components to guide electrostatic discharge current from a lens retainer to system ground. <CIT> and <CIT> generally disclose the use of "spark gaps" for ESD protection of electronic devices, including cameras.

The invention is set forth in the independent claims. Specific embodiments are presented in the dependent claims. The present document describes a camera module with ESD protection. In particular, the camera module includes a lightning rod structure, which guides an ESD current to a safe location (e.g., system ground) when a lens retainer of the camera module is hit by an ESD spark. In order to eliminate the impact on camera focus tuning and the risk of audio rub and buzz, the lightning rod structure does not physically touch the lens retainer. Thus, a gap (e.g., insulation) separates the lightning rod structure from the lens retainer. When the lens retainer is stressed by an ESD spark, the gap experiences electrical breakdown and becomes a conductor, establishing a conductive path to guide the ESD current to the safe location through the lightning rod structure. In this way, the ESD current flows along a controlled path instead of jumping to arbitrary locations, which protects nearby susceptible circuitry.

In aspects, a camera module for an electronic device is disclosed. The camera module includes a camera lens and an image sensor aligned with the camera lens. The camera module also includes a retainer encircling the camera lens. The retainer is movable during a focus tuning of the camera module. The camera module further includes an ESD bridge component arranged to provide a controlled path for an electrostatic discharge current to travel from the retainer to a system ground of the electronic device. In implementations, the ESD bridge component is separated from the retainer by a gap and positioned to guide the ESD current away from the image sensor.

In aspects, an electronic device is disclosed. The electronic device includes a housing, a system ground, and an IR cover disposed on an exterior surface of the housing. In some implementations, at least a portion of the infrared cover is configured to be substantially transparent to infrared light. Further, the infrared cover is separate from the retainer and has an aperture through which the retainer extends. The electronic device also includes one or more infrared light sources disposed within the housing behind the infrared cover and configured to generate infrared light that is directed through the infrared cover. In addition, the electronic device includes a camera module as disclosed above.

This summary is provided to introduce simplified concepts of a camera module with ESD protection, which are further described below in the Detailed Description. This summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

The details of one or more aspects of a camera module with ESD protection are described in this document with reference to the following drawings. The same numbers are used throughout the drawings to reference like features and components:.

The present document describes a camera module with ESD protection. In particular, the camera module of an electronic device includes an ESD bridging component (also referred to as a lightning rod structure), which guides the ESD current to the system ground of the electronic device by acting as a bridge between a metal, movable, lens retainer and a heat sink. The ESD bridging component is separated from the lens retainer by a gap to avoid impacting camera focus tuning and risking audio rub and buzz. When the lens retainer is stressed by an ESD spark (e.g., an electrostatically charged person touches the lens retainer or touches some location on the electronic device), a conductive path is established across the gap from the retainer to the ESD bridging component and further to the heat sink, which is safely grounded. In this way, the ESD current flows along a controlled path instead of jumping to arbitrary locations, thereby protecting nearby circuitry that is sensitive to ESD current.

Implementing the described techniques enables a more robust structure for a small form factor device (e.g., video-recording doorbell) because the described techniques provide ESD protection without requiring the use of TVS diodes in the nearby circuitry. Thus, component costs and space requirements are reduced, resulting in lower manufacturing costs and a smaller or thinner device.

While features and concepts of the described techniques for a camera module with ESD protection can be implemented in any number of different environments, aspects are described in the context of the following examples.

<FIG> illustrates an example network environment <NUM> (e.g., network environment) in which a camera module with ESD protection can be implemented. The network environment <NUM> includes a home area network (HAN). The HAN includes wireless network devices <NUM> (e.g., electronic devices) that are disposed about a structure <NUM>, such as a house, and are connected by one or more wireless and/or wired network technologies, as described below. The HAN includes a border router <NUM> that connects the HAN to an external network <NUM>, such as the Internet, through a home router or access point <NUM>.

To provide user access to functions implemented using the wireless network devices <NUM> in the HAN, a cloud service <NUM> connects to the HAN via a border router <NUM>, via a secure tunnel <NUM> through the external network <NUM> and the access point <NUM>. The cloud service <NUM> facilitates communication between the HAN and internet clients <NUM>, such as apps on mobile devices, using a web-based application programming interface (API) <NUM>. The cloud service <NUM> also manages a home graph that describes connections and relationships between the wireless network devices <NUM>, elements of the structure <NUM>, and users. The cloud service <NUM> hosts controllers which orchestrate and arbitrate home automation experiences, as described in greater detail below.

The HAN may include one or more wireless network devices <NUM> that function as a hub <NUM>. The hub <NUM> may be a general-purpose home automation hub, or an application-specific hub, such as a security hub, an energy-management hub, a heating, ventilation, and air conditioning (HVAC) hub, and so forth. The functionality of a hub <NUM> may also be integrated into any wireless network device <NUM>, such as a smart thermostat device or the border router <NUM>. In addition to hosting controllers on the cloud service <NUM>, controllers can be hosted on any hub <NUM> in the structure <NUM>, such as the border router <NUM>. A controller hosted on the cloud service <NUM> can be moved dynamically to the hub <NUM> in the structure <NUM>, such as moving an HVAC zone controller to a newly installed smart thermostat.

Hosting functionality on the hub <NUM> in the structure <NUM> can improve reliability when the user's internet connection is unreliable, can reduce latency of operations that would normally have to connect to the cloud service <NUM>, and can satisfy system and regulatory constraints around local access between wireless network devices <NUM>.

The wireless network devices <NUM> in the HAN may be from a single manufacturer that provides the cloud service <NUM> as well, or the HAN may include wireless network devices <NUM> from partners. These partners may also provide partner cloud services <NUM> that provide services related to their wireless network devices <NUM> through a partner Web API <NUM>. The partner cloud service <NUM> may optionally or additionally provide services to internet clients <NUM> via the web-based API <NUM>, the cloud service <NUM>, and the secure tunnel <NUM>.

The network environment <NUM> can be implemented on a variety of hosts, such as battery-powered microcontroller-based devices, line-powered devices, and servers that host cloud services. Protocols operating in the wireless network devices <NUM> and the cloud service <NUM> provide a number of services that support operations of home automation experiences in the distributed computing environment <NUM>. These services include, but are not limited to, real-time distributed data management and subscriptions, command-and-response control, real-time event notification, historical data logging and preservation, cryptographically controlled security groups, time synchronization, network and service pairing, and software updates.

<FIG> illustrates an example environment <NUM> in which a home area network, as described with reference to <FIG>, and aspects of a camera module with ESD protection can be implemented. Generally, the environment <NUM> includes the home area network (HAN) implemented as part of a home or other type of structure with any number of wireless network devices (e.g., wireless network devices <NUM>) that are configured for communication in a wireless network. For example, the wireless network devices can include a thermostat <NUM>, hazard detectors <NUM> (e.g., for smoke and/or carbon monoxide), cameras <NUM> (e.g., indoor and outdoor), lighting units <NUM> (e.g., indoor and outdoor), and any other types of wireless network devices <NUM> that are implemented inside and/or outside of a structure <NUM> (e.g., in a home environment). In this example, the wireless network devices can also include any of the previously described devices, such as a border router <NUM>, as well as the electronic device <NUM>.

In the environment <NUM>, any number of the wireless network devices can be implemented for wireless interconnection to wirelessly communicate and interact with each other. The wireless network devices are modular, intelligent, multi-sensing, network-connected devices that can integrate seamlessly with each other and/or with a central server or a cloud-computing system to provide any of a variety of useful automation objectives and implementations. An example of a wireless network device that can be implemented as any of the devices described herein is shown and described with reference to <FIG>.

In implementations, the thermostat <NUM> may include a Nest® Learning Thermostat that detects ambient climate characteristics (e.g., temperature and/or humidity) and controls an HVAC system <NUM> in the home environment. The learning thermostat <NUM> and other network-connected devices "learn" by capturing occupant settings to the devices. For example, the thermostat learns preferred temperature set-points for mornings and evenings, and when the occupants of the structure are asleep or awake, as well as when the occupants are typically away or at home.

A hazard detector <NUM> can be implemented to detect the presence of a hazardous substance or a substance indicative of a hazardous substance (e.g., smoke, fire, or carbon monoxide). In examples of wireless interconnection, a hazard detector <NUM> may detect the presence of smoke, indicating a fire in the structure, in which case the hazard detector that first detects the smoke can broadcast a low-power wake-up signal to all of the connected wireless network devices. The other hazard detectors <NUM> can then receive the broadcast wake-up signal and initiate a high-power state for hazard detection and to receive wireless communications of alert messages. Further, the lighting units <NUM> can receive the broadcast wake-up signal and activate in the region of the detected hazard to illuminate and identify the problem area. In another example, the lighting units <NUM> may activate in one illumination color to indicate a problem area or region in the structure, such as for a detected fire or break-in, and activate in a different illumination color to indicate safe regions and/or escape routes out of the structure.

In various configurations, the wireless network devices <NUM> can include an entryway interface device <NUM> that functions in coordination with a network-connected door lock system <NUM>, and that detects and responds to a person's approach to or departure from a location, such as an outer door of the structure <NUM>. The entryway interface device <NUM> can interact with the other wireless network devices based on whether someone has approached or entered the smart-home environment. An entryway interface device <NUM> can control doorbell functionality, announce the approach or departure of a person via audio or visual means, and control settings on a security system, such as to activate or deactivate the security system when occupants come and go. The wireless network devices <NUM> can also include other sensors and detectors, such as to detect ambient lighting conditions, detect room-occupancy states (e.g., with an occupancy sensor <NUM>), and control a power and/or dim state of one or more lights. In some instances, the sensors and/or detectors may also control a power state or speed of a fan, such as a ceiling fan <NUM>. Further, the sensors and/or detectors may detect occupancy in a room or enclosure and control the supply of power to electrical outlets or devices <NUM>, such as if a room or the structure is unoccupied.

The wireless network devices <NUM> may also include connected appliances and/or controlled systems <NUM>, such as refrigerators, stoves and ovens, washers, dryers, air conditioners, pool heaters <NUM>, irrigation systems <NUM>, security systems <NUM>, and so forth, as well as other electronic and computing devices, such as televisions, entertainment systems, computers, intercom systems, garage-door openers <NUM>, ceiling fans <NUM>, control panels <NUM>, and the like. When plugged in, an appliance, device, or system can announce itself to the home area network as described above and can be automatically integrated with the controls and devices of the home area network, such as in the home. It should be noted that the wireless network devices <NUM> may include devices physically located outside of the structure, but within wireless communication range, such as a device controlling a swimming pool heater <NUM> or an irrigation system <NUM>.

As described above, the HAN includes a border router <NUM> that interfaces for communication with an external network, outside the HAN. The border router <NUM> connects to an access point <NUM>, which connects to the external network <NUM>, such as the Internet. A cloud service <NUM>, which is connected via the external network <NUM>, provides services related to and/or using the devices within the HAN. By way of example, the cloud service <NUM> can include applications for connecting end-user devices <NUM>, such as smartphones, tablets, and the like, to devices in the home area network, processing and presenting data acquired in the HAN to end-users, linking devices in one or more HANs to user accounts of the cloud service <NUM>, provisioning and updating devices in the HAN, and so forth. For example, a user can control the thermostat <NUM> and other wireless network devices in the home environment using a network-connected computer or portable device, such as a mobile phone or tablet device. Further, the wireless network devices can communicate information to any central server or cloud-computing system via the border router <NUM> and the access point <NUM>. The data communications can be carried out using any of a variety of custom or standard wireless protocols (e.g., Wi-Fi, ZigBee for low power, 6LoWPAN, Thread, etc.) and/or by using any of a variety of custom or standard wired protocols (CAT6 Ethernet, HomePlug, and so on).

Any of the wireless network devices in the HAN can serve as low-power and communication nodes to create the HAN in the home environment. Individual low-power nodes of the network can regularly send out messages regarding what they are sensing, and the other low-powered nodes in the environment - in addition to sending out their own messages - can repeat the messages, thereby communicating the messages from node to node (e.g., from device to device) throughout the home area network. The wireless network devices can be implemented to conserve power, particularly when battery-powered, utilizing low-powered communication protocols to receive the messages, translate the messages to other communication protocols, and send the translated messages to other nodes and/or to a central server or cloud-computing system. For example, the occupancy sensor <NUM> and/or an ambient light sensor <NUM> can detect an occupant in a room as well as measure the ambient light, and activate the light source when the ambient light sensor <NUM> detects that the room is dark and when the occupancy sensor <NUM> detects that someone is in the room. Further, the sensor can include a low-power wireless communication chip (e.g., an IEEE <NUM>. <NUM> chip, a Thread chip, a ZigBee chip) that regularly sends out messages regarding the occupancy of the room and the amount of light in the room, including instantaneous messages coincident with the occupancy sensor detecting the presence of a person in the room. As mentioned above, these messages may be sent wirelessly, using the home area network, from node to node (e.g., network-connected device to network-connected device) within the home environment as well as over the Internet to a central server or cloud-computing system.

In other configurations, various ones of the wireless network devices can function as "tripwires" for an alarm system in the home environment. For example, in the event a perpetrator circumvents detection by alarm sensors located at windows, doors, and other entry points of the structure or environment, the alarm could still be triggered by receiving an occupancy, motion, heat, sound, etc. message from one or more of the low-powered mesh nodes in the home area network. In other implementations, the home area network can be used to automatically turn on and off the lighting units <NUM> as a person transitions from room to room in the structure. For example, the wireless network devices can detect the person's movement through the structure and communicate corresponding messages via the nodes of the home area network. Using the messages that indicate which rooms are occupied, other wireless network devices that receive the messages can activate and/or deactivate accordingly. As referred to above, the home area network can also be utilized to provide exit lighting in the event of an emergency, such as by turning on the appropriate lighting units <NUM> that lead to a safe exit. The light units <NUM> may also be turned on to indicate the direction along an exit route that a person should travel to safely exit the structure.

The various wireless network devices may also be implemented to integrate and communicate with wearable computing devices <NUM>, such as may be used to identify and locate an occupant of the structure and adjust the temperature, lighting, sound system, and the like accordingly. In other implementations, radio frequency identification (RFID) sensing (e.g., a person having an RFID bracelet, necklace, or key fob), synthetic vision techniques (e.g., video cameras and face recognition processors), audio techniques (e.g., voice, sound pattern, vibration pattern recognition), ultrasound sensing/imaging techniques, and infrared or near-field communication (NFC) techniques (e.g., a person wearing an infrared or NFC-capable smartphone), along with rules-based inference engines or artificial intelligence techniques may draw useful conclusions from the sensed information as to the location of an occupant in the structure or environment.

In other implementations, personal comfort-area networks, personal health-area networks, personal safety-area networks, and/or other such human-facing functionalities of service robots can be enhanced by logical integration with other wireless network devices and sensors in the environment according to rules-based inferencing techniques or artificial intelligence techniques for achieving better performance of these functionalities. In an example relating to a personal health area, the system can detect whether a household pet is moving toward the current location of an occupant (e.g., using any of the wireless network devices and sensors), along with rules-based inferencing and artificial intelligence techniques. Similarly, a hazard detector service robot can be notified that the temperature and humidity levels are rising in a kitchen, and temporarily raise a hazard detection threshold, such as a smoke detection threshold, under an inference that any small increases in ambient smoke levels will most likely be due to cooking activity and not due to a genuinely hazardous condition. Any service robot that is configured for any type of monitoring, detecting, and/or servicing can be implemented as a mesh node device on the home area network, conforming to the wireless interconnection protocols for communicating on the home area network.

The wireless network devices <NUM> may also include a network-connected alarm clock <NUM> for each of the individual occupants of the structure in the home environment. For example, an occupant can customize and set an alarm device for a wake time, such as for the next day or week. Artificial intelligence can be used to consider occupant responses to the alarms when they go off and make inferences about preferred sleep patterns over time. An individual occupant can then be tracked in the home area network based on a unique signature of the person, which is determined based on data obtained from sensors located in the wireless network devices, such as sensors that include ultrasonic sensors, passive IR sensors, and the like. The unique signature of an occupant can be based on a combination of patterns of movement, voice, height, size, etc., as well as using facial recognition techniques.

In an example of wireless interconnection, the wake time for an individual can be associated with the thermostat <NUM> to control the HVAC system in an efficient manner so as to pre-heat or cool the structure to desired sleeping and awake temperature settings. The preferred settings can be learned over time, such as by capturing the temperatures set in the thermostat before the person goes to sleep and upon waking up. Collected data may also include biometric indications of a person, such as breathing patterns, heart rate, movement, etc., from which inferences are made based on this data in combination with data that indicates when the person actually wakes up. Other wireless network devices can use the data to provide other automation objectives, such as adjusting the thermostat <NUM> so as to pre-heat or cool the environment to a desired setting and turning on or turning off the lighting units <NUM>.

In implementations, the wireless network devices can also be utilized for sound, vibration, and/or motion sensing such as to detect running water and determine inferences about water usage in a home environment based on algorithms and mapping of the water usage and consumption. This can be used to determine a signature or fingerprint of each water source in the home and is also referred to as "audio fingerprinting water usage. " Similarly, the wireless network devices can be utilized to detect the subtle sound, vibration, and/or motion of unwanted pests, such as mice and other rodents, as well as by termites, cockroaches, and other insects. The system can then notify an occupant of the suspected pests in the environment, such as with warning messages to help facilitate early detection and prevention.

The environment <NUM> may include one or more wireless network devices that function as a hub <NUM>. The hub <NUM> (e.g., hub <NUM>) may be a general-purpose home automation hub, or an application-specific hub, such as a security hub, an energy management hub, an HVAC hub, and so forth. The functionality of a hub <NUM> may also be integrated into any wireless network device, such as a network-connected thermostat device or the border router <NUM>. Hosting functionality on the hub <NUM> in the structure <NUM> can improve reliability when the user's internet connection is unreliable, can reduce latency of operations that would normally have to connect to the cloud service <NUM>, and can satisfy system and regulatory constraints around local access between wireless network devices.

Additionally, the example environment <NUM> includes a network-connected -speaker <NUM>. The network-connected speaker <NUM> provides voice assistant services that include providing voice control of network-connected devices. The functions of the hub <NUM> may be hosted in the network-connected speaker <NUM>. The network-connected speaker <NUM> can be configured to communicate via the HAN, which may include a wireless mesh network, a Wi-Fi network, or both.

<FIG> is a block diagram illustrating a representative network architecture <NUM> that includes a home area network <NUM> (HAN <NUM>) in accordance with some implementations. In some implementations, electronic devices <NUM> (e.g., wireless network devices <NUM>) in the network environment <NUM> combine with the hub <NUM> to create a mesh network in the HAN <NUM>. In some implementations, one or more of the smart devices <NUM> in the HAN <NUM> operate as a smart home controller. Additionally and/or alternatively, the hub <NUM> may operate as the smart home controller. In some implementations, a smart home controller has more computing power than other smart devices. The smart home controller can process inputs (e.g., from smart devices <NUM>, end user devices <NUM>, and/or server system <NUM>) and send commands (e.g., to smart devices <NUM> in the HAN <NUM>) to control operation of the network environment <NUM>. In aspects, some of the smart devices <NUM> in the HAN <NUM> (e.g., in the mesh network) are "spokesman" nodes (e.g., <NUM>-<NUM>, <NUM>-<NUM>) and others are "low-powered" nodes (e.g., <NUM>-n). Some of the smart devices in the network environment <NUM> may be battery-powered, while others may have a regular and reliable power source, such as via line power (e.g., to 120V line voltage wires). The smart devices that have a regular and reliable power source are referred to as "spokesman" nodes. These nodes are typically equipped with the capability of using a wireless protocol to facilitate bidirectional communication with a variety of other devices in the network environment <NUM>, as well as with the server system <NUM> (e.g., cloud service <NUM>, partner cloud service <NUM>). In some implementations, one or more "spokesman" nodes operate as a smart home controller. On the other hand, the devices that are battery-powered are the "low-power" nodes. These nodes tend to be smaller than spokesman nodes and typically only communicate using wireless protocols that require very little power, such as Zigbee, ZWave, 6LoWPAN, Thread, Bluetooth, etc..

Some low-power nodes may be incapable of bidirectional communication. These low-power nodes send messages but are unable to "listen". Thus, other devices in the network environment <NUM>, such as the spokesman nodes, cannot send information to these low-power nodes.

Some low-power nodes may be capable of only a limited bidirectional communication. As a result of such limited bidirectional communication, other devices may be able to communicate with these low-power nodes only during a certain time period.

As described, in some implementations, the smart devices serve as low-power and spokesman nodes to create a mesh network in the network environment <NUM>. In some implementations, individual low-power nodes in the network environment regularly send out messages regarding what they are sensing, and the other low-powered nodes in the network environment-in addition to sending out their own messages-forward the messages, thereby causing the messages to travel from node to node (e.g., device to device) throughout the HAN <NUM>. In some implementations, the spokesman nodes in the HAN <NUM>, which are able to communicate using a relatively high-power communication protocol (e.g., IEEE <NUM>), are able to switch to a relatively low-power communication protocol (e.g., IEEE <NUM>. <NUM>) to receive these messages, translate the messages to other communication protocols, and send the translated messages to other spokesman nodes and/or the server system <NUM> (using, e.g., the relatively high-power communication protocol). Thus, the low-powered nodes using low-power communication protocols are able to send and/or receive messages across the entire HAN <NUM>, as well as over the Internet (e.g., network <NUM>) to the server system <NUM>. In some implementations, the mesh network enables the server system <NUM> to regularly receive data from most or all of the smart devices in the home, make inferences based on the data, facilitate state synchronization across devices within and outside of the HAN <NUM>, and send commands to one or more of the smart devices to perform tasks in the network environment.

As described, the spokesman nodes and some of the low-powered nodes are capable of "listening. " Accordingly, users, other devices, and/or the server system <NUM> may communicate control commands to the low-powered nodes. For example, a user may use the end user device <NUM> (e.g., a smart phone) to send commands over the Internet to the server system <NUM>, which then relays the commands to one or more spokesman nodes in the HAN <NUM>. The spokesman nodes may use a low-power protocol to communicate the commands to the low-power nodes throughout the HAN <NUM>, as well as to other spokesman nodes that did not receive the commands directly from the server system <NUM>.

In some implementations, a lighting unit <NUM> (<FIG>), which is an example of a smart device <NUM>, may be a low-power node. In addition to housing a light source, the lighting unit <NUM> may house an occupancy sensor (e.g., occupancy sensor <NUM>), such as an ultrasonic or passive IR sensor, and an ambient light sensor (e.g., ambient light sensor <NUM>), such as a photo resistor or a single-pixel sensor that measures light in the room. In some implementations, the lighting unit <NUM> is configured to activate the light source when its ambient light sensor detects that the room is dark and when its occupancy sensor detects that someone is in the room. In other implementations, the lighting unit <NUM> is simply configured to activate the light source when its ambient light sensor detects that the room is dark. Further, in some implementations, the lighting unit <NUM> includes a low-power wireless communication chip (e.g., a ZigBee chip) that regularly sends out messages regarding the occupancy of the room and the amount of light in the room, including instantaneous messages coincident with the occupancy sensor detecting the presence of a person in the room. As mentioned above, these messages may be sent wirelessly (e.g., using the mesh network) from node to node (e.g., smart device to smart device) within the HAN <NUM> as well as over the Internet <NUM> to the server system <NUM>.

Other examples of low-power nodes include battery-operated versions of the hazard detectors <NUM>. These hazard detectors <NUM> are often located in an area without access to constant and reliable power and may include any number and type of sensors, such as smoke/fire/heat sensors (e.g., thermal radiation sensors), carbon monoxide/dioxide sensors, occupancy/motion sensors, ambient light sensors, ambient temperature sensors, humidity sensors, and the like. Furthermore, hazard detectors <NUM> may send messages that correspond to each of the respective sensors to the other devices and/or the server system <NUM>, such as by using the mesh network as described above.

Examples of spokesman nodes include entryway interface devices <NUM> (e.g., smart doorbells), thermostats <NUM>, control panels <NUM>, electrical outlets <NUM>, and other wireless network devices <NUM>. These devices are often located near and connected to a reliable power source, and therefore may include more power-consuming components, such as one or more communication chips capable of bidirectional communication in a variety of protocols.

In some implementations, the network environment <NUM> includes controlled systems <NUM>, such as service robots, that are configured to carry out, in an autonomous manner, any of a variety of household tasks.

As explained with reference to <FIG>, in some implementations, the network environment <NUM> includes a hub device (e.g., hub <NUM>) that is communicatively coupled to the network(s) <NUM> directly or via a network interface <NUM> (e.g., access point <NUM>). The hub <NUM> is further communicatively coupled to one or more of the smart devices <NUM> using a radio communication network that is available at least in the network environment <NUM>. Communication protocols used by the radio communication network include, but are not limited to, ZigBee, Z-Wave, Insteon, EuOcean, Thread, OSIAN, Bluetooth Low Energy, and the like. In some implementations, the hub <NUM> not only converts the data received from each smart device to meet the data format requirements of the network interface <NUM> or the network(s) <NUM>, but also converts information received from the network interface <NUM> or the network(s) <NUM> to meet the data format requirements of the respective communication protocol associated with a targeted smart device. In some implementations, in addition to data format conversion, the hub <NUM> further processes the data received from the smart devices or information received from the network interface <NUM> or the network(s) <NUM> preliminary. For example, the hub <NUM> can integrate inputs from multiple sensors/connected devices (including sensors/devices of the same and/or different types), perform higher-level processing on those inputs-e.g., to assess the overall environment and coordinate operation among the different sensors/devices-and/or provide instructions to the different devices based on the collection of inputs and programmed processing. It is also noted that in some implementations, the network interface <NUM> and the hub <NUM> are integrated into one network device. Functionality described herein is representative of particular implementations of smart devices, control application(s) running on representative electronic device(s) (such as a smart phone), hub(s) <NUM>, and server system(s) <NUM> coupled to hub(s) <NUM> via the Internet or other Wide Area Network. All or a portion of this functionality and associated operations can be performed by any elements of the described system-for example, all or a portion of the functionality described herein as being performed by an implementation of the hub can be performed, in different system implementations, in whole or in part on the server, one or more connected smart devices and/or the control application, or different combinations thereof.

<FIG> illustrates a representative operating environment <NUM> in which a server system <NUM> provides data processing for monitoring and facilitating review of events (e.g., motion, audio, security, etc.) in video streams captured by cameras <NUM> (e.g., video cameras, doorbell cameras). As shown in <FIG>, the server system <NUM> receives video data from video sources <NUM> (including video cameras <NUM> or video-recording doorbells <NUM>) located at various physical locations (e.g., inside or in proximity to homes, restaurants, stores, streets, parking lots, and/or the network environments <NUM> of <FIG>). Each video source <NUM> may be linked to one or more reviewer accounts, and the server system <NUM> provides video monitoring data for the video source <NUM> to client devices <NUM> associated with the reviewer accounts. For example, the portable end user device <NUM> is an example of the client device <NUM>. In some implementations, the server system <NUM> is a video processing server that provides video processing services to the video sources and client devices <NUM>.

In some implementations, the server system <NUM> receives non-video data from one or more smart devices <NUM> (e.g., audio data, metadata, numerical data, etc.). The non-video data may be analyzed to provide context for motion events detected by the video cameras <NUM> and/or the video-recording doorbells <NUM>. In some implementations, the non-video data indicates that an audio event (e.g., detected by an audio device such as an audio sensor integrated into the network-connected speaker <NUM>), a security event (e.g., detected by a perimeter monitoring device such as the camera <NUM> and/or a motion sensor), a hazard event (e.g., detected by the hazard detector <NUM>), medical event (e.g., detected by a health-monitoring device), or the like has occurred within a network environment <NUM>.

In some implementations, multiple reviewer accounts are linked to a single network environment <NUM>. For example, multiple occupants of a network environment <NUM> may have accounts liked to the network environment <NUM>. In some implementations, each reviewer account is associated with a particular level of access. In some implementations, each reviewer account has personalized notification settings. In some implementations, a single reviewer account is linked to multiple network environments <NUM> (e.g., multiple different HANs). For example, a person may own or occupy, or be assigned to review and/or govern, multiple network environments <NUM>. In some implementations, the reviewer account has distinct levels of access and/or notification settings for each network environment.

In some implementations, each of the video sources <NUM> includes one or more video cameras <NUM> or video-recording doorbells <NUM> that capture video and send the captured video to the server system <NUM> substantially in real-time. In some implementations, each of the video sources <NUM> includes one or more doorbells <NUM> that capture video and send the captured video to the server system <NUM> in real-time (e.g., within <NUM> second, <NUM> seconds, <NUM> seconds, or <NUM> minute). Each of the doorbells <NUM> may include a video camera that captures video and sends the captured video to the server system <NUM> in real-time. In aspects, a video source <NUM> includes a controller device (not shown) that serves as an intermediary between the one or more doorbells <NUM> and the server system <NUM>. The controller device receives the video data from the one or more doorbells <NUM>, optionally performs some preliminary processing on the video data, and sends the video data and/or the results of the preliminary processing to the server system <NUM> on behalf of the one or more doorbells <NUM> (e.g., in real-time). In some implementations, each camera has its own on-board processing capabilities to perform some preliminary processing on the captured video data before sending the video data (e.g., along with metadata obtained through the preliminary processing) to the controller device and/or the server system <NUM>. In some implementations, one or more of the cameras is configured to, optionally, locally store the video data (e.g., for later transmission if requested by a user). In some implementations, a camera is configured to perform some processing of the captured video data and, based on the processing, either send the video data in substantially real-time, store the video data locally, or disregard the video data.

In accordance with some implementations, a client device <NUM> includes a client-side module <NUM>. In some implementations, the client-side module communicates with a server-side module <NUM> executed on the server system <NUM> through the one or more networks <NUM>. The client-side module provides client-side functionality for the event monitoring and review processing and communications with the server-side module. The server-side module provides server-side functionality for event monitoring and review processing for any number of client-side modules each residing on a respective client device <NUM> (e.g., any one of client devices <NUM>-<NUM> to <NUM>-m). In some implementations, the server-side module <NUM> also provides server-side functionality for video processing and camera control for any number of the video sources <NUM>, including any number of control devices, cameras <NUM>, and doorbells <NUM>.

In some implementations, the server system <NUM> includes one or more processors <NUM>, a video storage database <NUM>, an account database <NUM>, an input/output (I/O) interface <NUM> to one or more client devices <NUM>, and an I/O interface <NUM> to one or more video sources <NUM>. The I/O interface <NUM> to one or more client devices <NUM> facilitates the client-facing input and output processing. The account database <NUM> stores a plurality of profiles for reviewer accounts registered with the video processing server, where a respective user profile includes account credentials for a respective reviewer account, and one or more video sources linked to the respective reviewer account. The I/O interface <NUM> to one or more video sources <NUM> facilitates communications with one or more video sources <NUM> (e.g., groups of one or more doorbells <NUM>, cameras <NUM>, and associated controller devices). The video storage database <NUM> stores raw video data received from the video sources <NUM>, as well as various types of metadata, such as motion events, event categories, event categorization models, event filters, and event masks, for use in data processing for event monitoring and review for each reviewer account.

Examples of a representative client device <NUM> include a handheld computer, a wearable computing device, a personal digital assistant (PDA), a tablet computer, a laptop computer, a desktop computer, a cellular telephone, a smart phone, an enhanced general packet radio service (EGPRS) mobile phone, a media player, a navigation device, a game console, a television, a remote control, a point-of-sale (POS) terminal, a vehicle-mounted computer, an eBook reader, or a combination of any two or more of these data processing devices or other data processing devices.

Examples of the one or more networks <NUM> include local area networks (LAN) and wide area networks (WAN) such as the Internet. The one or more networks <NUM> are implemented using any known network protocol, including various wired or wireless protocols, such as Ethernet, Universal Serial Bus (USB), FIREWIRE, Long Term Evolution (LTE), Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), code division multiple access (CDMA), time division multiple access (TDMA), Bluetooth, Wi-Fi, voice over Internet Protocol (VoIP), Wi-MAX, or any other suitable communication protocol.

In some implementations, the server system <NUM> is implemented on one or more standalone data processing apparatuses or a distributed network of computers. The server system <NUM> may also employ various virtual devices and/or services of third-party service providers (e.g., third-party cloud service providers) to provide the underlying computing resources and/or infrastructure resources of the server system <NUM>. In some implementations, the server system <NUM> includes, but is not limited to, a server computer, a handheld computer, a tablet computer, a laptop computer, a desktop computer, or a combination of any two or more of these data processing devices or other data processing devices.

The server-client environment shown in <FIG> includes both a client-side portion (e.g., the client-side module) and a server-side portion (e.g., the server-side module). The division of functionality between the client and server portions of the operating environment can vary in different implementations. Similarly, the division of functionality between a video source <NUM> and the server system <NUM> can vary in different implementations. For example, in some implementations, the client-side module is a thin client that provides only user-facing input and output processing functions, and delegates all other data processing functionality to a backend server (e.g., the server system <NUM>). Similarly, in some implementations, a respective one of the video sources <NUM> is a simple video capturing device that continuously captures and streams video data to the server system <NUM> with limited or no local preliminary processing on the video data. Although many aspects of the present technology are described from the perspective of the server system <NUM>, the corresponding actions performed by a client device <NUM> and/or the video sources <NUM> would be apparent to one of skill in the art. Similarly, some aspects of the present technology may be described from the perspective of a client device or a video source, and the corresponding actions performed by the video server would be apparent to one of skill in the art. Furthermore, some aspects of the present technology may be performed by the server system <NUM>, a client device <NUM>, and a video source <NUM> cooperatively.

In some aspects, a video source <NUM> (e.g., a video camera <NUM> or a doorbell <NUM> having an image sensor) transmits one or more streams <NUM> of video data to the server system <NUM>. In some implementations, the one or more streams include multiple streams, having respective resolutions and/or frame rates, of the raw video captured by the image sensor. In some implementations, the multiple streams include a "primary" stream (e.g., <NUM>-<NUM>) with a certain resolution and frame rate, corresponding to the raw video captured by the image sensor, and one or more additional streams (e.g., <NUM>-<NUM> through <NUM>-q). An additional stream is optionally the same video stream as the "primary" stream but at a different resolution and/or frame rate, or a stream that captures a portion of the "primary" stream (e.g., cropped to include a portion of the field of view or pixels of the primary stream) at the same or different resolution and/or frame rate as the "primary" stream. In some implementations, the primary stream and/or the additional streams are dynamically encoded (e.g., based on network conditions, server operating conditions, camera operating conditions, characterization of data in the stream (e.g., whether motion is present), user preferences, and the like.

In some implementations, one or more of the streams <NUM> is sent from the video source <NUM> directly to a client device <NUM> (e.g., without being routed to, or processed by, the server system <NUM>). In some implementations, one or more of the streams is stored at a local memory of the doorbell <NUM> and/or at a local storage device (e.g., a dedicated recording device), such as a digital video recorder (DVR). For example, in accordance with some implementations, the doorbell <NUM> stores the most-recent <NUM> hours of video footage recorded by the camera. In some implementations, portions of the one or more streams are stored at the doorbell <NUM> and/or the local storage device (e.g., portions corresponding to particular events or times of interest).

In some implementations, the server system <NUM> transmits one or more streams <NUM> of video data to a client device <NUM> to facilitate event monitoring by a user. In some implementations, the one or more streams may include multiple streams, of respective resolutions and/or frame rates, of the same video feed. In some implementations, the multiple streams include a "primary" stream (e.g., <NUM>-<NUM>) with a certain resolution and frame rate, corresponding to the video feed, and one or more additional streams (e.g., <NUM>-<NUM> through <NUM>-t). An additional stream may be the same video stream as the "primary" stream but at a different resolution and/or frame rate, or a stream that shows a portion of the "primary" stream (e.g., cropped to include a portion of the field of view or pixels of the primary stream) at the same or different resolution and/or frame rate as the "primary" stream.

3A is a block diagram illustrating the server system <NUM> in accordance with some implementations. The server system <NUM> typically includes one or more processors <NUM>, one or more network interfaces <NUM> (e.g., including the I/O interface <NUM> to one or more client devices and the I/O interface <NUM> to one or more electronic devices), memory <NUM>, and one or more communication buses <NUM> for interconnecting these components (sometimes called a chipset). The memory <NUM> includes high-speed random access memory, such as DRAM, SRAM, DDR SRAM, or other random access solid-state memory devices; and, optionally, includes non-volatile memory, such as one or more magnetic disk storage devices, one or more optical disk storage devices, one or more flash memory devices, or one or more other non-volatile solid-state storage devices. The memory <NUM>, optionally, includes one or more storage devices remotely located from one or more of the processors <NUM>. The memory <NUM>, or alternatively the non-volatile memory within memory <NUM>, includes a non-transitory computer-readable storage medium. In some implementations, the memory <NUM>, or the non-transitory computer-readable storage medium of the memory <NUM>, stores the following programs, modules, and data structures, or a subset or superset thereof:.

Each of the above-identified elements may be stored in one or more of the previously mentioned memory devices and may correspond to a set of instructions for performing a function described above. The above-identified modules or programs (e.g., sets of instructions) need not be implemented as separate software programs, procedures, or modules, and thus various subsets of these modules may be combined or otherwise rearranged in various implementations. In some implementations, the memory <NUM>, optionally, stores a subset of the modules and data structures identified above. Furthermore, the memory <NUM>, optionally, stores additional modules and data structures not described above.

<FIG> is a block diagram illustrating an example smart device <NUM> in accordance with some implementations. In some implementations, the smart device <NUM> (e.g., any device of the network environment <NUM> in <FIG>, including end user device <NUM>) includes one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, microprocessors, and the like), one or more communication interfaces <NUM> with radios <NUM>, image sensor (s) <NUM>, user interfaces(s) <NUM>, sensor(s) <NUM>, memory <NUM>, and one or more communication buses <NUM> for interconnecting these components (sometimes called a chipset). In some implementations, the user interface <NUM> includes one or more output devices <NUM> that enable presentation of media content, including one or more speakers and/or one or more visual displays. In some implementations, the user interface <NUM> includes one or more input devices <NUM>, including user interface components that facilitate user input such as a keyboard, a mouse, a voice-command input unit or microphone, a touch screen display, a touch-sensitive input pad, a gesture capturing camera, or other input buttons or controls. In some implementations, an input device <NUM> for a doorbell <NUM> is a tactile or touch-sensitive doorbell button. Furthermore, some smart devices <NUM> use a microphone and voice recognition or a camera and gesture recognition to supplement or replace the keyboard.

The sensor(s) <NUM> include, for example, one or more thermal radiation sensors, ambient temperature sensors, humidity sensors, infrared (IR) sensors such as passive infrared (PIR) sensors, proximity sensors, range sensors, occupancy sensors (e.g., using RFID sensors), ambient light sensors (ALS), motion sensors <NUM>, location sensors (e.g., GPS sensors), accelerometers, and/or gyroscopes.

In some implementations, the smart device <NUM> includes an energy storage component <NUM> (e.g., one or more batteries and/or capacitors). In some implementations, the energy storage component <NUM> includes a power management integrated circuit (IC). In some implementations, the energy storage component <NUM> includes circuitry to harvest energy from signals received via an antenna (e.g., the radios <NUM>) of the smart device. In some implementations, the energy storage component <NUM> includes circuitry to harvest thermal, vibrational, electromagnetic, and/or solar energy received by the smart device. In some implementations, the energy storage component <NUM> includes circuitry to monitor a stored energy level and adjust operation and/or generate notifications based on changes to the stored energy level.

The communication interfaces <NUM> include, for example, hardware capable of data communications using any of a variety of custom or standard wireless protocols (e.g., IEEE <NUM>. <NUM>, Wi-Fi, ZigBee, 6LoWPAN, Thread, Z-Wave, Bluetooth Smart, ISA100.5A, WirelessHART, MiWi, etc.) and/or any of a variety of custom or standard wired protocols (e.g., Ethernet, HomePlug, etc.), or any other suitable communication protocol, including communication protocols not yet developed as of the filing date of this document. The radios <NUM> enable one or more radio communication networks in the network environments <NUM>, and enable a smart device <NUM> to communicate with other devices. In some implementations, the radios <NUM> are capable of data communications using any of a variety of custom or standard wireless protocols (e.g., IEEE <NUM>. <NUM>, Wi-Fi, ZigBee, 6LoWPAN, Thread, Z-Wave, Bluetooth Smart, ISA100.5A, WirelessHART, MiWi, etc.).

The memory <NUM> includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid-state memory devices; and, optionally, includes non-volatile memory, such as one or more magnetic disk storage devices, one or more optical disk storage devices, one or more flash memory devices, or one or more other non-volatile solid-state storage devices. The memory <NUM>, or alternatively the non-volatile memory within the memory <NUM>, includes a non-transitory computer-readable storage medium. In some implementations, the memory <NUM>, or the non-transitory computer-readable storage medium of the memory <NUM>, stores the following programs, modules, and data structures, or a subset or superset thereof:.

Each of the above-identified elements may be stored in one or more of the previously mentioned memory devices and correspond to a set of instructions for performing a function described above. The above-identified modules or programs (e.g., sets of instructions) need not be implemented as separate software programs, procedures, or modules, and thus various subsets of these modules may be combined or otherwise rearranged in various implementations. In some implementations, the memory <NUM>, optionally, stores a subset of the modules and data structures identified above. Furthermore, the memory <NUM>, optionally, stores additional modules and data structures not described above, such as a sensor management module for managing operation of the sensor(s) <NUM>.

<FIG> is a block diagram illustrating a representative client device <NUM> associated with a user account in accordance with some implementations. The client device <NUM>, typically, includes one or more processing units (CPUs) <NUM>, one or more network interfaces <NUM>, memory <NUM>, and one or more communication buses <NUM> for interconnecting these components (sometimes called a chipset). Optionally, the client device also includes a user interface <NUM> and one or more built-in sensors <NUM> (e.g., accelerometer and gyroscope). The user interface <NUM> includes one or more output devices <NUM> that enable presentation of media content, including one or more speakers and/or one or more visual displays. The user interface <NUM> also includes one or more input devices <NUM>, including user interface components that facilitate user input such as a keyboard, a mouse, a voice-command input unit or microphone, a touch screen display, a touch-sensitive input pad, a gesture capturing camera, or other input buttons or controls. Furthermore, some of the client devices use a microphone and voice recognition or a camera and gesture recognition to supplement or replace the keyboard. In some implementations, the client device includes one or more cameras, scanners, or photo sensor units for capturing images (not shown). Optionally, the client device includes a location detection device <NUM>, such as a GPS (global positioning satellite) sensor or other geo-location receiver, for determining the location of the client device.

The memory <NUM> includes high-speed random access memory, such as DRAM, SRAM, DDR SRAM, or other random access solid-state memory devices; and, optionally, includes non-volatile memory, such as one or more magnetic disk storage devices, one or more optical disk storage devices, one or more flash memory devices, or one or more other non-volatile solid-state storage devices. The memory <NUM>, optionally, includes one or more storage devices remotely located from one or more processing units <NUM>. The memory <NUM>, or alternatively the non-volatile memory within the memory <NUM>, includes a non-transitory computer-readable storage medium. In some implementations, the memory <NUM>, or the non-transitory computer-readable storage medium of the memory <NUM>, stores the following programs, modules, and data structures, or a subset or superset thereof:.

Each of the above-identified elements may be stored in one or more of the previously mentioned memory devices and may correspond to a set of instructions for performing a function described above. The above-identified modules or programs (e.g., sets of instructions) need not be implemented as separate software programs, procedures, modules, or data structures, and thus various subsets of these modules may be combined or otherwise rearranged in various implementations. In some implementations, the memory <NUM>, optionally, stores a subset of the modules and data structures identified above. Furthermore, the memory <NUM>, optionally, stores additional modules and data structures not described above.

The entities described with respect to <FIG> may be further divided, combined, and so on. The environment <NUM> of <FIG> and the detailed illustrations of <FIG> illustrate some of many possible environments, devices, and methods capable of employing the described techniques, whether individually or in combination with one another.

<FIG> illustrates an isometric view <NUM> of an example video-recording doorbell (e.g., doorbell <NUM>) having a camera module, in accordance with some implementations. The doorbell <NUM> is illustrated as having a longitudinal axis <NUM> (e.g., y-axis), a lateral axis <NUM> (e.g., x-axis), and a central axis <NUM> (e.g., z-axis). The doorbell <NUM> may be elongated along the longitudinal axis such that the doorbell <NUM> has a height along the longitudinal axis <NUM> that is significantly greater (at least by a magnitude of two) than a width along the lateral axis <NUM>, and the width is greater than a depth along the central axis <NUM>. The doorbell <NUM> includes a camera-side end <NUM> and a button-side end <NUM>. The camera-side end <NUM> of the doorbell <NUM> includes an IR cover <NUM>, which includes a portion that is substantially transparent (e.g., <NUM>%, <NUM>%, <NUM>%, <NUM>% transparent) or translucent to IR light and another portion that is substantially opaque (e.g., <NUM>%, <NUM>%, <NUM>%, <NUM>% opaque) to IR light.

In aspects, the IR cover extends outwardly from a first surface <NUM> (e.g., front surface) of the housing of the doorbell <NUM>. The IR cover <NUM> forms an annular shape with a center aperture through which a camera lens <NUM> of the camera module (e.g., camera module <NUM> in <FIG>) extends. The annular shape is generally elliptical and, in some cases, where its major and minor axes are equal, the shape is circular. A retainer <NUM> (e.g., lens retainer) surrounds the camera lens <NUM> in the xy plane and extends through the center aperture of the IR cover <NUM> to protrude from an outer surface of the IR cover <NUM>. In this way, the retainer <NUM> extends outwardly from the housing (and from the IR cover <NUM>) and is exposed to the environment surrounding the doorbell <NUM>. In an example, the retainer <NUM> has a substantially tubular shape (with an elliptical cross-section or a circular cross-section) and the camera lens <NUM> is positioned within a center area of the retainer <NUM>. The retainer <NUM> reduces and/or prevents IR light from leaking into the camera lens <NUM> through the IR cover <NUM>. The IR light may be provided by IR illuminators (e.g., IR LEDs) disposed behind the IR cover <NUM> and configured to direct the IR light through one or more apertures <NUM> in the IR cover <NUM>. Also, the IR light may be received from the ambient environment, through the IR cover, and captured by a sensor (e.g., the image sensor, a passive infrared (PIR) sensor). Accordingly, the retainer <NUM> prevents the IR light from leaking into the sides or edges of the camera lens <NUM> from the IR cover <NUM>.

The button-side end <NUM> of the doorbell <NUM> includes a button <NUM>, which is pressable by a user to initiate a notification (e.g., chime). In aspects, the button <NUM> may be surrounded by a light ring <NUM>, which may be substantially flush with the first surface <NUM> of the doorbell <NUM>. The button <NUM> and/or light ring <NUM> may have a shape and/or size that substantially matches the outline and/or size of the IR cover <NUM>. In an example, the button <NUM> may have a diameter that is substantially equal to the outer diameter of the IR cover <NUM>. In another example, the light ring <NUM> has an outer diameter that is substantially the same as the outer diameter of the IR cover <NUM>.

<FIG> illustrates a front elevational view <NUM> of the example doorbell <NUM> in <FIG>. As illustrated, the camera lens <NUM> of the camera module <NUM> (not shown in <FIG>) is centered with respect to the IR cover <NUM> and encircled by the retainer <NUM>. In the xy-plane (e.g., cross-section of the retainer <NUM>), the button <NUM> has an elliptical shape, in which its major axis and minor axis are different (e.g., forming an ellipse) or equal to one another (e.g., forming a circular shape). The IR cover <NUM> may have an elliptical shape similar to that of the button <NUM>.

<FIG> illustrates a right elevational view <NUM> of the example doorbell <NUM> in <FIG>, in accordance with some implementations. As illustrated, the retainer <NUM> extends outwardly (in the z-direction) from the IR cover <NUM>, which prevents IR light traveling through the IR cover <NUM> from leaking into the camera lens <NUM>. The camera lens <NUM> may extend outwardly (in the z-direction) from the retainer <NUM> in order to maximize the field of view of the image sensor (e.g., image sensor <NUM> in <FIG>) via the camera lens <NUM>.

<FIG> illustrates an exploded view <NUM> of the example doorbell <NUM> in <FIG>. The doorbell <NUM> includes a front housing component <NUM> and a rear housing component <NUM>, which connect together to form a housing that encloses various components of the doorbell <NUM>. The IR cover <NUM> is assembled to an exterior surface (e.g., front surface, the first surface <NUM> in <FIG>) of the front housing component <NUM>. At the button-side end <NUM>, the doorbell <NUM> includes a button subassembly <NUM>, which may include the button <NUM>, a first reflector <NUM>, button foam <NUM>, a button flange <NUM>, a light guide <NUM>, a rubber button <NUM>, a dome <NUM>, a second reflector <NUM>, and a button PCB (e.g., button board <NUM>). One or more fasteners (e.g., fasteners <NUM>) may be used to assemble the components of the button subassembly <NUM> together.

The doorbell <NUM> also includes a speaker subassembly <NUM> and one or more antennas <NUM>, which are assembled in proximity to one another and to the button subassembly <NUM>. The doorbell <NUM> includes a battery <NUM>, which may be seated into a battery frame <NUM>. A battery heater <NUM> may be used to heat the battery <NUM> to maintain the battery <NUM> within an operable temperature range when the doorbell <NUM> is exposed to a cold environment (e.g., sub-zero temperatures).

At the camera-side end <NUM>, the doorbell <NUM> may include a PCB <NUM>, which may be a subassembly for IR sensors (passive infrared sensors), IR LEDs, and/or audio sensors (e.g., microphone). Pressure-sensitive adhesive (PSA) <NUM> may be disposed between the PCB <NUM> and the front housing component <NUM>. Also, mesh <NUM> for the audio sensor may be disposed adjacent to the audio sensor. Additionally, an IR flexible printed circuit (FPC) <NUM> may connect the PCB <NUM> to the camera module <NUM>. The camera module <NUM> includes a camera subassembly <NUM> and a PCB (e.g., camera board <NUM>). The camera subassembly <NUM> is aligned with the IR cover <NUM>. In aspects, one or more thermal interface materials (TIMs) <NUM> may be disposed adjacent to the camera board <NUM> to transfer heat generated by one or more integrated circuit components on the camera board <NUM>, including an image sensor. Fasteners <NUM> may be used to fasten the camera board <NUM> to the camera subassembly <NUM> and/or the front housing component.

A main FPC <NUM> may be used to connect the camera board <NUM> to a main logic board (MLB) subassembly <NUM> for the doorbell <NUM>. A heat sink <NUM> may be disposed adjacent to the MLB subassembly <NUM> to distribute heat away from the MLB subassembly <NUM> and transfer the heat toward the housing, including the rear housing component <NUM>. A gasket <NUM> (e.g., an O-ring) may be disposed between the rear housing component <NUM> and the front housing component <NUM> to form a seal and prevent water ingress along the seam between the housing components <NUM> and <NUM>. The doorbell <NUM> may also include a label plate <NUM> for adding and/or interchanging one or more labels. Electrical connectors <NUM> (e.g., wiring, dongle) are used to connect the doorbell <NUM> to line power. To mount the doorbell <NUM> to a surface (e.g., a wall), a wall plate <NUM> and/or a wedge <NUM> may be used. The wall plate <NUM> and the wedge <NUM> may be fixed to the surface. The doorbell <NUM> includes one or more studs <NUM> that are attached to the rear housing component <NUM> and are configured to hook onto the wall plate <NUM> to secure the doorbell <NUM> to the surface. After assembling the doorbell <NUM> to the wall plate <NUM>, a lock fastener <NUM> may be used to further secure the doorbell <NUM> to the wall plate <NUM>. A hex key <NUM> (e.g., Allen key) or other suitable tool may be used to insert and tighten the lock fastener <NUM> into place.

<FIG> illustrates an example implementation of a camera module (e.g., the camera module <NUM>). In the illustrated example, the camera subassembly <NUM> is mounted to the camera board <NUM>. Also, the camera module <NUM> includes a movable lens retainer (e.g., retainer <NUM>), which is movable along the z-axis (e.g., direction of an axial center <NUM> of the camera lens) for camera focus tuning. The retainer <NUM> surrounds the camera lens <NUM> to prevent IR light from leaking into the camera lens <NUM> in the xy-plane. The retainer <NUM> is metal, however, and therefore vulnerable to attracting ESD sparks. Included in the camera subassembly <NUM> is an electrically conductive material (e.g., ESD bridge component <NUM>, also referred to herein as a "lightning rod structure"), which is configured to guide ESD energy passing through the retainer <NUM> to the system ground. In this way, the ESD bridge component <NUM> acts as a bridge to route the ESD current from the retainer to the system ground. The ESD bridge component <NUM> may have any suitable shape, including the illustrated planar shape with a body portion and an arm portion extending outwardly from the body portion in the plane. The ESD bridge component <NUM> may be oriented relative to the retainer <NUM> such that the arm is between the body and the retainer <NUM>. The tip of the arm is sharp (e.g., triangular, pointed). In this way, the electrical field between the ESD bridge component <NUM> and the retainer <NUM> is significantly higher than other regions and the space (e.g., gap) between the tip of the arm and the retainer <NUM> is easier to be electrically broken down. In one implementation, the plane defined by the planar shape of the ESD bridge component <NUM> is substantially orthogonal to the axial center <NUM> of the camera lens <NUM>. In another implementation, the plane defined by the planar shape of the ESD bridge component <NUM> is non-orthogonal and non-parallel to the axial center <NUM> of the camera lens <NUM>. In other implementations, the ESD bridge component <NUM> has a non-planar shape (e.g., curved) but guides the ESD current away from the retainer <NUM> and to the system ground.

<FIG> illustrates an exploded view <NUM> of the camera module <NUM> in <FIG>. The camera module <NUM> includes a gasket <NUM> (e.g., O-ring), the ESD bridge component <NUM>, and the retainer <NUM> assembled to a lens holder <NUM>. A removable IR cut filter <NUM> (ICR <NUM>) may be inserted into the lens holder <NUM>. The camera board <NUM> includes an image sensor <NUM> (e.g., the image sensor <NUM>), which may be protected by a rubber seal <NUM>. When assembled together, the ICR <NUM> is arranged between the camera lens <NUM> and the image sensor <NUM> to block IR light during the day to enable capture of clear images. At night, the ICR <NUM> may be moved away from the lens for surveillance in low light. The camera module <NUM> may also include a shielding element <NUM> having graphite. One or more thermal interface materials <NUM> may be disposed between the camera board <NUM> and the shielding element <NUM> to help distribute heat generated by integrated components (e.g., the image sensor <NUM>) on the camera board <NUM>. The camera module <NUM> and its components are further described with respect to <FIG>.

<FIG> illustrates a cross-section view <NUM> of the doorbell <NUM> in <FIG>, taken along line A-A in <FIG>. When an ESD spark <NUM> hits the metal retainer <NUM>, ESD current <NUM> travels through the retainer <NUM>. For example, the retainer <NUM> may receive the ESD current <NUM> when an ESD spark jumps from an electrostatically charged person or object that touches or moves into proximity (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) of the retainer <NUM>. The ESD bridge component <NUM> is disposed in a location and an orientation to provide a conductive path for the ESD current <NUM> from the retainer <NUM> to system ground (e.g., the heat sink <NUM>, which may be grounded to an external ground via one or more conductive paths in the doorbell <NUM>). The ESD bridge component <NUM> does not touch or contact the retainer <NUM>, enabling the retainer <NUM> to move during focus tuning of the camera without adversely affecting a connection to the ESD bridge component <NUM>. Rather, a gap (e.g., gap <NUM>) exists between the retainer <NUM> and the ESD bridge component <NUM> to enable movement of the retainer <NUM> relative to the ESD bridge component <NUM>. The gap <NUM> may include any suitable insulation material, which is flexible or compressible, including air, gas (e.g., nitrogen), plastic, or other material that experiences electrical breakdown at voltage levels associated with electrostatic discharges to establish a conductive path for the ESD current. The gap <NUM> is sufficiently small, however, to provide a path of least resistance from the retainer <NUM> to the ESD bridge component <NUM>. In an example, if the gap is an air gap, the electrical breakdown results in an electric arc of current flowing from the retainer <NUM> to the ESD bridge component <NUM>. Depending on space constraints within the doorbell <NUM>, the ESD bridge component <NUM> may include a lip, rib, wall, or extension disposed at the end of the arm of the ESD bridge component <NUM> and extending in a direction that is non-parallel to the plane of the body of the ESD bridge component <NUM> (e.g., ±<NUM>, ±<NUM>, ±<NUM>, ±<NUM> degrees relative to a surface of the ESD bridge component <NUM>).

The ESD current <NUM> jumps from the retainer <NUM> to the ESD bridge component <NUM>. The ESD current <NUM> then flows through the ESD bridge component <NUM> and passes to a grounding element, such as the heat sink <NUM>. Optionally, another gap (e.g., gap <NUM>) exists between the ESD bridge component <NUM> and the heat sink <NUM>. The gap <NUM> may include the same (or similar) material as that of the gap <NUM> (e.g., air, gas, plastic). In some implementations, the gap <NUM> may include a different material than that of the gap <NUM>, where the different material experiences electrical breakdown at voltage levels associated with electrostatic discharges to establish a conductive path for the ESD current. Because there is no movable or dynamic part in or adjacent to the gap <NUM>, galvanic contact (e.g., spring, pogo pin, conductive foam) can be used to establish the ESD path through the gap <NUM> between the ESD bridge component <NUM> and the heat sink <NUM>. Using the gap <NUM>, the ESD current <NUM> jumps from the ESD bridge component <NUM> to the heat sink <NUM>. The heat sink <NUM> may be connected to other grounding elements, which ground the ESD current <NUM>, (e.g., to an external ground) for the doorbell <NUM>.

The gap <NUM> and the gap <NUM> may have any suitable width that enables the ESD current <NUM> to jump from one component to the next component, in particular to jump from the retainer <NUM> to the ESD bridge component <NUM> and then from the ESD bridge component <NUM> to system ground (e.g., the heat sink <NUM>). In some aspects, the gaps <NUM> and <NUM> may have the same width. In some aspects, the gaps <NUM> and <NUM> may have different widths. The widths of the gaps <NUM> and <NUM> may be within a range of, e.g., <NUM> millimeters (mm) to <NUM>.

The ESD bridge component <NUM> acts as a bridge between the retainer <NUM> and the grounding element (e.g., the heat sink <NUM>) for controlling the ESD current <NUM> of the ESD spark <NUM>. By providing a conductive path away from ESD-sensitive circuitry, the ESD spark does not affect the operation of the camera. Rather, the ESD current <NUM> flows in a controlled way, by being routed to a safe location and being prevented from jumping to undesirable locations in the doorbell <NUM>, such as to an ESD-sensitive PCB (e.g., the PCB <NUM>, the camera board <NUM>). The ESD bridge component <NUM> may be disposed at any suitable location between the retainer <NUM> and the system ground (e.g., the heat sink <NUM>, which is safely grounded). In the illustrated example, the ESD bridge component <NUM> is disposed on one side of the retainer <NUM> between the PCB <NUM> and the camera board <NUM>.

Claim 1:
A camera module (<NUM>) for an electronic device (<NUM>, <NUM>), the camera module (<NUM>) comprising:
a camera lens (<NUM>);
an image sensor (<NUM>, <NUM>) aligned with the camera lens (<NUM>);
a retainer (<NUM>) encircling the camera lens (<NUM>), the retainer (<NUM>) being movable during a focus tuning of the camera module (<NUM>); and
an electrostatic discharge bridge component (<NUM>) arranged to provide a controlled path for an electrostatic discharge current to travel from the retainer (<NUM>) to a system ground of the electronic device (<NUM>, <NUM>), the electrostatic discharge bridge component (<NUM>) separated from the retainer (<NUM>) by a gap (<NUM>) and positioned to guide the electrostatic discharge current conducted by the gap to the electrostatic discharge bridge component (<NUM>) away from the image sensor (<NUM>, <NUM>).