多实例输入设备控制的制作方法

专利名称：多实例输入设备控制的制作方法
技术领域：
本发明涉及媒介源输入设备如麦克风和摄像机，并且尤其是涉及媒介源输入设备与应用程序的接口。
背景技术：
一般地，当一个应用程序连接到一个媒介源时，所有其它的应用程序都被禁止使用该媒介源。对于通用的个人计算机，当一个应用程序呼叫以便与一个媒介源通信时，该应用程序呼叫其驱动器文件或动态链接库(DLL或*.dll)。一般地，DLL提供一个或多个特定的函数，以及一个程序通过创建到该DLL的链接访问该函数。DLL也可以包含数据，有些DLL与操作系统(如窗口操作系统)设置在一起并且对于任何操作系统应用来说都是可用的。为了某种特定的应用可以写其它的DLL并将其与应用程序(例如一个媒介源控制应用程序)一起装载。当媒介源控制应用程序呼叫以连接到一个媒介源时，在该点处，驱动器检查以确定没有其它的应用已打开该特定的摄像机驱动器文件(*.dll)，以及如果没有其它的应用已打开的话，该驱动器就打开该特定的驱动器文件。这样做之后，就会通过该打开的媒介源(如摄像机)驱动器文件在媒介源(如摄像机)与应用程序之间存在一个单一的线程连接，如

图1所示。
图1表示与一个媒介源连接的应用程序，其中媒介源是摄像机。如图1中所示的，驱动器文件14被驱动器12打开，其中驱动器12被呼叫应用程序10呼叫并且装载在呼叫应用程序的存储器内。由于摄像机驱动器文件14已经被应用程序10打开，试图呼叫该摄像机的下一个应用就被禁止这样做。在多个应用程序之间共享媒介源中有关冲突的问题就是众所周知的突发事件。由于在某一时侯一般的输入设备驱动器仅允许一个应用使用该输入设备数据，因此总是存在着突发事件。这是因为摄像机驱动器文件已经被装载进第一应用程序的存储器内并且不能被另外一个呼叫程序使用。因此，潜在地呼叫该摄像机的每个应用程序必须考虑到已经使用该摄像机的另外一个应用程序的存在。相应地，这些应用程序被这样一种需要所阻碍，即要首先检查以确定是否已连接到该摄像机的另外一个第一应用程序被执行，并且如果是这样，第二呼叫程序必须具有例程以允许它协商对该摄像机的共享。但是这种共享是单一-即时(single-instant)的，意思是说在摄像机与第一应用程序之间的连接将不得不断开(即，第一应用程序将不得不关断或关掉摄像机)，然后建立摄像机与第二应用程序之间的连接。由这两个竞争应用程序之间的通信来解决授权、优先权以及其它的安全方面和相应的错误处理。目前甚至没有应用程序试图解决这些问题，并且如果在呼叫程序与摄像机之间的连接不能建立的话，由操作系统来解决不希望的应用程序错误，该操作系统会发出相当不雅和无法翻译的错误消息，留给最终用户去推断可能没有建立正确的连接。最好，第二呼叫应用程序接收一个指示目前呼叫的设备正在使用以及不可用的消息。
应用程序在尺寸、灵活性以及可用性上不断地增加，并且这种趋势是从大的单片应用程序向由很多小程序构成的程序转变。这种提供模块的方法具有很多的优点，例如便于以后的修改和配置。而且操作系统供应商如微软公司已经采用这种模块化方法，并且提供了很多个可处理很多实用型功能(排队文件到打印机，安装和运行打印机驱动器(如DLL)文件以打印文件)的标准子程序或对象。该驱动器(如DLL)文件本身是对象或子程序。而且为了使对象独立于以不同的高级编程语言写的更小的子程序，操作系统供应商已经开发了用于可执行程序的模型，它们在二进制的层次上是兼容的。由微软公司开发的这种二进码的模型是组件对象模型(COM)。该COM可以使编程员开发出可由任何COM兼容应用访问的对象。尽管通过将大的单片应用程序转变成更小的子程序的集合和对象可以实现很多的优点，但是这些优点在对这些附加的例程的需要所造成的负担方面要进行均衡，允许中间处理在这些子程序和对象之间进行通信。
除了在复杂性与使用性方面的增长外，多单元应用程序已经从单一主机区移植到多主机不同种类的网络环境。因此，现在不是没有听到使一个单一应用程序由多个不同的例程构成，每个例程可以由不同的高级语言编写并且驻留在独立的计算机内，其中所有这些计算机通过一个网络彼此连接到一起。在这种实现中，对于有效的网内与网间以及交互处理通信的需求表现出其自身的生命力，从编程员的写应用程序的主要功能上转换开来。该编程员还不得不处理由在网上传播应用程序所引起的通信问题。再次，操作系统供应商已经意识到这种挑战以及潜在的转移，并且以多种方式解决了它。例如微软通过发开分布式组件对象模型(DCOM)来扩展COM的功能。DCOM是COM的扩展以支持在网络上分布的对象。除了作为COM的扩展外，DCOM提供了处理网络通信协议的细节的接口，允许应用编程员将精力集中在开发特定应用程序的主要功能上，DCOM被设计成为分布组件体系解决企业要求。例如一种商业可能想要建立并展开客户订单入口应用，该应用可能涉及几种不同的功能区如税务计算、客户信用验证、库存管理、担保更新以及订单入口。利用DCOM，该应用可以从五个独立的组件建立并且运行在通过浏览器访问的网络服务器上。每个组件可以驻留在访问不同的数据库的不同计算机上。编程员可以集中在应用的开发上，并且由DCOM处理该应用程序的独立组件的交互处理通信事务。例如，DCOM将处理组件通信与相应排队的集成以及服务器上的组件应用与基于HTML的互连网应用的集成。
因此，尽管很多的计算机系统操作系统供应商提供了很多标准的可执行程序的标准化模型，但是这种可执行的应用程序中俑与媒介源输入设备按照一对一地进行接口。一个标准化的设备驱动器文件，一旦链接到一个应用程序，对于另外应用程序来说将不再是可用的。因此，存在着允许多个应用程序共享一个单一的媒介源输入设备的需求，这种设备一般来说是摄像机或麦克风。
发明概述本发明组合了可执行处理与对多应用程序的需要的特征以便共享一个单一的输入设备，例如摄像机或麦克风。象摄像机或麦克风这样的输入设备一个开放的外部设备，并且响应于来自应用程序的呼叫一直保持开放。本发明提供一个作为允许多应用与单一输入设备进行通信的处理进程而实现的可执行程序，这是通过创建到物理输入设备的虚拟接口(一个实例)以及将输入设备控制可执行程序装载进一个处理进程而实现的。一个实例(instance)是实际的使用以及装载进存储器的一个实体的拷贝的虚拟生成。该可执行程序处理进程作用是一个服务器以允许多应用程序与同一输入设备接口。这里使用的该可执行程序称作多实例输入设备控制(MIDC)，可执行程序响应每个应用程序请求，就好象该输入设备是为该呼叫应用程序开放的，因此每个应用程序能与该输入设备实例进行通信而不会干扰其它应用程序与同一输入设备的通信。换句话说，该MIDC通过创建一个客户—服务器体系而虚拟化了一个输入设备，在此每个呼叫应用程序是一个客户并且其中该MIDC是服务器，使该驱动器文件服务于每个呼叫应用程序。
该MIDC以及虚拟化输入设备的方法可以在运行各种操作系统的许多计算平台上实现。象摄像机或麦克风这样的媒介源输入设备一般地与一个主机计算机进行接口。该主机计算机通常是一台个人计算机，如Mac计算机。但是，由于技术的进步使得计算与通信设备之间的界限变得模糊，因此这里所用的主机计算机是与智能主机同义的，并且这里所说的智能主机是指包括所有具有处理器、存储器、输入输出设备以及存储装置的任何主机。其它智能型主机的例子(同样可以与本发明的实施例结合使用)包括手持计算机、交互式机顶盒、瘦(thin)客户计算设备、个人访问设备、个人数字助理以及因特网设备。
在一种实现中，在运行通用的窗口操作系统的PC主机上，(MIDC)可执行程序可以是一个DCOM对象，DCOM可以用作一个接口，以使多个应用程序与一个单一输入设备进行通信。DCOM接口处理的接口操作包括装载、执行、缓冲、上载以及呼叫可执行程序。在基于DCOM的实现中，MIDC对象本身是一个DCOM服务器。该MIDC通过连接到作为一个可执行程序实现的DCOM对象内的输入设备而工作。因此，MIDC变成一个作为可执行程序实现的DCOM对象，意思是说MIDC是一个处理进程，类似于任何其它的操作系统(O/S)处理—可由其它的应用共享。通过将输入设备访问程序放进一个独立的可执行处理进程，该输入设备能够被多个应用程序共享。对于应用程序来说，DCOM接口看起好象只是为呼叫该DCOM对象的应用而开放，尽管只有一个输入设备的实例。
实施MIDC以便对于每个实际的硬件输入设备来说，DCOM服务器创建单一输入设备实例并且连接到该硬件设备。当一个应用程序与该输入设备控制(是一个可执行的DCOM服务器)连接时，该DCOM服务器创建一个MIDC实例(以及一个接口)，通过该实例应用程序与该单一输入设备实例进行通信。由单一输入设备实例为每个输入设备控制的实例提供用于输出的数据，由此允许多个应用与一个单一输入设备同时进行通信。全局设置是(MIDC)特定实例。另外，保护该输入设备实例以便输入设备控制程序的多个实例不能执行会影响另一个实例的处理的任务。利用这种方法，就可以写应用程序而不需要考虑可能已经使用同一输入设备的另一个应用的存在。
本发明的其它方面是针对客户端的机制，使应用程序与可执行的输入设备服务器进行通信。如上面所描述的，可执行的MIDC是在客户—服务器体系下实现的，在此每个应用程序是一个客户。很自然，客户必须能与服务器进行通信。本发明的方法提供几种机制，以使一个应用程序与MIDC服务器进行通信。在PC/窗口环境中，通过ActiveX控件呼叫的输入设备端口(portal)传送第一客户端机制。第二客户端机制也是在PC/窗口环境下，是通过DirectShowTM视频捕获源过滤器传送的。
在端口方案下的客户端机制包括与MIDC服务器通信以及将用户接口元素提供给一个应用。利用这种端口方案，虚拟化一个输入设备的所有功能是由MIDC服务器执行的，并且因此与MIDC服务器通信的应用程序可要求用户接口编程。为了完成这些，在视频端口方案下，提供一个模板以允许各种应用程序提供商产生它们自己的客户输入设备端口。
在第二种方案(即DirectShowTM方案)下客户端机制采用标准化的DirectShow模块化组件呼叫过滤器。该第二客户端机制利用一个虚拟源过滤器替换标准源(媒介输入)，其直接与MIDC服务器进行通信。该虚拟源过滤器是一个到MIDC服务器的客户。利用这种机制，DirectShow应用不能区分“真实”的和“虚拟的”源过滤器。这种第二客户端机制的优点是写到DirectShow环境内的函数的任何应用程序将很容易地共享一个输入设备而不需要在与MIDC服务器进行通信时进行任何附加的用户接口编程。
为了进一步理解本发明的优点和本质，下面结合附图参照下面的描述进行说明。
附图的简要说明图1是表示现有技术的单一应用程序与单一摄像机进行通信的方法的方框图；图2是描述本发明的多实例输入设备控制程序的一个实施例的方框图；图3是表示在与单一输入设备连接的一个应用中所涉及的步骤的流程图。
具体实施例方式
图2表示在PC/Wndows环境中描述本发明的多实例的输入设备控制程序(MIDC)的一个实施例的方框图。在该实施例中，输入设备是一个摄像机，可执行程序是一个DCOM可执行程序，该实施例描述了多应用程序是如何共享单一摄像机的。一旦第一应用程序100响应以连接到该摄像机108，该呼叫被传送到DCOM应用程序接口(API)102。对于DCOM的更详细的描述可以参照Microsoft网站的相应的Microsoft文档。该DCOM API 102处理该DCOM可执行程序的装载，并建立从应用程序到DCOM可执行程序200的连接。DCOM服务器200创建一个单一的摄像机实例106以及第一MIDC实例104。下一步该DCOM服务器200将该单一摄像机实例106连接到摄像机驱动器107，以及利用该单一摄像机实例106摄像机驱动器107连接到摄像机设备108与第一MIDC实例104。摄像机实例106是一个到物理摄像机设备108的虚拟接口。一个实例是实际使用的并且由装载进存储器的实体的拷贝虚拟生成的。在该实施例中，所有的实例存储器位于可执行服务器内。最后建立连接300，以允许客户应用程序100通过新例示(instantiate)的DCOM接口(单一摄像机实例)106与该摄像机设备108接口。
一旦第二应用程序110呼叫以连接到摄像机108，DCOM服务器200生成第二MIDC实例114，并将其连接到单一摄像机实例106，如此通过建立的第二连接310，就可允许第二客户应用110通过该单一摄像机实例106与摄像机设备108交互。随后的应用程序120等也通过DCOM例示的单一摄像机实例接口106与摄像机设备108通过随后建立的连接320等交互。
图3是描述图2的处理过程的流程图。一旦客户应用程序呼叫以连接到摄像机设备(步骤103)，该应用程序呼叫被发送到DCOM API(步骤203)。下一步，DCOM API确定是否装载DCOM实现的可执行MIDC。一般地，第一客户应用程序导致装载可执行的MIDC。如果没有装载可执行的DCOM服务器，由该DCOM API获得该获呼叫并使DCOM服务器装载该DCOM实现的可执行MIDC的服务器(步骤403)。下一步，MIDC服务器生成一个输入设备控制实例(步骤503)。如果已经装载了MIDC可执行的服务器，步骤403就不需要了，那么在步骤303之后的下一步是503。MIDC服务器随后生成一个单一的摄像机实例并将其连接到摄像机设备，然后将该输入设备控制实例连接到单一摄像机实例(步骤603)。最后，MIDC服务器生成一个接口，通过该接口第一客户应用程序与单一摄像机实例进行通信(步骤703)。
在图2中描述的摄像机实例106是一个与摄像机设备的接口，它维护输入设备控制的实例的状态，该输入设备实例106是一个存储器块，维护着已经与该摄像机设备建立的连接数量的计数以及每个连接的特定状态。该摄像机实例106还融合了优化每个输入设备控制实例连接的请求所必需的逻辑以及多路复用和解决冲突请求。由于MIDC服务器是作为一个独立的进程存在的，视频(和音频)数据必须为请求访问该视频(和音频)数据的每个客户复制。为了减少复制，MIDC服务器设计成记录视频(和音频)、检测运动、保存画面以及媒介源捕获设备的其它典型功能。因此MIDC服务器将数据复制仅限于需要求媒介源数据(如视频和音频)进行直接访问的应用。
例如，第一输入设备实例可能正在请求640×480像素的分辨率的视频流，而同时第一和第三实例可能正在请求320×480和160×120像素的分辨率的视频流。在这种情况下，摄像机实例106将随后确定以最大的分辨率640×480捕获视频以及然后调整它或剪辑它成为由第二和第三实例正请求的较低的分辨率。按照同一逻辑，如果随后第一视频实例与该摄像机断开，摄像机实例106将随后解决第二和第三实例请求320×480和160×120像素的分辨率的请求，即通过以最高分辨率320×480像素捕获视频以满足第二实例的请求，以及随后向下调整或剪辑320×480像素视频流为160×120像素以满足第三实例的请求。
在涉及三个输入设备控制实例的另一个示例中，第一输入设备控制实例 可能正在发送一个运动检测命令给虚拟摄像机设备，同时其它两个实例仅请求视频流。那么摄像机实例106将以最高需求的分辨率捕获视频并且通过一个用于第一输入设备控制实例的运动检测计算传送该视频流。
而在另一个涉及三个输入设备控制实例的示例中，第二输入设备控制实例可能正请求一个视频图像的文本覆盖，同时其它两个实例仅请求视频流。那么，摄像机实例106将以最高需求的分辨率捕获视频并且仅增加文本覆盖到流向第二输入设备请求的流。
尽管上面描述的这些实施例是在与个人计算机主机接口的摄像机环境下进行的，但是本发明的范围并不仅限于摄像机或者特定类型的计算机。如上面所描述的，本发明的这些实施例是针对由几个应用程序同时享一个输入设备，并且是通过虚拟化一个设备驱动器文件且驱动器文件依次是通过将该输入设备控制程序实施为一个可执行服务器来达到的。尽管上面描述的输入设备是一个摄像机，可配置成被同时共享的另一个输入设备是麦克风。因此，输入设备实例(图2中的106)融合了优化每个输入设备控制实例的请求所必需的逻辑以及多路复用和解决冲突请求。将该视频源的共享性能扩展为还包含一个音频输入源不仅仅是很自然的事，而且也是必须的，因为视频和音频通常都是捆绑在一起作为自然补充的媒介源。
例如，参照图2，希望在设备108记录视频的同时麦克风(未示出)还记录声音。那么，例如第一输入设备实例可以以44.1kHz请求具有一个位深(depth)的16位的音频，同时第二实例可以11.025kHz请求具有8位深的音频流。在这种情况下，输入设备实例将随后确定以最高的采样率和位深捕获音频，然后调整或将其压缩到第二实例所请求的较低的位深或采样率。
MIDC和虚拟化输入设备的方法可以在很多运行各种操作系统的计算平台上实现，象摄像机或麦克风这样的媒介源输入设备通常与一个主机计算机接口，并且该主机计算机通常是一个人计算机，如通常的Mac计算机，但是由于技术上的进步使得计算设备与通信设备之间的边界越来越模糊，因此这里所用的主机计算机与智能主机是同义的，并且这里所用的智能主机包括所有具有处理器、存储器、输入输出装置以及存储装置的主机的示例。其它示例的主机(同样可以与本发明的实施例结合使用)包括手持计算机、交互式机顶盒、瘦客户计算设备、个人访问设备、个人数字助理以及因特网设备。
本发明的其它方面是针对该客户端机制，它能使应用程序与可执行的设备服务器进行通信。如上所描述的，可执行的MIDC是客户—服务器体系下实现的，在此每个应用程序是一个客户，因此一个客户能与该服务器通信。本发明的方法提供了几种机制，使应用程序与MIDC服务器通信。在PC/Windows环境下，第一客户端机制是通过称作ActiveX控件的输入设备端口传送的，在PC/Windows环境下的第二客户端机制是通过一个DirectShow视频捕获源过滤器传送的。
在端口方案下的客户端机制包括与MIDC服务器通信以及将用户接口元素提供给一个应用。利用端口方案，虚拟化输入设备的所有功能是通过MIDC服务器执行的，因此与MIDC服务器通信的应用程序将要求用户接口编程。为了完成它，在视频端口方案下，提供一个模板以允许各种应用程序提供商产生它们自己的客户输入设备端口。
在第二种方案(即DirectShow方案)下客户端机制采用称作标准化DirectShow模块化组件的过滤器。由MicrosoftTM提供的DirectShowTM服务为多媒介流提供回放服务，包括设备的多媒介流的捕获。DirectShowTM服务的中心是称为可插入组件的过滤器的模块化系统。这些模块化组件可以按照源、变换或呈送(renderer)进行分类，过滤器对数据流的操作是通过读、拷贝、修改或写数据到一个文件或将文件呈送到输出设备实现的。这些过滤器具有输入输出装置并且按照称称作过滤器图的配置彼此连接。应用程序使用一个称作过滤器图管理器的对象来组装该过滤器图并通过它移动数据。过滤器图管理器处理从输入设备到回放设备的数据流。DirectShowTM服务与MicrosoftTMDirectXTM媒介软件开发工具的进一步描述可以通过参照本技术领域人员所知的相应文件而获得。
第二种客户端机制用虚拟源过滤器替换了标准源(媒介输入)过滤器，它与MIDC服务器直接进行通信，虚拟源过滤器是到MIDC服务器的客户。利用这种机制，DirectShow应用不能区分“真实”与“虚拟”源过滤器。该第二种客户端机制的优点是写到DirectShow环境中的函数的所有应用程序都能很轻易地共享输入设备而不必在与MIDC服务器通信前进行任何的附加的用户接口编程。
本技术领域内人均知，本发明可以其它特定形式实现而不会脱离本发明的本质特征。例如，MIDC可以作为任何其它的可执行处理进程实现而不只是基于DCOM的处理，以及所有其它接口协议而不是DCOM接口能用于允许多应用程序与该处理通信。这些实施例希望都能涵盖在本发明的范围内，并由下面的权利要求给出。
权利要求
1.一种允许多客户应用程序同时与单一输入设备通信的输入设备控制程序，其中所述输入设备控制程序是作为一个处理进程装载的，以及其中所有随后的应用程序呼叫所述处理进程以建立与所述单一输入设备的通信。
2.如权利要求1所述的输入设备控制程序，其中所述的输入设备包括数字因特网摄像机。
3.如权利要求1所述的输入设备控制程序，其中所述的输入设备包括一个麦克风。
4.如权利要求1所述的输入设备控制程序，其中所述的输入设备控制程序包括下列进程a)视频控制方法包括i)初始化一个视频控制；ii)摄取数字静态图像；iii)记录数字视频图像；iv)获取视频驱动器信息；v)设置摄像机属性；以及vi)获取摄像机属性；b)摄像机事件通知包括i)运动检测通知；ii)音频视频(AVI)错误通知；iii)摄像机分开通知；以及iv)摄像机重新接上通知。
5.如权利要求1所述的输入设备控制程序，其中所述的处理进程处理所有的网络协议的细节，包括装载所述的输入设备控制程序；利用相关的输入/输出数据呼叫所述的输入设备控制程序；从所述的输入设备控制程序或向该设备控制程序缓冲输入与输出；执行所述的输入设备控制程序；以及上载所述的输入设备控制程序。
6.一种允许多客户应用程序同时与一个输入设备通信的输入设备控制程序，其中所述的输入设备控制程序响应一个第一应用程序请求建立到所述输入设备的第一连接i)传送所述的第一应用程序呼叫到一个处理进程的应用程序接口(API)；ii)使所述的处理进程的网络协议装载所述的可执行的输入设备控制程序到一个处理服务器；iii)使所述的处理服务器生成一个单一输入设备实例，并将所述的单一输入设备实例连接到所述输入设备；iv)使所述的处理服务器生成一第一输入设备控制实例并将所述的第一输入设备控制实例连接到所述的单一输入设备实例；v)使所述的处理服务器生成一个接口，通过该接口所述的客户应用程序与所述的单一输入设备实例进行通信；以及vi)响应来自请求到所述的单一输入设备的第二连接的第二应用程序的呼叫生成一个第二输入设备控制实例，并将所述的第二输入设备控制实例连接到所述的单一输入设备实例，以允许所述的第二应用程序与所述的同一输入设备实例进行通信。
7.如权利要求6所述的输入设备程序，其中所述的输入设备控制程序是一个分布式组件对象模型(DCOM)的可执行程序，它包括下列例程a)视频控制方法包括i)初始化一个视频控制；ii)摄取数字静态图像；iii)记录数字视频图像；iv)获取视频驱动器信息；v)设置摄像机属性；以及vi)获取摄像机属性；b)摄像机事件通知包括i)运动检测通知；ii)音频视频(AVI)错误通知；iii)摄像机分开通知；以及iv)摄像机重新接上通知。
8.如权利要求6所述的输入设备控制程序，其中所述的处理进程是一个分布式组件对象模型(DCOM)可执行程序。
9.一种允许多客户应用程序同时与一个输入设备通信的分布式组件对象模型(DCOM)可执行输入设备控制程序，其中所述的程序响应一个第一应用程序请求建立到所述输入设备的第一连接i)传送所述的第一应用程序呼叫到一个DCOM应用程序接口(API)；ii)使所述的DCOM的网络协议装载所述的可执行的输入设备控制程序到一个DCOM服务器；iii)使所述的DCOM服务器生成一个单一输入设备实例，并将所述的单一输入设备实例连接到所述输入设备；iv)使所述的DCOM服务器生成一第一输入设备控制实例并将所述的第一输入设备控制实例连接到所述的单一输入设备实例；v)使所述的DCOM服务器生成一个接口，通过该接口所述的客户应用程序与所述的单一输入设备实例进行通信；以及vi)响应来自请求到所述的单一输入设备的第二连接的第二应用程序的呼叫生成一个第二输入设备控制实例，并将所述的输入设备实例连接到所述的单一输入设备实例，以允许所述的第二应用程序与所述的同一输入设备实例进行通信。
10.一种具有嵌入其中的计算机可读代码的计算可用媒介，该代码可使一个输入设备可由运行在一个主机上且呼叫所述输入设备的多个应用程序共享，所述的计算机可读代码虚拟化一个输入设备驱动器文件；其中所述的计算机可读代码可在一个可执行的客户—服务器体系下实现，其中每个所述的应用程序是一个客户，以及其中所述的计算机可读代码是一个服务器。
11.如权利要求10所述的计算机可用媒介，其中所述的输入设备包括与所述主机接口的数字摄像机。
12.如权利要求10所述的计算机可用媒介，其中所述的输入设备包括与所述的主机接口的麦克风。
13.如权利要求10所述的计算机可用媒介，其中所述的主机是从下列中选择个人计算机、手持计算机、交互式机顶盒、瘦客户计算设备、个人访问设备、个人数字助理、因特网设备、因特网连接的数字图像帧及其组合等。
14.如权利要求10所述的计算机可用媒介，其中通过作为输入设备端口实现的客户端机制所述的应用程序与所述的客户—服务器体系通信。
15.如权利要求14所述的计算机用户媒介，其中所述的输入设备端口是一个ActiveX控件。
16.如权利要求10所述的计算机用户媒介，其中通过作为虚拟源过滤器实现的客户端机制所述的应用程序与所述的客户—服务器体系通信。
17.一种允许多客户应用程序与单一输入设备进行通信的方法，包括i)传送所述的第一应用程序呼叫到一个处理进程的应用程序接口(API)；ii)使所述的处理进程的网络协议装载所述的可执行的输入设备控制程序到一个处理服务器；iii)使所述的处理服务器生成一个单一输入设备实例，并将所述的单一输入设备实例连接到所述单一输入设备；iv)使所述的处理服务器生成一第一输入设备控制实例并将所述的第一输入设备控制实例连接到所述的单一输入设备实例；v)使所述的处理服务器生成一个接口，通过该接口所述的客户应用程序与所述的单一输入设备实例进行通信；以及vi)响应来自请求到所述的单一输入设备的第二连接的第二应用程序的呼叫生成一个第二输入设备控制实例，并将所述的第二输入设备控制实例连接到所述的单一输入设备实例以生成一个接口，通过该接口所述的第二客户应用与所述的同一输入设备实例进行通信。
18.如权利要求17所述方法，其中所述的可执行输入设备控制程序是一个分布式组件对象模型(DCOM)可执行程序。
19.如权利要求17所述的方法，其中所述的处理进程是一个DCOM处理。
全文摘要
本发明组合了可执行进程与多应用程序共享一个单一的输入设备的需要，提供一个作为处理进程实现的可执行程序，允许多个应用与一个单一输入设备通信，这是通过装载该输入设备控制可执行程序作为一个处理进程实现的。该可执行程序是一个服务器允许多个应用程序与同一输入设备接口。该多实例输入设备控制(MIDC)可执行程序响应每个应用程序请求，如同该输入设备是对该呼叫应用程序开放一样。每个应用程序因此通过能与输入设备实例通信而不会干扰与该输入设备正在通信的其它应用程序的操作，该输入设备实例跟踪与其所有连接并多路复用和解决冲突请求。
文档编号G06F9/44GK1405680SQ0212332
公开日2003年3月26日 申请日期2002年6月17日 优先权日2001年6月15日
发明者阿龙·斯坦德韦特, 蒂姆·迪克曼 申请人:罗技欧洲公司