CN104796453A - 信息处理终端及控制方法 - Google Patents

Abstract

本发明提供信息处理终端及控制方法。为了经由用户代理，来调用驻留在所述信息处理终端中的应用提供的功能，代理应用将该应用的定义信息转换为Web Intents格式，并且利用所述用户代理来登记所转换的信息。响应于Web Intents请求，所述用户代理向用户提供画面，该画面用来调用驻留在网络上的服务、以及驻留在所述信息处理终端中的所述应用提供的功能。响应于由用户向所述画面发出的选择指令，所述用户代理经由所述代理应用来调用所述应用的功能。

Description

信息处理终端及控制方法

技术领域

本发明涉及能够用来使驻留在网络上的服务和驻留在信息处理终端中的应用相互协作的技术。

背景技术

近年来，随着诸如智能电话等的信息处理终端的普及，用来实现多个应用之间的协作以及用来向用户提供更高级的服务的方案已进入实践。

例如，日本特开2013-96969号公报讨论了如下的技术：随着第一应用将图像标识符传递到第二应用，第二应用变得能够显示比第一应用显示的图像的分辨率更高的图像。

此外，在互联网上，已提出了如下的方案，该方案用来实现驻留在具有Web服务器功能的网站中的Web应用之间的协作。这些方案的示例包括Web Intents(Web意图)。

然而，在日本特开2013-96969号公报中讨论的上述技术，使驻留在信息处理终端中的两个应用能够相互协作，而未考虑到与互联网上的Web应用的协作。

此外，诸如Web Intents等的新协作方案使Web应用能够相互协作，而不能实现与驻留在信息处理终端中的一般应用的协作。

发明内容

本发明是针对使在信息处理终端内执行的应用和Web应用能够轻松地相互协作的方案。

根据本发明的一方面，提供一种信息处理终端，其具有使得客户端和服务能够经由网络相互协作的中继功能，所述客户端管理数据，并且所述服务利用由所述客户端管理的数据来提供功能，该信息处理终端包括：接收单元，其用于接收功能信息，该功能信息用于调用驻留在所述网络上的第一服务提供的功能；转换单元，其用于将驻留在所述信息处理终端中的第二服务的定义信息，转换为所述功能信息的格式，以便经由所述中继功能来调用所述第二服务提供的功能；登记单元，其用于进行用于调用所述第一服务及所述第二服务提供的功能的、使用所述中继功能的登记处理；以及提供单元，其用于根据所述登记处理，向用户提供用来调用所述第一服务及所述第二服务提供的功能的画面，其中，根据由用户向所述画面发出的选择指令，利用由所述接收单元接收到的所述功能信息、或者由所述转换单元转换所述定义信息而获得的信息，来进行功能的调用。

通过以下参照附图对示例性实施例的描述，本发明其他的特征将变得清楚。

附图说明

图1例示了Web Intents的基本系统配置的示例。

图2是例示Web Intents的基本操作的示例概要的序列图。

图3A及图3B例示了Web Intents中的登记标记的示例以及WebIntents中的基本Web Intent处理请求的示例。

图4例示了Local Intents(本地Intents)的总体配置的示例。

图5是例示Local Intents的基本操作的示例概要的序列图。

图6A及图6B例示了Local Intents中的登记标记的示例以及LocalIntents中的基本Local Intent处理请求的示例。

图7例示了根据本发明的示例性实施例的系统配置。

图8例示了信息处理终端的示例硬件配置。

图9A和图9B分别例示了服务器和信息处理终端的示例软件配置。

图10A、图10B、图10C及图10D例示了根据第一示例性实施例的表的示例配置。

图11是例示根据第一示例性实施例的、在安装代理应用时进行的示例操作的序列图。

图12是例示根据第一示例性实施例的、当客户端和协作目的地应用进行协作时进行的示例操作的序列图。

图13A及图13B例示了根据第一示例性实施例的信息处理终端的示例用户界面(UI)。

图14A和图14B分别例示了根据第二示例性实施例的代理应用的清单文件和源代码的示例。

图15A、图15B及图15C例示了根据第三示例性实施例的表的示例配置。

图16是例示根据第三示例性实施例的、在安装代理应用时进行的示例操作的序列图。

图17是例示根据第三示例性实施例的、当客户端和协作目的地应用进行协作时进行的示例操作的序列图。

图18A及图18B例示了根据第三示例性实施例的信息处理终端的示例UI。

图19例示了根据第四示例性实施例的代理应用的清单文件的示例。

图20例示了根据第四示例性实施例的信息处理终端的示例用户界面(UI)。

具体实施方式

下面，将参照附图来详细描述本发明的各种示例性实施例、特征及方面。

<Web Intents的基本结构>

首先，参照图1至图3A来描述关于Web Intents的基本结构，WebIntents是用于在不使用专用的应用编程接口(API)的情况下与任意的Web服务(或Web应用)协作的示例框架(framework)。虽然在本发明的示例性实施例中，以Web Intents作为具体示例，但是也可以应用其他类似的框架，作为用来与任意的Web服务(或Web应用)协作的技术。

图1例示了Web Intents的总体配置。

参照图1，Web Intents服务(以下简称“服务”)103利用Web Intents技术来提供服务或功能。Web Intents客户端(以下简称“客户端”)101使用服务103。用户代理(UA)106用来将来自客户端101的请求传递到服务103，并且将来自服务103的结果传递到客户端101。UA 106可以说是如下的中继功能，该中继功能用于在客户端101与服务103之间进行请求和交换数据。此外，UA 106使得能够利用UA 106来登记WebIntent，该Web Intent是用于调用服务103的提供功能(服务103提供的功能)的信息。

在本结构中，例如，客户端101是布置有用于管理数据和调用服务的按钮的网站。UA 106是用于显示该网站的Web浏览器。服务103是作为客户端101的协作目的地的网站，该网站用于经由UA 106来接收由客户端101管理的数据，并且处理所述数据。

例如，在本结构被应用于社交网络服务(SNS)的情况下，服务103是如下的发布(posting)目的地服务，该发布目的地服务接收由客户端管理的照片或评论，并且构成浏览站点。如果将SNS服务的诸如“喜欢”、“检查”及“共享”等的社交按钮比作Web Intents的结构，则客户端101是布置有按钮的站点，UA 106是Web浏览器，并且服务103是诸如“喜欢”等的发布对象(post)被递送到的发布目的地服务。当服务103提供服务时，如果需要用户验证或用户操作，则用户在UA 106上进行此种操作。

除了Web浏览器之外，还可以利用在信息处理终端上运行的操作系统(OS)或应用，来实现UA 106，只要UA 106具有用于与后述服务协作的功能即可。信息处理终端的示例包括个人计算机、智能电话、平板型计算机和汽车导航系统。

服务103也可以是服务提供者，其示例除了诸如上述发布目的地服务等的互联网上的服务提供者之外，还包括内置于信息处理终端中的诸如照相机、打印机及扫描器等的设备。此外，服务103的示例包括诸如打印机、扫描器和网络照相机等的外围设备、以及诸如冰箱及电视机等的家用电器，这些设备经由网络而被连接。客户端101、UA 106及服务103的任意组合均能够在同一系统内运行。具体而言，具有与Web浏览器等同的功能的文档编辑应用，可以作为包括客户端101及UA 106的配置而操作。此外，客户端101、UA 106及服务103可以全部在同一装置上运行。

图2是例示关于使用Web Intents的服务的提供的基本操作的序列图。该序列图包含包括步骤S201至S207的服务登记部、以及包括步骤S208至S222的服务执行部。

首先，描述服务登记部。

在步骤S201中，UA 106响应于用户操作而访问服务103。在步骤S202中，服务103生成包括登记标记的超文本标记语言(HTML)响应，所述登记标记用来使服务103提供的功能被UA 106登记。在步骤S203中，服务103将HTML响应发送到UA 106。

图3A例示了在步骤S203中从服务103发送到UA 106的HTML文档300的示例。下面，参照图3A中所示的示例，来描述从服务103发送到UA 106的HTML文档300的内容。

在<intent>标签中，描述了用于指定提供功能以及调用服务103提供的功能的功能信息。action(动作)属性代表提供功能的分类信息(类别)。换言之，action属性代表如下的分类信息，该分类信息表示提供功能提供何种功能或服务。提供功能的分类信息的示例包括与共享数据的功能相对应的分类信息“Share”(共享)、与编辑数据的功能相对应的分类信息“Edit”(编辑)、与查看数据的功能相对应的分类信息“View”(查看)、与拾取数据的功能相对应的分类信息“Pick”(拾取)以及与保存数据的功能相对应的分类信息“Save”(保存)。换言之，在上述的功能信息中，描述了例如Share、Edit、View、Pick及Save中的任何一者的分类信息。

type(类型)属性代表提供功能能够处理的数据的类型。换言之，type属性代表针对action属性能够处理的数据类型。href属性代表提供功能的连接目的地(统一资源定位符(URL))。title(标题)属性代表提供功能的标题。disposition(布置)属性代表调用的提供功能如何被显示。

在图3A中所示的示例中，提供功能的类别是“Share”，能够处理的数据的类型是“每种格式(*)的图像数据”，并且连接目的地是“share.html”。此外，标题是“Share image using e-mail”(利用电子邮件共享图像)。此外，该示例表示经由UA 106在单独的窗口上显示该提供功能。

在步骤S204中，UA 106接收并分析HTML响应。在步骤S205中，UA 106显示提供功能登记画面(例如，在UA 106是Web浏览器的情况下显示弹出窗口)，以提示用户确定是否利用UA 106来登记服务103的提供功能。在步骤S206中，UA 106确定用户是否已决定利用UA 106来登记服务103的提供功能。如果用户已决定将提供功能登记为Web Intents(步骤S206：是)，则在步骤S207中，UA 106进行登记处理，以将在步骤S204中接收到的信息存储在UA 106中。具体而言，UA 106将在步骤S204中接收到的信息，存储到运行UA 106的信息处理终端的存储区中，从而将信息作为Web Intents登记在UA 106中。另一方面，如果用户已决定不将提供功能登记为Web Intents(步骤S206：否)，则UA 106不进行Web Intents的登记处理。

接下来，描述服务执行部。

在步骤S208中，UA 106响应于用户操作而访问客户端101。在步骤S209中，客户端101生成描述了如下信息的HTML文档，所述信息表示客户端101打算使用服务103的提供功能(Web Intent)。在步骤S210中，客户端101将HTML文档发送到UA 106。例如，在充当客户端101的网站上显示“共享”按钮以及图像的情况下，该网站向UA 106发送作为WebIntent处理请求的HTML文档，该HTML文档包括诸如图3B中所示的ECMAScript。

图3B例示了在步骤S210中从客户端101发送到UA 106的HTML文档400的示例。下面，参照图3B中所示的示例，来描述从客户端101发送到UA 106的HTML文档400的内容。

ECMAScript表示在点击具有HTML中的ID“share-photo”(共享照片)的按钮时，执行指定的未命名函数。未命名函数首先生成新的Intent对象，并且使用该新Intent对象作为参数，来调用startActivity()函数。当该函数被执行时，UA 106从通过使用UA 106自身而登记的Web Intents之中，提取action及type与指定的Web Intent对象一致的Web Intents，并且显示提取出的Web Intents的列表，从而提示用户进行选择。此外，UA 106执行在未命名函数内调用的getImageFrom()函数，以获取存储在客户端101中的图像数据。

在步骤S211中，UA 106接收从客户端101发送的HTML文档，并且显示基于所接收到的HTML文档的画面。在步骤S212中，当检测到画面上的“共享”按钮被用户按下时，UA 106如上所述执行用于启动WebIntents的ECMAScript，并且向客户端101发出图像数据获取请求。在步骤S213中，在接收到在步骤S212中发出的图像数据获取请求时，客户端101准备图像数据。在步骤S214中，客户端101将所准备的图像数据发送到UA 106。然后，UA 106接收从客户端101发送的图像数据。

随着在步骤S212中的“共享”按钮的按下，而后在步骤S215中，UA106确定是否利用UA 106自身登记了任何Web Intents。如果利用UA 106登记了任何Web Intents(步骤S215：是)，则在步骤S216中，UA 106显示利用UA 106登记的Web Intents的列表。如果未利用UA 106登记表示提供功能的Web Intents(步骤S215：否)，则处理进入到步骤S221。在步骤S221中，UA 106向客户端101发送表示处理失败的消息。

当检测到用户从Web Intents的列表中，选择了表示服务103的提供功能的Web Intent，则在步骤S217中，UA 106向提供所选择的提供功能的服务103，发送超文本传送协议(HTTP)请求(Web Intent处理请求)。此时，UA 106在发送的数据中，包括通过图3B中所示的ECMAScript而创建的Web Intent对象的内容。

在步骤S218中，服务103从接收自UA 106的HTTP请求(Web Intent处理请求)中提取Web Intent对象，并且在经由UA 106与用户交互的同时，实现选择的提供功能(在此，为属于客户端101的图像数据的“共享”)的使用。

在关于提供功能的处理完成时，在步骤S219中，服务103向UA 106发送响应，该响应包括用于将处理结果发送到客户端101的ECMAScript。在步骤S220中，UA 106执行该响应中包括的ECMAScript，并且调用回调函数onSuccess()，该回调函数onSuccess()是由在步骤S211中获得的startActivity()函数的参数而指定的。在步骤S221中，UA 106根据回调函数onSuccess()，将处理结果发送到客户端101。最后，在步骤S222中，客户端101接收所述处理结果。

在此，描述在图2中所示的序列中使用WebMail的示例。首先，用户使用Web浏览器(UA 106)来访问提供了如下按钮的站点，所述按钮用于调用管理照片数据的Web存储(客户端101)的Web Intents，并且，用户按下该按钮。然后，Web浏览器(UA 106)显示包括登记的服务的列表的弹出窗口。当用户选择WebMail功能作为服务时，在单独的窗口上显示用于提供WebMail功能的站点，并且作为处理结果，在该窗口上创建附加有照片数据的新邮件。在以下的描述中，将如上所述的操作称为“处理Web Intent”，所述操作用于从Web Intent处理请求中提取WebIntent对象，并且分析和处理该Web Intent对象。

上述的处理使客户端101能够经由UA 106，来调用服务103提供的Web Intents的功能(在该示例中，为图像数据的“共享”)。

<关于移动终端内的应用之间的协作的基本方案>

接下来，参照图4及图5，来描述关于在作为信息处理终端的示例的移动终端内运行的应用之间的协作的基本方案。在本示例性实施例中，描述在Android(注册商标)(安卓)等在移动终端内作为操作系统运行的情况下的示例。

在Android(注册商标)操作系统(OS)中，使用Intents来进行协作，诸如在多个应用之间传递和接收数据。在此，Android中的Intents是指在应用之间的协作中用于服务的调用的登记信息，或者是指使用登记信息的方案。在本说明书中的以下描述中，作为如下的登记信息的示例的Intents被称为“Local Intents”(本地Intents)，以与Web Intents进行区分，所述登记信息用于调用在由Android等的OS执行的终端内运行的不同应用的功能。此外，本发明还能够适用于运行除Android以外的OS的情况，只要具有类似的方案，以实现如上所述的、在终端内运行的应用之间的数据交换或服务协作即可。

图4例示了Local Intents的总体配置。

参照图4，在信息处理终端102中，协作目的地应用503利用LocalIntents技术来提供功能。协作源应用501使用协作目的地应用503的功能。控制单元502将来自协作源应用501的请求传递到协作目的地应用503，并且将来自协作目的地应用503的结果传递到协作源应用501。可以利用例如OS来实现控制单元502。

图5是例示关于使用Local Intents的功能的提供的基本操作的序列图。该序列图包含包括步骤S601及S602的应用登记部、以及包括步骤S603至S612的应用执行部。

首先，描述应用登记部。

在通过用户操作等被安装在信息处理终端102上之后，在步骤S601中，协作目的地应用503向控制单元502，发送关于协作目的地应用503提供的功能的信息。在接收到来自协作目的地应用503的信息时，在步骤S602中，控制单元502利用控制单元502，来登记关于协作目的地应用503提供的功能的信息。

图6A例示了清单文件700的一部分的示例，该清单文件700用于在协作目的地应用503被安装之后，利用控制单元502来登记协作目的地应用503提供的功能。

在清单文件700中，记载了<application>(应用)标签。在<application>标签中，描述了协作目的地应用503提供的功能的定义信息。在<activity>(活动)标签中，描述了关于协作目的地应用503提供的功能的信息。在协作目的地应用503提供多个功能的情况下，在清单文件700中，记载与提供的功能的数量相对应的数量的<activity>标签。

在<intent-filter>(Intent过滤器)标签中，描述了如下的信息，该信息用于向控制单元502，通知该功能能够接受何种Local Intent请求、以及该功能能够处理何种数据。具体而言，在<intent-filter>标签中，记载了<action>、<category>(类别)及<data>(数据)标签。

<action>标签表示该功能能够接受何种Local Intents请求。<category>标签表示代表该功能的类型的附加信息。<data>标签表示该功能能够处理的数据的类型。换言之，<data>标签表示针对<action>标签的内容能够被处理的数据的类型。图6A中所示的示例表示，“activity”的名称是“SendActivity”(发送活动)的功能接受发送数据(intent.action.SEND)(Intent.动作.发送)的Local Intent请求。此外，<data>标签的描述表示能够处理的数据的类型是每种格式(*)的图像数据。

接下来，描述应用执行部。

在步骤S603中，在接收到诸如按钮的按下等的用户操作时，协作源应用501向控制单元502发送Local Intent处理请求作为应用协作处理请求，以便与其他应用协作。在步骤S604中，控制单元502接收在步骤S603中发送的请求。在步骤S605中，控制单元502显示能够与协作源应用501协作的应用的列表。在此，参照图6B，来详细描述用于在步骤S603中、使协作源应用501接受按钮的按下的源代码的示例、以及步骤S603及S604中的操作。

图6B例示了用于在步骤S603中、使协作源应用501接受按钮的按下的源代码800的一部分的示例。

源代码800由两个函数onClick()及onActivityResult()组成。onClick()函数是协作源应用501在接受按钮的按下时执行的函数。onActivityResult()函数协作源应用501在从控制单元502接收到响应于Local Intent处理请求而获得的结果时执行的函数。

当用户界面(UI)上显示的按钮被按下时，协作源应用501执行onClick()函数。在onClick()函数中，协作源应用501生成新的Local Intent对象，并且使用该新的Local Intent对象作为参数，来调用控制单元502的startActivityForResult()函数(步骤S603)。在startActivityForResult()函数被执行之后，控制单元502接收作为应用协作处理请求的Local Intent处理结果(步骤S604)。接下来，控制单元502提取如下的应用，这些应用提供利用控制单元502而登记的提供功能之中的、Action(动作)及Type(类型)与指定的Local Intent一致的提供功能，并且，控制单元502显示提取出的应用的列表。然后，控制单元502接受用户进行的协作目的地应用的选择(步骤S605)。在图6B中所示的示例中，Action表示ACTION_SEND(动作_发送)，并且显示了能够处理每种格式(*)的图像数据的应用的列表。因此，协作目的地应用503也被显示在列表中。

现在，返回到图5进行描述。

当由用户从列表中选择了协作目的地应用503时，在步骤S606中，控制单元502向选择的协作目的地应用503发送应用处理请求。具体而言，控制单元502向选择的协作目的地应用503传递Local Intent处理请求。此时，控制单元502在该Local Intent处理请求中，包括Local Intent对象的内容。

在步骤S607中，协作目的地应用503接收Local Intent处理请求。在步骤S608中，协作目的地应用503从在步骤S607中接收到的LocalIntent处理请求中，提取Local Intent对象，并且实现要提供的功能(由协作源应用501请求的功能)。例如，协作目的地应用503从Local Intent对象中提取图像数据，并且将图像数据存储到协作目的地应用503自身管理的区域中。在以下的描述中，将如上所述的操作称为“处理LocalIntent”，所述操作用于从Local Intent处理请求中提取Local Intent对象，并且分析和处理提取出的Local Intent对象。

在Local Intent处理完成时，在步骤S609中，协作目的地应用503将处理结果发送到控制单元502。在步骤S610中，控制单元502接收所述处理结果。在步骤S611中，控制单元502调用回调函数onActivityResult()，以将处理结果发送到协作源应用501。在步骤S612中，协作源应用501接收所述处理结果。

上述的处理使协作源应用501能够经由控制单元502，来调用协作目的地应用503提供的功能。

<本发明的示例性实施例中的系统配置>

图7例示了根据本发明的示例性实施例的、应用Web Intents的方案的网络系统的配置示例。

参照图7，在信息处理终端102上，运行充当Web Intents的用户代理(UA)的Web浏览器106、控制单元502以及协作目的地应用503。此外，在信息处理终端102上，还运行后述的图9B中所示的代理应用901。在服务器104上，运行Web Intents的客户端101。

信息处理终端102和服务器104能够经由网络105相互通信。网络105可以是局域网(LAN)、互联网或此二者的组合。网络105的连接配置可以是有线的或无线的。

<根据本示例性实施例的信息处理终端102的硬件配置示例>

图8是例示执行充当UA 106、协作目的地应用503及代理应用901的程序的信息处理终端102的硬件配置的框图。此外，运行充当客户端101的程序(网站等)的服务器104也可以具有类似的配置。

参照图8，信息处理终端102包括中央处理单元(CPU)1002、随机存取存储器(RAM)1003、只读存储器(ROM)1004及外部存储设备1009。CPU 1002执行存储在ROM 1004及外部存储设备1009中的程序，或是在诸如LAN或互联网等的网络105上下载的程序，并且CPU 1002全面地控制连接到系统总线1011的各设备。

RAM 1003充当CPU 1002的主存储器或工作区。外部存储设备1009由硬盘(HD)或存储卡(MC)组成。外部存储设备1009存储包括引导程序、操作系统、验证服务器及验证客户端的各种应用、数据库数据以及用户文件。

键盘控制器(KBDC)1006向CPU 1002，发送来自键盘(KBD)1005或定点设备(未例示)的输入信息。在信息处理终端102是移动终端的情况下，一般可以利用软件来实现键盘1005。

视频控制器(VC)1008控制显示设备1007的显示操作，所述显示设备1007由阴极射线管(CRT)或液晶设备(LCD)组成。盘控制器(DKC)1010控制对外部存储设备1009的访问。信息处理终端102经由通信控制器(COMM I/F)1012连接到网络105。

<根据本示例性实施例的服务器104的软件配置示例>

图9A例示了服务器104的软件(处理单元)的配置示例。

在服务器104中，客户端101及各处理单元作为存储在服务器104的外部存储设备1009中的文件而存在。这些文件是程序模块，这些程序模块在执行时，被其他处理单元(服务器104的CPU 1002)利用OS或其各处理单元，而加载到服务器104的RAM 1003上，然后被执行。

客户端101是如下的应用，该应用提供例如存储服务，诸如图像数据或文档数据的存储。客户端101被实现为响应于HTTP请求来执行处理的程序。客户端101包括Intent处理请求生成单元1102、呈现单元1103及数据管理单元1105。

Intent处理请求生成单元1102是如下的软件模块，该软件模块生成作为Intent处理请求的ECMAScript。呈现单元1103是如下的软件模块，该软件模块响应于经由通信单元1101接收的页面获取请求来生成HTML文档。数据管理单元1105是如下的软件模块，该软件模块响应于来自呈现单元1103的请求，而在客户端数据存储单元1106中获取或存储诸如图像数据等的数据。

客户端数据存储单元1106存储和管理数据，并且响应于来自其他处理单元的请求，来进行数据的存储及检索。客户端数据存储单元1106存储并管理诸如后述的图10A中所示的图像数据管理表1210、以及诸如图像数据等的数据。此外，客户端数据存储单元1106可以位于其他装置上。

通信单元1101是如下的软件模块，该软件模块接收来自外部装置的HTTP请求消息，并且将该HTTP请求消息的内容通知给呈现单元1103。此外，通信单元1101响应于来自呈现单元1103的请求，而向外部装置发送HTTP响应消息。

<根据本示例性实施例的信息处理终端102的软件配置示例>

图9B例示了信息处理终端102的软件(处理单元)的配置示例。

在信息处理终端102中，控制单元502、UA 106、协作目的地应用503、代理应用901以及各处理单元，作为存储在信息处理终端102的外部存储设备1009中的文件而存在。这些文件是程序模块，这些程序模块在执行时，被其他处理单元(信息处理终端102的CPU 1002)利用OS或其各处理单元，而加载到信息处理终端102的RAM 1003上，然后被执行。

应用信息存储单元1121连接到控制单元502。例如，在进行图5中所示的步骤S601之后，在步骤S602中，控制单元502利用应用信息存储单元1121，来登记在诸如图6A中所示的清单文件中描述的信息。应用信息存储单元1121存储并管理诸如后述的图10B中所示的已登记应用管理表1220。

UA 106包括显示单元1142、分析单元1143及服务管理单元1144。显示单元1142是绘制HTML文档的软件模块。此外，显示单元1142响应于来自其他处理单元的请求，而显示用来接受服务的选择的画面。

分析单元1143是分析HTML文档的软件模块。分析单元1143还分析作为Intent处理请求的ECMAScript。服务管理单元1144是如下的软件模块，该软件模块在后述的服务存储单元1145中，获取或存储指定登记的提供功能的信息。服务存储单元1145管理Web Intents的提供功能的列表，所述Web Intents的提供功能包括图1中所示的服务103、以及后述的代理应用901提供的提供功能，并且，服务存储单元1145响应于来自服务管理单元1144的请求，而进行数据的存储及检索。服务存储单元1145存储并管理诸如图10C中所示的已登记Web Intents服务表1230。此外，服务存储单元1145可以位于信息处理终端102的外部存储设备1009内，或者可以位于不同于信息处理终端102的装置上。

代理应用901包括呈现单元1111、Intent转换单元1112、转换表管理单元1113及Intent处理单元1114。呈现单元1111是如下的软件模块，该软件模块响应于利用控制单元502来登记关于协作目的地应用503的信息的请求，来生成HTML文档。此外，协作目的地应用503提供的功能不符合用于UA 106的登记处理的格式(Web Intents的格式)。

Intent转换单元1112是如下的软件模块，该软件模块进行Web Intents格式的信息和Local Intents格式的信息的转换。转换表管理单元1113是如下的软件模块，该软件模块在后述的转换表存储单元1115中，获取或存储用于Intent转换单元1112进行信息转换的转换表。Intent处理单元1114是如下的软件模块，该软件模块进行关于Local Intents的处理，诸如Local Intents信息的获取。

转换表存储单元1115管理如下的表，这些表用来进行Web Intents格式的信息和Local Intents格式的信息的转换，并且，转换表存储单元1115响应于来自转换表管理单元1113的请求，而进行数据的存储及检索。转换表存储单元1115存储并管理诸如后述的图10D中所示的Action转换表1240、应用信息转换表1250及已登记应用管理表1260。此外，转换表存储单元1115可以位于信息处理终端102的外部存储设备1009内，或者可以位于不同于信息处理终端102的装置上。

通信单元1150响应于来自其他处理单元的请求，而向外部装置或代理应用901发送HTTP请求消息。此外，通信单元1150是如下的软件模块，该软件模块接收来自外部装置或代理应用901的HTTP响应消息，并且将该HTTP响应消息的内容通知给分析单元1143。

图10A、图10B、图10C及图10D例示了根据第一示例性实施例的表的配置示例。

图10A例示了由服务器104的客户端101管理的图像数据管理表1210的配置示例。图10A中所示的表配置仅是示例，并且可以是不同的表配置。

图像数据管理表1210是如下的表，该表用来管理客户端101处理的图像数据。利用图像数据管理表1210管理的信息包括“ImageID”(图像ID)及“File”(文件)。“ImageID”是如下的标识符(ID)，该ID用于在客户端101中唯一地识别各特定数据。“File”代表各特定数据的文件名。因此，在图像数据管理表1210的情况下，两个图像数据文件“image125.jpg”及“image435.jpg”被管理。

图10B例示了由信息处理终端102的控制单元502管理的已登记应用管理表1220的配置示例。图10B中所示的表配置仅是示例，并且可以是不同的表配置。

已登记应用管理表1220是如下的表，该表用来管理利用信息处理终端102登记的应用的提供功能的列表。由已登记应用管理表1220管理的信息包括“App ID”(应用ID)、“application name”(应用名称)、“action”及“mime(多用途互联网邮件扩展(MIME))type”(MIME类型)。“AppID”是如下的ID，该ID用于在控制单元502中唯一地识别各应用的提供功能。“application name”代表各应用的名称。“action”代表各应用能够提供的功能的类别。“mime type”表示各应用能够处理的数据等的类型。

图10C例示了由信息处理终端102的UA 106管理的已登记WebIntents服务表1230的配置示例。图10C中所示的表配置仅是示例，并且可以是不同的表配置。

已登记Web Intents服务表1230是如下的表，该表用来管理关于UA106能够中继的Web Intents的提供功能的信息。由已登记Web Intents服务表1230管理的信息包括“ID”、“action”、“type”、“href”、“title”及“baseURL”(基URL)。这些元素对应于由图3A中所示的<intent>标签表示的信息。

“ID”是如下的ID，该ID用于在UA 106中唯一地识别Web Intents的各提供功能。“action”代表各提供功能的类别。“type”代表各提供功能能够处理的数据等的类型。“href”代表各提供功能的连接目的地(URL)。“title”代表各提供功能的标题。“base URL”代表如下的URL，该URL充当提供各提供功能的站点的基准。

图10D例示了由信息处理终端102的代理应用901管理的各表的配置示例。图10D中所示的表配置仅是示例，并且可以是不同的表配置。

代理应用901管理Action转换表1240、应用信息转换表1250以及已登记应用管理表1260。

Action转换表1240是如下的表，该表用来管理Web Intents action(Web Intents动作)和Local Intents action(Local Intents动作)的转换方法。应用信息转换表1250是如下的表，该表用来管理通过将信息处理终端102中的各应用的信息转换为Web Intents格式的信息而获得的结果。已登记应用管理表1260类似于图10B中所示的已登记应用管理表1220。

由Action转换表1240管理的信息包括“ID”、“Web Intents action”及“Local Intents action”。“ID”是如下的ID，该ID用于在代理应用901中唯一地识别转换方法。“Web Intents action”代表Web Intents的action信息。“Local Intents action”代表Local Intents的action信息。

由应用信息转换表1250管理的信息包括“ID”、“App ID”、“action”、“type”、“href”、“title”及“base URL”。“ID”是用于唯一地识别转换的WebIntents信息的ID。“App ID”是如下的ID，该ID用于唯一地识别利用应用信息转换表1250进行信息转换的各应用。在图10D中所示的情况下，在应用信息转换表1250的“App ID”中，存储与已登记应用管理表1260的“App ID”相对应的ID。在应用信息转换表1250的“action”、“type”、“href”、“title”及“base URL”中，存储由已登记应用管理表1260的“application name”、“action”及“mime type”生成的信息。稍后描述此类信息的生成的规则。

由于已登记应用管理表1260类似于图10B中所示的已登记应用管理表1220，所以省略重复的描述。

接下来，参照图11及图12，来描述当客户端101和信息处理终端102中包括的协作目的地应用503相互协作时进行的操作。

首先，参照图11的序列图，来描述在如下的时段中进行的操作，所述时段从将代理应用901安装在信息处理终端102上时起，直到WebIntents的信息被存储到UA 106中时为止。

图11是例示在如下的时段中进行的操作的序列图，所述时段从将代理应用901安装在信息处理终端102上时起，直到Web Intents的信息被存储到UA 106中时为止。在此，进行如下的假设：关于协作目的地应用503的信息以与图5中所示的步骤S601及S602中类似的方式，利用控制单元502被预先登记，并且利用已登记应用管理表1220而被管理。

在步骤S1301中，响应于用户操作等，控制单元502将代理应用901安装在信息处理终端102上。在诸如文件复制等的与安装相关联的处理完成、并且代理应用901被启动之后，在步骤S1302中，代理应用901进行与安装相关联的处理，诸如利用控制单元502登记应用信息。

在步骤S1303中，代理应用901的Intent处理单元1114向控制单元502，发送对已登记应用信息的获取请求。例如，在Android OS中，Intent处理单元1114可以通过调用诸如PackageManager(包管理器)类的getInstalledApplications()等的各种函数，来发出获取请求。

在步骤S1304中，控制单元502接收在步骤S1303中发送的获取请求，并且从应用信息存储单元1121中，获取诸如图10B中所示的已登记应用管理表1220。然后，在步骤S1305中，控制单元502向代理应用901，发送所获取到的已登记应用管理表1220的信息，作为已登记应用信息收集结果。

在步骤S1306中，代理应用901接收在步骤S1305中发送的收集结果，并且经由转换表管理单元1113，将收集结果的副本存储到转换表存储单元1115中的已登记应用管理表1260中。

在步骤S1307中，代理应用901利用已登记应用管理表1260及Action转换表1240，在转换表存储单元1115内部生成应用信息转换表1250。

例如，在生成应用信息转换表1250中的“ID”是“1”的条目的信息的情况下，代理应用901将已登记应用管理表1260的“App ID”(在本示例中为“1”)，存储到应用信息转换表1250的“App ID”中。

代理应用901存储通过如下的转换而获得的值，所述转换利用Action转换表1240，将已登记应用管理表1260的“action”的值转换为应用信息转换表1250的“action”。在本示例中，已登记应用管理表1260的“action”的值是“ACTION_SEND”。通过利用Action转换表1240转换“ACTION_SEND”，产生应用信息转换表1250的“action”的值“http://WebIntents.org/share”。在本示例性实施例中，该值被简写为“share”(共享)。

此外，代理应用901将已登记应用管理表1260的“mime type”的值，存储到应用信息转换表1250的“type”中。代理应用901在应用信息转换表1250的“href”中，登记代理应用901能够识别的连接目的地，作为相对连接目的地(URL)。在此，代理应用901登记由已登记应用管理表1260的“action”的值而生成的字符串(ACTION_SEND.html)。

代理应用901将已登记应用管理表1260的“application name”的值，存储到应用信息转换表1250的“title”中。代理应用901在应用信息转换表1250的“base URI”(基URI)中，登记通过将应用名称“aaa App”附加至“http://localhost/proxy/”而获得的“http://localhost/proxy/aaa_App”。在此，“http://localhost/proxy/”是代理应用901自身的基准URL。通过组合上述的“href”和“base URI”，能够生成Web Intents的公开Web页。

此外，虽然在上述示例中，“mime type”及“application name”的值被直接存储在应用信息转换表1250的“type”及“title”中，但是，转换表也可以被单独使用。此外，可以在应用信息转换表1250的“href”及“base URI”中，登记通过不同生成规则而生成的值。如上所述，代理应用901的Intent转换单元1112依照Web Intents的功能信息中包括的分类信息的格式，来转换信息处理终端102中的应用的定义信息中包括的分类。

在步骤S1308中，代理应用901的Intent处理单元1114生成用于启动UA 106的Local Intent处理请求，并且将该Local Intent处理请求发送到控制单元502。此时，Intent处理单元1114指定由代理应用901公开的、用来登记Web Intents服务的Web页的URL，作为UA 106访问的URL。在此，指定的URL是“http://localhost/proxy/”。

在步骤S1309中，控制单元502经由通信单元1150，来接收在步骤S1308中发送的Local Intent处理请求。在步骤S1310中，控制单元502启动UA 106，以便访问在步骤S1308中指定的URL。

在被控制单元502启动之后，在步骤S1311中，UA 106向在步骤S1310中指定的URL，发送HTML获取请求作为HTTP请求。换言之，UA 106访问在步骤S1308中指定的、由代理应用901公开的Web页。在这种情况下，具体而言，来自UA 106的HTTP请求经由通信单元1150而被传递到代理应用901。

在步骤S1312中，代理应用901检测对公开Web页的访问。然后，在步骤S1313中，代理应用901的呈现单元1111生成Web Intents服务的登记标记。在本示例中生成的Web Intents服务的登记标记，用于登记在步骤S1307中生成的应用信息转换表1250中登记的、Web Intents格式的信息。

在步骤S1314中，代理应用901的呈现单元1111向UA 106，发送包括在步骤S1313中生成的登记标记的HTML文档，作为HTTP响应。在步骤S1315中，UA 106接收在步骤S1314中发送的HTTP响应。然后，在步骤S1316中，UA 106的分析单元1143分析在步骤S1315中接收到的HTML文档中包括的登记标记，并且登记Web Intents服务。具体而言，分析单元1143分析登记标记，以指定Web Intents服务。然后，UA 106的服务管理单元1144将所需的信息，登记在服务存储单元1145的已登记Web Intents服务表1230中。

如上所述，通过执行图11中所示的序列而登记的Web Intents服务是如下的项目，这些项目的已登记Web Intents服务表1230的“ID”的值是“4”、“5”及“6”。

以上，描述了图11中所示的序列图。

接下来，参照图12的序列图，来描述当客户端101和协作目的地应用503相互协作时进行的操作。

图12是例示当客户端101和协作目的地应用503相互协作时进行的操作的序列图。图12中所示的步骤S1401至S1409中的处理类似于图2中所示的步骤S208至S216中的处理。下面，借助图13A及图13B中所示的用户界面(UI)的示例，来补充上述步骤的描述。图13A及图13B例示了当客户端101和协作目的地应用503相互协作时、在信息处理终端102的显示设备1007上显示的UI画面的示例。

图13A例示了在步骤S1404中显示由UA 106从客户端101接收的HTML文档的UI的示例。在图13A中所示的UI，对应于供客户端101用于将图像数据文件“image125.jpg”1502发送到其他服务的UI。在步骤S1405中，UA 106接受在图13A中所示的UI中对“发送”按钮1501的按下，并且执行用于Web Intents启动的ECMAScript，以向客户端101发出图像数据获取请求。

在此，假设执行图3B中所示的ECMAScript 400，则响应于“发送”按钮1501的按下，执行“action”是“http://Web Intents.org/share”的WebIntents。在步骤S1408及S1409中，UA 106从客户端101接收图像数据文件“image125.jpg”，并且显示利用UA 106自身而登记的Web Intents服务的提供功能的列表。具体而言，UA 106从在图10C中所示的已登记Web Intents服务表1230中登记的Web Intents信息中，提取“action”是“share”的服务，并且显示提取出的服务的列表。在图13B中，例示了显示有提取出的服务的列表的UI的示例。在图13B中所示的示例中，服务1511至1514的列表被显示为选项。

现在，返回到图12进行描述。

在步骤S1410中，与图2中的步骤S217类似地，UA 106响应于来自用户的对UI画面的选择指令，而将HTTP请求发送到被指定为选择的提供功能的连接目的地的服务。此时，与图2中的步骤S217类似地，UA106也在发送的数据中，包括由图3B中所示的ECMAScript 400生成的Intent对象的内容。在此，假设已由用户选择了代理应用901提供的提供功能(“aaa App”1513或“bbb App”1514)。在这种情况下，代理应用901接收在步骤S1410中发送的HTTP请求。

在步骤S1411中，代理应用901从在步骤S1410中接收到的HTTP请求中提取Web Intent对象，并且将提取出的Web Intent对象转换为LocalIntents格式。具体而言，代理应用901在使用图10D中所示的Action转换表1240的同时，将Web Intent对象的“action”转换为Local Intents格式的“action”。此外，代理应用901根据由代理应用901自身定义的规则，将“type”转换为“mime type”。同样，代理应用901从被UA 106调用的URL中，剪去协作目的地应用的信息。

在步骤S1412中，代理应用901作为协作源应用501，利用在步骤S1411中转换的信息明确地指定协作目的地应用503，并且向控制单元502发送Local Intent处理请求(对应于图5中的步骤S603)。控制单元502基于Local Intent处理请求，来选择协作目的地应用503，并且向协作目的地应用503发送应用处理请求(对应于图5中的步骤S604至S606)。协作目的地应用503执行请求的处理，并且经由控制单元502，将处理结果发送到充当协作源应用501的代理应用901(对应于图5中的步骤S607至S612)。步骤S1412与图5中所示的步骤S603至S612类似，因而省略重复的描述。

接下来，在步骤S1413中，代理应用901将从协作目的地503接收到的Local Intent处理结果，转换为Web Intents格式的处理结果。具体而言，代理应用901的Intent处理单元1114基于图6B中所示的回调函数onActivityResult()，来接收协作目的地应用503中的Local Intent处理结果(成功/失败)。接下来，代理应用901的Intent转换单元1112基于所接收到的处理结果，来生成要发送到客户端101的、包括ECMAScript的响应。

接下来，在步骤S1414中，代理应用901作为服务103，将在步骤S1413中生成的响应发送到UA 106。步骤S1415至S1417与图2中所示的步骤S220至S222类似，因而省略重复的描述。

以上，描述了图12中所示的序列图。

以上，也描述了第一示例性实施例。

如上所述，在第一示例性实施例中，代理应用901将从Web应用发出的处理执行请求，转换为信息处理终端中包括的应用能够处理的处理执行请求，并且进行中继操作(或者进行Intent解释或数据传送)。这使得能够由信息处理终端中包括的应用(协作目的地应用503)，来处理从互联网上的Web应用(客户端101)发出的处理请求。换言之，网络上的服务(互联网上的Web应用)和信息处理终端中包括的应用能够轻松地相互协作。

在上述第一示例性实施例中，描述了如下的示例：当安装代理应用901时，利用UA 106来登记关于之前存在的应用的信息。在第二示例性实施例中，描述如下的示例：在代理应用901被安装之后，利用UA 106来登记关于在信息处理终端102上新安装的应用的信息。

图14A和图14B分别例示了根据第二示例性实施例的代理应用901的清单文件和源代码的一部分的示例。

图14A例示了根据第二示例性实施例的代理应用901中包括的清单文件1600的一部分的示例。

如图14A所示，在代理应用901中包括的清单文件1600中，记载了<receiver>(接收者)标签。在<receiver>标签中，描述了关于代理应用901接收的广播Intent的信息。

在图14A中所示的示例中，作为代理应用901接收的广播Intent，记载了“PACKAGE_ADDED(包_被添加)(在信息处理终端上安装了新应用)”。广播Intent是当信息处理终端102的状态发生了改变时、控制单元502通过广播而发送的Intent。

图14B例示了代理应用901的源代码1700的一部分的示例。

在代理应用901的源代码1700中，记载了onReceiver()函数。onReceiver()函数是代理应用901在接收到从控制单元502发送的广播Intent时执行的函数。

当在代理应用901被安装之后、在信息处理终端102上安装了其他应用时，由控制单元502发送广播Intent，以调用onReceiver()函数。当检测到onReceiver()函数被调用时，代理应用901执行图11中所示的步骤S1303。换言之，代理应用901向控制单元502，发送对已登记应用信息的获取请求。结果，关于所述应用的信息被转换为Web Intents信息，然后被登记在UA 106的已登记Web Intents服务表1230中(图11中所示的步骤S1304至S1316)。之后客户端101和协作目的地应用503相互协作的过程，与第一示例性实施例中的图12中所示的类似。

以上，描述了第二示例性实施例。

如上所述，除了在第一示例性实施例中获得的有利效果之外，第二示例性实施例还具有如下的有利效果：即使当在代理应用901被安装之后、在信息处理终端102上安装了其他应用时，客户端101和协作目的地应用503也能够相互协作。

此外，在第一示例性实施例及第二示例性实施例中，描述了如下的示例：在信息处理终端102上安装了应用时，代理应用901经由控制单元502，将关于应用提供的功能的信息转换为Web Intents格式，并且利用UA 106来登记转换的Web Intents信息。然而，控制单元502、代理应用901或UA 106可以周期性地搜索信息处理终端102的内部，并且在该周期性搜索中检测到关于要新登记的应用提供的功能的信息时，可以将检测到的信息转换为Web Intents格式，并利用UA 106来登记转换的WebIntents信息。作为另一选择，控制单元502、代理应用901或UA 106可以在UA 106被启动时，搜索关于要新登记的应用提供的功能的信息，并且在该搜索中检测到关于要新登记的应用提供的功能的信息时，可以将检测到的信息转换为Web Intents格式，并利用UA 106来登记转换的WebIntents信息。

在第三示例性实施例中，进行如下的假设：关于要利用UA 106来登记的服务的信息，仅是关于代理应用901的提供功能的信息。然后，描述如下的示例：当用户选择了代理应用901的提供功能、作为Web Intent处理请求目的地时，在代理应用901的公开Web页上，列举出能够协作的应用。

图15A、图15B及图15C例示了根据第三示例性实施例的表的示例配置。

图15A至图15C例示了通过将适合于第三示例性实施例的数据、存储到图10B至图10D中所示的表中而获得的表的示例。

接下来，参照图16及图17，来描述第三示例性实施例中的、当客户端101和信息处理终端102中包括的协作目的地应用503相互协作时进行的操作。

首先，参照图16的序列图，来描述在如下的时段中进行的操作，所述时段从将代理应用901安装在信息处理终端102上时起，直到代理应用901的Web Intents信息被存储到UA 106中时为止。

图16是例示在如下的时段中进行的操作的序列图，所述时段从将代理应用901安装在信息处理终端102上时起，直到代理应用901的WebIntents信息被存储到UA 106中时为止。

当根据与图11中所示的步骤S1301及S1302中类似的处理、安装然后启动代理应用901时，代理应用901执行步骤S1901中的处理。在步骤S1901中，代理应用901通过使用图15C中所示的Action转换表1240，来生成图15C中所示的应用信息转换表1250。

此时，代理应用901将应用信息转换表1250的列“App ID”保留为空白，该列“App ID”在第三示例性实施例中不使用。在列“action”中，仅存储在Action转换表1240的列“Web Intents action”中存储的值之中的、不同值的类别。因此，在本示例中，在应用信息转换表1250的列“action”中，不存储ID＝4及ID＝6的“Web Intents action”的值，这两个值分别等于ID＝3及ID＝5的“Web Intents action”的值。换言之，代理应用901以如下的方式来生成应用信息转换表1250：使得列举出关于协作目的地应用能够提供的全部功能的类别的信息。

在列“type”中，存储了表示每种类型的标记“*”。用于存储“href”的值的方法与在步骤S1307中所述的方法类似，因而省略重复的描述。在列“title”中，存储了“Proxy Application”(代理应用)，这是代理应用901自身的应用名称。在列“base URI”中，存储了“http://localhost/proxy/”，这是代理应用901的基准URL。通过组合“href”和“base URI”的值，能够生成代理应用901的Web Intents的公开Web页。

步骤S1902中的处理与图11中所示的步骤S1308至S1316中类似，因而省略重复的描述。此外，在执行步骤S1901之前，代理应用901可以进行图11中所示的步骤S1303至S1306中的应用信息收集处理，并且可以预先生成图15C中所示的已登记应用管理表1260。在这种情况下，进行后述的图17中所示的步骤S2003中的处理，以更新已登记应用管理表1260的值。

以上，描述了图16的序列图。

接下来，参照图17的序列图，来描述当客户端101和协作目的地应用503相互协作时进行的操作。

图17是例示根据第三示例性实施例的、当客户端101和协作目的地应用503相互协作时进行的操作的序列图。

步骤S2001中的处理与图12中所示的步骤S1401至S1409中类似，因而省略重复的描述。在此，客户端101发出“action”是“share”的WebIntents请求。在这种情况下，UA 106显示诸如图18A中所示的UI，以接受用户对Web Intents处理目的地的选择。

由于客户端101发出了“action”是“share”的Web Intents请求，因此，UA 106从图15B中所示的已登记Web Intents服务表1230中，提取“action”是“share”的服务，并且将提取出的服务的列表显示为选项1801至1803。

在步骤S2002中，UA 106接收基于在步骤S2001中显示的提取的服务的列表的、Web Intents的选择。在此，假设选择充当选项1803的代理应用901，作为Web Intents处理目的地。UA 106向代理应用901，发送处理Web Intents的HTTP请求。

在步骤S2003中，代理应用901进行应用信息收集处理，并且将收集到的值，存储到图15C中所示的已登记应用管理表1260中。步骤S2003中的处理与图11中所示的步骤S1303至S1306中类似，因而省略重复的描述。

在步骤S2004中，代理应用901提取能够提供与客户端101请求的“action”(在本示例中为“share”)一致的功能的应用，并且显示提取出的应用的列表。为了实现上述的提取，代理应用901使用Action转换表1240和已登记应用管理表1260。

具体而言，代理应用901通过使用Action转换表1240，而将WebIntents的“action”(http://Web Intents.org/share)转换为Local Intents的“action”(ACTION_SEND)。接下来，代理应用901提取“action”是“ACTION_SEND”的提供功能的应用(“application name”)。

图18B例示了在步骤S2004被执行之后显示的UI的示例。在图18B中所示的UI的示例中，应用“aaa App”1811及“bbb App”1812被作为选项显示在列表中。

此外，如果要显示在列表中的项目的数量仅是1，则代理应用901可以假设该单个项目已被选择，而不显示诸如图18B中所示的UI画面，并且可以使处理前进到步骤S2006，而不执行步骤S2005。此外，如果不存在要显示的项目，则代理应用901以与图12中所示的步骤S1414中类似的方法，来发送表示处理失败的消息。

在步骤S2005中，代理应用901作为协作源应用，接受用户对协作目的地应用的选择。具体而言，在图18B中所示的UI的示例中，代理应用901接受应用“aaa App”1811或“bbb App”1812的选择。然后，当检测到应用“aaa App”1811或“bbb App”1812的选择时，代理应用901作为协作源应用，使处理前进到步骤S2006。

步骤S2006中的处理与图12中所示的步骤S1412至S1417中类似，因而省略重复的描述。以上，描述了图17的序列图。以上，也描述了第三示例性实施例。

如上所述，除了在第一示例性实施例中获得的有利效果之外，第三示例性实施例还具有如下的有利效果：即使当在信息处理终端上添加或删除了应用时，也能够通过在接收到Web Intents请求时更新关于应用的信息，来动态地建立该应用与Web应用之间的适当协作。

在第四示例性实施例中，描述了如下的示例：从UA 106的UI向代理应用901，发出协作目的地应用信息的更新处理的请求。

图19例示了根据第四示例性实施例的代理应用901中包括的清单文件2200的一部分的示例。

与图6A中所示的清单文件700相比，图19中所示的清单文件2200的不同之处在于，在<intent-filter>标签内的<action>标签中，记载了用于接受来自UA 106的更新处理请求的、名称为“intent.action.SYNC”(Intent.动作.同步)的“action”。

进行与图12中所示的步骤S1401至S1409中类似的处理，并且由UA 106，来显示供用户用于选择Web Intents处理目的地的列表。在这种情况下，根据第四示例性实施例的UA 106显示诸如图20中所示的UI，并且接受用户进行的选择。

图20例示了用于实现第四示例性实施例的UI的示例。

参照图20，“更新”按钮2301用来更新关于协作目的地应用的信息。

当检测到用户在图20中所示的UI上按下“更新”按钮2301时，UA 106向代理应用901，发出用于更新关于协作目的地应用的信息的LocalIntents处理(“action”是“intent.action.SYNC”)。这使代理应用901进行与“intent.action.SYNC”功能相对应的处理。在这种情况下，代理应用901、控制单元502及UA 106进行与图11中所示的步骤S1303至S1316中等同的处理，以更新已登记应用管理表1220。

换言之，在第四示例性实施例中，响应于通过在显示Web Intents的列表的画面上的“更新”按钮的按下而发出的更新指令，代理应用901经由控制单元502，来搜索关于要新登记的应用提供的功能的信息。然后，在该搜索中检测到关于要新登记的应用提供的功能的信息时，代理应用901将该信息转换为Web Intents格式，并利用UA 106来登记转换的WebIntents信息。

以上，描述了第四示例性实施例。

如上所述，除了在第一示例性实施例中获得的有利效果之外，第四示例性实施例还具有如下的有利效果：即使当在信息处理终端上添加或删除了应用时，也能够响应于用户的指令而更新关于应用的信息，并且动态地建立该应用与Web应用之间的适当协作。

此外，上述各种数据的配置和内容不是限制性的，并且一般可以根据预期的用途或目的而以各种方式进行修改。

虽然描述了一些示例性实施例，但是，本发明可以通过系统、装置、方法、程序或存储介质的形式而得以实施。此外，本发明可以应用于由多个设备组成的系统，或者可以应用于由单个设备组成的装置。

此外，在本发明中，还可以包括通过组合上述各示例性实施例而获得的各种配置。

其他实施例

本发明的实施例还可以通过如下的方法来实现，即，通过网络或者各种存储介质将执行上述实施例的功能的软件(程序)提供给系统或装置，该系统或装置的计算机或是中央处理单元(CPU)、微处理单元(MPU)读出并执行程序的方法。

虽然参照示例性实施例对本发明进行了描述，但是应当理解，本发明并不限定于所公开的示例性实施例。所附权利要求的范围应当被赋予最宽的解释，以便涵盖所有这类修改以及等同的结构和功能。

Claims (11)

1.一种信息处理终端，其具有使得客户端和服务能够经由网络相互协作的中继功能，所述客户端管理数据，并且所述服务利用由所述客户端管理的数据来提供功能，该信息处理终端包括：

接收单元，其用于接收功能信息，该功能信息用于调用驻留在所述网络上的第一服务提供的功能；

转换单元，其用于将驻留在所述信息处理终端中的第二服务的定义信息，转换为所述功能信息的格式，以便经由所述中继功能来调用所述第二服务提供的功能；

登记单元，其用于进行用于调用所述第一服务及所述第二服务提供的功能的、使用所述中继功能的登记处理；以及

提供单元，其用于根据所述登记处理，向用户提供用来调用所述第一服务及所述第二服务提供的功能的画面，

其中，根据由用户向所述画面发出的选择指令，利用由所述接收单元接收到的所述功能信息、或者由所述转换单元转换所述定义信息而获得的信息，来进行功能的调用。

2.根据权利要求1所述的信息处理终端，其中，所述转换单元依照所述功能信息中包括的分类信息的格式，来转换所述第二服务的所述定义信息中包括的分类。

3.根据权利要求1所述的信息处理终端，其中，响应于通过被调用的所述第二服务提供的功能而获得的处理结果的通知，所述转换单元将所述处理结果，转换为通过所述第一服务提供的功能而获得的处理结果的格式，其中，所述第二服务是通过使用由所述转换单元转换所述定义信息而获得的信息而调用的。

4.根据权利要求1所述的信息处理终端，其中，所述提供单元提供所述画面，在所述画面上，显示有基于由所述转换单元转换所述定义信息而获得的信息的功能信息、或者管理所述第二服务的调用的其他服务的功能信息，以调用所述第二服务提供的功能。

5.根据权利要求1所述的信息处理终端，其中，所述登记单元在如下情形中的至少一种情形下进行所述登记处理：在所述信息处理终端上安装了应用时、在通过周期性搜索而检测到要新登记的信息时、以及在所述中继功能被启动时检测到要新登记的信息的情况下。

6.根据权利要求1所述的信息处理终端，该信息处理终端还包括更新指示单元，该更新指示单元用于接受用于检测是否不存在要新登记的信息的更新指令，

其中，所述登记单元在如下情形中的至少一种情形下进行所述登记处理：在通过所述更新指令而检测到要新登记的信息时、在所述信息处理终端上安装了应用时、在通过周期性搜索而检测到要新登记的信息时、以及在所述中继功能被启动时检测到要新登记的信息的情况下。

7.根据权利要求1所述的信息处理终端，其中，所述网络包括互联网。

8.根据权利要求1所述的信息处理终端，其中，所述客户端、所述服务及所述中继功能中的至少两者是在相同装置中运行的功能。

9.根据权利要求1所述的信息处理终端，其中，在所述功能信息中，与共享数据的功能相对应的分类信息、与编辑数据的功能相对应的分类信息、与查看数据的功能相对应的分类信息、与拾取数据的功能相对应的分类信息以及与保存数据的功能相对应的分类信息中的至少一者被描述为分类。

10.根据权利要求1所述的信息处理终端，其中，所述第二服务提供的功能不符合用于利用所述中继功能进行的所述登记处理的格式。

11.一种信息处理终端的控制方法，该信息处理终端具有使得客户端和服务能够经由网络相互协作的中继功能，所述客户端管理数据，并且所述服务利用由所述客户端管理的数据来提供功能，该控制方法包括：

接收步骤，接收功能信息，该功能信息用于调用驻留在所述网络上的第一服务提供的功能；

转换步骤，将驻留在所述信息处理终端中的第二服务的定义信息，转换为所述功能信息的格式，以便经由所述中继功能来调用所述第二服务提供的功能；

登记步骤，进行用于调用所述第一服务及所述第二服务提供的功能的、使用所述中继功能的登记处理；以及

提供步骤，根据所述登记处理，向用户提供用来调用所述第一服务及所述第二服务提供的功能的画面，

其中，根据由用户向所述画面发出的选择指令，利用所接收到的功能信息或者通过转换所述定义信息而获得的信息，来进行功能的调用。