Extendible and open camera connector system

RELATED APPLICATIONS

0001This application claims the benefit of U.S. Provisional Patent Application Number 60/673,281 filed on Apr. 20, 2005.

FIELD OF THE INVENTION

0002The present invention relates to the field of remote video camera operation. More specifically, the present invention is a universal, vendor/model-independent remote video camera access and operations management system.

BACKGROUND OF THE INVENTION

0003With increasing security needs, the use of video cameras in various types of surveillance is becoming increasingly important. Video surveillance is typically a part of many aspects of most businesses. However, due to the variety of camera types on the market, a “surveillance coordination” problem has developed when businesses either merge, or when they out-source video surveillance to third parties. The combining of several types of cameras has made centralized surveillance a complicated and costly operation to setup.

0004This is because typically, network-based video camera operations link a camera type (make and model) with a special-purpose remote access, manipulation and monitoring control system developed specifically for that camera type. The IP camera control system generally comprises a client application developed for a particular user device. The client application is also generally created specifically for that particular camera.

0005A conceptual model of a prior art network video application is shown in <figref idref="DRAWINGS">FIG. 1</figref>. In the figure, a client application <b>1</b> is created specifically for a particular type of camera <b>2</b>; Type A, of which there are two cameras <b>2</b>A and <b>2</b>B being utilized as part of a surveillance system covering two different locations. That application permits the user to request access to either or both cameras, operate them, for example to pan or zoom the view, and receive content from them, for example, in the form of video images. If additional but different type cameras, for example Type B, shown as <b>4</b>A and <b>4</b>B, are to be added into the system, a completely new application <b>3</b> would have to be written to support the new units. While this would increase the surveillance capacity of the overall system, neither of the applications would be able to communicate with the other's cameras, an inefficient and undesirable effect.

0006As shown above, adding a new camera type to an existing surveillance system is cumbersome. Combining several diverse monitoring operations into a single, seamless surveillance system, as might be required during a merger of two companies, would increase the difficulty many times over. The consolidation of a group of systems would be very time consuming and potentially very costly for system managers. Therefore, there is clearly a need for improvement in methods for integrating diverse camera operation systems.

SUMMARY OF THE INVENTION

0007While traditional video surveillance has been performed using conventional, CCTV analog cameras, advances in video technology have produced a new product group comprising network (or IP) video cameras. These products, which offer system developers an opportunity to improve the flexibility, accessibility and coordination of diverse remote monitoring systems have not been adequately incorporated into such systems.

0008As a way to address the integration difficulties stated above, an extendable and open remote video camera connection (XOCC) system is disclosed, which, in conjunction with a client application permits the access, manipulation and monitoring of any type of network digital video content source (DVCS), e.g., network video cameras, USB cameras, live internet audio/video streams, web-enabled digital video recorders, etc., by that client application. The system comprises an XOCC framework and at least one XOCC driver.

0009An XOCC driver (a “driver”) is a custom-built DVCS interface module written to extend the control of a network video source, for which the driver is written, to a remote client application which functions to access, consume or manipulate the content provided by the source. The client's control is implemented via the XOCC framework. Each driver is written specifically for the type of DVCS it controls and interfaces with elements of the framework.

0010The XOCC framework comprises a client-to-driver API, a driver manager and a driver container. The API provides an abstraction layer to a client's operation of a remote video source device. It permits a single client application to interface with diverse DVCS types, via their respective drivers, in such a way that the client sees no difference between DVCS/driver types in the control of the remote video source. The driver container is a storage area for drivers which are available to the system running the client application. The driver manager is a program component which manages the access and delivery of the appropriate stored driver for a given video source requested by the client.

0011All that is required to integrate diverse surveillance systems is: 1) the XOCC framework and 2) an XOCC driver for each DVCS type in each surveillance system. In essence, the XOCC system functions by having the client application access the XOCC API, which in turn accesses the XOCC-compatible video source driver, which then accesses the driver-specific video source. The abstraction occurs within the XOCC framework, which receives a request from the client, interprets it in light of the environment of the request and accesses the appropriate driver for the request. The XOCC API then addresses the request to the driver, which then acts on the video source. All this happens seamlessly to the user. Further, the layer of abstraction between the content producer (i.e., the DVCS) and the content consumer (e.g., end user applications or devices used for content recording, etc.), ensures video source and client application-independent communication from the consumer's side. That is, a client application designed to work with camera X will also work with camera Y, provided both camera driver types are available to the system.

0012The XOCC system is designed to allow the client application to 1) facilitate manipulation of the video source (i.e., moving the camera, in the case of a PTZ camera; setting media parameters: quality, format, etc.), 2) access the video media produced by the source, and 3) to provide the client application with a set of generic interfaces allowing retrieval of detailed information about the video source (e.g., current position, current frame rate, comments, event notifications, media format, available features, etc.). This invention is video source, client application, protocol and computer language-independent and can thus be potentially used with virtually any technology available in the industry.

0013The Driver Manager is the center-piece and entry of the XOCC system framework. At start time the driver manager examines the environment and determines which drivers are available for use. Available drivers are loaded and registered making them ready for use.

0014The client application accesses the driver manager and either asks the driver manager which drivers are available or directly asks the manager to provide a specific driver (e.g., the driver for vendor “Sony”, model “XCST10”) for a targeted video source.

0015Once the application accesses the correct driver, it uses XOCC interfaces to learn about the source: parameters needed to establish a connection, format of the coordinates, format of the media returned, available features etc.

0016Besides being designed to handle communication with PTZ and non-PTZ network cameras, XOCC has built-in capabilities for handling any video source available over the network or other digital mediums accessible from the environment on which the client applications are installed.

0017Both the XOCC system components and the XOCC drivers are developed using libraries of XOCC framework development code. The drivers may either be developed by integrators during the XOCC system development or the drivers may be added later as more DVCS devices are added to the client application's network.

BRIEF DESCRIPTION OF THE DRAWINGS

0018Exemplary embodiments of the invention are discussed hereinafter in reference to the following drawings, in which:

0019<figref idref="DRAWINGS">FIG. 1</figref> is a network diagram illustrating prior art implementations of client applications involving multiple IP camera types.

0020<figref idref="DRAWINGS">FIG. 2</figref> is a schematic depicting the XOCC framework, drivers and their interaction with a client application controlling a network video device.

0021<figref idref="DRAWINGS">FIG. 3</figref> is a functional diagram depicting the integrated use of an application augmented with the XOCC system in processing client requests associated with control of a network video device.

0022<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart showing the XOCC driver registration process for all drivers available to the system.

0023<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart showing the process of associating a compatible registered driver with a client application in response to a request to access a specific camera.

DETAILED DESCRIPTION OF PREFERRED EXEMPLARY EMBODIMENTS

0024The XOCC system of the present invention comprises an XOCC framework (the “framework”) and at least one XOCC driver (a “driver”). As is illustrated in <figref idref="DRAWINGS">FIG. 2</figref>, the framework <b>20</b> comprises an XOCC API <b>21</b>, a driver manager <b>22</b> and a driver container <b>23</b> operating as part of the driver manager. The XOCC framework operates in conjunction with a client application <b>26</b>, from which a user may control a web-based system of digital video content sources (DVCS) <b>25</b>. The DVCS comprise, for example, network video cameras, USB cameras, live internet audio/video streams, web-enabled digital video recorders, etc.

0025Drivers <b>27</b> comprise custom-built DVCS device control modules which are designed to interface with the XOCC API (rather than the client application) in controlling a specific make and model of DVCS device. They receive instructions from the API, which is operating under the direction of a client application which, in effect is utilizing the XOCC framework as an integrated extension of itself. The drivers facilitate access to, manipulation of, retrieval of operational information from and retrieval of video content from the DVCS devices they directly control. They operate in much the same manner as typical device drivers do, interfacing with an operating system to facilitate control of the device, however, these XOCC drivers are available for IP video source devices. They may be designed by either XOCC system integrators or DVCS device manufacturers, in either case, utilizing XOCC application development libraries, which will be described further hereunder. The drivers reside in a driver repository <b>24</b> until called into the driver container by the driver manager for registration and use, all of which is explained below.

0026The XOCC API <b>21</b> is created by the application developer, also from libraries as referred to later on, to provide a functional abstraction layer between the client application and the DVCS drivers. <figref idref="DRAWINGS">FIG. 3</figref> shows conceptually how the API functions to assist the client in working with a variety of drivers by accepting instructions from the client for a particular DVCS and interfacing with the DVCS drivers to implement those instructions.

0027In an exemplary embodiment, as depicted in <figref idref="DRAWINGS">FIG. 3</figref>, a client first sends an instruction (line <b>31</b>) for a “zoom” operation of Camera B to the API. The zoom instruction coming from the client application is generic. That is, the client issues the same instruction to the XOCC API regardless of the device being accessed by the application. The API interprets the request and makes an interfacing call (line <b>32</b>) to the driver for Camera B to have the request executed. Because of the abstraction provided by the API, the client does not know which type of DVCS device it is trying to access. It simply communicates its generic request to the API, which in turn communicates with the appropriate driver, as referred to the API by the driver manager. The driver receives the API instruction and sends a DVCS-friendly command to the associated DVCS device. In the example above, the driver sends a camera-friendly zoom instruction (line <b>33</b>) to Camera B.

0028In another exemplary embodiment, the client instruction (line <b>31</b>) may be a request for camera information, which is subsequently returned to the client by the system. For example, instead of a request to zoom, the client may send a request to know the current position of the camera. The request is passed from the API to the driver (line <b>32</b>) and from the driver to the camera (line <b>33</b>). In response to the request, Camera B returns its current position (line <b>34</b>) to the driver, which returns it (line <b>35</b>) to the API, which returns it (line <b>36</b>) to the client.

0029Driver container <b>23</b> comprises a storage area, accessible by the driver manager which is used for storing XOCC drivers registered by the manager. The storage area may be in memory, on a hard disc, etc. The nature of the interface between the storage container, the XOCC API and the driver manager is explained below.

0030The driver manager <b>22</b> comprises a program component within the XOCC framework which interfaces with the XOCC API <b>21</b>, the client application <b>26</b> and its own driver container <b>23</b> to register and return drivers stored on the system for use by the application at the request of the client. As shown in <figref idref="DRAWINGS">FIG. 4</figref>, the driver registration process begins with the start of the application (step <b>41</b>). Once started, the application will create a list of drivers available to the XOCC system (step <b>42</b>). This list may be generated from configuration files, from the current environment, from the end user, from the application server, or elsewhere. A repository <b>24</b> of available drivers is shown schematically in <figref idref="DRAWINGS">FIG. 2</figref>. Next, one of the listed drivers is loaded into the storage container (step <b>43</b>). The application will then retrieve the driver manager (step <b>44</b>) and the driver manager will register the stored driver (step <b>45</b>). Then the system will check to see if there are additional drivers available for use (step <b>46</b>). If there are, the process repeats itself from step <b>43</b>. If there are no more un-registered drivers, the registration process is finished (step <b>47</b>). At this point, all drivers which have been created for the XOCC-enhanced application are loaded, registered and ready for use. The method of their usage is described below.

0031With all drivers <b>27</b> loaded into the storage container <b>23</b> and registered with the driver manager <b>22</b>, the client application is able to access, manipulate and consume content from any DVCS devices within the application <b>26</b>. <figref idref="DRAWINGS">FIG. 5</figref>, depicts the process of associating a client application with a specific registered driver for a specific system camera. In step <b>51</b>, at the request of the client for access a system camera, the system retrieves the driver manager <b>22</b>. In step <b>52</b>, the application asks the driver manager to call up a registered driver. The driver manager retrieves a driver from the storage container (step <b>53</b>) and in step <b>54</b>, checks to see if that driver supports the operation of the requested camera. If it does not, the process moves to step <b>55</b>, wherein the driver manager checks to see if more registered drivers are available. If there are, the process reverts to step <b>53</b> to retrieve another driver. If in step <b>54</b> the retrieved driver does support the desired camera, the process passes to step <b>56</b> where the manager returns (i.e., establishes a reference for) the current driver to the client. If in step <b>55</b>, the driver manager finds no acceptable drivers, it returns an error message (step <b>57</b>) to the client.

0032Functionally, the operation of the XOCC system with respect to camera access and camera control is shown schematically in <figref idref="DRAWINGS">FIG. 2</figref>. The schematic depicts a request by the client application to access a Canon camera <b>25</b>. The request comes in the form of a Get Driver instruction (line <b>211</b>) to the driver manager <b>22</b>. The driver manager proceeds through the driver selection process of <figref idref="DRAWINGS">FIG. 5</figref> (line <b>212</b>), ultimately selecting the Canon driver (line <b>213</b>) as the driver to associate with the client. The driver manager then returns the Canon driver by establishing a reference to that driver (line <b>214</b>) with the API <b>21</b>. The API is now ready to receive requests from the client application for control of the Canon camera.

0033Camera control operation is demonstrated by following the process of a camera “pan” request in <figref idref="DRAWINGS">FIG. 2</figref>. The application initiates the request (line <b>215</b>) as a generic request to the API <b>21</b>. The API processes the request (line <b>216</b>) into a pan instruction (line <b>217</b>) which will be understood by the Canon driver. The Canon driver then generates a pan command (line <b>218</b>) to the Canon camera.

0034The invention comprises not only the XOCC framework and driver concepts, but includes the method of their development, as well. The XOCC system may be integrated into a developer's application through a set of libraries. There is one library for the framework creation and another for driver development. It is not necessary to install all drivers during framework development. The drivers may be created and integrated later as diverse surveillance system mergers occur or as different camera types are added to a single system due to expansion, attrition, etc.

0035Because many varying and different embodiments may be made within the scope of the inventive concept herein taught, and because many modifications may be made in the embodiments herein detailed in accordance with the descriptive requirements of the law, it is to be understood that the details herein are to be interpreted as illustrative and not in a limiting sense.