WO2009138721A2

WO2009138721A2 - Network camera management

Info

Publication number: WO2009138721A2
Application number: PCT/GB2009/001168
Authority: WO
Inventors: James Kevin Meagher
Original assignee: Intamac Systems Limited
Priority date: 2008-05-12
Filing date: 2009-05-12
Publication date: 2009-11-19
Also published as: WO2009138721A3; GB0808539D0

Abstract

A camera network management apparatus is configured to enable a user to issue control instructions to at least one camera and view an image stream from the camera. The user and camera are in different locations both remote from the camera network management apparatus. The camera network management apparatus comprises a device manager arranged to receive a camera instruction from a user and provide said instruction to the camera responsive to a polling message from the camera. It also comprises a streaming device capable of requesting an image stream from the camera and supplying the image stream to a user device.

Description

Network Camera Management

TECHNICAL FIELD

This invention relates broadly to camera viewing, monitoring and administration from a remote location. Embodiments of the invention relate to apparatus and methods for remotely accessing data from and changing attributes of cameras, in particular IP- compatible cameras on Local Area Networks, as well as generating alerts and transmitting said alerts through a central server platform when those cameras change state, for instance when they detect movement. Embodiments of the application also relate to viewing real time and pre-recorded images via a central server platform.

BACKGROUND

Video cameras have for many years been used for surveillance in areas that necessitate monitoring, notably banks, shops, airports, convenience stores and other public places. They are now also increasingly being used as part of home and business security systems in order to give home owners and business owners peace of mind. Remote access to these security systems, and more particularly to the images from cameras, is becoming progressively more important and desirable as people come to rely on video security more and more for both personal and business use.

Many camera manufacturers produce Internet Protocol (IP) compatible cameras, which allow a certain degree of remote access via ADSL, cable or broadband internet connections. However, most cameras of this type have, until now, had many practical limitations which have limited their usage. One such limitation is that these IP compatible cameras are generally configured to communicate only one way with any ease. That is to say, most IP cameras are operable to transmit images to a certain electronic device, but it is very difficult or impossible for a user to remotely view images in certain circumstances, or control attributes or configuration settings of the cameras.

Where two-way control has been implemented, i.e. both the uploading of camera images to a remote system and providing remote access back to the camera from said system, a peer- to-peer (P2P) configuration has generally been used. A P2P network arrangement usually requires specific router or modem configuration to enable two-way control from external nodes. This often involves complex port forwarding and Dynamic Domain Name Systems (DDNS). In this way, it is often necessary for a user to manually configure certain ports and network settings in order to bypass firewalls and/or routers to allow P2P access. Without the appropriate knowledge and skill-set, this can be very difficult and the installation of systems of this type is usually left to an experienced service engineer. In addition, if anything goes wrong with these systems, most end users do not have the requisite knowledge to rectify problems. This makes networked camera systems of this type difficult to operate, unreliable and/or expensive to install and maintain.

No currently known technology provides a system in which IP-compatible cameras can be supplied directly to and easily installed on local networks by end-users, and which can be securely managed and viewed from a remote location by those end-users, without the need for manual network configuration at the installation site. Additionally, no known technology provides camera probing to monitor the status of cameras and connecting lines for security and camera diagnostic purposes. Furthermore, no known technology enables real-time camera view capabilities via a streaming server acting as a proxy on a central platform to negate the requirement for direct remote camera access to a local network by a user.

SUMMARY

According to an embodiment of the invention, there is provided a camera network management system enabling a user to issue a control instruction to one or more cameras and view an image stream from the camera, wherein the user, and each said camera are in different locations remote from the management system, comprising: a device manager arranged to receive a camera instruction from a user and provide said instruction to the camera responsive to a polling message from the camera; and a streaming device capable of requesting an image stream from the camera and supplying the image stream to a user device.

In one embodiment, there is at least one camera for connection to a wireless network, wherein the camera firmware comprises a fixed pointer and a device identifier. In an initialisation mode, an initialisation message is sent from the camera to the device manager responsive to its first connection to the Internet, and the device manager reconciles the device identifier from the initialisation message with a corresponding identifier recorded in a user account store such that the newly connected device is registered as a device belonging to the relevant user account. Thereafter, the user can provide one or more instructions to be deposited in a data store via a graphical user interface GUI to the device manager, wherein said instructions are queued in a camera data store and provided to the camera responsive to a polling message from the camera.

In an embodiment, the device manager maintains a device data store, for example a camera data store, the device data store recording instructions to be dispatched to the device. Instructions may relate to control settings and/or configurations and/or commands for the device.

The device manager is preferably capable of causing generation of a graphical user interface enabling the user provide device instructions to outputs from the device. Instructions for the device which originate from the user are captured by the device manager and written to the device data store, and, optionally, also the user account store. In the case of the camera, a user is also able to view images streamed from the device in real-time or close to real time.

Typically, the fixed pointer is a predetermined URL. Typically, the device identifier comprises a MAC address of the device.

In one embodiment, a confirmation message is returned to the device manager once the instructions have been implemented at the camera.

In typical embodiments, device events can trigger a communication from a device to the device manager. For example, in the case of a camera, a camera event causes camera event data to be sent responsive to a trigger condition, such as a sensor on the camera detecting motion. In another embodiment, the camera or another device can be caused to send device event data responsive to detection of an event by any one of a number of security sensors and/or environmental sensors deployed with connectivity to a central panel. In such a case, device event data, optionally with additional information such as a device identifier, is sent to the device manager and stored in the device data store. Optionally, specific instructions are returned to the device responsive to the detection of a device event. In the case of a camera, a buffer holding images relating to a predefined period will be maintained at all times such that camera event data includes images for a period of time before, during and after said trigger event. Such an approach may be appϊied with respect to other devices in some embodiments.

Preferably, the streaming device can request a real-time (or close to real time) image stream from the camera. In such a case, the streaming device is a streaming server capable of providing a streaming request including a dynamic URL for the camera to use when sending the image stream so that a streaming session can be established between the camera and the streaming device independently of the control path between the camera and the device manager. The streaming request can be initiated for example responsive to a user request, in which case the device manager causes the streaming server to initiate the streaming request responsive to request data in the camera data store. In other words, a user can request a live stream Via the graphical user interface (GUI) and the request data is recorded in the camera data store, and optionally also the user account store, after it is received by the device manager.

Alternatively, or in addition, the streaming request may be initiated by the device manager responsive to camera event data. Irrespective of how the streaming request is initiated, the device manager may provide a streaming session identifier to a user so that the user can view the streamed images. The streaming session identifier may be forwarded to the user by one or more preferred communication channels, for example a communication channel identified by the user and recorded in the user account store, and preferably includes a link to a streaming session. Where the streaming request is responsive to camera event data, the device manager may issue an alert message to a user based on information in the user account store. The streaming session identifier may be included in this alert message.

In some embodiments, the device manager monitors a polling interval and detects missing polling messages from one or more registered devices. Depending on the application, the device manager may apply a set of rules to determine the likely cause of said failure to poll. Depending on the result of said determination, the user can be alerted as to the reason and/ or probability of a fault and /or tamper event.

In the described example, streaming device is a streaming server and the device manager is a separate server with access to one or more data stores holding user account information and device data.

According to an embodiment of the invention, there is provided a device network management system enabling a user to issue a control instruction to one or more devices, comprising: a device manager arranged to receive a instruction from a user and provide said instruction to the device responsive to a polling message from the device, wherein the system comprises a user account store holding an inventory of devices allocated to each user and a device data store holding a queue of instructions to be provided to the device responsive to the device contacting said device manager.

Also provided are methods of operating said systems and devices described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the invention and as to how the same may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:

Figure 1 illustrates an embodiment of a remote camera system according to an embodiment of the present invention;

Figure 2 shows a more detailed illustration of a central server platform according to an embodiment of the present invention;

Figure 3 shows an example of one process by which a camera registers with the central server platform according to embodiments of the present invention;

Figure 4 shows an example of the 'polling' mechanism according to embodiments of the present invention; Figure 5 shows an illustrative example of a process by which a camera records an event, with the central server platform according an embodiment of the present invention;

Figure 6 illustrates an example of a process by which image data is streamed in real time by the streaming server in response to camera event data;

Figure 7 illustrates an example of a process by which image data is streamed in real time by the streaming server in response to a user request; and

Figure 8 illustrates the process by which the centrai server platform generates an alert message in response to the lack of an expected polling signal.

DETAILED DESCRIPTION

Those skilled in the art will appreciate that while this disclosure describes what is considered to be the best mode and, where appropriate, other modes of performing the invention, the invention should not be limited to the specific configurations and methods disclosed in this description of the preferred embodiment.

Figure 1 illustrates a remote camera system according to an embodiment of the present invention 100. The system comprises a central server platform 102 in communication with one or more cameras 104 situated remotely from the server platform 102 and capable of transferring data to and from the central server platform 102 via a suitable connection, such as a broadband internet link 105. After registration with central server platform, the one or more cameras 104 may be managed by a user at a remote location though a suitable electronic device 110 such as a desktop computer, PDA or mobile phone in communication with central server platform 102. The process of camera registration is described in more detail with reference to Fig. 3.

The cameras 104 are typically commercially available, IP-compatible cameras capable of joining a network through a residential gateway either wirelessly (e.g. via Wi-Fi) or by cable (e.g. via Ethernet) forming part of a LAN/wireless-LAN 114, together with other networked devices such as personal computers 112. In addition, the one or more cameras 104 may be in communication with a security panel 116, either wirelessly or by fixed cable. The security panel 116 is a residential or business security device used for on-site monitoring and may have connected to it one or more other security devices. The other security devices include, for example, panic buttons, alarms, flood detectors, smoke/fire detectors, proximity detectors or any other type of security or environmental sensor. According to an embodiment of the invention, each of the other security devices is able to initiate the camera 104 through the security panel 116. According to a preferred embodiment of the invention, however, the camera 104 further comprises a motion detector 108 which is operable to independently initiate the camera upon detection of motion.

In a typical network environment such as a LAN, internet access is provided through a residential gateway such as a DSL, ADSL or Cable modem connected to (or integrated with) a router. Devices on the LAN then connect to the Internet through the router by Ethernet or WiFi. The router is connected to the Internet and advertises the 'public' IP address as issued by the Internet service provider (ISP). Networked devices behind the router, on the other hand, have 'local' IP addresses on a sub-network (subnet). These local IP addresses are issued by the router and, using network address translation (NAT), the source and/or destination addresses of IP packets is re-written as they pass through the router's firewall, ensuring data reaches its intended destination. Thus, according to this type of arrangement, multiple hosts on a local network are able to access the Internet using a single public IP address.

In this embodiment, the cameras 104 are manufactured to operate in a standard consumer IP network environment, such as a LAN, where the IP address is subject to frequent change. The IP address is said to be "dynamic" in this regard. Most residential LANs utilise dynamic IP address allocation, and most routers utilise Dynamic Host Configuration Protocol (DHCP) to dynamically re-use IP addresses. Under such systems, a range of IP addresses are reserved for devices connecting to the network, and each device on the network is configured to request an IP address from the router DHCP upon initialisation. The dynamic nature of IP address allocation often makes it difficult to connect remotely to devices on a network since their address is unpredictable. It is also difficult to circumvent firewalls without proper configuration.

According to embodiments of the present invention, the camera 104 is programmed with a pointer such as a Uniform Resource Locator (URL) which always directs the camera 104 to the central server platform 102 for connectivity and data transmission. In this sense, the URL is said to be "fixed" and resides permanently in the camera firmware until it is updated. Since the URL always directs to the central server platform, it does not matter if the dynamic IP address of the camera 104 is unknown or changes on the local area network. Similarly, it does not matter if the public IP address of the router changes or is unknown. As long as the camera is able to connect to the Internet, it can transmit data to the central server platform 102 via an open port on the router, such as HπP port 80, FTP port 21 etc. using the fixed URL to direct data traffic.

Figure 2 shows a more detailed illustration of the central server platform 102. The central server platform has at least one storage device 202, which is able to hold a plurality of user accounts residing in account data store 204. The user account data may be held as a combination of different data types in a relational database and/or in text files. User account data includes, for example, user ID, password, the physical address at which one or more cameras are installed, the MAC (Media Access Control) address of one or more cameras and such like.

The central server platform further comprises a device manager, in this case a Device Management Server (DMS) 201. The DMS comprises an external interface 203 and a processor 205. The external interface 203 is operable to receive data from the at least one camera 104 via communication link 105, and pass said data to the DMS processor 205 for ^• processing. As stated above, the fixed URL written into the camera firmware points the camera 104 to central server platform 102, and more specifically to interface 203.

The central server platform further comprises: a web server 210 and an application server 212, for providing an interface through which a user can upload data to and download data from central server platform 102; and a streaming server 214 enabling camera image data to be streamed to a user's mobile device, PC or other electronic device in real time in response to a detected camera event and/or in response to a user request

Figure 3 shows an example of one process by which a camera 104 registers with the central server platform according to embodiments of the present invention. The camera is initialised 302 when the user first switches it on, and it then advertises its services to control points on the local area network. Once the router has issued the camera with an IP address, it will be able to transmit data via the Internet. As mentioned above, the camera 104 is preprogrammed upon manufacture, or thereafter, with a fixed URL (HTTP or otherwise) pointing at central server platform 102 and, once connected to the Internet, uses the URL to send 304 an initial packet of data comprising at least a device identifier (for instance, the camera's MAC address). The initial packet of data may a)so comprise the camera's IP address, along with other information about the camera and/or network to which it is attached.

According to a preferred embodiment, the MAC address of a given camera is pre-registered with central server platform 102. Most typically this is done at a point of sale when a user purchases the camera. The user will provide some identification information at the point of sale (for example name, address or other contact details), which is then sent along with the MAC address of the camera to the central server platform 102, either securely over the Internet or by some other means. Once the MAC address and user identification information is received by the central server platforrη, it is sent to the DMS 201. The DMS 201 then creates a user account based on the provided MAC address and user identification information in account data records 204. At the same time, the DMS may also set up an associated camera data store 206.

Following step 304, when the initial data packet containing the identifier (in this case the MAC address) is received 306 by the DMS 201 via interface 203 upon camera initialisation, the DMS processor 205 is able to match 308 the MAC address provided in the initial data packet with that in the pre-created user account stored in account data records 204. In this regard, the DMS verifies the camera and user and the account becomes active.

A skilled person will appreciate that an alternative device identifier may be used in the described process, provided the same identifier is used to reconcile the device with the relevant user account during or after installation.

According to another example, user details and device identifier may not be taken at the point of sale. In an alternative to the above registration process, the camera is supplied with registration software which can be run on a computer connected to the LAN. When the camera is first initiated, it connects to the local area network and sends its MAC/IP address to the central server platform in the data packet using the fixed URL in the same way as described above. However, in this example the user also concurrently runs the registration software, which at some point prompts the user to provide identification information necessary to generate a user account. In another embodiment, software also automatically detects the MAC address of the camera. The user account information and MAC address is sent to the central server platform 102 by the computer running the software over the Internet, which the DMS 201 then uses to create a user account in account data records 204 in the same way as described above.

According to yet another embodiment, a user account may be manually created by a user through a web interface, wherein the user navigates to a webpage which is linked to DMS 201. The webpage is configured to accept user identification information and the MAC address of the camera, and send this data to the DMS. The DMS then creates a user account in account data records 204 based on this data.

After registration, for example by any of the methods described above, on a predetermined, user configurable, time cycle the camera sends 310 a data transmission (also called a "polling signal") to the fixed URL of the central server platform. In this regard, communications with the central server platform 102 are camera-initiated. The polling signal may be any arbitrary data packet, such as an echo request packet, or may contain specific information from the camera. Generally, the data transmission comprises at least a device identifier containing some information related to the identity and the location of the camera; generally the MAC and IP addresses. Using this information, the central server platform is able to establish a two-way communication link with the camera, since it knows where to direct any return data traffic. Thus, the polling mechanism enables the central server platform to both uniquely identify the camera and to open a data session via a two- way communication link, should it be required.

By virtue of the polling mechanism and to the advantage of the embodiments of the present invention, any data sent by camera 104 from within a LAN is not restricted by firewall. This is because data is transmitted via the fixed URL on open out-going ports not affected by the firewall, for example on standard HTTPS port 443 or HTTP port 80. Therefore, complex port forwarding or dynamic DNS is not required from the end user in order to enable the camera 104 to communicate with the central server platform 102. If necessary, the central server platform 102 can push data back to the camera through open incoming data ports.

As stated above, according to previously known technology, it was necessary for a user to manually set up and map ports on cameras and residential gateways in order to establish a P2P connection for remote administration and/or viewing of camera images. However, the system of the present invention dispenses with the need for users to manually configure an IP-camera to allow remote access over a LAN, and facilitates functional and secure two-way control. The embodiments of the present invention therefore vastly simplify the installation and operation of cameras over the internet for both the end user and, where applicable, professional installers.

Referring again to Fig. 2, each user account in account data records 204 has an associated camera data store 206 suitable for storing data received from one or more registered cameras 104. Camera data store 206 also resides on storage device 202. Although data received from camera 104 may be pre-recorded image data, the camera data store 206 is not limited to storing only image data and may additionally store other information such as configurable attributes and/or instructions supported by the cameras, security settings available for the camera, response data, a log of camera events, a log of error messages, a temporary record of the IP address and such like. In addition, the camera data, store 206 may further include information indicating the camera class, possible camera states and one or more condition codes for controlling attributes of the camera. It is a feature of an embodiment of the present invention that a user is able to generate instructions and requests in camera data store 206 via a suitable graphical user interface (GUI) that provides the user's interface to the account. The web server 210 generates the GUI and the adjustments (including any changes to configuration, new commands or settings etc.) are recorded back into the account data store 204 and/or camera data store 206 as may be required. In this way control inputs to the camera can in effect be queued on the central platform pending the next polling signal. Figure 4 shows an example of the 'polling' mechanism according to embodiments of the present invention. The camera 104 is programmed to send a data transmission (polling signal) to the central server platform at predetermined time intervals 402 written into the camera 104 firmware. This predetermined time interval may be set as a default upon manufacture and thereafter be configured according to preference, security requirements and such like. According to one embodiment, the time interval may be as long as several minutes. According to another embodiment the time interval may be as short as a fraction of a second. According to a preferred embodiment, the time interval is between 5 and 20 seconds. In this way camera 104 is able to transmit to the DMS 201 at predetermined intervals by sending a data polling signal. The camera monitors 404 the time interval by checking it against an internal camera clock or timer. When the relevant time interval has been reached, the camera transmits 406 a polling signal to the DMS 201, where it is received at interface 203. The DMS processor 205 will perform a look-up 408 of the records in the camera data store 206 to ascertain if there are any pending instructions to be written to the camera. Typically pending instructions will specify that a user wishes to change one or more camera attributes, including initiating a real time view session with the camera. The DMS then establishes a two-way connection 410 to the camera 104 using data contained in the polling signal and/or known information about the camera stored in storage device 202, and transmits any pending data 412 to the camera. Optionally, the camera 104 may then send confirmation back to the central server platform once the camera attributes have been changed 414 and the central server platform will close 416 the connection.

As well as sending a polling signal at predetermined intervals, the one or more cameras 104 are also configured to transmit data to the central server platform 102 when the camera detects an event. This includes for example when motion detector 108 detects motion. Such data will be referred to throughout as 'camera event data' and is intended to encompass not only the detection of motion but also any other proactively reported data from camera 104, for example, a fault. In other words, although the camera sends a polling signal at a predetermined interval, it may also send a transmission to central server platform 102 immediately upon detection of an event, before waiting for the next poWing signal time. When the camera 104 detects an event, the camera is operable to construct a suitable camera event data packet and transmit said camera event data packet to DMS 201. The camera event data packet typically comprises image data (either still or motion) transmitted via FTP protocol, however, other protocols may also be used and the data is not limited only to image data. A user can view camera event data stored in the camera data store 206 through a suitable graphical interface provided by the centra) server platform by logging into their user account from a remote control device such as a desktop computer, mobile phone, PDA, Blackberry equipped with a suitable web browser.

Figure 5 shows an illustrative example of a process by which a camera records an event, with the central server platform 102. According to one example, the camera 104 is triggered by an in-built motion detector 108 that, when the camera is on, will detect movement within the camera's field of view by determining the changes in pixel state of image data received by the camera. Although an event may be motion detected by motion detector 108, an event may also be detected through a security panel, for instance, after the triggering of an alarm or other external detector connected to camera 104. After detection of event by whichever means, the camera initiates generation of a camera event data packet. The detection of a camera event and generation of data packet is shown in step 502.

Whenever it is switched on, the camera 104 may be configured to constantly record image data in a local buffer for a predetermined amount of time (for instance 5 seconds) so that the camera event data packet can comprise 'before' and 'after' image data. Upon detection of an event, the camera 104 will begin to record for a predetermined length (for instance 15 seconds) after the motion has been detected. The camera then combines the recorded image data with image data in the buffer, encodes a camera event data packet, typically also comprising the camera MAC address/)? address, and transmits this data proactively 504 ("proactively" in this context means that the camera does not wait for a polling event before establishing a connection with central server platform 102) to DMS 210 via the fixed URL It is thereafter received by interface 203 and the DMS processor 205 then sends 506 the camera event data packet to the camera data storage 206. The DMS processor concurrently checks 508 the camera data storage associated with the relevant user account in order to determine 510 if there is any pending instruction data for transmission back to the camera. If the user has specified one or more instructions, the processor establishes a two-way link to the camera 104 using the MAC address and IP address of the camera, and transfers the instruction data 512 to the camera. Once the camera has carried out instruction 514 it may send confirmation 516 of completion. The DMS processor 205 then closes the connection 518.

Therefore, according to embodiments of the present invention, a user does not initiate and establish a direct connection to camera 104, as they would with a conventional P2P system. Rather, the user logs instructions on the central server platform 102 through their user account, and when camera 104 transmits data to the central server platform, e.g. sends the polling signal or camera event data packet, any pending instructions can be automatically transferred from the central server platform to the camera via a subsequently established two-way communication channel. In other words, a user is able to administrate one or more cameras 104 by proxy by leaving instructions in a data store associated with their user account, which are then relayed to the camera by DMS processor 205 via the camera data store 206.

Referring again to Fig. 2, the central server platform 102 further comprises a web server 210 and an application server 212 for providing an interface through which a user can upload data to and download data from central server platform 102. According to one embodiment, there is provided a graphical user interface operable to receive user inputs through a web browser. These user inputs will generally be instructions for changing attributes of the camera 104, including initiating a real-time image stream. Upon receipt of user inputs, the application server 212 sends instruction data to the DMS 201, which then sends instruction data to the camera data store 206. The DMS transmits this instruction data to camera 104 upon receipt of its next polling signal or camera event data packet from the camera as described with reference to Figs. 4 and 5. The web and application servers 210, 212 also enable the user to receive data, for example, real-time streaming, still or moving images downloaded from cameras 104, as well as other digital media or operational statistics (such as up-time, data packets sent/received etc.). It is an aspect of embodiments of the present invention that the DMS 201 can initiate a predefined and configurable response based upon the receipt of a camera event data packet. For instance, an alert message may be sent to the user's mobile phone, email etc. to alert them that an event has been detected. This message may additionally contain a URL link or similar pointer which is linked to streaming server 214. The streaming server 214 enables camera image data to be streamed to a user's mobile device, PC or other electronic device in real time in response to a detected camera event and/or in response to a user request. Contact information enabling this kind of response communication is generally stored in the user account in account data store 204. The information includes, but is not limited to: mobile phone number and/or e-mail address.

Figure 6 illustrates an example of a process by which image data is streamed in real time by the streaming server 214 in response to camera event data. An event is detected 602 either by the camera itself (e.g. using the motion sensor 108) or by another monitoring device in the property (e.g. an IP Security Alarm connected to security panel 116), which triggers the camera to generate and transmit 604 a camera event data packet to DMS 201 on central server platform 102. On receipt 606 of the camera event data, the DMS 201 will initiate 608 streaming server 214, which then requests 610 a real-time image stream from the camera via DMS 201. The streaming server generates a "dynamic" URL which is sent 612 to the camera 104, for example via Common Gateway Interface (CGI) script. This "dynamic" URL allows image data to be streamed in a real-time session to streaming server 214, and will only be valid until the real-time session ends. It is not to be confused with the "fixed" URL which always points the camera to the central server platform 102 for sending the polling signal or camera event data packet. The camera 104 will then initiate 614 a real-time image stream, e.g. via Real-Time Streaming Protocol (RTSP), and send it back to the streaming server 214 via the dynamic URL. The user is then typically notified that the stream is available through streaming server 214 and will be sent 616 a streaming "session" URL, as distinct from both fixed and dynamic URLs, that points to the stream and enables the user to view it in real time with a suitable electronic device, the session URL may be provided in an alert message, for example, by e-mail, text message etc.. Figure 7 illustrates an example of a process by which image data is streamed in real time by the streaming server 214 in response to a user request. The application server 212 receives 702 a user request, for example through the web interface, and sends it 704 to the DMS 201, typically in the format of a CGI command. The DMS writes 706 this request into the camera data store 206 as a request flag. When the next polling signal received 708 from camera 104 by the DMS 201 via interface 203, the DMS processor 205 will look up 710 the data in camera data store 206 to check for any pending request flags. The DMS processor 205 will then send an appropriate command 712 to the camera 104 to initiate a stream, e.g. via RTSP, which is then transmitted 714 by camera 104 to streaming server 214 in the same way as described in accordance with Fig. 6. Again, a streaming session URL will also be created for the user and is transmitted 716 e.g. via text message (SMS) or email for the user to link to the incoming stream via RTSP.

The streaming server 214 is operably connected to the application server 212 and web server 210. Whenever the real-time data stream is received from the camera 104 by the streaming server 214, a user is able to view the image data via a suitable web browser. According to one example this is done directly through web server 210 via an embedded third party (e.g. Real Networks) media player, however, other methods and technologies may also be used to view the stream.

Therefore according to embodiments of the invention, upon detection of an event or any request from the end user, a real-time link suitable for streaming image data can be created between the camera 104 and the platform 102. However, image data is not received directly from the camera itself, but rather it is relayed to a user via streaming server 214 on central server platform 102.

Figure 8 illustrates the process by which the central server platform generates an alert message in response to the lack of an expected polling signal. Under correct operating conditions (e.g. as described in accordance with Fig. 4), the camera sends a polling signal at predetermined intervals 802 and, from receipt of polling signals, the DMS processor 205 is able to ascertain that the camera is working correctly 804. However, after the time interval between polling signals passes 806, the DMS processor 205 detects that there is a missing polling signal 808. This information can then be used to ascertain diagnostic characteristics, for instance, a problem with the network, camera or Internet service. The amount of times the processor 205 has to detect missing polling signals before the central server platform concludes that there is a problem may be preset to a certain number, either by the system administrators or by the user according to preference. For example, the processor 205 may wait until there are two or more missing polling signals before reporting the event, in order to account for anomalous missing polling signals e.g. where there is a temporary loss in communication between the camera and the central server platform 102.

Typically, a user will specify what action the DMS should take in such an event by specifying one or more response actions in database 204. The DMS will check 810 for said response actions and initiate an appropriate command. In one example, if no polling signal is received from the camera by the central server platform for x times in succession, the DMS generates an alert and sends it to the user. For a high level of security, for instance, the user may wish to be alerted by the central server platform 102 after one or two missed polling signals-, whereas for lower priority cameras the central server platform 102 may generate an alert only after numerous failed polling signals. These priorities, as well as the response actions, are configurable by the user or system administrators according to preference and/or security demand. Typically, the centra) server platform will generate an alert message 812 indicating to the user that the camera is not functioning correctly or has been lost, and send that message 814 to a communication means as specified by the user in their user account, i.e. alert by email, SMS, etc..

It is an aspect of embodiments of the present invention that if a user has several cameras 104 associated with the central server platform 102 in their user account, then the DMS processor 205 is capable of analysing data provided by all the cameras in order to infer the severity of a given alert. For example, the processor 205 may detect that one out of ten cameras on a LAN at a particular property is not sending the expected polling signal. From this information, the DMS processor may deduce that, since is it only a single camera which is not poUing, and not all ten, that the problem may be less serious than a primary line \oss (where all ten cameras would be undetectable) and alerts the user accordingly e.g. by generating and transmitting an alert. In other words, by determining discrepancies between expected data and data received, the DMS processor 205 is able to provide a user with intelligent diagnostic information.

Thus, failure of the central server platform to detect the polling signal for a set period before one or more cameras may be used as a diagnostic to indicate that one of three problems has occurred: that one or more cameras are not operating; there is a problem with local area network to which the one or more cameras are attached; or there is a problem with the internet service itself.

According to another embodiment, one or more other detectors may be used in addition to or as an alternative to one or more cameras 104. Examples of other detectors include smoke detectors, fire detectors, flood detectors, passive infrared sensors (PIRs) and other similar devices. According to one example, each of the one or more other detectors has an associated data store equivalent to the camera data store 206, for storing data detected by the one or more other devices.

Those skilled in the art will recognise that the invention has application in a broad range of services and cameras, from emergency and high-security based systems, to low end domestic applications. Hence the present invention enables full social and environmental monitoring to become simpler, more intelligent and more cost efficient with regular reporting of priority and non priority events to end users.

Claims

1. A camera network management apparatus configured to enable a user to issue control instructions to at least one camera and view an image stream from the camera, wherein the user and each said camera are in different locations remote from the camera network management apparatus, the camera network management apparatus comprising: a device manager arranged to receive a camera instruction from a user and provide said instruction to the camera responsive to a polling message from the camera; and a streaming device capable of requesting an image stream from the camera and supplying the image stream to a user device.

2. A camera network management apparatus as in claim 1, comprising a remote camera connection interface corresponding to a. fixed pointer coded into firmware of at least one camera.

3. A camera network management apparatus, as in claim 2, wherein said remote camera connection interface is configured to receive polling messages from cameras of said remote camera network and said device manager has a processor for processing said messages.

4. A camera network management apparatus as in any preceding claim, wherein at least one camera is configured for connection to a wireless network.

5. A camera network management apparatus as in as in any preceding claim, wherein said device manager comprises a device data store arranged to hold one or more camera control instructions in a queue ahead of sending it to a camera of the camera network.

6. A camera network management apparatus as in claim 5, wherein said camera control instructions comprise one or more of: camera control settings; camera configuration settings; and camera commands'.

7. A camera network management apparatus as in any preceding claim, wherein said device manager is configured to supply a camera control instruction to a camera device of the camera network responsive to receipt of a^' polling message from the relevant camera device.

8. A camera network management apparatus as in as in any preceding claim, wherein the device manager comprises a camera data store arranged to hold camera event data from a remote camera of the camera network.

9. A camera network management apparatus as in as in any preceding claim, further comprising a plurality of user accounts each recording associations with a set of individual device identifiers indicating devices deployed in a camera network controlled by a user.

10. A camera network management apparatus according to any preceding claim, wherein the device manager is configured to generate a user interface enabling a user at a user device to input device instructions to be sent to a camera device of the camera network via a device data store.

11. A camera network management apparatus according to any preceding claim, wherein the device manager is configured to generate user interface enabling a user to view i images streamed from a camera device of the camera network.

12. A camera network management apparatus according to any preceding claim, wherein the device manager is configured to generate a user interface enabling a user to view images streamed from a camera device of the camera network in one or more of: realtime; close to real time; and pre-recorded.

13. A camera network management apparatus according to any preceding claim, wherein the device manager is configured to generate an alert message to cause a user to view images from a camera device of the camera network.

14. A camera network management apparatus as in any preceding claim, configured to cause a camera to send camera event data to said remote camera connection interface of the device manager responsive to a trigger condition.

15. A camera network management apparatus as in claim 14, configured such that a camera event trigger condition comprises the detection of motion by a sensor on the camera.

16. A camera network management apparatus as in claim 14, configurable such that a camera is caused to send device event data responsive to detection of an event by one or more of a security sensor and environmental sensor, deployed with connectivity to a central panel.

17. A camera network management apparatus as in any preceding claim, configurable such a buffer holding images relating to a predefined period will be maintained such that camera event data includes images for one or more of: a period of time before the trigger event, a period of time during the trigger event; and a period of time after the trigger event.

18. A camera network management apparatus as in any preceding claim, wherein the streaming device comprises a streaming server capable of providing a streaming request to the camera such that a streaming session can be established between the camera and the streaming device independently of the control path between the camera and the device manager.

19. A camera network management apparatus as in any preceding claim, wherein the streaming device comprises computer control code to cause a streaming request to be initiated responsive to a user request.

20. A camera network management apparatus as in any preceding claim, wherein the streaming device comprises computer control code to cause a streaming request to be initiated by the device manager responsive to a camera event data.

21. A camera network management apparatus as in any preceding claim, wherein the device manager is configured to provide a streaming session identifier to a particular user by means of a communication channel recorded in a user account store associated with that particular user.

22. A camera network management apparatus as in any preceding claim, wherein said streaming session identifier includes a link to a streaming session.

23. A camera network management apparatus as in any preceding claim, wherein said streaming session identifier is sent as an alert responsive to camera event data and includes a link to a streaming session.

24. A camera network management apparatus as in any preceding claim, wherein the device manager comprises a polling interval monitoring module configured to detect, and optionally determine likely cause of, missing polling messages from one or more registered devices.

25. A device network management system enabling a user to issue a control instruction to one or more devices, comprising: a device manager arranged to receive a instruction from a user and provide said instruction to a device responsive to a polling message from the device. to the device manager, wherein the system comprises a user account store holding an inventory of devices allocated to each user and a device data store holding a queue of instructions to be provided to the device responsive to the device polling the device manager.

26. A method of operating a camera network management device comprising:

receiving at a device manager corresponding to a fixed pointer an initialisation message sent from a camera coded with the fixed pointer, the initialisation message being sent responsive to the camera's first connection to the Internet and comprising a device identifier;

the device manager reconciling the device identifier from the initialisation message with a corresponding identifier recorded in a user account store such that the camera device is registered as a device belonging to the relevant user account-

providing one or more camera instructions in a camera data store; and

sending the at least one camera instruction from said camera data store to said camera responsive to a polling message from the camera to the device.

27. A method of operating a camera network apparatus configured to enable a user to control at least one remote camera deployed in a remote network, the method comprising:

receiving at least one control instruction for a camera from a user device;

queuing said camera controi instruction in a device data store of the device manager, said device data store comprising part of a control path between the user and the camera;

receiving a polling message from the camera deployed in the remote network and in response referencing the device data store to check for instructions queued for the camera, wherein a communication channel is established to the camera and the queued instruction is sent to the camera in the event it is determined that an instruction is queued for the camera.

28. A method as in claim 27, wherein the camera network apparatus further comprises a streaming apparatus and wherein said device manager can request a streaming connection is setup between the camera and a user device, each remote from the camera network management apparatus, to enable a user to view images streamed from the camera.

29. A method as in claim 28, wherein the request from the device manager is caused by a user device.

30. A method as in claim 28 or 29, wherein the request from the device manager is caused by event data sent from a device of the camera network.

31. A method as in claim 30, wherein the request from the device manager is caused by camera event data sent from a camera in the camera network.

32. A computer program product comprising a computer readable medium having thereon program code; which when loaded and executed, cause a computer controlled apparatus to perform any of the methods of claims 26-31.

33. A computer readable medium having program code recorded thereon which when loaded and executed, cause a computer controlled apparatus to perform any of the methods of claims 26-31.

34. Computer program code which when loaded and executed, cause a computer controlled apparatus to perform any of the methods of claims 26-31.