CN101344741A - 程序确定装置和程序确定方法 - Google Patents

Abstract

公开的程序确定装置包括：日志记录单元，其被配置用于响应于来自在成像装置中使用的程序的、对于所述成像装置的预定功能的使用的使用请求和由所述程序对所述成像装置的预定资源的消耗中的至少一个，记录使用请求和消耗中的所述至少一个的内容作为日志信息；以及确定单元，其被配置用于确定由所述程序请求的所述预定功能的使用和由所述程序对所述预定资源的消耗中的所述至少一个是否满足预定约束。

Description

程序确定装置和程序确定方法

技术领域

本发明通常涉及一种程序确定装置和一种程序确定方法，并且具体地涉及一种被配置用于确定成像装置的程序的程序确定装置和一种用于确定图像处理装置的程序的程序确定方法。

背景技术

这些年，被称为多功能机器或复合机器的一些成像装置能够在它们出货后使用了所发布的API(应用编程接口)来开发和安装新应用(例如，见日本专利特许公开号2005-269619)。在这样的成像装置中，不仅可以安装和使用由成像装置的厂商开发的应用，还可以安装和使用其它软件厂商开发的应用。

被施加在如这些成像装置的内置型设备上的资源使用限制比被施加在通用计算机上的资源使用限制更严格。因此，预先确定诸如应用的存储器消耗的资源使用上的限制，并且要求软件厂商设计能够在这种限制(在下文中被称为“资源限制”)下操作的应用。

同时，软件厂商希望提供更有用和更高性能的应用。通常，程序的性能越高，程序的存储器使用越高。如果软件厂商过多关注于对终端用户的可用性上，则不满足资源限制的应用可能被投放市场。

在多个应用被并行使用的情况下，即使每个应用都满足资源限制，但取决于用户使用应用的方式，成像装置的资源也可能被用完。

如果资源被耗尽，不保证应用正确地操作，这导致对终端用户的不便。此外，成像装置的厂商和开发应用的厂商需要调查出错的原因。

发明内容

基于前述，本发明目的在于提供一种程序确定装置、一种程序确定方法、和一种存储了确定程序能够减少由于程序造成的成像装置出错的风险的程序的计算机可读记录介质。

在本发明的实施例中，提供一种程序确定装置，包括：日志记录单元，其被配置用于响应于来自在成像装置中使用的程序的、对于所述成像装置的预定功能的使用的使用请求和由所述程序对所述成像装置的预定资源的消耗中的至少一个，记录使用请求和消耗中的所述至少一个的内容作为日志信息；以及确定单元，其被配置用于确定由所述程序请求的所述预定功能的使用和由所述程序对所述预定资源的消耗中的所述至少一个是否满足预定约束。

该程序确定装置可以减少成像装置由于该程序而出错的风险。

在本发明的另一实施例中，提供一种可由计算机执行的程序确定方法。该方法包括日志记录步骤，用于响应于来自在成像装置中使用的程序的、对于所述成像装置的预定功能的使用的使用请求和由所述程序对所述成像装置的预定资源的消耗中的至少一个，记录使用请求和消耗的所述至少一个的内容作为日志信息；以及确定步骤，用于确定由所述程序请求的所述预定功能的使用和由所述程序对所述预定资源的消耗中的所述至少一个是否满足预定约束。

根据本发明的一个方面，可以提供能够减少成像装置由于该程序而出错的风险的程序确定装置、程序确定方法和存储了程序确定程序的计算机可读记录介质。

附图说明

图1是说明本发明的实施例的概观的图；

图2是说明根据本发明的实施例的多功能机器的硬件配置的例子的方框图；

图3是说明根据本发明的实施例的多功能机器的软件配置的例子的方框图；

图4是说明应用束(application bundle)和服务束(service bundle)的状态转变模型的实现例子的图；

图5是说明请求路径控制单元的功能的方框图；

图6是说明暂时激活脚本和临时激活服务的图；

图7是说明根据第一个实施例的用于由多功能机器暂时激活的处理过程的顺序图；

图8是说明被存储在扫描应用的应用管理文件中的应用信息的例子的图；

图9是说明根据第一个实施例的主脚本的描述的例子的图；

图10是说明根据第一个实施例的场景脚本(scenario script)的描述的例子的图；

图11是说明扫描应用的操作屏幕的例子的图；

图12是说明根据本发明的第一个实施例的动作脚本的描述的例子的图；

图13是说明暂时激活日志的语法的例子的图；

图14是说明暂时激活日志的例子的图；

图15是说明由安全管理器使用以标识对象的生成器的方法的图。

图16是说明用于使用线程组来标识调用应用的名字的方法的图；

图17是示出了具有多个虚拟机的多功能机器的软件配置的例子的图；

图18A-18C是说明由(多个)应用造成的存储器消耗的图表；

图19是示出了根据第二个实施例的主脚本的描述的例子的图；

图20是说明SAS管理器如何管理被激活的应用的流程图；

图21是说明如何通过重新排列(restring)状态转变来适当地管理存储器使用的图表；

图22是说明根据第三个实施例的使用暂时激活进行故障分析的方法的图；以及

图23是说明根据第四个实施例的使用暂时激活进行故障分析的方法的图。

具体实施方式

图1是说明本发明的实施例的概观的图。根据本发明的该实施例，多功能机器10是成像装置的例子，其中应用可以被添加至该成像装置。在图1中，虽然在上边和下边示出两个多功能机器10，但是它们是在不同的时间点上的相同的多功能机器10。

根据该实施例，新安装到多功能机器10中的应用被暂时地激活(步骤S11)。暂时激活是激活应用以确定应用的资源使用和要由应用使用的多功能机器10的服务(功能)。指示要由应用使用的多功能机器10的服务的信息在下文中被称为应用操作信息。在该实施例中，暂时被激活的应用不能向用户提供应用的常规功能。在暂时激活期间，多功能机器10输出应用操作信息作为暂时激活日志(步骤S12)。在暂时激活完成之后，多功能机器10基于暂时激活日志来确定暂时激活是否成功(步骤S13)。如果暂时被激活的应用被确定以在预定的限制(在资源使用和要被使用的多功能机器10的服务上的限制)内操作，则暂时激活被确定为成功。如果暂时被激活的应用不在预定的限制内操作，则暂时激活被确定为已经故障。

如果暂时激活成功，应用被安装进多功能机器10中，并且允许应用的完全激活。因此，响应于来自用户的激活请求，完全地激活应用(步骤S14)。完全激活、暂时激活的反义词，用于激活应用以提供应用的常规功能。即，完全激活允许应用的正常使用。在完全激活应用时以及完全激活应用期间，多功能机器10基于暂时激活日志来控制应用的操作。例如，多功能机器10拒绝应用的激活，限制应用的激活的定时(timing)，控制应用的状态转变(处理的进行)，并且约束由应用对多功能机器10的服务的使用。

如以上所描述，多功能机器10预先暂时激活将被新增加至多功能机器10的应用(即，将被安装进多功能机器10的应用)，并且因此能够基于在暂时激活期间所获得的暂时激活日志来控制在完全激活期间的应用的操作。因此，可能限制如下应用的操作：该应用不满足诸如资源使用约束的对资源的预定约束，并且可以控制被并发(并行的)激活的各个应用对资源的使用的定时。

应用的暂时激活不需要由其中将完全激活应用的多功能机器10进行。例如，如图1所示，可以由通用计算机400进行暂时激活(步骤S11a)。在暂时激活期间，计算机400输出应用操作信息作为暂时激活日志(步骤S12a)。在完成暂时激活之后，计算机400基于暂时激活日志来确定暂时激活是否成功(步骤S13a)。如果暂时激活成功，应用可以被安装进多功能机器10中。

以下给出具体描述。图2是示出了根据本发明的实施例的多功能机器10的硬件配置的例子的图。在图2中，多功能机器10包括控制器201、操作面板202、传真控制单元(FCU)203、成像单元121和打印单元122。

控制单元201包括CPU 211、ASIC 212、NB 221、SB 222、MEM-P 231、MEM-C 232、HDD(硬盘驱动器)233、存储卡插槽234、NIC(网络接口控制器)241、USB设备242、IEEE1394设备243和Centronics设备244。

CPU 211是用于进行各种信息处理的IC。ASIC 212是用于进行各种图像处理的IC。NB 221是控制器201的北桥。SB 222是控制器201的南桥。MEM-P231是多功能机器10的系统存储器。MEM-C 232是多功能机器10的本地存储器。HDD 233是多功能机器10的存储单元。存储卡插槽234是存储卡235的插槽。NIC 241是用于基于MAC地址的网络通信的控制器。USB设备242用于提供遵守USB规范的连接端。IEEE 1394设备243用于提供遵守IEEE1394规范的连接端。并行接口设备244用于提供遵守并行接口规范的连接端。

操作面板202用作操作员通过其将输入键入到多功能机器10中的硬件单元(操作单元)，并且还用作操作员通过其获取多功能机器10的输出的硬件单元(显示单元)。

图3是示出了根据本发明的实施例的多功能机器10的软件配置的例子的图。在图3中，软件112包括JSDK应用30、JSDK平台40、请求路径控制单元50和本地服务层60。在存储卡235和其它存储单元中所存储的程序由CPU 211处理，以使这些软件组件操作。

本地服务层60用于向更高模块提供用于使用多功能机器10的硬件和软件的功能的接口，并且响应于对接口的调用(功能的使用的请求)，进行用于实现该功能的控制。例如，本地服务层60包括提供用于控制网络通信的接口的模块、提供用于控制传真功能的接口的模块、提供用于控制所存储的文档(被存储在HDD 233中的文档(图像)数据)的传输的接口的模块、用于控制成像单元121和打印单元122的接口、提供用于控制存储器(231和232)和HDD 233的接口的模块、提供用于控制操作面板202的接口的模块、提供用于控制验证和记帐的接口的模块，和提供用于管理用户信息的接口的模块。

JSDK 40平台是为JSDK应用30提供执行环境、并且提供Java(注册商标)接口给更高模块的软件平台。JSDK平台40包括标准Java类、用于被扩展用于多功能机器10的类的类库，和Java虚拟机。在图3中，示出安全管理器41和日志服务42作为JSDK平台40的组件的例子。

安全管理器41根据预先定义在策略文件中的访问控制信息来约束由JSDK应用30对诸如文件、网络套接字、和打印机的资源的访问。即，JSDK平台40被配置用于在收到访问资源的请求时向安全管理器41发出调用。安全管理器41响应于该调用来决定是否允许对资源的访问。在可替换的实施例中，可以使用标准的Java SecurityManager类来提供安全管理器41。

日志服务42在JSDK应用30的暂时激活期间输出暂时激活日志80。

JSDK平台40被实现为OSGi(开放服务网关初始)(Open Service Gatewayinitiative)平台。OSGI平台是由OSGi联盟标准化的技术、并且是提供用于基于Java语言使用开放软件组件技术所创建的软件组件的执行环境的软件平台。在OSGi平台上、以称为“束”的软件组件的格式实现用Java语言所编写的软件。单个JAR(Java档案)形成单个束。可以独立地和动态地(不需要重启机器)安装束。

JSDK应用30是使用在JSDK平台中所公开的专用SDK(软件开发工具包)来开发的应用(在下文中被称为“SDK应用”)。使用Java语言所开发的SDK应用被称为JSDK应用。在该实施例中，进行JSDK应用的暂时激活。

在图3中，示出SAS(SDK应用服务)管理器31、应用束32和服务束33作为JSDK应用30的例子。SAS管理器31控制其它JSDK应用(应用束32和服务束33)的安装(增加)、卸载(删除)、激活和激活的终止。

应用束32是导致操作屏幕被显示在操作面板202上并且由终端用户通过操作屏幕直接使用(操作)的JSDK应用30的束。在图3中，示出扫描应用321作为应用束32的例子。扫描应用321被配置用于使用成像单元121来读文档的图像。

服务束33是向应用束32等提供服务的JSDK应用30的束。即，服务束33响应于来自应用束32等的调用来执行对应于各个束的操作，并且向应用束32等传输处理结果。在图3中，示出扫描服务331、面板服务332和暂时激活服务333作为服务束33的例子。

扫描服务331提供关于图像读功能的服务。面板服务332提供关于操作面板202的显示控制的服务。暂时激活服务333提供用于基于暂时激活脚本70的描述来控制暂时激活的服务。在下面更为详细地描述暂时激活脚本70。

在该实施例中，诸如应用束32和服务束33的应用根据状态转变模型来操作，在该状态转变模型中，状态从初始状态(init state)转移(即，处理进行)至暂停状态(pause state)、至活跃状态(active state)，并且然后至销毁状态(destroy state)。初始状态是进行初始处理的初始的状态。应用在激活后首先立即移动至初始状态。暂停状态是等状态。在暂停状态中，应用等待称为可执行的。活跃状态是进行应用的常规功能的状态。销毁状态是终止状态。将被终止的应用移动至销毁状态，在该销毁状态中应用在进行终止处理(如释放资源)后被终止。

为了实现这样的状态转变模型，如以下所描述地配置应用束32和服务束33。图4是示出了应用束32和服务束33的状态转变模型的实现例子的图。如图4所示，应用束32和服务束33(结合图4的以下描述中被称为“应用束32等”)包括对应于每个状态的实例化的对象。即，初始状态对象341、暂停状态对象342、活跃状态对象343和销毁状态对象344被分别实例化对应于初始状态、暂停状态、活跃状态和销毁状态。

响应于导致状态转变的事件(消息)，应用束34等将处理的控制(应用的控制)从当前对象移动至下一个对象。例如，处理控制从初始状态对象341移动至暂停状态对象342。这样的控制的转变实现了状态转变。

注意虽然应用束32等根据状态转变模型而操作，但这不意味着为了应用本发明的实施例，需要根据特定状态转变模型来实现应用。

请求路径控制单元50监视从JSDK应用30发布至本地服务层60的请求(用于预定功能的使用的请求)，并且取决于发布请求的JSDK应用30是否被暂时激活来控制请求的传输路径。如果JSDK应用30被暂时激活，请求被传输至暂时激活服务333。如果JSDK应用30没有被暂时激活(即，JSDK应用30被完全激活)，请求被传输于本地服务层60。

图5是说明了请求路径控制单元50的功能的方框图。在图5中，用相同的附图标记来指示如在图3中示出的同样的元件。在图5中，应用A 322是被完全激活的应用束32。应用B 323是被暂时激活的应用束32。如图5所示，请求路径控制单元50允许从完全激活的应用A 322发出、经由JSDK平台40的对本地服务层60的调用通过(步骤S21)。在这种情况下，多功能机器10实际地在本地服务层60的控制下操作。

另一方面，请求路径控制单元50将从被暂时激活的应用B 323发出的调用经由JSDK平台40传输至被暂时激活的服务333而不是至本地服务层60(步骤S22)。在这种情况下，暂时激活服务333用作本地服务层60，并且以与本地服务层60所使用的格式相同的格式将指示结果的响应传输至应用B323。因此，对应用B 323来说好像已经成功调用了本地服务层60并且已经进行了功能。以此方式，在暂时激活期间，请求路径控制单元50防止本地服务层60及其更低组件运作(即，防止多功能机器10实际地操作)以便检测JSDK应用30。

在以下更详细地描述暂时激活脚本70和暂时激活服务333。图6是说明暂时激活脚本70和暂时激活服务333的图。

如图6所示，暂时激活脚本70包括三个文件，即，主脚本71、场景脚本(scenario script)72和动作脚本73。主脚本71定义用于标识场景脚本72和动作脚本73的信息以被用于暂时激活，和用于确定暂时激活是否成功的标准。场景脚本72定义暂时激活的场景。场景是用于使用操作面板202操作被暂时激活的应用的过程。动作脚本73定义本地服务层60响应于由请求路径控制单元50传输至暂时激活服务333的调用的动作(模拟(emulation)的内容)。

由暂时激活服务333解释主脚本71。因此，暂时激活服务333根据主脚本来控制暂时激活。暂时激活服务333生成用于解释场景脚本72的线程(场景服务334)和用于解释动作脚本73的线程(动作服务335)。

场景服务334运作为根据场景脚本72键入用于被暂时激活的应用的操作指令的伪操作员。从应用至本地服务层60的调用(该调用根据场景服务334的操作指令而生成)由请求路径控制单元50传输至动作服务335。动作服务335根据动作脚本73的定义，响应于所传输的调用来进行模拟，并且发送与由本地服务层60所使用的格式相同的格式的指示结果的响应。因为所传输的响应的格式与本地服务层60所使用的格式相同，对应用来说好像已经调用了本地服务层60。

在以下描述由多功能机器10进行的处理过程。图7是说明根据第一个实施例的用于由多功能机器10暂时激活的处理过程的顺序图。

当请求应用的安装时，SAS管理器31搜索多功能机器10的存储卡插槽234中的SD卡中所存储的应用管理文件，并且从SD卡获得所有被检测到的应用管理文件(步骤S101)。每个应用管理文件存储了关于相应的应用的组件的信息、安装所必要的信息、以及其它管理信息(在下文中被称为“应用信息”)。应用管理文件被附于它们对应的应用。即，如果多个JSDK应用30被存储在SD卡中，则获得多个应用管理文件。

图8是示出了被存储在扫描应用321的应用管理文件中的应用信息的例子的图。以基于XML(可扩展标记语言)的JNLP(Java网络发起协议(JavaNetwork Launch Protocol)(JSR-56))的扩展格式来表述在图8中所示出的应用信息410。

应用信息410包括由<information>标签包围(enclose)的信息元素411、由<resources>标签包围的资源元素412、由<pseudo-boot>标签包围的伪启动(pseudo-boot)元素413，和由<xlet-desc>标签包围的xlet-desc元素414。

信息元素411包括用于标识应用(扫描应用321)的信息。例如，产品id元素4111包括扫描应用321的产品ID。标题元素4112包括扫描应用321的标题(应用名)。厂商元素4113包括开发了扫描应用321的厂商的名字。

资源元素412包括关于用于执行扫描应用321必要的资源的信息。例如，jar元素的href属性的值指定了扫描应用321的JAR文件的文件名(路径名)。

伪启动元素413定义了关于暂时激活的信息。例如，伪启动元素413的触发器(trigger)属性4131的值指定了执行暂时激活的定时。在图8的例子中，触发器属性4131的值是“安装”，指示在扫描应用321的安装时进行暂时激活。平台属性4132的值指定了在其上进行暂时激活的平台。在图8的例子中，平台属性4132的值是“相同”，指示在与进行完全激活的平台相同的平台上进行暂时激活。pb元素4133的href属性的值指定了扫描应用321的暂时激活脚本70的主脚本71的文件名(“ScanApp.pb”)。注意伪启动元素413被包括需要在暂时激活的情况中。因此，能够基于是否包括了伪启动元素413来确定进行暂时激活的必要性。

xlet-desc元素414的可见属性4141的值指定了扫描应用321是否在操作面板202上进行屏幕显示。在图8的例子中，可见属性4141的值是“可见”，指示扫描应用321进行屏幕显示。

当图8示出扫描应用321的应用信息的例子时，以与扫描应用321的应用信息的格式相同的格式定义其它应用的应用信息。

接着，SAS管理器31基于所获得的应用管理文件来确定哪个应用可安装在多功能机器10中，并且使得操作面板202示出可安装的应用的列表(例如，可安装的应用的名字的列表)(步骤S102和S103)。

操作员从在操作面板202上所示的应用的列表中选择将被安装的应用。在该例子中，选择扫描应用321。当选择扫描应用321时，用于开始扫描应用321的安装的请求被传输至SAS管理器31(步骤S104)。

响应于用于开始安装的请求，SAS管理器31根据扫描应用321的应用管理文件(应用信息410)来请求JSDK平台安装扫描应用321(步骤S105)。JSDK平台40安装扫描应用321作为束(步骤S106)。

然后，SAS管理器31确定在应用信息410中是否包括用于暂时激活的指令(伪启动元素413)。如果包括了用于暂时激活的指令，SAS管理器31开始扫描应用321的暂时激活(步骤S107)。如果暂时激活服务333没有被激活，SAS管理器31开始暂时激活服务333的激活(步骤S108)。首先，SAS管理器31请求JSDK平台40安装暂时激活服务333(步骤S109)，并且JSDK平台安装暂时激活服务333(步骤S110)。然后SAS管理器31请求JSDK平台40激活暂时激活服务333(步骤S111)，致使JSDK平台激活暂时激活服务333(步骤112)。

当暂时激活服务333被激活时，暂时激活服务333注册关于暂时激活服务333能够在JSDK平台40中提供的服务的接口信息段(piece)(步骤S113)。暂时激活服务333从JSDK平台40获得请求路径控制单元50的接口信息段(步骤S114)。在该例子中，接口信息段指示用于调用请求路径控制单元50必要的信息。注意，当例如开始多功能机器10时，激活请求路径控制单元50。此时，请求路径控制单元50的接口信息段被注册进JSDK平台40中。

SAS管理器31从JSDK平台40获得暂时激活服务333的接口信息段(步骤S115)。SAS管理器31涉及应用信息410的pb元素4133以获得对应于在pb元素4133中所指定的文件名(“ScanApp.pb”)的主脚本71。SAS管理器31将主脚本71和扫描应用321的应用名传输至暂时激活服务333，从而请求暂时激活服务333以控制扫描应用321的暂时激活(步骤S116)。

图9是示出了根据第一个实施例的主脚本71的描述的例子的图。以下结合步骤来描述在主脚本71中所包括的描述，在这些步骤中执行该描述。在该实施例中，主脚本71、场景脚本72，和动作脚本73被存储在存储了相应的应用的SD卡中。

暂时激活服务333向请求路径控制单元50传输要被暂时激活的扫描应用321的应用名，并且请求该请求路径控制单元50向暂时激活服务333传输来自扫描应用321的用于对本地服务层60的调用的请求(消息)(步骤S117)。请求路径控制单元50保留步骤S117中所传输的应用名以标识要被暂时激活的应用。

暂时激活服务333执行主脚本71的描述711。描述711定义使用具有文件名“ScanApp.s”的场景脚本72和具有文件名“ScanApp.b”的动作脚本73来进行暂时激活。因此，暂时激活服务333激活(生成)场景服务334并且传输场景脚本72(ScanApp.s)至场景服务334(步骤S 118)。另外，暂时激活服务333激活(生成)动作服务335并且传输动作脚本73(ScanApp.b)至动作服务335(步骤S119)。

图10是示出了根据第一个实施例的场景脚本71的描述的例子的图。在图10中示出的场景脚本72定义：如果从显示扫描应用321的操作屏幕并且在操作屏幕上显示字符串“完成”起的3秒后按下开始按钮，则确定根据场景要进行的操作。该定义是以下所描述被配置的扫描应用321的操作屏幕的前提。

图11是示出了扫描应用321的操作屏幕的例子的图。图11示出了操作屏幕的两个例子。当扫描应用321处于初始状态时(在显示操作屏幕后紧接着)，显示在左边的操作屏幕510a。当成功地完成扫描应用321时，显示左边的操作屏幕510b。在以下描述中，当没有需要区分它们时，操作屏幕510a和510b被称为“操作屏幕510”。

在该实施例中，操作屏幕510包括指示将被激活的应用是扫描应用321的标签511、开始按钮512，和结果标签513。开始按钮512由用户使用以键入用于开始扫描应用321的执行的指令。结果标签513被配置用于显示扫描应用321的处理结果。如果成功地完成扫描应用321(如果扫描是成功的)，如在操作屏幕510b中示出地显示字符串“完成”。如果非正常地终止扫描应用321(如果扫描故障)，则显示例如“错误”的字符串。注意，如在操作屏幕510a中所示，结果标签513当扫描应用321处于初始状态时什么也不显示。

图12是示出了根据第一个实施例的动作脚本73的描述的例子的图。动作脚本73的描述不是在特定步骤中所执行的定义，而是动作服务335的设置信息段。描述731定义扮演(模拟)好像响应于关于扫描服务(在本地服务层60中提供关于扫描仪(成像单元121)的服务的模块)的请求而成功地进行了操作。描述732定义扮演(模拟)好像响应于关于面板服务(在本地服务层60中提供关于操作面板202的服务的模块)的请求而成功地进行操作。

SAS管理器31请求JSDK平台40以激活扫描应用321(步骤S 120)。由暂时激活服务333暂时地激活扫描应用321。响应于用于激活扫描应用321的请求，JSDK平台40转移扫描应用321的状态至初始状态，并且向日志服务42传输指示扫描应用321已经被移动至初始状态的信息(步骤S121)。日志服务42在暂时激活日志80中记录所传输的信息。

根据例如以下所描述的语法，将暂时激活日志80写在文件中。图13是说明暂时激活日志80的语法的例子的图。在图13中，以树格式来编写暂时激活日志的语法的单个行(单个记录)。树的每个节点是组成暂时激活日志80的项。

如图13所示，暂时激活日志80包括作为第一项的编号、作为第二项的日期、作为第三项的时间，和作为第四项的应用名。编号指示日志条目的所记录的次序。日期和时间指示日志条目何时被记录。应用名指示被暂时激活的应用的名字。应用名可以由产品ID代替。作为第五项，包括日志条目的所记录的内容的类型。作为类型，记录“Bundle(束)”、“Memory(存储器)”、“Scan(扫描)”、“panel(面板)”，或“hdd”。

“Bundle”指示日志条目关于束(应用)的状态转变。在这种情况下，在转变之后的束的状态(例如，“initState”或“activeState”)被记录作为第六项。“initState”指示了初始状态。“activeState”指示活跃状态。

“Memory”指示日志条目关于保留或释放存储器空间。在这种情况下，作为第六项，以“Heap＝<Size>”的格式记录应用的堆存储器的总使用。作为第七项，以“Stack＝<Size>”的格式记录应用的栈区域的总使用。作为第八项，例如“Object”被记录作为用于新保留的存储器的项的类型。“Object”指示对象。作为第九项，“Object”被记录作为用于新保留的存储器的项的类型或类名。虽然在图13中“Heap”、“Stack”，和“Object”好像具有图13中的选择性的关系，但是如以上所描述地，连续地记录这些项。

“Scan”指示日志条目关于扫描仪(成像单元121)的操作。在这种情况下，关于扫描仪的操作的类型(例如，“setup”、“start”或“complete”)被记录作为第六项。“setup”指示设置扫描仪。“start”指示开始扫描。“complete”指示扫描是成功的。在“setup”的情况下，指示属性设置的值(“attribute(属性)”)被记录作为第七项；并且指示单色扫描的值(“mono(单色)”)或指示彩色扫描的值(“color(彩色)”)被记录作为第八项。

“Panel”指示日志条目关于操作面板202的操作。在这种情况下，操作面板202的操作的类型(例如，“show(示出)”)被记录作为第六项。“show”指示操作面板202上显示信息(屏幕、消息等)。

“hdd”指示日志条目关于HDD 233的操作。在这种情况下，操作的类型(例如，“read(读)”或“write(写)”)被记录作为第六项。“read”指示读信息。“write”指示写信息。

图14是说明暂时激活日志80的例子的图。在图14所示的例子中，根据图13中所示的语法来写暂时激活日志80。以CSV(逗号分隔值(CommaSeparated Values))格式描述图14的暂时激活日志80。在图14中，第一行是响应于步骤S 121中所传输的信息所记录的日志条目的例子。在第一行的日志条目中，“0001”指示编号；“2007.05.10”指示日期；“11:30:24:04”指示时间；以及“ScanApp”指示扫描应用321的应用名。此外，第五项是“Bundle”，以及第六项是“initState”。即，第一行的日志条目指示扫描应用321被移动至初始状态。

返回参考图7，在步骤S121后，响应于用于激活扫描应用321的请求，JSDK平台40将扫描应用321转移至活跃状态，并且将指示扫描应用321已经被移动至活跃状态的信息传输至日志服务42(步骤S122)。日志服务42记录所传输的信息作为在暂时激活日志80中的日志条目。在步骤S 122中所记录的日志条目对应于图14的暂时激活日志80的第二行。出于简化说明的目的，省略扫描应用321至暂停状态的转变。

然后JSDK平台40激活扫描应用321的束(步骤S123)。当被激活时，扫描应用321从JSDK平台40获得将由扫描应用321使用的服务束33的接口信息段(步骤S124)。在该例子中，获得扫描服务331和面板服务332的接口信息段。注意，当例如开始多功能机器10时，扫描服务331和面板服务332被激活。此时，扫描服务331和面板服务332的接口信息段被注册进JSDK平台40。

然后扫描应用321根据扫描服务331的接口信息段生成用于使用扫描服务331必要的、扫描服务331的对象(ScanService类的实例)。确切地，在接下来的处理中，经由该对象来进行从扫描应用321至扫描服务331的请求的传输。由安全管理器41对诸如扫描服务331的服务束33的对象的生成施加访问控制。因此，指示扫描服务331的对象的生成的信息在对象的构造器中被传输至安全管理器41(步骤S125)。收到了该信息，安全管理器41标识生成了该对象的生成器(扫描应用321)的类名，并且向日志服务42传输指示扫描应用321的存储器的消耗以及对象的类名和大小的信息(步骤S 126)。可以基于类名确定对象的大小。在以下给出关于安全管理器41如何标识生成了对象的生成器的详细描述。

日志服务42在暂时激活日志80中记录传输信息作为的日志条目。在该步骤中所记录的日志条目对应于图14的暂时激活日志80的第三行。在图14的暂时激活日志80的第三行，记录“Memory，Heap＝2MB，Stack＝100KB，Object，ScanService＝1MB”。这指示扫描应用321的堆存储器的当前总使用是2MB；栈区域的总使用是100KB；已经生成了ScanService类的对象；并且对象的大小是1MB。

然后扫描应用321基于扫描服务331的接口信息段，进行扫描服务331的初始设置，用于构造对应于应用321的动作(即，用于单色扫描的初始设置)的扫描处理(步骤S127)。扫描服务331尝试将来自扫描应用321的初始设置请求经由请求路径控制单元50传输至本地服务层60(步骤S128)。然而，因为作为初始设置请求的起源的扫描应用321被暂时激活，因此请求路径控制单元50将初始设置请求不传输至本地服务层60而是传输至动作服务335(步骤S129)。在以下给出关于请求路径控制单元50如何确定调用应用(在该例中，初始设置请求的起源)被暂时激活的详细描述。

动作服务335模拟扫描仪的初始设置，并且将处理结果经由请求路径控制单元50传输至请求的起源(扫描应用321)。在该步骤中，根据在动作脚本73的描述731中定义的设置，传输指示成功地进行了初始设置的信息。因此，扫描应用321确定成功地进行用于扫描的初始设置。如果扫描应用321没有被暂时激活(即，如果扫描应用321被完全激活)，被传输至请求路径控制单元50的请求被传输至本地服务层60，以便实际地进行初始设置。

然后动作服务335向日志服务42传输指示请求了用于单元扫描的初始设置的信息(步骤S130)。日志服务42在暂时激活日志80中记录所传输的信息作为日志条目。在该步骤中所记录的日志条目对应于图14的暂时激活日志80的第四行。并且，动作服务335向场景服务334传输指示用于单色扫描的初始设置的完成(模拟)的信息。场景服务334是用作应用的伪操作员的服务，并且因此场景脚本334不能运作直到在操作面板202上显示应用的操作屏幕510a。场景服务334因此并不开始场景脚本72的定义的执行并且忽略来自动作服务335的信息直到报告了在操作面板202上绘制(显示)操作屏幕510a的完成。

由动作服务335向日志服务42和场景服务334的信息的传输是根据先前被合并在动作服务335中的逻辑所进行的操作(并且不是基于动作脚本73所进行的操作)。即，动作服务335被配置用于当收到其路径被请求路径控制单元50改变的服务请求时，将指示服务请求的接收的信息传输至日志服务42，并且响应于服务请求，还将由动作服务335进行的模拟的结果传输至场景服务334。

然后扫描应用321根据面板服务332的接口信息段，来生成用于使用面板服务332所必要的面板服务332的对象(PanelService类的实例)。确切地，在以下处理中，经由该对象进行从扫描应用321至面板服务332的请求的传输。指示面板服务332的对象的生成的信息在对象的构造器中被传输至安全管理器41(步骤S 132)。收到了信息，安全管理器41标识生成了对象的生成器(扫描应用321)的类名，并且向日志服务42传输指示扫描应用321的存储器的消耗以及对象的类名和大小的信息(步骤S133)。日志服务42在暂时激活日志80中记录所传输的信息作为日志条目。该步骤中所记录的日志条目对应于图14的暂时激活日志80的第五行。在图14的暂时激活日志80的第五行中，记录“Memory，Heap＝3MB，Stack＝300KB，Object，PanelService＝1MB”。这指示扫描应用321的堆存储器的当前总使用是3MB；栈区域的总使用是300KB；已经生成PanelService类的对象；并且对象的大小是1MB。

然后扫描应用321基于面板服务332的接口信息段，向面板服务332传输用于在操作面板202上绘制扫描应用321的操作屏幕510a的请求(步骤S134)。

面板服务332构造(生成)将被传输至本地服务层的屏幕信息，以在操作面板202上绘制扫描应用321的操作屏幕510a，并且尝试经由请求路径控制单元50向本地服务层60传输用于基于屏幕信息而绘制操作屏幕510a的请求(步骤S135)。然而，因为作为用于绘制操作屏幕510a的请求的起源的扫描应用321被暂时激活，请求路径控制单元50不向本地服务层60而是向动作服务335传输绘制请求以及屏幕信息(步骤S136)。

动作服务335模拟基于屏幕信息来绘制操作屏幕510a。结果，操作屏幕510a虚拟地被绘制。属于“虚拟地”指示实际上没有在操作面板202显示操作屏幕510a。然而，在动作服务335中保留操作屏幕510a的屏幕信息。动作服务335经由请求路径控制单元50向请求的起源传输绘制操作屏幕510a的模拟的结果(扫描应用321)。在该步骤中，根据在动作脚本73的描述732中定义的设置，传输指示成功地进行了绘制的信息。

然后动作服务335向日志服务42传输指示请求了绘制操作屏幕510a的信息(步骤S137)。日志服务42在暂时激活日志80中记录所传输的信息作为日志条目。在该步骤中所记录的日志条目对应于图14的暂时激活日志80的第六行。而且，动作服务335将指示绘制操作屏幕510a的完成(模拟)的信息传输至场景服务334(步骤S138)。

收到了指示绘制操作屏幕510a的完成的信息，场景服务334开始对应于场景脚本72的定义的处理。首先，基于图10的描述721，获得操作屏幕510a(图11)的开始按钮512的对象(在下文被称为“开始按钮对象”)。开始按钮对象是组成操作屏幕510的屏幕信息的对象组的对象，并且由动作服务335响应于对描述721中所描述的函数的调用而获得。自从显示操作屏幕510a，经过由在描述722中被描述的函数的变元(argument)指定的预定的时间周期(三秒)之后，指示按下开始按钮512的消息基于描述723被传输至请求路径控制单元50(步骤S139)。注意为了制作与用户的输入的实际条目相似的场景服务334的输入的伪条目，在自从显示操作屏幕510a的三秒后进行指示按下开始按钮512的消息的传输。即，因为实际用户并不在显示操作屏幕510a后立即按开始按钮512，而是在大概自从显示操作屏幕510a的三秒后按下开始按钮512。

然后场景服务334基于场景脚本72的描述742获得屏幕510的Result标签513的对象(在下文中被称为“Result标签对象”)。Result标签对象是组成操作屏幕510的屏幕信息的对象组的对象，并且由动作服务335响应于对描述724中所描述的函数的调用而获得。

然后，基于场景脚本72的描述725，场景服务334被置为写状态，以等待Result标签513被更新。因此，在该阶段没有被进行遵循描述726的处理。

同时，在步骤S139中从场景服务334收到了指示按下开始按钮512的消息，请求路径控制单元50传输消息至面板服务332(步骤S140)。

收到了指示按下开始按钮512的消息，面板服务332将指示按下开始按钮512的信息传输至扫描应用321(步骤S141)。收到了指示按下开始按钮512的消息，扫描应用321请求扫描服务331开始扫描(步骤S142)。开始服务331尝试从扫描应用321经由请求路径控制单元50传输扫描开始请求至本地服务层60(步骤S143)。然而，因为作为扫描开始请求的起源的扫描应用321被暂时激活，因此请求路径控制单元50不向本地服务层60而是向动作服务335传输扫描开始请求(步骤S144)。

然后动作服务335将指示请求了开始扫描的信息传输至日志服务42(步骤S145)。日志服务42在暂时激活日志80中记录所传输的信息作为日志条目。在该步骤中所记录的日志条目对应于图14的暂时激活日志的第七行。而且，动作服务335将指示要开始扫描的信息传输至场景服务334(步骤S146)。因为场景服务334处于等待状态以等待Result标签513被更新，所以场景服务334不进行操作。

然后动作服务335模拟扫描，并且传输处理结果至请求路径控制单元50(步骤S147)。在步骤S147中，根据在动作脚本73的描述731中所定义的设置，传输指示成功地进行(完成)了扫描的消息。而且，动作服务335传输指示扫描的成功完成的信息至日志服务42和场景服务334(步骤S148、S149)。日志服务42在暂时激活日志80中记录所传输的信息作为日志条目。在该步骤中所记录的日志对应于图14的暂时激活日志80的第八行。收到了指示扫描的成功完成的信息，因为场景服务334处于等待状态以等待Result标签513的被更新，所以场景服务334不进行操作。

同时，在步骤147中从动作服务335收到了指示扫描的成功完成的消息，请求路径控制单元50传输消息至扫描服务331(步骤150)。扫描服务331传输指示扫描的成功完成的信息至扫描开始请求的起源，也就是扫描应用321(步骤S151)。

收到了指示扫描的成功完成的信息，扫描应用321请求面板服务332在操作屏幕510的Result标签513上显示字符串“完成”(步骤S152)。响应于来自扫描应用321的请求，面板服务332尝试经由请求路径控制单元50传输用于显示字条串“完成”的请求至本地服务层60(步骤S153)。然而，因为作为用于显示字符串“完成”的请求的起源的扫描服务321被暂时激活，因此请求路径控制单元50没有向本地服务层60而是向动作服务335传输用于显示字符串“完成”的请求(步骤S154)。

动作服务335虚拟地在Result标签513上显示“完成”。更具体地，动作服务335向在保持的屏幕信息中的Result标签对象指定字符串“完成”，因此模拟了显示字符串“完成”的处理。动作服务335经由请求路径控制单元50传输模拟的结果至请求的起源(扫描应用321)。在该步骤中，根据动作脚本73的描述732中定义的设置，传输指示成功地显示字符串“完成”的信息。

然后动作服务335将指示请求了更新操作屏幕的信息传输至日志服务42(步骤S155)。日志服务42在暂时激活日志80中记录所传输的信息作为日志条目。在该步骤中所记录的日志条目对应于图14的暂时激活日志80的第九行。而且，动作服务335将指示字符串“完成”被显示在Result标签513上的信息传输至场景服务334(步骤S156)。

收到了信息，场景服务334从等待Result标签513被更新的等待状态移回，并且根据场景脚本的描述726来确定在Result标签513上所显示的字符串是否是“完成”(图10)。如果在Result标签513上所显示的字符串是“完成”，场景服务334根据描述727向暂时激活服务333传输指示被暂时激活的应用根据场景(场景的成功)来操作的信息(步骤S157)。另一方面，如果在Result标签513上所显示的字符串不是“完成”，场景服务334根据描述728向暂时激活服务333传输指示被暂时激活的应用不根据场景(场景的故障)来操作的信息。

收到了指示场景的成功的信息，暂时激活服务333根据主脚本71(图9)的描述712请求日志服务42搜索具有名称“ScanApp”的应用(扫描服务321)的暂时激活日志(步骤S158)。日志服务42基于应用名在暂时激活日志80中搜索扫描应用321的暂时激活日志，并且将搜索结果传输至暂时激活服务333(步骤S159)。在图14中所示的例子中，暂时激活日志80只包括扫描应用321的日志信息。因此，在图14中所示的第一行至第九行中的内容被传输至暂时激活服务333。

然后，根据主脚本(图9)的描述713，暂时激活服务333确定暂时激活是否成功。扫描713定义了成功的暂时激活的条件，该条件是：存储器使用少于5MB；没有数据被写入HDD 233；并且扫描模式是单色。因此，暂时激活服务333在指示在暂时激活日志80中以格式“Memory，Heap＝xxxMB”所写的堆存储器的使用的日志中搜索最大值，并且确定所检测的最大值是否等于或小于5MB。而且，暂时激活服务333在暂时激活日志80中搜索如“hdd，wirte”的描述以确定数据是否被写入HDD 233。此外，暂时激活服务333在暂时激活日志80中搜索如“Scan，setup，attribute，mono”的描述以确定扫描模式是否是单色。

根据该实施例的暂时激活日志80，如第三行中所写，堆存储器的使用的最大值是3MB，小于5MB。没有如“hdd，write”的描述。这指示没有数据被写入HDD 233。描述“Scan，setup，attribute，mono”被包括在第四行中。这指示扫描模式是单色。即，满足成功的暂时激活的条件。因此，根据主脚本71的描述714，暂时激活服务333传输指示成功的暂时激活的信息至SAS管理器31(步骤S160)。

收到了指示成功的暂时激活的信息，SAS管理器31请求JSDK平台40终止被暂时激活的扫描应用321(步骤S161)。JSDK平台40将扫描应用321将被移动至销毁状态的信息传输至日志服务42(步骤S162)。日志服务42在暂时激活日志80中记录所传输的信息作为日志条目。在该步骤中所记录的日志条目对应于图14的暂时激活日志80的第十行。然后JSDK平台40终止扫描应用321(步骤S163)。

同时，在步骤S161中请求扫描应用321的终止之后，SAS管理器31使得操作面板202显示扫描应用321的安装的完成的指示(步骤S164)。该指示让操作员知道扫描应用321被成功地安装(步骤S165)。然后，为了使用扫描应用321，操作员使用操作面板202键入用于完全激活扫描应用321的指令(步骤S166)。用于完全激活扫描应用321的指令被传输至SAS管理器31(步骤S167)。SAS管理器31请求JSDK平台40以完全地激活扫描应用321(步骤S168)。然后JSDK平台40完全地激活扫描应用321(步骤S169)。

来自被完全激活的扫描应用321的请求被传输至本地服务层60，而请求的路径没有被请求路径控制单元50改变。因此，实际地显示了操作屏幕，并且响应于操作员在操作屏幕上输入的条目，实际地进行扫描。

如果暂时激活故障，(例如，如果被暂时激活的扫描应用321没有根据场景操作，或者如果没有满足成功的暂时激活的条件(在主脚本71的描述713中)，暂时激活服务333根据主脚本71(图9)的描述715在步骤S160中传输指示暂时激活的故障的信息至SAS管理器31。收到了信息，SAS管理器31使得操作面板202显示指示扫描应用321的安装已经故障的指示，并且禁用扫描应用321的安装。从而，操作员不能完全激活(即，不能实际地使用)扫描应用321。

在以下给出关于安全管理器41在步骤S126等中如何标识对象的生成器的详细描述。图15是说明由安全管理器41使用以标识对象的生成器的方法的图。在图15中所示的例子中，扫描应用321生成扫描服务331的对象。即，在图15中所示的处理对应于图7的步骤S125和S126。

在图15中，“ScanApp”代表扫描应用321的类名；“ScanService”代表扫描服务331的类名；“a：ScanApp”代表ScanApp类的对象a(即，被实例化的扫描应用321)；以及“b：ScanService”代表ScanService类的对象b(即，被实例化的扫描服务331)。

当对象a调用ScanService类的构造器以生成对象b时(步骤S21)时，类名(“ScanApp”)被存储在栈中(步骤S22)。当对象b在构造器中调用安全管理器41时(步骤S23)，对象b的类名(“ScanService”)被存储在栈中(步骤S24)。响应于来自对象b的调用，安全管理器41在栈中追踪数据，从而标识调用应用的类名是“ScanApp”，即，对象b的生成器是扫描应用321(步骤S25)。

接着，在以下描述关于请求路径控制单元50在步骤S129等中如何确定调用本地服务层60的请求的起源是否被暂时激活的详细描述。首先，前提是在请求路径控制单元50中注册将被暂时激活的应用(例如，步骤S116)。因此，如果可以在请求路径控制单元50中标识调用请求的起源的应用名，则可以确定应用是否被暂时激活。

在该实施例中，应用束32作为JSDK应用30被暂时激活。JSDK应用30是Java应用。因此，例如，可以使用线程组(ThreadGroup)作为标准Java类来标识应用。线程组指示一个线程(Thread)或线程的组。一个或多个线程可以与ThreadGroup相关联。可以给线程组名字(线程组名)。在每个线程中，可以标识当前线程所属的线程组。在该实施例中，应用束32和服务束33被实现作为“束”。在这里使用的术语“束”指示可以动态链接的库(函数或类的集合)。请求路径控制单元50也是库(函数或类的集合)。因此，它们中没有被激活作为进程的。所调用的一方(party)在调用应用的线程上操作。

基于该机制，请求路径控制单元50如以下所描述可以标识调用应用的名字。图16是说明用于使用线程组来标识调用应用的名字的方法的图。在图16中，为了解释的目的，模块之间的层次关系与图3中所示的层次关系不同。

在图16中，GPx(x指示a-c)指示线程组，以及thx(x指示a-d)指示线程。在图16的例子中，扫描应用321与线程组GPb相关联，扫描应用321的应用名被给予该线程组GPb作为线程组的名字。扫描服务333与线程组GPc相关联。

扫描应用321包括执行方法A的线程tha和执行方法B的线程thb。线程tha和线程thb属于线程组GPb。例如，如果从扫描应用321的方法B调用扫描服务331的方法C，方法C在线程thb上操作。此外，如果从方法C调用请求路径控制单元50的函数D，函数D在线程thb上操作。因此，线程thb被标识为函数D中的当前线程，并且线程组GPb被标识为线程thb所属于的线程组。从而，通过获得线程组GPb的线程组名来获得调用函数B的应用的名字(即，请求路径控制单元50)。此外，所获得的应用名(线程组名)与被暂时激活的应用的先前所注册的名字比较，从而确定调用函数B的应用是否被暂时激活。

线程组不是必要地被用于标识调用应用。例如，可以通过每个方法或函数的变元来接替调用应用的名字。

如以上所描述的，根据第一实施例的多功能机器10，在实际地使用应用之前，暂时激活应用，并且记录关于该操作的日志(暂时激活日志80)。然后，可以基于暂时激活日志80确定应用是否满足预定约束。因此，可以防止不满足预定约束的应用操作并且因此减少由于应用而导致的出错的风险。

在暂时激活脚本70(主脚本71、场景脚本72，和动作脚本73)中定义用于确定暂时激活是否是成功的标准、被暂时激活的应用的操作，以及在暂时激活期间动作服务335的动作，作为与程序分开的文件。因此，能够根据每个应用和多功能机器10的资源中的改变(例如，增加存储器)来容易地修改这些信息段(确定标准、操作、动作等)。具体地，如果在该实施例中以文本文件的格式描述信息段，则能够更容易地修改信息段。

动作服务335如本地服务层60一样响应(即，以与本地服务层相同的方式响应)应用，以便应用不需要知道被暂时激活。因此，不需要实现特别用于暂时激活目的的应用。

能够暂时激活不满足预定的约束的应用。因此，在一个应用被暂时激活同时另一个应用被完全激活的情况下，被完全激活的应用的操作的处理可能由于被暂时激活的应用对被完全激活的应用的消极作用(如存储器不足)而被阻止。

为避免这样的问题，可以如下所述配置多功能机器10的软件。图17是示出了具有多个虚拟机的多功能机器10a的软件配置的例子的图。在图17中，由相同的附图标记指示与图3中那些所示的相同的元素。

在图17中，多功能机器10a包括两个JSDK平台，即，JSDK平台40a和JSDK平台40b。每个JSDK平台40包括Java虚拟机(VM)。虚拟机被激活作为单独的进程，并且在JSDK平台40(40a，40b)上的JSDK应用30(30a，30b)被激活作为相应的虚拟机的进程中的线程。

在该配置中，优选地，JSDK平台40a被用作例如被完全激活的应用束32a的执行环境，同时JSDK平台40b被用作例如被暂时激活的应用束32b的执行环境。这些执行环境使用不同的进程。因此，即使JSDK平台40b的进程由于应用束32b的出错而停止，但减少了消极影响完全激活的进程的风险。因此，可以防止例如被完全激活的应用束32a的稳定性由于暂时激活的执行而降低。

至于用于暂时激活的进程(虚拟机)，优选地，所给予的优先级次序低于给予用于完全激活的进程(虚拟机)的优先级次序；虚拟存储器被启用；并且被分配给用于暂时激活的进程的堆存储器大于被分配给用于完全激活的进程的堆存储器。至于用于完全激活的进程，优选地，分派了更高的优先级次序，并且虚拟存储器被禁用，从而改善实时性能。为什么给用于暂时激活的进程和用于完全激活的进程分派不同的优先级次序的原因是防止暂时激活的执行对被完全激活的应用的消极影响。为什么用于暂时激活的进程的虚拟机被启用并且被分配给用于暂时激活的进程的堆存储器大于被分配给用于完全激活的进程的堆存储器的原因，是因为为了确定是否能够使用具有被分配用于完全激活的大小的堆存储器来执行应用，大于用作完全激活的存储器的存储器需要首先被检查。

如结合图1提及的，在暂时激活期间，没有调用本地服务层60，致使没有使用专用于多功能机器10的硬件(例如，用于图像处理的硬件)。因此，可以在通用个人计算机(PC)400中进行暂时激活。在这种情况下，不包括图3的本地服务层60的软件需要在计算机400中是可执行的。

在以下描述第二个实施例。在第一个实施例中，基于暂时激活日志80确定每个应用的存储器使用是否等于或小于限制值(5MB)。然而，在并行激活多个应用的情况下，在第一个实施例中所做的确定可能不足以防止出错。

图18A-18C是说明(多个)应用的存储器消耗的图表。

图18A是示出了时间(应用状态转变)和应用束32(在下文中被称为“应用A”)的堆存储器的最大使用之间的关系的图。如图18A所示，在初始状态中应用A的堆存储器的最大使用是3MB，在暂停状态中是1MB，以及在活跃状态中是4MB。在这种情况下，遍历全部状态的应用A的堆存储器的最大使用是4MB，这小于5MB并且满足第一个实施例的约束。因此，应用A的暂时激活被确定是成功的。

图18B是示出了时间(应用状态转变)和另一个应用束32(在下文中被称为“应用B”)的堆存储器的最大使用之间的关系的图。如图18B所示，在初始状态中应用B的堆存储器的最大使用是3MB，在暂停状态中是1MB，以及在活跃状态中是1MB。在这种情况下，遍历全部状态的应用B的堆存储器的最大使用是3MB，这小于5MB并且满足第一个实施例的约束。因此，应用B的暂时激活被确定也是成功的。

图18C是示出了时间和同时被激活的应用A和应用B的堆存储器的最大使用之间的关系的图。在激活其中每个应用的完全激活被允许的两个应用、并且同时进行两个应用的状态转变的情况下，在初始状态中堆存储器的最大使用是3+3＝6MB，在暂停状态中是1+1＝2MB，以及在活跃状态中是1+4＝5MB。在这种情况下，在初始状态中堆存储器的最大使用超过了例如5MB的限制值，这可能导致应用不正常地操作。

在第二个实施例中防止了这个问题。在以下描述第一个实施例和第二个实施例的不同。在这里没有被描述的第二个实施例的特性可以与第一个实施例的特性相同。

在第二个实施例中，主脚本71a被定义为如下所描述的。图19是示出了根据第二个实施例的主脚本71a的描述的例子的图。在图19中，由相同的附图标记指示如图9中所示的那些相同的元素。第二个实施例的主脚本71a对应于第一个实施例的主脚本71。

主脚本71a与第一个实施例的主脚本71不同在于具有描述716。描述716定义脚本函数的接口pbCasel。在第二个实施例中，用于存储暂时激活日志的变量(PseudoBootLog日志)被定义作为用于通过引用来调用的OUT参数。该参数的值被定义在描述712中。

在第二个实施例中多功能机器10的暂时激活的处理过程与第一个实施例中相似。然而，在第二个实施例中，基于主脚本71a中的描述716，暂时激活服务333向SAS管理器31传输暂时激活日志80的内容以及指示在步骤S160中暂时激活是否是成功的信息。SAS管理器31关联所传输的暂时激活日志80和被暂时激活的应用束32(在图7的例子中，扫描应用321)，并且在例如HDD 233中存储和管理暂时激活日志80。可以通过例如给予应用束32的应用名作为暂时激活日志80的文件名，将暂时激活日志80与应用束32相关联。

第二个实施例与第一个实施例进一步不同在于，当在步骤S 167中SAS管理器31收到激活指令时，SAS管理器31如何管理所激活的应用(包括正被激活的应用)。

图20是说明SAS管理器31如何管理被激活的应用的流程图。进行在图20中所说明的处理用于将被完全激活的应用和完全激活了的应用(即，暂时激活成功的应用)。

在多功能机器10中，如果有需要状态转变(包括在激活时至初始状态的状态转变)的应用(在下文中被称为“应用A”)(在步骤S201中是Yes)，SAS管理器31确定在应用A的目的地状态中应用A的最大存储器使用与当前被完全激活的其他应用的最大存储器使用的总和是否等于或小于预定的限制值(例如，5MB)(步骤S202)。

注意，SAS管理器31基于与各自的应用相关的暂时激活日志80，来确定在目的地状态中应用A的最大存储器使用和处于其当前状态的其它应用的最大存储器使用。SAS管理器31基于来自应用的通知，来检测需要状态转变的应用的存在。

如果最大存储器使用的总和等于或小于限制值(在步骤S202中是Yes)，SAS管理器31允许应用A的状态转变。因此应用A移动至其目的地状态(步骤S203)。另一方面，如果最大存储器使用的总和大于限制值(在步骤S202中是No)，SAS管理器31抑制(withhold)应用A的状态转变并且注册指示应用A正等待进行其状态转变的信息(在下文中被称为“等待信息段”)。等待信息段包括，例如，应用A的标识信息和目的地状态的标识信息。等待信息段可以包括处于目的地状态中的最大存储器使用，来替代目的地状态的标识信息。在这种情况下，可以删去用于再次引用应用A的目的地状态的存储器使用的暂时激活日志80的处理。状态转变等待队列是等待信息段的队列或列表。能够基于状态转变等待队列来标识等待进行其状态转变的应用。

当应用A在步骤S203中移动至其目的地状态时，处于其各自状态的每个应用的最大存储器使用的总和由于应用A的状态转变而改变。即，有机会能够允许等待进行其状态转变的应用的状态转变。因此，SAS管理器31执行步骤S205中的处理以及后来的步骤。

更具体地，SAS管理器31确定在状态转变等待队列中是否有任何等待信息段，从而确定是否有等待进行其状态转变的任何应用(步骤S205)。如果没有等待进行其状态转变的应用(即，如果状态转变等待队列是空的)(在步骤S205中是No)，处理返回步骤S201。

另一方面，如果有等待进行其状态转变的应用(在步骤205中是Yes)，SAS管理器31从状态转变等待队列获得一个等待信息段(步骤S206)。从状态转变等待队列获得的等待信息段的次序可以基于FIFO(先进先出)或者可以基于LRU(最近被使用)。可替换地，应用可以被区分优先次序致使按优先级的次序来获得等待信息段。优先级的次序可以被先前注册在HDD 233等等中。

然后SAS管理器31确定处于其目的地状态的、关于所获得的等待信息段(在下文中被称为“当前等待信息段”)的应用的最大存储器使用与处于其各自状态的其它应用的最大存储器使用的总和是否等于或小于预定的限制值(步骤S207)。

如果存储器使用的总和等于或小于限制值(在步骤S207中是Yes)，SAS管理器31从状态转变等待队列删除当前等待信息段(步骤S208)并且将等待进行状态转变的应用移动至其目的地状态(步骤S203)。在应用的状态转变后，进行在步骤S205和后来的步骤中的处理以确定是否允许其它应用之一的状态转变。

另一方面，如果最大存储器使用的总和大于限制值(在步骤S207中是No)，处理返回至步骤S201。可替换地，处理可以返回至步骤S206。在这种情况下，在等待信息段被注册进状态转变等待队列中的应用之中，能够进行状态转变而不导致超过限制值的应用被给予用于状态转变的优先级。

如参考图20所描述的，可以通过约束应用的状态转变来避免在图18C中所说明的情形。如以下所描述地改进图18C的例子。图21是说明如何通过重新排列状态转变来适当地管理存储器使用的图表。

在图21中，如果应用A和应用B都处于初始状态，应用A与应用B的最大存储器使用的总和超过了限制值(5MB)。因此，在移动应用B至暂停状态后，应用A被移动至初始状态。从而，在整个处理中存储器使用的总和被保持在等于或小于限制值。

如以上所描述，根据第二个实施例的多功能机器10，即使多个应用并行操作，也能够基于在应用的暂时激活期间所记录的暂时激活日志80中的信息来控制应用的动作(行为)。即，每个应用的最大存储器使用的总和能够被保持在等于或小于预定的限制值。因此，可以减少由于应用的出错的风险。

注意在第二个实施例的例子中，确定在暂时激活期间遍历状态的最大存储器使用是否等于或小于限制值。因此，基于仅满足该条件的应用将被完全激活的前提来描述图20的处理过程。在可替换的实施例中，当完全激活应用时，SAS管理器31通过参考应用的暂时激活日志80确定遍历状态的应用的最大存储器使用，并且如果最大存储器使用大于限制值，则拒绝应用的完全激活。在这种情况下，在暂时激活期间不必要进行最大存储器使用的确定。即，可以移除在主脚本71a的描述713中的描述“log.Maxmem≤5MB”。

在可替换的实施例中，可以由JSDK平台40进行图20的处理。

在以上描述中，暂时激活被用于先前地确定应用的足够性。然而，暂时激活可以被用于其它目的。例如，暂时激活可以被用作分析在应用的完全激活期间故障的原因。在接下来的例子中，暂时激活被用于根据第三个实施例和第四个实施例的故障原因分析。

图22是说明根据第三个实施例的使用暂时激活的故障分析的方法的图。在图22中，故障支持服务器20是经由如因特网的网络而连接至多功能机器10以从远程地点监视多功能机器10的计算机。故障支持服务器20可以由多功能机器10的厂商操作。

响应于来自操作员的指令，多功能机器10的SAS管理器31完全地激活应用(例如，扫描应用321)(步骤S301)。如果在应用的完全激活期间发生故障，面板服务332显示报告故障发生的警告屏幕(步骤S302)。然后SAS管理器31发送指示故障的类型的信息(例如，错误代码)至故障支持服务20(步骤S303)。

基于指示故障的类型的信息，故障支持服务器20发送适合于调查故障的原因的暂时激活脚本70至多功能机器10(步骤S304)。例如，在故障支持服务器20的存储器单元中，对于每个应用和对于每个故障类型，先前地存储了用于调查故障的原因的暂时激活脚本70。适合用于调查故障的原因的暂时激活脚本70可以包括定义了用于分析故障的场景的场景脚本72和定义了适合用于分析故障的模拟的内容的动作脚本73。

多功能机器10使用所收到的暂时激活脚本70来暂时激活故障的应用(步骤S305)。在步骤S305中所使用的过程和与结合图7的描述是相同的。结果，生成暂时激活日志80。多功能机器10的SAS管理器31发送暂时激活日志80至故障支持服务器20(步骤S306)。

故障支持服务器20分析暂时激活日志80以标识故障的原因。可以自动地或手工地标识故障的原因。在标识原因后，故障分析的结果被报告给操作员(步骤S307)。可以自动地通过电子邮件等发送结果。如果故障由bug所致，可以从故障支持服务器20将修改后的版本远程地安装进多功能机器10中。

可替换地，每个故障类型的暂时激活脚本70可以先前被存储在多功能机器10中，以便多功能机器10进行原因分析。在这种情况下，故障支持服务器20不是必需的。

在以下描述第四个实施例。图23是说明根据第四个实施例的使用暂时激活的故障分析的方法的图。在图23中，由相同的附图标记指示与图22中所示的那些相同的元素。在第四个实施例中，故障支持服务器20包括JSDK应用30、JSDK平台40，和请求路径控制单元50。

在图23中，步骤S401-S403与图22的步骤S301-S303相同。

基于指示故障的类型的信息，故障支持服务器20从存储器单元选择适合用于调查故障的原因的暂时激活脚本70(步骤S404)。故障支持服务器20使用所收到的暂时激活脚本70暂时地激活故障的应用以生成暂时激活日志80。然后故障支持服务器20分析暂时激活日志80以标识故障的原因(步骤S405)。在标识原因后，故障支持服务器20将故障分析的结果报告至操作员(步骤S406)。如果故障是由bug所致，从故障支持服务器20将修改后的版本远程地安装至多功能机器10中。

如以上所描述的，基于对应于故障的暂时激活脚本70进行应用的暂时激活以生成暂时激活日志80，以便能够基于暂时激活日志80适当地进行原因分析。

尽管根据优选的实施例描述了本发明，但可以在被不脱离所附权利要求中所阐述的发明的范围的情况下进行变化和修改。

本申请基于2007年7月10日向日本专利局提交的日本优先权申请号2007-181345，和2008年4月4日向日本专利局提交的日本优先权申请号2008-098627，其全部内容被引用附于此。

Claims (18)

1.一种程序确定装置，包括：

日志记录单元，其被配置用于响应于来自在成像装置中使用的程序的、对于所述成像装置的预定功能的使用的使用请求和由所述程序对所述成像装置的预定资源的消耗中的至少一个，记录使用请求和消耗中的所述至少一个的内容作为日志信息；以及

确定单元，其被配置用于确定由所述程序请求的所述预定功能的使用和由所述程序对所述预定资源的消耗中的所述至少一个是否满足预定约束。

2.如权利要求1所述的程序确定装置，进一步包括：

响应单元，其被配置用于如果激活了所述程序，其中要由所述确定单元对所述程序进行确定，则响应对于来自所述程序的对于所述预定功能的使用的所述使用请求，来替代被配置用于根据所述使用请求来实现所述预定功能的功能实现单元。

3.如权利要求2所述的程序确定装置，进一步包括：

请求目的地控制单元，其被配置用于监视来自所述程序的对于所述预定功能的使用的所述使用请求，并且如果激活了所述程序，其中要由所述确定单元对所述程序进行确定，则不向所述功能实现单元而向所述响应单元发送所述使用请求。

4.如权利要求1所述的程序确定装置，其中所述确定单元通过比较由所述程序请求的所述预定功能的使用和由所述程序对所述预定资源的消耗中的所述至少一个与在第一文件中所存储的预定条件，来确定由所述程序请求的所述预定功能的使用和由所述程序对所述预定资源的消耗中的所述至少一个是否满足预定约束。

5.如权利要求1所述的程序确定装置，进一步包括：

操作单元，其被配置用于根据在第二文件中所存储的定义来产生所述程序的操作屏幕的输入。

6.如权利要求2所述的程序确定装置，其中所述响应单元根据在第三文件中所存储的定义来响应所述使用请求。

7.一种可由计算机执行的程序确定方法，所述方法包括：

日志记录步骤，用于响应于来自在成像装置中使用的程序的、对于所述成像装置的预定功能的使用的使用请求和由所述程序对所述成像装置的预定资源的消耗中的至少一个，记录使用请求和消耗的所述至少一个的内容作为日志信息；以及

确定步骤，用于确定由所述程序请求的所述预定功能的使用和由所述程序对所述预定资源的消耗中的所述至少一个是否满足预定约束。

8.如权利要求7所述的程序确定方法，进一步包括：

响应步骤，如果激活了所述程序，其中要在所述确定步骤中对所述程序进行确定，则响应来自所述程序的对于所述预定功能的使用的所述使用请求，来替代用于根据所述使用请求来实现所述预定功能的功能实现步骤。

9.如权利要求8所述的程序确定方法，进一步包括：

请求目的地控制步骤，用于监视对于来自所述程序的对于所述预定功能的使用的所述使用请求，并且如果激活了所述程序，其中要在所述确定步骤中对所述程序进行确定，则不向所述功能实现步骤而向所述响应步骤发送所述使用请求。

10.如权利要求7所述的程序确定方法，其中，在所述确定步骤中，通过比较由所述程序请求的所述预定功能的使用和由所述程序对所述预定资源的消耗中的所述至少一个与在第一文件中所存储的预定条件，来确定由所述程序请求的所述预定功能的使用和由所述程序对所述预定资源的消耗中的所述至少一个是否满足预定约束。

11.如权利要求7所述的程序确定方法，进一步包括：

操作步骤，用于根据在第二文件中所存储的定义来产生所述程序的操作屏幕的输入。

12.如权利要求8所述的程序确定方法，其中，在所述响应步骤中，根据在第三文件中所存储的定义来响应所述使用请求。

13.一种存储程序确定程序的计算机可读记录介质，该程序确定程序包括用于执行方法的计算机可执行的指令，所述方法包括：

日志记录步骤，用于响应于来自在成像装置中使用的成像装置程序的、对于所述成像装置的预定功能的使用的使用请求和由所述成像装置程序对所述成像装置的预定资源的消耗中的至少一个，记录使用请求和消耗的所述至少一个的内容作为日志信息；以及

确定步骤，用于确定由所述成像装置程序请求的所述预定功能的使用和由所述成像装置程序对所述预定资源的消耗中的所述至少一个是否满足预定约束。

14.如权利要求13所述的计算机可读记录介质，

其中所述方法进一步包括：响应步骤，如果激活了所述成像装置程序，其中要在所述确定步骤中对所述成像装置程序进行确定，则响应来自所述成像装置程序的对于所述预定功能的使用的所述使用请求，来替代用于根据所述使用请求来实现所述预定功能的功能实现步骤。

15.如权利要求14所述的计算机可读记录介质，

其中所述方法进一步包括：请求目的地控制步骤，用于监视用于来自所述成像装置程序的对于所述预定功能的使用的所述使用请求，并且如果激活了所述成像装置程序，其中要在所述确定步骤中对所述成像装置程序进行确定，则不向所述功能实现步骤而向所述响应步骤发送所述使用请求。

16.如权利要求13所述的计算机可读记录介质，其中，在所述确定步骤中，通过比较由所述成像装置程序请求的所述预定功能的使用和由所述成像装置程序对所述预定资源的消耗中的所述至少一个与在第一文件中所存储的预定条件，来确定由所述成像装置程序请求的所述预定功能的使用和由所述成像装置程序对所述预定资源的消耗中的所述至少一个是否满足预定约束。

17.如权利要求13所述的计算机可读记录介质，

其中所述方法进一步包括：操作步骤，用于根据在第二文件中所存储的定义来产生所述成像装置程序的操作屏幕的输入。

18.如权利要求14所述的计算机可读记录介质，其中，在所述响应步骤中，根据在第三文件中所存储的定义来响应所述使用请求。

Images