CN107872599B - 图像形成设备 - Google Patents

Abstract

图像形成设备。图像形成设备包括：架构上的应用，所述应用被分离成管理基础处理的核心逻辑部分、以及管理渲染处理的用户接口框架部分，并且所述应用在所述架构上操作；以及控制器，所述控制器执行所述应用和所述架构，其中，所述核心逻辑部分用由所述架构所限定的应用编程接口来实现。所述应用包括多个应用，所述多个应用包括特定应用，所述特定应用的核心逻辑部分将用户信息一齐存储在用户上下文中，并且另一个应用的核心逻辑部分从所述用户上下文获取所述用户信息。

Description

图像形成设备

技术领域

本发明涉及图像形成设备。

背景技术

具有诸如复印、打印和传真的功能的多功能机器的功能进一步扩展，因此要求有效地构造包括各种应用的整个系统。

日本未审查专利申请公开No.2012-248102描述了一种图像形成设备，该图像形成设备允许用户容易地识别应用列表画面上显示的图标的应用是否是在执行期间。该构造包括：画面信息存储单元，其存储列表画面信息，列表画面信息包括用于调用在其中注册了应用和所述应用的操作设置的宏的图标的图标位置、图标图像、应用识别信息和宏识别信息；画面控制单元，其获取关于工作状态从备用变成执行的应用的状态信息，输出识别信息并且发出画面更新请求；画面创建单元，如果接收到对基于列表画面信息而创建的应用列表画面的画面更新请求，则画面创建单元将由所获取的识别信息所指示的应用的图标的显示样式更新成与另一个应用的图标不同的显示样式；以及显示单元，其显示包括更新的图标的列表画面。

日本未审查专利申请公开No.2012-27662描述了在具有扩展功能的多功能机器中改进了用户的可操作性。该构造包括：布置信息存储单元，其存储图标布置信息，在图标布置信息中，标准应用、扩展应用、以及用于标识标准应用和扩展应用的应用识别信息与关于对应图标的坐标信息和关于图标的图像信息相关联；列表画面创建单元，其创建应用列表画面，在应用列表画面中，基于图标布置信息显示与标准应用和扩展应用对应的图标；显示单元，其显示所创建的应用列表创建画面；以及画面控制单元，其根据图标布置信息指定与被按下的图标对应的标准应用或扩展应用，并且向指定的标准应用或扩展应用做出操作画面显示请求。

在相关技术中，作为图像形成设备的系统，准备大的根应用并且设置将从相应应用使用的各种功能。所有的应用都取决于根应用。

另外，专门管理图像形成设备中的各种装置的状态的装置应用是独立存在的。基本上所有的应用都取决于装置应用。

另外，应用之间的公共实现在进行，并且应用也相互依赖。

因此，每当添加或删除应用时，需要在应用之间进行调节，并且同时，时常需要校正根应用。因此，可能不能容易地添加或删除应用。

发明内容

本发明的目的是提供一种图像形成设备，该图像形成设备限制了应用之间的依赖并且允许容易地添加或删除应用。

根据本发明的第一方面，一种图像形成设备包括：架构上的应用，所述应用被分离成管理基础处理的核心逻辑部分、以及管理渲染处理的用户接口框架部分，并且所述应用在所述架构上操作；以及控制器，所述控制器执行所述应用和所述架构。所述核心逻辑部分用由所述架构所限定的应用编程接口(API)来实现。所述应用包括多个应用，所述多个应用包括特定应用，所述特定应用的核心逻辑部分将用户信息共同地存储在用户上下文中，并且另一个应用的核心逻辑部分从所述用户上下文获取所述用户信息。

根据本发明的第二方面，基于第一方面中描述的图像形成设备，所述多个应用中包括的所述特定应用的核心逻辑部分可与用户的登录关联地将所述用户信息存储在所述用户上下文中。

根据本发明的第三方面，基于第一方面或第二方面中描述的图像形成设备，在画面的顶部显示所述应用时，所述应用可从所述用户上下文获取所述用户信息。

根据本发明的第四方面，提供了一种图像形成设备，该包括图像形成设备：架构上的应用，其被分离成管理基础处理的核心逻辑部分和管理渲染处理的用户接口框架部分，并且所述应用在所述架构上操作；以及控制器，其执行所述应用和所述架构。所述核心逻辑部分用由所述架构所限定的应用编程接口来实现。所述应用包括多个应用，所述多个应用包括特定应用，所述特定应用的核心逻辑部分将系统特定信息共同地存储在全局上下文中，并且另一个应用的核心逻辑部分从所述全局上下文获取所述系统特定信息。

关于本发明的第一方面，应用之间的依赖性可被限制，应用可被容易地添加或删除，并且可在多个应用中容易地使用用户信息。

关于本发明的第二方面，另外，用户信息可与登录关联地被改变。

关于本发明的第三方面，另外，可减少多个应用的访问。

关于本发明的第四方面，应用之间的依赖性可被限制，应用可被容易地添加或删除，并且可在多个应用中容易地使用系统特定信息。

附图说明

将基于以下附图详细地描述本发明的示例性实施方式，其中：

图1是图像形成设备的功能框图；

图2是系统的逻辑配置图；

图3是示出主画面的示例的说明视图；

图4是应用的逻辑配置图；

图5是相关技术的系统的逻辑配置图；

图6是架构上的应用的配置图；

图7是示出应用的特定配置示例的说明性视图；

图8是示出应用列表的特定配置示例的说明性视图；

图9提供示出核心逻辑和UI框架的模式(pattern)的说明性视图；

图10A至图10C是UI和逻辑改变时的说明性视图；

图11A和图11B是均示出框架上的应用的模式的说明性视图；

图12是包括启动器(booter)和起动器(starter)的生命周期管理的系统配置示图；

图13是生命周期管理的时序图；

图14是示出从系统激活到主画面显示的时间的曲线图；

图15是用户上下文的说明视图；

图16是针对用户上下文的第一操作处理流程图；

图17是针对用户上下文的第一操作处理流程图；

图18是针对用户上下文的第三操作处理流程图；

图19是针对用户上下文的第四操作处理流程图；

图20A至图20C是登录时的画面说明视图；以及

图21是全局上下文的说明视图。

具体实施方式

以下，参照附图来描述本发明的示例性实施方式。

总体系统构造

图1是包括根据本示例性实施方式的图像形成设备的图像形成系统的功能框图。图像形成系统包括终端设备10和图像形成设备12。终端设备10和图像形成设备12通过通信单元14相互连接。通信单元14使用例如诸如局域网(LAN)的数据通信网络。

终端设备10通过通信单元14与图像形成设备12连接，并且根据用户的指令发送例如包括文档打印命令的打印工作。

图像形成设备12包括只读存储器(ROM)16、随机存取存储器(RAM)18、硬盘驱动器(HDD)20、由一个或多个中央处理单元(CPU)构成的控制器22、输入/输出接口(I/F)24、诸如触摸面板的操作单元26和图像形成单元28。

由一个或多个CPU构成的控制器22通过输入/输出接口I/F 24从终端设备10接收例如打印工作命令，解释页面描述语言(PDL)数据并生成中间数据，并且根据存储在ROM 16中的处理程序从所生成的中间数据来进一步生成渲染数据(栅格数据)。另外，控制器22执行从操作单元26接收的诸如复印、扫描和传真的各种命令。

图像形成单元28包括打印模块、扫描模块、传真模块、进纸模块、文档馈送模块和图像处理加速器。

打印模块具有将图像输出到纸张上的功能。例如，打印模块包括已知喷墨方法的配置，并且将渲染数据打印到纸张上。打印模块从喷嘴等排放液体或熔融的固体墨水，并且在纸张、膜或其它材料上执行记录。排放墨水的方法包括利用静电吸附力排放墨水的按需喷墨方法(压力脉冲方法)、以及通过利用在高温下因热形成和生长气泡而产生的压力来排放墨水的热喷墨方法。待使用的记录头包括例如排放青色墨水的头、排放品红色墨水的头、排放黄色墨水的头和排放黑色墨水的头。每个头使用线形头，该线形头的宽度至少与纸张的宽度相等。相应颜色的墨水液滴被记录头排放在中间转印主体上用于记录，然后被转印到纸张上用于打印。

扫描模块从纸张读取图像并且将图像转换成电子数据。

传真模块包括调制解调器和传真图像处理模块，并且执行传真功能。

进纸模块将纸张从纸托盘传送到打印模块。

文档馈送模块将纸张从文档托盘传送到扫描模块。

图像处理加速器是与例如扫描模块关联执行压缩/扩张处理的模块。图像处理加速器不是必须设置并且图像处理加速器可以是附加模块。

除了以上提到的模块，图像形成设备12还可包括：整理机，其针对纸张提供例如冲孔和拣选；通用串行总线(USB)；认证单元，其由集成电路(IC)卡读取器等构成，并且对用户进行认证；计费单元；和/或人传感器、面部相机等。

另外，图像形成设备12可通过通信单元14与互联网连接，或者可包括以太网(Ethernet，注册商标)和/或Wi-Fi(注册商标)。

程序的逻辑配置

图2示出由控制器22执行的系统的逻辑配置。系统被大致分离成两层，所述两层包括呈现层30和装置服务层32。

呈现层30是在其中实现各种应用的层，并且包括架构31和各种应用。架构31是允许能在计算机系统上操作JavaScript(注册商标)应用的执行环境软件群组。更具体地，JavaScript在网络浏览器上执行，并且基础框架和UI框架作为超文本标记语言(HTML)的iframe被加载。另外，这样的应用是用由架构31所提供的应用编程接口实现的JavaScript软件。架构31管理各种应用的生命周期。也就是说，对于各种应用中的每个，架构31创建基础框架，读取应用的核心逻辑，并且向核心逻辑给出初始化指令。另外，在去激活系统时，架构31向各种应用中的每个的核心逻辑给出最终化指令，并且删除基础框架。随后更详细地描述各种应用中的每个的核心逻辑和生命周期管理。

装置服务层32是管理各种硬件装置的层。硬件装置包括例如上述图像形成单元28的打印模块。

图3示出在图像形成设备12的操作单元26上显示的画面(主画面)的示例。主画面包括在其上显示的图标。这些图标包括复印按钮34、ID卡复印(ID复印)按钮36、扫描按钮38、传真按钮40、我的复印按钮42、网络应用(网络应用1)按钮44和简单复印按钮46。当用户触摸并选择多个按钮中的一个时，激活分配给该按钮的应用，并且画面转变为应用画面。用户可认识到按钮对应于应用。

每个应用是由如上所述的架构31所提供的应用编程接口实现的JavaScript软件，并且是直接向用户提供功能的部件。每个应用具有由架构31所限定的公共配置。另外，每个应用被配置成具有相对于另一个应用的低链接度。应用包括通过用户接口(UI)与用户协作进行操作的应用和不与用户协作的应用。与用户协作的应用通过呈现层30主观地执行显示和输入。

该图还示出用于用户登录的登录按钮48。该按钮也对应于应用。

应用的实现结构。

图4示出应用的结构。应用50大致被分离成三个部件。也就是说，应用50被分离成核心逻辑52、UI框架54和清单(manifest)文件56。在这种情况下，“分离”不代表物理分离，而是代表逻辑分离。

核心逻辑52是将基础处理(基础行为和应用间关联)作为应用来执行的部件，并且必须存在于每个应用中。核心逻辑设置由架构31所限定的应用编程接口。

UI框架54是作为应用提供渲染和显示的部件，或者更具体地，作为显示窗口被管理。

清单文件56是关于每个应用的被动(passive)信息的列表。被动信息可包括应用的标识符(ID)、显示名称、图标图像、版本、创建日期等。清单文件56包括核心逻辑清单文件56-1和UI框架清单文件56-2。将由清单文件56写入的一条信息是isLaunchable属性。用该属性，确定应用是否被显示为主画面上的图标(按钮)。属性如下：

如果isLaunchable＝真，则选择显示；以及

如果isLaunchable＝假，则选择不显示。

用该配置，核心逻辑52和UI框架54之间的通信规则如下：

(1)核心逻辑52与另一个核心逻辑52通信；以及

(2)UI框架54只与核心逻辑52通信。

因此，UI框架54不与另一个UI框架54通信。

图5示出相关技术的程序配置。在相关技术中，准备大的根应用(root app)600并且提供将被相应应用使用的各种功能。所有的应用取决于该根应用600。另外，专门管理各种装置状态的装置应用(device app)620也是独立存在的。基本上所有的应用都取决于该装置应用620。另外，应用之间的公共实现在进行，并且应用相互依赖。因此，即使在添加或删除应用的情况下，每当出现该情况时，也需要在应用之间进行调节，并且通常需要校正根应用600。可能不能容易地添加或删除应用。

相比之下，图6示出该示例性实施方式的程序配置。每个应用被分离成核心逻辑52、UI框架54和清单文件56。每个应用的核心逻辑52与架构31连接。每个应用的UI框架54与应用的核心逻辑52连接。

例如，示例性描述复印应用，复印应用被分离成核心逻辑52、UI框架54和清单文件56。核心逻辑52与架构31连接。UI框架54与核心逻辑52连接。与相关技术不同，相应应用之间的链接被限制，没有依赖性，因此由架构31通过核心逻辑52来执行应用之间的关联。每个应用的核心逻辑52提供由架构31所限定的应用编程接口。因此，当新添加应用时，可通过提供由架构31所限定的应用编程接口来容易地执行添加。另外，由于应用之间的链接被限制，因此应用可被容易地删除。

图7示出复印应用的示例。在图7中，baseframe.html是核心逻辑52，并且base_manifest.json是核心逻辑52的清单文件56-1。另外，uiframe.html是UI框架54，并且app_manifest.json是UI框架54的清单文件56-2。

图8示出应用列表的示例。在图8中，“base”代表核心逻辑52的清单文件56-1，并且“app”代表UI框架54的清单文件56-2。在清单文件56-2中，“type”代表应用的类型。应用的类型如下。

特别地，应用包括四种类型。

STD：预先安装的应用

OT：预先安装的应用(STD)的快捷方式

EXT：可添加的应用(类型I应用)

CS：可添加的应用(类型II应用)

预先安装的应用是图3中示出的与复印、扫描、传真等对应的应用。另外，OT、EXT和CS的每个应用被分配特定配套应用。每个配套应用管理对应的功能。每个配套应用还包括核心逻辑52，与STD应用类似。由于清单文件56包括应用的类型，因此可将每个应用的内部实现与另一个应用的内部实现区分开。

另外，清单文件56-2中的“isLaunchable”是如上所述确定图标是否在主画面上显示的属性信息。在图8中，显示如下。

isLaunchable＝真

这代表显示复印按钮。

由于应用被分离成核心逻辑52和UI框架54，因此应用列表描述了其间的对应。

针对每个应用创建清单文件56。因此，期望设置代表每个应用的类型的标识符和类型的唯一标识符。例如，复印应用的清单文件具有如下的标识符。

type(类型)：STD

ID：copy(复印)

在这些标识符中，type是代表类型(预先安装的应用)的标识符，并且ID是唯一标识符。

另外，清单文件56包括在激活时所需的信息和将主画面渲染为静态信息所需的信息。在激活时所需的信息是关于核心逻辑52的存储位置信息和关于UI框架54的存储位置信息。架构31参照核心逻辑52的存储位置信息来加载核心逻辑52。另外，如有需要，核心逻辑52参照关于UI框架54的存储位置信息来加载UI框架54。

渲染主画面所需的信息是关于图标按钮的存储位置信息和按钮的显示次序。

装置服务层中的应用管理部件参考清单文件56并且使用清单文件56用于创建应用列表(随后描述)。

图9示出应用的实现结构的模式。

图9中的部分(a)满足存在核心逻辑52而不存在UI框架54的模式。这并不对应于预先安装的应用，而是对应于例如配套应用。图9中的部分(d)是与图9中的部分(a)对应的应用列表。

图9中的部分(b)满足核心逻辑52和UI框架54一一对应存在的模式。图9中的部分(e)是与图9中的部分(b)对应的应用列表。

相比之下，图9中的部分(c)示出以下情况：存在核心逻辑52和多个UI框架54，并且多个UI框架54共享公共核心逻辑52。UI框架54确定在主画面上显示按钮时的显示样式。即使当显示多个按钮时，通过共享公共核心逻辑52，实现的效率也增加。另外，如果多个应用共享公共核心逻辑52，则维持性能增强。共享公共核心逻辑52的UI框架54的数量不受限制。图9中的部分(f)是与图9中的部分(c)对应的应用列表。清单文件56-1的特定示例例如如下。

清单文件56-2的特定示例例如如下。

另一个示例如下。

在图9中的部分(b)和图9中的部分(c)中，通过设置UI框架54的清单文件56-2的isLaunchable属性值，确定在主画面上是否实际显示按钮。例如，在图9中的部分(c)中，在存在共享公共核心逻辑52的第一UI框架54和第二UI框架54，第一UI框架54的清单文件是isLaunchable＝真，并且第二UI框架54的清单文件是isLaunchable＝假的情况下，前一个被显示为按钮，而后一个没有被显示。

作为应用的执行结构，核心逻辑52与UI框架54分离。因此，只可改变UI框架54，而不改变核心逻辑52，并且可容易地定制应用的画面上的显示样式。

图10A至图10C均示出定制画面上的显示样式的示例。

图10A是初始显示样式。重点放在ID卡复制的应用，其UI框架54是idcopy/uiframe.html，并且其清单文件56-2是idcopy/app_manifest.json。

图10B示出定制显示样式的情况。在ID复制的应用中，针对新的显示样式，用idcopy_for_xxx/uiframe.html和idcopy_for_xxx/app_manifest.json来替换UI框架54和清单文件56-2。当然，也可只替换清单文件56-2。

相比之下，图10C示出不改变显示样式而改变应用的逻辑的情况。在这种情况下，所有核心逻辑52、UI框架54和清单文件56都被新部件替换。也就是说，用copy_for_xxx替换copy所指示的部分。

图11A和图11B均示出包括架构31的特定应用的实现结构的模式。

图11A示出在实现复印应用和ID复印应用的情况下的模式的示例。复印应用被分离成核心逻辑52和UI框架54。核心逻辑52与架构31通信。UI框架54只与核心逻辑52通信。类似地，ID复印应用被分离成核心逻辑52和UI框架54。核心逻辑52与架构31通信。UI框架54只与核心逻辑52通信。

图11B示出除了复印应用和ID复印应用之外还实现打印应用的情况的另一个示例。复印应用和ID复印应用被分离成公共核心逻辑52和相应的UI框架54。也就是说，复印应用和ID复印应用通过公共核心逻辑52与架构31通信。另外，打印应用具有核心逻辑52，但不具有UI框架54。图11A和图11B包括图9中示出的所有模式。

在相关技术的应用实现结构中，与以上提到的结构不同，核心逻辑52和UI框架54没有相互分离，并且处理和画面渲染混合，从而导致结构复杂。另外，不存在应用的公共编程接口，并且每个应用自由地公布编程接口并且自由地参考编程接口。相比之下，在本示例性实施方式中，架构31限定应用编程接口，并且每个应用的核心逻辑52必须用应用编程接口来实现。因此，本示例性实施方式中的应用编程接口的方向不同于相关技术的方向。另外，除了架构31和每个应用之间的通信之外，可通过由架构31所提供的编程接口公布功能和应用编程接口参考功能来实现应用之间的通信编程接口。

理论上，多个应用可共享公共UI框架54并且可分别地具有单个核心逻辑52。然而，在这种情况下，就架构31的观点而言，结构可能是复杂的，因此在本示例性实施方式中没有特别地描述这种情况。当然，不是必须旨在排除该模式。

应用的生命周期管理

图12示出当架构31针对每个应用执行生命周期管理时的基本配置。在这种情况下，架构31是应用的执行环境。

在呈现层中除了存在架构31和各种应用50之外，还存在启动器60和起动器应用64。另外，在装置服务层中存在应用管理部件62。

启动器60是执行整个呈现层的激活/去激活管理的部件。由启动器60来初始化和激活架构31。

应用管理部件62基于各种应用50的清单文件56向架构31提供应用列表。

起动器应用64是用由架构31所限定的起动器编程接口70实现的应用。起动器应用64只是该系统中存在的一个应用，并且当所有应用50的初始化完成时，从架构31调用起动器应用64。

各种应用50包括复印应用、ID复印应用、传真应用等，并且包括如上所述的核心逻辑52。各种应用50的核心逻辑52均用由架构31所限定的应用编程接口72来实现。

具体地，每个应用50中实现的应用编程接口如下。

·初始化处理(initialize)

·最终化处理(finalize)

·窗口推出处理(windowPushedOut)

·窗口准备暴露处理(windowPrepareExposed)

·窗口准备终止处理(windowPrepareTerminated)。

针对这些事件用处理程序(handler)来实现每个应用50。

架构31包括用于启用方法的公布/调用的JavaScript部件(被称为通信控制部件)和各种应用50的核心逻辑52之间的事件的公布/购买/发行。方法可被定义为采用所期望参数并且返回所期望的返回值。以应用为基础来独立地管理所公布的方法。调用方法的应用可通过回调来检查方法的处理的完成。另外，可由每个应用用所期望的数据来定义事件。以应用为基础来独立地管理所公布的事件。更具体地，通信控制部件通过核心逻辑52来启用方法的公布和调用，启用监听方的事件和注册的定义和发行，通过“ON”来公布方法，并且通过“OFF”来停止方法的公布。所公布的方法能够通过调用(call)进行调用。例如，第一应用向架构31针对公布设置特定应用编程接口“ON”，并且第二应用向架构31针对第一应用的所公布的编程接口进行“调用”。

图13是架构31对各种应用中的每个进行的生命周期管理的时序图。

当启动器60激活架构31时，架构31从装置服务层中的应用管理部件62请求应用列表，并且从应用管理部件62获取应用列表。

当架构31获取应用列表时，架构31根据该列表以应用为基础来创建基础框架，并且加载包括起动器应用64的各种应用50(加载阶段)。也就是说，架构31读取每个应用的核心逻辑52。具体地，架构31参照在清单文件56中限定的关于核心逻辑52的存储位置信息来加载核心逻辑52。基础框架是用于执行每个应用的核心逻辑52的框架，并且没有显示该框架。期望地确定相应应用的核心逻辑52的加载次序并且此次序不受特别限制。在所有应用已经完成了应用编程接口实现的注册的时间点，该阶段进行到下一个阶段。

要注意，在应用编程接口实现的注册处理之前公布每个应用的方法和事件。

接下来，架构31通过应用编程接口向每个应用给出初始化指令(初始化阶段)。具体地，架构31向每个应用发行“应用(app)”事件和“初始化(initialize)”方法。在响应于初始化指令而在处理完成之后所有应用回调的时间点，架构31将初始化处理的完成通知启动器60，并且该阶段进行到下一个阶段。还可期望地确定相应应用的初始化次序。在该初始化处理中，每个应用执行从装置服务层的获取数据。

然后，启动器60向架构31给出通过应用来提供功能的起动指令，并且架构31响应于所给出的指令而向起动器应用64给出起动指令(起动阶段)。起动器应用64获取关于在装置服务层中管理的初始激活应用的信息，并且显示初始画面。在起动器应用64响应于起动指令在处理完成之后进行回调的时间点，完成该阶段。

在系统去激活时，架构31向每个应用的核心逻辑52给出最终化的指令。另外，架构31删除每个应用的基础框架。

在加载阶段中，没有特定限制的次序来读取相应应用的核心逻辑52。因此，即使当添加应用时，加载阶段也不一定改变。另外，在初始化阶段中，所有应用被初始化。因此，确信调用其它应用，并且不需要进行单独的同步。如上所述，由于不再需要应用之间的同步并且只加载大小相对小的核心逻辑52，因此系统激活时间和应用激活时间减少。

如果每个应用独立地公布应用编程接口，则激活、预初始化处理、初始化处理、后初始化处理、停止、暂停等在应用的基础上是不同的。在每个应用的初始化级中产生差异，并且能够调用应用的定时也改变。特别地，需要在调用应用之前，检查是否能够调用主题应用。控制可能是复杂的。相比之下，在示例性实施方式中，如上所述可减少初始化时间，并且初始化之后的主画面的激活时间可减少。

图14示出根据相关技术和示例性实施方式的从系统激活到主画面显示的时间。

在相关技术中，除了单纯初始化时间之外，应用初始化时间还需要同步，并且类似地，除了单纯激活时间之外，主画面的激活时间也需要同步。相比之下，在本示例性实施方式中，单纯初始化时间可减少，并且可去除同步。另外，对于主画面激活时间，可提供类似的效果。在相关技术中，如果应用相互依赖，则需要进行调节以防止产生死锁。然而，在本示例性实施方式中，不存在这样的依赖，因此不再需要死锁调节。

如上所述，在本示例性实施方式中，应用被分离成核心逻辑52和UI框架54，在核心逻辑52中实现由架构31所限定的应用编程接口，核心逻辑52通过架构31与另一个应用的核心逻辑52通信，并且UI框架54只与应用的核心逻辑52通信。因此，每个应用具有由架构31所限定的公共配置，并且可被配置成与另一个应用具有低链接度。可以容易地添加或删除应用。

接下来描述在显示主画面之后用户执行登录的情况。

在相关技术中，当用户登录时，每个应用从下层接收关于用户登录的事件通知，并且执行改变用户的处理。也就是说，每个应用独立地获取关于当前登录的用户的信息。

相比之下，在本示例性实施方式中，随着被激活的应用的数量增加，从下层提取用户信息需要根据获取的量的时间。据此，管理登录处理的应用从下层获取用户信息并且共同地存储用户信息，并且每个应用都参考共同地存储的用户信息。

图15示意性示出根据示例性实施方式的登录时的处理。在用户登录时，各种应用50之中的管理登录的应用(认证应用)从下层获取关于用户的信息，并且将信息存储在用户上下文80中。然后，当除了认证应用之外的应用获取用户信息时，应用不从下层提取用户信息，而是通过参考由认证应用所创建的(更具体地，由认证应用的核心逻辑52所创建的)用户上下文80来获取所需的用户信息。因此，相比于相关技术，可在短时间内容易地获取用户信息。例如，用户上下文8 0如下创建。

UC1：active

UC0：inactive

UC2：inactive

UC3：inactive

在这种情况下，active代表激活状态，inactive代表不激活状态。随后，描述激活(active)和不激活(inactive)。

图16至图19是与登录关联的用户上下文80的操作流程图。

首先，图16示出系统激活时的处理。管理登录的认证应用从下层获取默认用户信息。然后，认证应用创建DUC作为默认用户上下文80(S101)。

然后，认证应用在所创建的DUC中设置从下层获取的默认用户信息(S102)。然后，认证应用将其中设置有默认用户信息的DUC激活(S103)。

图17示出当用户进行登录时的处理。认证应用获取登录的用户的名称(登录用户名)(S201)。

然后，认证应用从下层获取关于登录用户的信息(S202)。

然后，认证应用创建用户上下文80(S203)，并且在用户上下文80中设置关于在S203中获取的登录用户的信息(被称为UC1)(S204)。然后，认证应用使其中设置有登录用户信息的UC1激活(S205)。此时，如果存在另一个激活UC，则UC变成不激活。(存在一个激活的UC。)

图18示出登录之后的每个应用50的处理。每个应用50都参考激活的用户上下文80(AUC)(S301)。在这种情况下，由于UC1是激活的，因此应用参考UC1。

然后，应用从作为是激活的用户上下文80的UC1获取所需的用户信息(S302)。

图19示出当用户退出时的处理。首先，认证应用获取当前为激活的用户上下文80(AUC)(S401)。认证应用指示下层退出。然后，认证应用从下层获取默认用户信息。然后，认证应用创建DUC作为默认用户上下文，并且在所创建的DUC中设置从下层获取的默认用户信息。然后，认证应用使默认用户上下文80(而不是AUC)激活(S403)。认证应用删除已为激活的用户上下文80(S402)。

可理解，每当用户登录时就创建新的用户上下文80，在用户上下文80中设置关于用户的信息，并且用户上下文80变成激活。

图20A至图20C均示出登录时的画面。图20A是初始画面，并且在预定位置显示“登录”图标。该图标与认证应用关联，该认证应用是管理登录的应用。这种情况下的用户上下文80是默认用户上下文80，即DUC。

图20B是当用户操作登录图标时的画面示例。画面转变成针对用户名和密码的输入画面。当用户输入用户名和密码时，认证应用验证输入的用户名和密码。如果认证应用认证了用户是合法用户，则认证应用新创建用户上下文80，在用户上下文80中设置关于登录用户的信息，并且将用户上下文80激活。

当用户上下文80被新改变时，每个应用50从激活的用户上下文80获取新的用户信息。然而，如果所有应用50全都在用户上下文80中提取信息，则相比于如相关技术从下层提取信息的情况，访问的次数增加，尽管仍然高效。

因此，关注的是，各种应用50之中的显示画面中占主导地位的应用被限于位于画面的顶部的应用，当在画面的顶部显示主题应用时，该应用参考激活的用户上下文80来获取关于登录用户的信息。因此，访问的次数可减少。

图20C是登录处理之后的画面。渲染主画面的应用在画面的顶部。参考激活的用户上下文80来获取关于登录用户的信息，并且在画面上的预定位置(在图中，登录图标的位置)处显示用户名(在图中，A先生)。

在用户上下文80中设置用户信息。特别地，可设置以下信息。

·用户名

·用户图标

·用户显示语言

·用户键盘语言、用户输入语言

例如，在用户显示语言的情况下，当用户登录时，认证应用获取登录用户的ID并且将ID存储在用户上下文80中，另外，将显示语言作为一条关于用户的用户信息存储在用户上下文80中。然后，应用转变为各种应用50之中的应用1。应用1参考用户上下文80来获取显示语言，按照显示语言来创建画面，并且显示画面。类似地，当应用转变为另一个应用2时，应用2参考用户上下文80来获取显示语言，按照显示语言来创建画面，并且显示画面。

上述处理是与用户信息相关的处理。然而，除了用户信息之外，系统还可包括诸如系统设置值的唯一信息。更具体地，唯一信息是例如产品贮存信息和机器特定信息。在相关技术中，当应用需要唯一信息时(特别地，在激活系统时)，每个应用从下层提取唯一信息。然而，特定应用可类似地从下层获取这种唯一信息并且将唯一信息共同地存储为上下文，并且每个应用都可参考该上下文。

图21示意性示出这种情况下的配置。在激活系统时，各种应用50之中的计费应用(在图中，认证应用；然而，不受特别限制)从下层获取关于用户的信息，并且将该信息存储在全局上下文82中。然后，当相应应用50获取唯一信息时，应用50不从下层提取唯一信息，而是参考由认证应用所创建的全局上下文82来获取所需的唯一信息。因此，相比于相关技术，可在短时间内容易地获取唯一信息。在激活系统时，架构31可首先创建默认全局上下文82，然后，计费应用可获取唯一信息并且在全局上下文82中设置该信息。

本示例性实施方式中的“部件”代表可逻辑上被分离的软件的部件。可由一个或多个处理器来执行部件。在本本示例性实施方式中，使用JavaScript。然而，当然，可使用其它编程语言中的任一种。

另外，本发明不限于上述示例性实施方式，并且可按各种方式进行修改。以下，描述修改形式。

修改形式

在示例性实施方式中，图像形成设备12的控制器(处理器)22执行呈现层30中的架构31和各种应用50。然而，由于如图2中所示呈现层30和装置服务层32相互分离，因此与图像形成设备12不同的用于控制图像形成设备12的单个设备(例如，诸如智能电话或平板终端的移动终端中的处理器)可执行呈现层30中的架构31和各种应用50。另外，图1中的操作单元26期望被安装在移动终端上。在这种情况下，移动终端和图像形成设备12可被统称为图像形成设备或图像形成系统。

出于例示和描述的目的已经提供了以上对本发明的示例性实施方式的描述。这不旨在是穷尽的或者将本发明限于所公开的精确形式。显而易见，对于本领域的技术人员而言，许多修改和变型将是清楚的。选择实施方式并进行了描述，以最佳地说明本发明的原理及其实际应用，由此使本领域的其它技术人员能够理解本发明的各种实施方式和适于预料中的特定使用的各种修改。本发明的范围旨在由以下权利要求书及其等同物来限定。

Claims (4)

1.一种图像形成设备，该图像形成设备包括：

架构上的多个应用，所述多个应用中的每一个被分离成管理基础处理的核心逻辑部分、以及管理渲染处理的用户接口框架部分，并且所述应用在所述架构上操作；以及

控制器，所述控制器执行所述应用和所述架构，

其中，每个用户接口框架部分只与对应的核心逻辑部分通信，

其中，所述核心逻辑部分用由所述架构所限定的应用编程接口来实现，并且

其中，所述多个应用包括特定应用，所述特定应用的核心逻辑部分将用户信息共同地存储在用户上下文中，所述特定应用使具有所述用户信息的所述用户上下文激活，并且另一个应用的核心逻辑部分从激活的用户上下文获取所述用户信息。

2.根据权利要求1所述的图像形成设备，

其中，所述多个应用中包括的所述特定应用的核心逻辑部分与用户的登录关联地将所述用户信息存储在所述用户上下文中。

3.根据权利要求1或2所述的图像形成设备，

其中，在画面的顶部显示所述应用时，所述应用从所述用户上下文获取所述用户信息。

4.一种图像形成设备，该图像形成设备包括：

多个应用，所述多个应用中的每一个被分离成管理基础处理的核心逻辑部分、以及管理渲染处理的用户接口框架部分，并且所述应用在架构上操作；以及

控制器，所述控制器执行所述应用和所述架构，

其中，每个用户接口框架部分只与对应的核心逻辑部分通信，

其中，所述核心逻辑部分用由所述架构所限定的应用编程接口来实现，并且

其中，所述多个应用包括特定应用，在所述图像形成设备激活时，所述特定应用的核心逻辑部分将系统特定信息共同地存储在全局上下文中，并且另一个应用的核心逻辑部分从所述全局上下文获取所述系统特定信息。

Images