Patent Description:
A doorbell is a signaling device typically placed near a door to a building's entrance. When a visitor presses a button, the bell rings or otherwise generates a human discernable signal inside the building, alerting the occupant to the presence of the visitor. Although the first doorbells were mechanical, activated by pulling a cord, modern doorbells are generally electric switches; and the most recent versions may contain miniature cameras, may be connected to the Internet, and may even incorporate facial recognition technology. These doorbells permit a user to monitor doorbell activation remotely via an application user-accessible device such as a computer or smartphone.

<CIT> discloses a network of video bell cameras, wherein the source of the video to be shown in the display is selected based on the motion detection.

<CIT> also discloses a doorbell community approach where the most relevant doorbell camera image is chosen.

However, modern doorbells continue to suffer from several drawbacks. For example, while such doorbells can contain a camera, the camera typically fails to provide an optimum viewing angle due to the placement of the doorbell itself being in a traditional mid-height location near the door.

Nor can the viewing angle of the typical doorbell camera be altered in any way. Nor can a camera connected to the doorbell be switched to a different camera.

A need therefore exists for an improved doorbell system which eliminates one or more of the foregoing disadvantages.

An electronic doorbell system can be configured to allow simultaneous video and audio communication to a user on a computing device in which the video is provided by a camera that is selected from among multiple available cameras provided at different locations, while the audio is provided by a microphone of the doorbell system, such as a microphone associated with the doorbell or a selected camera. User input can allow selection of one or more cameras. When multiple cameras are selected, the system can take an audio/video feed from the cameras in predetermined sequence or random sequence based on events observed by the system. In one aspect, audio can be streamed from the microphone of another camera in the system, while audio form the doorbell is recorded to be played back later or immediately after the audio from camera is stopped. The camera could be selected by default, based on user input, and/or automatically using artificial intelligence. Selection by artificial intelligence could comprise, for example, selecting a camera based on a detected motion and/or sound, a captured image matching a predetermined image and/or a captured sound matching a predetermined sound. The doorbell system can communicate the video and audio to the user as a synchronized media stream, such as during a Voice over Internet Protocol (VoIP) call, and the source of the video and/or audio can be dynamically switched mid-stream, during the VoIP call, upon selection of alternate camera.

Specifically then, one aspect of the present invention can provide an electronic doorbell system, including: an electronic doorbell configured to capture an audio stream; at least two cameras, each camera being configured to capture a video and/or audio stream; and a hub in communication with the electronic doorbell and the cameras, the hub having a processor. The processor is configured to execute a program stored in a non-transient medium operable to select a camera from the multiple cameras for capturing a video stream, and synchronize the video stream from the selected camera with the audio stream from the electronic doorbell to produce a synchronized media stream.

Another aspect of the present invention can provide a method for electronic monitoring, including: configuring an electronic doorbell to capture an audio stream; configuring multiple cameras to each capture a video and/or audio stream; selecting a camera from the multiple cameras for capturing a video stream; and synchronizing the video stream from the selected camera with the audio stream from the electronic doorbell to produce a synchronized media stream.

These and other objects, advantages and aspects of the invention will become apparent from the following description. The particular objects and advantages described herein can apply to only some embodiments falling within the claims and thus do not define the scope of the invention. In the description, reference is made to the accompanying drawings which form a part hereof, and in which there is shown a preferred embodiment of the invention. Such embodiment does not necessarily represent the full scope of the invention and reference is made, therefore, to the claims herein for interpreting the scope of the invention.

Preferred exemplary embodiments of the invention are illustrated in the accompanying drawings in which like reference numerals represent like parts throughout, and in which:.

Referring now to <FIG>, a diagram illustrating a system <NUM> for electronic monitoring is provided in accordance with an aspect of the invention. The system <NUM> can comprise an electronic doorbell system <NUM>, including an electronic doorbell <NUM>, two or more cameras <NUM>, such as first and second cameras 16a and 16b, respectively, a hub or base station <NUM>, and/or a chime <NUM>. The base station <NUM> can communicate with the doorbell <NUM>, the cameras <NUM> and/or the chime <NUM> through a wireless local network, such as an IEEE <NUM> wireless Local Area Network (LAN). The base station <NUM>, in turn, can connect to network access equipment <NUM>, such as modem and/or router, for communicating with a backend system <NUM> through a Wide Area Network (WAN) <NUM> such as the Internet. The backend system <NUM>, which could comprise one or more servers, in turn, can communicate with an electronic device <NUM>, such a smart phone, tablet computer, or laptop or desktop computer operated by a user <NUM>.

The doorbell system <NUM> can be arranged with respect to a building <NUM>, such as a home or office building. For example, the doorbell <NUM> can be arranged proximal to a door <NUM> of the building <NUM>. This location may, for example, be in a traditional location customarily found by visitors, such as against an exterior wall or doorframe of the building <NUM> adjacent to the door <NUM> at a height just above a door knob <NUM>. Each camera <NUM> can also be arranged with respect to a building <NUM>, but advantageously at separate locations from the doorbell <NUM> to provide optimum viewing angles of visitor(s). For example, a first camera 16a can be arranged against the exterior wall of the building <NUM>, several feet above the door <NUM>, to provide an optimum angle for viewing a visitor <NUM> standing in front of the door. Also, a second camera 16b can be arranged against a different area of the building <NUM>, such as several feet above a side or back window <NUM>, distal from the first camera 16a, to provide an optimum angle for viewing any person proximal to such alternative access point. "Distal" refers to a physical separation between devices such that views and/or sounds captured by the devices far enough away from one another such that the devices are operable provide distinctly different points of observation that are useful to the user <NUM>. As yet another example, a camera (not shown) could be mounted on a post or tree located several feet away from the building with a view of the door <NUM>.

In addition, in one aspect, a computer <NUM> can be connected directly to the system, such as through the network access equipment <NUM>, for allowing a user in the building <NUM> direct access to the doorbell system <NUM> like the device <NUM>. The computer <NUM> could, for example, comprise a tablet, laptop, or desktop computer. This can serve as a back-up to the device <NUM> when the user <NUM> is in the building <NUM> for communicating over the VoIP telephone call with the visitor <NUM> as described herein.

A visitor <NUM> approaching the door <NUM> can cause a trigger event. Such trigger events could comprise, for example: the visitor <NUM> pressing or otherwise actuating a button on the doorbell <NUM>; motion of the visitor <NUM> being detected by a motion sensor of the doorbell <NUM> and/or in a floodlight, a camera, or other device located in the vicinity of the doorbell and in communication with thee base station <NUM>; and/or a sound of the visitor <NUM> being detected by a microphone of the doorbell <NUM>. Following occurrence of the trigger event, the system <NUM> is configured to immediately call the user <NUM> via the device <NUM>. In the most typical case in which the call is an audio form, possibly accompanied by video data, enabled by the base station <NUM> making a Voice over Internet Protocol (VoIP) call to the device <NUM>. The system <NUM> may reduce latency by omitting push notifications to the device <NUM>, which otherwise would require the user <NUM> to open an application program on the device <NUM> before making any calls. In this case, the system proceeds to immediately call the user's device. The remainder of the specific example contained herein assumes such a telephone call.

In one aspect, an audio stream captured by a microphone of the doorbell <NUM>, and a video stream captured by a camera <NUM>, such as the first camera 16a, can be synchronized by the base station <NUM> to communicate a synchronized media stream in near real time to the device <NUM>. "Near real time" refers to the time delay introduced, by automated data processing and/or network transmission, between the occurrence of an event and the use of the processed data, such as for display or feedback and control purposes. For example, a near real time display depicts an event or situation as it existed at the current time minus the processing time, as nearly the time of the live event. Also, an audio stream captured by a microphone of the device <NUM> can be returned to the base station <NUM> to communicate to the doorbell <NUM> to allow a near real time VoIP conversation between the user <NUM> and the visitor <NUM> during a call.

Referring now to <FIG>, a diagram illustrating communication in the system <NUM> is provided in accordance with an aspect of the invention. The doorbell <NUM> can include a button <NUM>, a built-in camera <NUM>, a microphone <NUM>, a speaker <NUM> and/or a motion sensor <NUM>. As mentioned, some of these functionalities could be provided on or duplicated on devices located apart from the doorbell. The doorbell <NUM> can also include processing and circuitry contained in a doorbell housing configured to be arranged proximal to the door <NUM>. The button <NUM> can be a doorbell button or switch that is sensed by the base station <NUM> when actuated by the visitor <NUM>. The microphone <NUM> can be configured to capture an incoming audio stream for communication in the system and for detection of sound (such as the voice of visitor <NUM>). The speaker <NUM> can be configured to play an outgoing audio stream for communication to the visitor <NUM>. The motion sensor <NUM> could be an active or passive Infrared (IR) motion sensor for detection of motion (such as by the visitor <NUM>).

The camera <NUM> can include a lens, a microphone, a speaker and/or a motion sensor. The camera <NUM> can also include processing and circuitry contained in a camera housing configured to be arranged in diverse locations, such as against an exterior wall of the building <NUM> or even apart from but facing the building. The camera <NUM> can be configured to capture a video stream for communication in the system. The camera <NUM> can also be configured for detection of motion (such as from the visitor <NUM>).

With additional reference to a process <NUM> of <FIG> and continued reference to the system schematic of <FIG>, an operation for a VoIP telephone call to the device <NUM>, triggered by the system <NUM>, is provided in accordance with an aspect of the invention. Beginning at decision steps <NUM> and <NUM>, the system <NUM> can monitor for a trigger event near the doorbell continuously in a loop. For example, at decision step <NUM>, the base station <NUM> can monitor the button <NUM> of the doorbell <NUM> for actuation by a visitor <NUM>. If the button <NUM> is not actuated or pressed ("No"), the base station <NUM> can proceed to decision step <NUM> to monitor for another triggering event such as the detection of motion and/or sound near the doorbell, such as motion detected by the motion sensor <NUM>, sound detected by the microphone <NUM>, and/or motion or sound detected by the camera <NUM>. If another trigger event is not detected ("No"), the base station <NUM> can return to decision step <NUM> in a loop. However, if the button <NUM> is actuated or pressed at decision step <NUM> ("Yes"), and/or if another trigger event such as motion and/or sound is detected at decision step <NUM> ("Yes"), the process <NUM> can break the monitoring loop and proceed to step <NUM>. Such trigger events can be detected by an event handler <NUM> of the base station <NUM>.

Next, in response to the trigger event, the system <NUM> can proceed to take any or all of several actions near simultaneously. At step <NUM>, the base station <NUM> can control the chime <NUM> to ring in the building <NUM>, causing an audible alarm to alert occupants of the building <NUM> of the presence by the visitor <NUM>. At step <NUM>, the base station <NUM> can stream audio captured by the doorbell <NUM> and video captured by the camera <NUM> (it being understood that the camera may be any of several cameras 16a, 16b, etc. that are active at that time). In particular, an audio stream manager <NUM> of the base station <NUM> can capture the audio stream from the doorbell <NUM>, and a video stream manager <NUM> of the base station <NUM> can capture the video stream from the camera <NUM>, along with an audio stream from a microphone <NUM> of the camera <NUM>, if the camera <NUM> is so equipped. A multiplexor <NUM> of the base station <NUM> can synchronize the audio stream from the audio stream manager <NUM> with the video stream from the video stream manager <NUM> for later communicating a synchronized media stream to the device <NUM> after communication has been established.

At step <NUM>, the base station <NUM> can proceed to wake the device <NUM> for the call. In the case of the call being a telephone call, the base station <NUM> can register itself for the VoIP call, through the backend system <NUM>. In particular, the base station <NUM> can wake the device <NUM> for the telephone call by the event handler <NUM> contacting a system events service <NUM> of the backend system <NUM>. The event handler <NUM> can request, through the system events service <NUM>, an endpoint for making the call. The system events service <NUM>, in turn, can send a wake-up notification to a notify service <NUM>. The notify service <NUM>, in turn, can send the wake-up notification to a wake-up handler <NUM> executing on the device <NUM>. Also, the base station <NUM> can register for the call through the backend system <NUM> by the event handler <NUM> contacting a call registration service <NUM>.

At step <NUM>, the device <NUM> can wake via the wake-up handler <NUM>. Also, the device <NUM> can register to receive the VoIP call through the backend system <NUM>. With the call registered at each endpoint, a call manager <NUM> of the base station <NUM> can send a call invite to the device <NUM> through a signaling service <NUM>. The signaling service <NUM> can provide Session Initiation Protocol (SIP) signaling for initiating, maintaining, and terminating real-time sessions that include voice, video and messaging applications between the system <NUM> and the device <NUM>. A call manager <NUM> of the device <NUM>, in turn, can receive the invitation. This can appear to the user <NUM> as the device <NUM> spontaneously waking and ringing with an immediate incoming phone call with a caller identification (Caller ID) indicating the system <NUM> as being the caller.

At decision step <NUM>, the user <NUM> can choose to accept or decline the call, such as by tapping an appropriate selection on a touchscreen of the device <NUM>, like other incoming phone calls. If the user chooses to decline the call ("No"), the process <NUM> can proceed to step <NUM> in which the base station <NUM>, being operable to detect a failure of the electronic device to answer the call, controls the doorbell <NUM> to play a predetermined greeting and record a voice message with a defined start and stop from the visitor <NUM> in response to the greeting. For example, the doorbell <NUM> may relay "I cannot come to the door right now. " The voice message, in turn, can be sent by the base station <NUM> to device <NUM>. In other words, if at decision step <NUM> the user declines the call ("No"), then a SIP call is not initiated between the doorbell <NUM> (through the base station <NUM>) and the device <NUM>. Instead, a prerecorded audio message can be played at the doorbell <NUM>, such as: "We are not able to come to the door right now. Please leave a message.

In addition, in the process <NUM>, at step <NUM>, a loaded application program executing on the device <NUM> can receive the synchronized media stream to the device <NUM>. In particular, a hub stream manager <NUM> of the base station <NUM> can send the synchronized media stream from the multiplexor <NUM> ("mux") to a media transport tunneling service <NUM> of the backend system <NUM>. The media transport tunneling service <NUM> can provide Real Time Streaming Protocol (RTSP) signaling to control the media stream as Real-time Transport Protocol (RTP) packets between the base station <NUM> and the device <NUM>. An application stream manager <NUM> of the device <NUM>, executing as part of the application program, can receive the media stream. The user <NUM> can open the application program on the device <NUM> to see and hear the media stream in real time through the application program. Alternatively, the user <NUM> can place the device <NUM> back into sleep with the possibility of returning to the application program later for viewing the media stream as a recorded event.

However, returning to decision step <NUM>, and with additional reference to <FIG>, if the user chooses to accept the call ("Yes"), the process <NUM> can proceed to a telephone call routine ("Call Start") at process <NUM>. In other words, if at decision step <NUM> the user accepts the call ("Yes"), then a SIP call is initiated between the doorbell <NUM> (through the base station <NUM>) and the device <NUM>. By default, the microphone of the device <NUM> can be muted. At decision step <NUM>, after accepting the call, the user <NUM> can choose whether to communicate directly or indirectly with the visitor <NUM>, such as by tapping another selection on the touchscreen of the device <NUM>. If the user chooses to communicate directly with the visitor ("Yes"), such as for a more traditional phone call, the process <NUM> can proceed to step <NUM> in which the microphone of the device <NUM> is unmuted, and the base station <NUM> and the device <NUM> exchange bi-directional media streams in a VoIP call that is near real time. In one aspect, the exchange of bi-directional media streams can comprise outgoing video and audio streams from the system <NUM> (and the doorbell <NUM>) to the device <NUM>, and only an incoming audio stream from the device <NUM> to the system <NUM>. However, in another aspect, the doorbell <NUM> can be configured with a display, and the exchange of bi-directional media streams can comprise outgoing video and audio streams from the system <NUM> (and the doorbell <NUM>) to the device <NUM>, and incoming video and audio streams from the device <NUM> to the system <NUM>. The process can then proceed to decision step <NUM> in which the user <NUM> can choose to end the call at any time. If the user <NUM> does not end the call ("No"), the process can return to step <NUM> in which the base station <NUM> and the device <NUM> continue to exchange bi-directional media streams. In other words, the SIP session stays active until the user <NUM> ends the call via the device <NUM>. However, if the user <NUM> does end the call ("Yes"), the process can return to the process <NUM> of <FIG> ("Call End"), returning to decision steps <NUM> and <NUM>, monitoring for another trigger event.

However, returning to decision step <NUM> of <FIG> as well as the system diagram of <FIG>, after accepting the call, the user <NUM> can also choose to communicate indirectly with the visitor <NUM>. If the user <NUM> chooses to communicate indirectly with the visitor <NUM> ("No"), the process <NUM> can proceed instead to step <NUM> in which the microphone of the device <NUM> continues to be muted, and the device <NUM> proceeds to receive the synchronized media stream from the base station <NUM>. Despite inhibiting audio from the device <NUM>, the user <NUM> of the device <NUM> can still listen/view the media stream from the doorbell <NUM>. In addition, at decision step <NUM>, the user <NUM> can at any time decide whether to send a message to play at the doorbell <NUM>. The user <NUM> can type or dictate a custom message, and/or select any of multiple predetermined messages, including messages pre-recorded by the user <NUM> and/or "stock" messages selectable by the user from a pre-programmed list, for playing to the speaker <NUM> of the doorbell <NUM>. One exemplar message could be: "Please leave your package by the door. " Another exemplar message could be: "Sorry I cannot come to the door right now. Please contact me later. " If the user <NUM> decides to send a predetermined message ("Yes"), the process can proceed to step <NUM> in which the user <NUM> selects the message at the device <NUM> for the base station <NUM> to play at the doorbell <NUM>. However, if the user <NUM> decides not to send a predetermined message ("No"), the process can bypass step <NUM> and proceed to decision step <NUM> for ending the call at any time. If the user <NUM> does not end the call ("No"), the process can return to step <NUM>, continuing to receive at the device <NUM> the synchronized media stream from the base station <NUM>, in a loop. In other words, the SIP session stays active until the user <NUM> ends the call via the device <NUM>. In addition, during the call, the user <NUM> can continue to send messages to be played at the doorbell <NUM>. Also, at any time during the call, the user <NUM> can unmute the microphone of the device <NUM> and start talking to the visitor, with an exchange of bi-directional media streams between the base station <NUM> and the device <NUM>. However, if the user <NUM> does end the call ("Yes"), the process can return to the process <NUM> of <FIG> ("Call End"), returning to decision steps <NUM> and <NUM>, monitoring for another trigger event.

With additional reference <FIG> and <FIG>, in another aspect of the invention, the user <NUM> can control the device <NUM> to make a VoIP telephone call without waiting for a trigger event. Beginning at decision step <NUM>, the user <NUM> can choose whether to call the doorbell <NUM> from the device <NUM>. If the user <NUM> chooses not to call the doorbell <NUM> ("No"), the process <NUM> goes no further. However, if the user <NUM> does choose to call the doorbell <NUM> ("Yes"), the process <NUM> can proceed to step <NUM> in which the device <NUM> can register itself for a VoIP call and notify the base station <NUM>. In particular, the device <NUM> can register for the call by contacting the call registration service <NUM> of the backend system <NUM>. Also, the device <NUM> can notify the base station <NUM> to receive the call by contacting the system events service <NUM> of the backend system <NUM> which, in turn, contacts the event handler <NUM>. At step <NUM>, the base station <NUM> can register for the call by the event handler <NUM> contacting the call registration service <NUM>. With the call registered at each endpoint, the call manager <NUM> of the device <NUM> can send a call invitation to the base station <NUM> through the signaling service <NUM>. The call manager <NUM> of the base station <NUM>, in turn, can receive the invite and automatically accept the call. With additional reference to <FIG>, with the VoIP call connected, the process <NUM> can proceed to the telephone call routine ("Call Start") at process <NUM> as described above.

Referring now to <FIG>, a diagram illustrating an exemplary system <NUM> having a doorbell <NUM>, multiple cameras <NUM>, such as five cameras labeled 16a-f, and a base station <NUM>, is provided in accordance with an aspect of the invention. The doorbell <NUM> and the cameras 16a-<NUM> can each be connected to the base station <NUM> through a single wireless LAN. The doorbell <NUM> can be configured to capture an audio stream ("AUD0"), such as through the microphone <NUM>, for sending to the device <NUM> when a visitor <NUM> triggers the doorbell. The doorbell <NUM> can also be configured to play an audio stream ("AUD_IN"), such as from the device <NUM>, enabling bi-directional, real-time communication with the visitor <NUM> during a VoIP call. In addition, each camera <NUM> can be configured to capture a video stream ("VIDx") and an audio stream ("AUDx"), such as the first camera 16a capturing a first video stream ("VID <NUM>") and a first audio stream ("AUD1"), the second camera 16b capturing a second video stream ("VID2") and a second audio stream ("AUD2"), and so forth. The base station <NUM> can execute a program stored in a non-transient medium to select a given one of cameras 16a-16e from among the multiple cameras for capturing a video stream ("VID") from the given (selected) camera to synchronize such video stream from the camera ("VID_X") with an audio stream ("AUD_X") from the doorbell <NUM> ("AUD0") or a given camera 16a-16e ("AUD1"-"AUD5") to produce a synchronized media stream ("VID_X"/"AUD_X").

The synchronized media stream can be sent to and played by the device <NUM>, thereby appearing to the user <NUM> of the device <NUM> like a traditional video conference call. The device <NUM> can return audio to the doorbell <NUM> in the form of audio stream ("AUD_IN"). As a result, the system <NUM> can allow simultaneous video and audio communication to a user <NUM> on the device <NUM>, in which the video is provided by a specific camera <NUM> that is selected from among the multiple cameras <NUM> provided at different locations, while audio can be provided by the device <NUM> back to the doorbell <NUM>, during a telephone call.

Referring now to <FIG>, a diagram illustrating a system <NUM> for selection of a camera <NUM>, for capturing the video stream ("VIDX") for the synchronized media stream to the device <NUM>, is provided in accordance with an aspect of the invention. Various aspects of the system <NUM> could be implemented, for example, by the base station <NUM> in hardware, software and/or firmware. In the system <NUM>, a selection engine <NUM> can select a camera <NUM> for providing a captured video stream from the camera to a synchronization engine <NUM>. For example. The selection engine <NUM> could select the third camera 16c for providing a captured video stream ("VID3") from the third camera as the video stream ("VIDX") being to the synchronization engine <NUM>. The synchronization engine <NUM>, in turn, can synchronize the selected video stream ("VIDX") with the audio stream from the doorbell <NUM> ("AUD0"), such as based on timestamps of corresponding packets, to produce the synchronized media stream ("VID_X"/"AUD0").

The selection engine <NUM> can receive input for selecting one of the available cameras <NUM>. Such input can allow selection of a camera <NUM> by default, based on user input, and/or automatically using artificial intelligence. In one aspect, with additional reference to <FIG>, a flow chart illustrating a process <NUM> for selection of a camera <NUM> for capturing video for the synchronized media stream is provided. The process begins at step <NUM> with a doorbell trigger event. Such an event could comprise, for example, a visitor <NUM> pressing the button <NUM> of the doorbell <NUM>, motion and/or sound of the visitor <NUM> being detected by the doorbell <NUM>, and/or the user <NUM> calling the doorbell <NUM>, including as described above with respect to <FIG>. Next, at decision step <NUM>, the system can determine whether user input is received for selecting a given camera <NUM>. Such user input may override selection by any other technique. The user input can be provided in various ways, such by the user <NUM> through accessing a touchscreen on the device <NUM>, through accessing a touchscreen, mouse, or keypad of the computer <NUM>, etc..

For example, with additional reference to <FIG>, in one aspect, the user <NUM> can provide user input for selecting a given camera <NUM> through a Graphical User Interface (GUI) <NUM> implemented by an application program executing on the device <NUM>. The GUI <NUM> could provide multiple thumbnails <NUM>, such as five thumbnails labeled 242a-f, each corresponding to an image, video and/or audio captured by a corresponding one of the cameras 16a-f, respectively. The user <NUM> can select a given thumbnail <NUM> to thereby select the camera associated with that thumbnail <NUM>. For example, the user <NUM> may select the thumbnail 242a upon recognizing an image of the visitor <NUM> in the thumbnail 242a to thereby select the corresponding camera 16a.

In another aspect, the user <NUM> could provide user input by other means, such as selecting a given camera <NUM> from a dropdown menu of the GUI <NUM>. Such variations are within the scope of the invention.

Referring back to <FIG>, such user input can be processed by user input logic <NUM> providing feedback to the selection engine <NUM>. Referring again to <FIG>, if the system determines that user input is received for selecting a specific camera such as camera 16a ("Yes"), the process <NUM> can proceed to step <NUM> in which the selection engine <NUM> receives the input logic <NUM> to select the specified camera for sending the corresponding video stream ("VID_X") of the selected camera to the synchronization engine <NUM>. However, if the system determines that user input is not received ("No"), the process <NUM> can proceed to decision step <NUM>.

At decision step <NUM>, when enabled by the user <NUM>, the system can determine whether to automatically select a given camera <NUM>. Referring back to <FIG>, in one aspect, the system can implement an artificial intelligence system <NUM> to automatically select the given camera <NUM>. The artificial intelligence system <NUM> could comprise, for example, a neural network which can be trained to make desirable selections with improved accuracy over time. In one aspect, the artificial intelligence system <NUM> could be configured to select a camera <NUM> according to any motion or sound being detected by the camera <NUM>, such as by an imager, motion sensor and/or microphone <NUM> of the camera <NUM>. In another aspect, the artificial intelligence system <NUM> could be configured to select a camera <NUM> according to an image captured by the camera <NUM> by using pattern recognition to match the received image with one or more predetermined images <NUM> stored in a non-transient medium. For example, the third camera 16c could be selected according to an image captured by such camera matching a predetermined image of a person. The predetermined image could be captured by the system itself or could be provided to the system from an external source. In yet another aspect, the artificial intelligence system <NUM> could be configured to select a camera according to a sound captured by the camera <NUM> matching one or more predetermined sounds <NUM> stored in the non-transient medium. For example, the fourth camera 16d could be selected according to a sound captured by a microphone <NUM> of such camera matching a predetermined sound of glass breaking.

Referring again to <FIG>, if the system is enabled to automatically select a camera <NUM> ("Yes"), the process <NUM> can proceed to step <NUM> in which the selection engine <NUM> receives input from the artificial intelligence system <NUM> to select the camera <NUM> for sending the corresponding video stream ("VID _X") of the selected camera <NUM> to the synchronization engine <NUM>. However, if the system is not enabled to make an automatic selection ("No"), such as upon being disabled, the process <NUM> can proceed to decision step <NUM> to select a default camera. The default camera could be, for example, the fist camera 16a, which could be arranged against the exterior wall of the building <NUM>, several feet above the door <NUM>, to provide an optimum angle for viewing the visitor <NUM> standing in front of the door <NUM>. The default camera could be preconfigured by the user <NUM> during system setup.

Next, at step <NUM>, now receiving the video stream ("VID _X") from the selected camera <NUM>, the synchronization engine <NUM> can proceed to synchronize packets of the selected video stream ("VID_X") with matching packets of the audio stream from a selected source, such as the doorbell <NUM> ("AUD0") or a given camera 16a-16e with a microphone ("AUD1"-"AUD5"), which synchronization can be based on corresponding timestamps, as a synchronized media stream ("VID_X"/"AUD0"). In one aspect, audio can be streamed from the microphone of another camera in the system, while audio from the doorbell <NUM> is recorded to be played back later or immediately after the audio from camera is stopped. Then, the synchronized media stream can be sent to the device <NUM>, such as during a Voice over Internet Protocol (VoIP) call.

Next, at decision step <NUM>, the system can determine whether an event requiring dynamic selection of a different camera <NUM> has occurred during the same doorbell event or call. Such an event could comprise, for example, receiving a new or updated user selection from the user input logic <NUM>, detecting a new or updated event from the artificial intelligence system <NUM>, and the like. For example, user input or a default selection may have been used to initially select the first camera 16a for viewing the visitor <NUM>. However, during the event or call, the artificial intelligence system <NUM> might have detected the sound of breaking glass at the fifth camera 16e. Upon such occurrence, the system can dynamically switch from the first camera 16a to the fifth camera 16e for providing the selected video stream ("VID_X"). This allows the synchronized media stream to be updated to synchronize a new video stream, from a newly selected camera <NUM>, with the audio stream from the doorbell <NUM>. This can appear to the user <NUM> of the device <NUM> like a continuous video conference call in which the video suddenly changes. The system can also be configured to select camera 16a-e in a round-robin way so that the user <NUM> is able to see video from each camera <NUM> in the system for a configurable time, such as a few seconds, during an ongoing doorbell call.

If the system determines that an event requiring dynamic selection of a different camera <NUM> has occurred ("Yes"), the process <NUM> can proceed to allow such selection of a different camera <NUM>, such as by repeating the decision steps <NUM> and <NUM>. However, if the system determines that an event requiring dynamic selection of a different camera <NUM> has not occurred ("No"), the process <NUM> can proceed to decision step <NUM> to determine whether the event or call has ended, such as by checking whether motion is still detected by the doorbell <NUM>. If the event or call has not yet ended ("No"), the process <NUM> can return to step <NUM> to continue synchronizing packets and sending the synchronized media stream. However, if the event or call has ended ("Yes"), the process <NUM> can return to step <NUM> to await a next doorbell trigger event.

Although the best mode contemplated by the inventors of carrying out the present invention is disclosed above, practice of the above invention is not limited thereto. It will be manifest that various additions, modifications and rearrangements of the features of the present invention may be made without deviating from the scope of the invention defined by the claims.

Claim 1:
An electronic doorbell system (<NUM>), comprising:
an electronic doorbell (<NUM>) configured to capture an audio stream; and
a plurality of cameras (16a, 16b), each camera (16a, 16b) being configured to capture a video stream and an audio stream;
a hub (<NUM>) in communication with the electronic doorbell (<NUM>) and the plurality of cameras (16a, 16b), the hub (<NUM>) having a processor executing a program stored in a non-transient medium and being operable to:
select a first camera from the plurality of cameras (16a, 16b) for capturing a video stream;
characterized by
receive user input from an electronic device (<NUM>) in communication with the hub (<NUM>), wherein the the first camera (16a) is selected according to the user input or, alternatively, the processor is operable to automatically select the camera without user input;
capture the video stream from the first camera (16a) with a first stream manager (<NUM>);
capture an audio stream from the electronic doorbell (<NUM>) or from a second camera (16b) from the plurality of cameras (16a, 16b) with a second stream manager (<NUM>);
synchronize the video stream from the first camera (16a) with the audio stream from the electronic doorbell (<NUM>) or from the second camera (16b) in near real-timeto produce a synchronized media stream; and
transmit the synchronized media stream to the electronic device (<NUM>).