Multi-instance input device control

Details Multi-instance input device control Multi-instance input device control

1999-11-10

2003-03-25

Gaffin, Jeffrey (Department: 2182)

Electrical computers and digital data processing systems: input/

Input/output data processing

Peripheral adapting

C710S020000, C710S036000, C348S014050

Reexamination Certificate

active

06539441

ABSTRACT:

BACKGROUND OF THE INVENTION
The present invention relates to video cameras, and in particular to the interfacing of the video camera to application programs.
Traditionally, when one application connects to a video camera, all other applications are prevented from using that camera. When an application program calls to communicate with a video camera, the application program calls to the driver files or the dynamic link library (DLL or *.dll) files. Typically, a DLL provides one or more particular functions and a program accesses the function by creating a link to the DLL. DLL's can also contain data. Some DLL's are provided with the operating system (such as the Windows operating system) and are available for any operating system application. Other DLL's are written for a particular application and are loaded with the application program (such a video control application program). When a video control application program calls to connect to a video camera, at that point, the driver checks to make sure that no other application has opened the particular camera driver file (*.dll), and if no other has, the driver will open the particular driver file. Having done so, there now exists a single threaded connection between the video camera and the application program through the opened video camera driver file as seen in FIG.
1
.
As depicted in
FIG. 1
, the driver file
14
is opened by the driver
12
which is called by the calling application program
10
and gets loaded in the calling application program's memory. Since the video camera driver file
14
has been opened by the application program
10
, the next application which attempts to make a call to the video camera is prevented from doing so. This is because the video camera driver file has been loaded in the first application program's memory and is not available to be accessed by another calling program. Therefore, each application program which potentially makes calls to a video camera must account for the presence of another application program possibly already using the camera. Accordingly, such application programs are encumbered by the need to first check to determine whether another first application program was executed that had connected to the video camera, and if so the second calling program must have routines allowing it to negotiate the sharing of the camera. However such sharing is a single-instant one, meaning the that connection between the camera and the first application program would have to be broken (i.e. the first application program would have to be shut down or the video camera turned off) before the connection between camera and the second application program could be established. Authority, priority, and other security aspects as well as appropriate error handling must also be resolved by the communications between the two competing application programs. Presently, no application program even attempts to resolve any of these issues, and therefore if a connection between a calling program and a camera cannot be established, the unexpected application programs errors are resolved by the operating system which issues rather inelegant and undecipherable error messages leaving theultimate user to only infer that a proper connection could not be established.
Application programs have continued to grow in size, flexibility and usability, and the trend has been to move away from large monolithic application programs to programs that are made of many smaller sub-programs. This building block approach provides many advantages such as ease of later modification and configurability. Moreover, operating system suppliers have also adopted such a modular approach and hence offer many standard sub-programs or objects that handle utility type functions such as queuing files to a printer, and loading and running printer DLL files to print files. The DLL files themselves are objects or sub-programs. And in an effort to a allow interoperability between objects and smaller sub-programs written in different high level programming languages, operating systems suppliers have developed models for executable programs, which can be compatible with each other at the binary level. One such model for binary code developed by Microsoft is the component object model (COM). The COM enables programmers to develop objects that can be accessed by any COM-compliant application. Although many benefits can be realized by transitioning from large monolithic application programs to sets of smaller sub-programs and objects, those advantages must be balanced against the burdens imposed by the need for the additional routines allowing for inter process communications amongst these sub-programs and objects.
Besides growing in complexity and usability, multi-unit application programs have been migrating from single-host sites to multiple host heterogeneous network environments. Consequently, it is now not unheard of to have a single application program be comprised of many different routines, each written in different high level programming languages and each residing on a separate computer, where all those computers are connected to each other across a network. In such implementations, the demands for efficient intra and inter-network and inter-process communications can take on a life of their own, detracting from the programnmer's primary function of writing an application program. The programmer also has to handle the communications issues posed by spreading application programs across a network. Once again, operating systems suppliers have realized this challenge and potential detraction and have addressed it in various ways. Microsoft has extended the COM functionality by developing the distributed component object model (DCOM). DCOM is an extension of COM to support objects distributed across a network. Besides being an extension of COM, DCOM provides an interface which handles the details of network communication protocols allowing application programmers to focus on their primary function of developing application specific programs. DCOM is designed to address the enterprise requirements for distributed component architecture. For example, a business may want to build and deploy a customer order entry application that involves several different areas of functionality such as tax calculation, customer credit verification, inventory management, warranty update and order entry. Using DCOM the application may be built from five separate components and operated on a web server with access via a browser. Each component can reside on a different computer accessing a different database. The programmer can focus on application development and DCOM is there to handle the inter process communications aspects of the separate components of the application program. For example, DCOM would handle the integration of component communication with appropriate queues and the integration of component applications on a server with HTML-based internet applications.
SUMMARY OF THE INVENTION
The present invention combines features of an executable process with the need for multiple application programs to share a single input device, such as video camera. An input device such as a video camera is a peripheral device that is opened and remains open in response to a call from an application programs. The present invention provides an executable program implemented as a process that allows multiple applications to communicate with a single input device. This is achieved by creating a virtual interface (an instance) to the physical input device and by loading the input device control executable program into a process. An instance is an actual usage and the resulting virtual creation of a copy of an entity loaded into memory. The executable program process acts as a server thus allowing multiple application programs to interface with the same input device. The multi-instance input device control (MIIDC) executable program responds to each application program request as if the input device is open for the calling application progr

Affiliated with

Also associated with

Rating

Multi-instance input device control does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Multi-instance input device control, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Multi-instance input device control will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3015624