CN102272721A

CN102272721A - 移动通信设备

Info

Publication number: CN102272721A
Application number: CN2009801543708A
Authority: CN
Inventors: K·约翰斯通; G·埃蒙兹; S·戴维斯; G·维托洛; A·金科拉
Original assignee: INQ Enterprises Ltd
Current assignee: INQ Enterprises Ltd
Priority date: 2008-11-07
Filing date: 2009-11-06
Publication date: 2011-12-07
Anticipated expiration: 2029-11-06
Also published as: AU2009312609A1; WO2010052477A3; EP2611083A1; CN102272721B; EP2359239A2; GB0820427D0; WO2010052477A2; US20120129572A1; CA2742882A1; EP2605476A1

Abstract

本发明提供了移动通信设备、移动通信方法以及应用管理器，其能够协调有关诸如社交网络通信服务等通信服务的新应用的功能到所述通信设备上预装的用户界面应用的集成。本发明还提供了能够基于由通信服务所提供的图像数据更新诸如有关联系人列表中的联系人的头像等图像数据的移动通信设备。本发明还提供了一种移动通信设备，其能够确定该设备是否处在特定的网络中并且根据所述网络是否属于预定的类别而确定所述设备是否能够访问有关服务的数据。

Description

移动通信设备

本发明涉及移动通信技术并且具体地涉及移动通信设备的改进架构。此外，本发明提供了实现该架构的设备和方法。

当前，移动技术正在扩展到使移动通信设备能够提供其他形式的通信，而非仅仅为语音和文本通信。能够经由移动通信设备通过因特网访问许多服务使得可以与利用能够访问因特网的计算机终端类似的方式对其进行利用。服务的示例为社交网络应用，诸如Facebook、MySpace、Twitter和Bebo等。可将这些服务视为基于因特网的社交网络。许多因特网服务是所谓的Web 2.0网站并且具有API接口，所述API接口通常为RESTful，这是本领域的技术人员熟知的术语。此外，服务的其他示例为在线拍卖应用，诸如eBay。存在许多问题需要处理以虑及可在移动通信设备上访问这样的服务并且虑及任何被访问的服务在移动通信设备上以最用户友好的方式操作。例如，与计算机显示屏相比，移动通信设备具有有限的显示区域和有限的用于与用户界面交互的装置。

用户能够使用由他们的移动网络服务提供商所提供的因特网服务通过他们的移动通信设备访问因特网。为了使用户能够访问特定的服务，网络服务提供商可能需要建立专用的应用服务器。此外，许多服务依赖于网络服务提供商支持并且维护服务通过其而可用的基础设施。即使服务被提供给用户的移动设备，新的服务也需要与移动设备兼容以确保用户界面不会受损并且该服务提供相关联的功能。新的服务可能要求网络提供商对系统、技术或者服务器的安装。服务通常由可被添加至移动设备的移动客户端应用提供，这样的应用必须与移动设备兼容。

根据第一方面，本发明提供了一种移动通信设备的架构，其能够接收有关服务的新应用并且动态地将所述应用及其功能集成到已经存在于所述移动通信设备上的一个或多个应用中。由于小显示屏幕的实际状况(real-estate)和有限的用于用户输入的装置，诸如电话等移动设备在用户界面设计方面有显著的限制，因此提供集成的用户界面特别重要，即其中所安装的应用呈现在已经存在于所述移动通信设备上的那些应用中的一个或多个的应用界面中。

本发明提供了一种应用管理器组件，其协调新应用到已经存在于所述移动通信设备上的一个或多个应用的集成。

根据另一方面，本发明提供了一种将已经被安装在移动通信设备上的有关服务的新应用的功能与已经存在于所述移动通信设备上的一个或多个当前应用集成的方法，所述方法包括：

接收新应用的安装包并且将所述新应用安装在所述移动通信设备上，所述安装包包括有关所述新应用的集成能力的数据；

发起所述新应用的功能与已经存在于所述移动通信设备上并且通过来自所述安装包的数据被识别的一个或多个当前应用的集成。

所述功能的集成优选地包括重新构建所述(一个或多个)当前应用的用户界面。

这允许许多新应用变为集成到运行在所述移动通信设备上的当前应用的用户界面中，并且这种集成在所述移动通信设备处动态地实现。而且，在所有所述集成都发生在电话中的情况下，对网络运营商安装系统、技术或服务器(在仅提供从移动通信设备到因特网的数据连通性之外)或者对通过特定的聚合器保持伙伴关系有很小的依赖性或没有依赖性。这使得本发明的移动通信设备能够用在许多网络上而无需扩展或者改变网络基础设施以支持本文所提出的集成。因此，这也使所述设备对于向多个网络运营商出售在商业上更具吸引力。

根据另一方面，本发明提供了一种移动通信设备，其包括：

用于经由电路交换和/或分组交换电信网络发送和接收信号的装置；

用于经由独立的通信服务通过因特网协议网络发起通信的装置；

数据存储单元，其用于存储有关所述电信网络和所述通信服务的联系人列表中的联系人的图像数据；

用于基于由所述通信服务所提供的图像数据更新所述数据存储单元中的有关所述联系人的图像数据的装置。

这允许有关联系人的图像数据被更新而无需用户介入以示出当前为联系人在通信服务上的图像的部分的最近的图像。

根据另一方面，本发明提供了一种移动通信设备，其包括：

用于通过因特网协议网络连接到通信服务的模块，所述模块包括：用于确定所述设备所位于的电路交换和/或分组交换网络的网络服务提供商的标识数据的装置；用于将所述标识数据与多个网络服务提供商的预定标识数据进行比较的装置，其中所述多个网络服务提供商分别被分配到多个类别中的一个；以及用于判断所述设备是否位于所述多个类别中的一个的装置。

在一特定实施例中，所述类别为网络服务提供商的白名单、灰名单和黑名单。漫游时的用户可根据他们正在其中漫游的网络而自动地被允许对服务的访问。

为了使本发明被理解，将仅通过参考附图举例说明的方式来描述实施例，在附图中：

图1示出了根据本发明的第一实施例的移动通信设备的架构的示意图；

图2示出了包括图1所示的架构的第一类型的移动通信设备的透视图；

图3示出了被执行以根据图1的架构将HLet应用集成到本地应用中的步骤的流程图；

图4a示出了包括图1所示的架构的第二类型的移动通信设备的透视图，图4b示出了图4a中的设备从一侧看的透视图，而图4c示出了图4a中的设备从另一侧看的透视图；

图5示出了包括图1所示的架构的第三类型的移动通信设备的透视图；

图6a至图6d示出了表示当设备的用户访问联络簿时图2、4或5中的设备的用户界面的示例屏幕截图；

图7a至图7j示出了表示当执行来自各个通信服务的联系人的合并时图2、4或5中的设备的用户界面的示例屏幕截图；

图8a示出了表示当在设备上访问天气微件应用时图2、4或5中的设备的用户界面的示例屏幕截图，图8b示出了由设备所做出的决定，而图8c示出了在用户驻留在灰名单网络中的情况下的示例屏幕截图。

图9示出了H_API的各个组件之间的交互图。

参考图1，本发明的第一实施例为移动电信设备的架构10。图2示出了其中设备为移动电话手持话机(handset)200的一个实施例。将理解的是诸如配有适当的电话硬件的个人数字助理等能够连接到移动电话网络并且接收因特网协议(IP)多媒体的其他移动设备能够被用在本发明中。在图4和图5中示出了能够被使用的其他类型的移动电话，其中图4示出了移动手持话机400并且图5示出了移动手持话机500。相同的参考标号被用来指示具有相似功能的特征。移动手持话机500与图2和图4中的手持话机不同在于其具有比移动手持话机200、400更大的显示屏并且具有″QWERTY″键区。

参考图2、4和5，移动电话手持话机200、400、500包括显示屏202和在电话主体部分的侧部上的许多按钮204以使用户能够控制电话的某些方面，诸如扬声器音量或其他方面。在手持话机200的前表面上提供了另外的按钮206，其也允许电话的其他方面由用户控制。一个被称为切换器按钮208的特定按钮提供了改进的功能并且随后将被描述。该切换器按钮在这个实施例中是电话右边向下第三个按钮，但是不局限于这个位置。

架构10不同于常规的移动电话架构在于其允许一个或多个应用被安装在电话上并且允许那些应用参与呈现一个集成的用户界面。这些应用在下文中将被称为″HLet 11″。HLet 11可在装运之前被安装到电话上或者随后被安装(例如通过用户下载它们)并且通常与特定的因特网方式通信的社区相关联。HLet 11被示出在图1的架构10中的区域110中。HLet可以具有相关联的用户界面11a。不带用户界面的HLet将实质上充当因特网服务函数(function)与本地应用中的等价函数之间的适配器。带用户界面的Hlet允许与因特网服务的一组更丰富的用户交互，除了使因特网函数暴露于本地应用以外所述交互特定于该服务。

这些HLet 11可包括许多在线社区。举例来说，这些是诸如Skype、Windows Live Messenger、Yahoo！等因特网协议语音(VoIP)和即时消息传递社区并且还包括在线社交网络社区，诸如Facebook、MySpace、Twitter、Bebo等。此外，HLet可包括在线拍卖应用，诸如eBay。在已知每个社交网络在各个国家的流行度的条件下HLet 11的准确选择可以是特定于国家的或者HLet 11的准确选择还可以由出售移动电话手持话机的运营商根据他们的业务和/或他们保持的伙伴关系来确定。

架构10还具有许多本地应用12，其主要负责呈现通用的用户界面。这些本地应用12在移动电话手持话机中常常被用作指代预装的用户界面应用的术语，其是大部分手持话机共有的并且对将手持话机用于电路网络通信和分组网络通信是基本的-诸如呼叫拨号、电话簿、消息传递、浏览等。本地应用12通常在手持话机被出售以前就被预装并且经常作为一套交互应用被写入(例如可从键区、从电话簿、从消息传递和呼叫记录启动呼叫)。然而，有可能通过诸如OMA设备管理等已知方法更新本地应用12。

本地应用12被示出在图1的架构10中的区域120中。一旦本地应用12被安装，每个本地应用12都具有对HLet 11进行特定应用编程接口(API)调用(call)的能力。稍后将描述HLet 11到移动电话的安装和集成程序。一组限定的方法被用于使本地应用12能够查询并且与HLet 11交互。因此，本地应用12应当了解该组限定的方法以使交互正确地进行。

本地应用12适用于通过被写入为了解HLet 11中的API功能并且使得可构建动态用户界面(UI)以包括来自每个HLet 11的特征而与HLet 11兼容。已经使得API被了解或者包括动态UI单元的优选实施例的移动手持话机中的本地应用12的示例包括：

-联络簿(在这个应用中互换地被用作″电话簿″和″联络簿″以指代同一本地应用)

-消息传递

-媒体库

-照相机，图片和视频两者

-呼叫/事件日志

-拨号器(负责发起和接收呼叫的应用)

-因特网浏览器

-状态栏

-弹出管理器

此外，如图1所示，一种特定类型的本地应用12是″切换器12a″。该切换器12a具有通过在移动手持话机上提供激活该切换器12a的专用键208(示出在图2中)而允许用户在不同的通信应用之间快速地并且直观地切换的功能。此外，该切换器12a提供了进一步的功能在于其提供了：

-每个通信应用内的状态(例如当前他们是登录还是登出社交社区、该应用是打开的还是关闭的等)。所述状态反映在所显示的图标中；

-由每个下层的本地应用12或HLet 11所定义的交互选项(例如当状态示出用户已签到时从切换器菜单退出的选项，反过来也一样)；

-在新应用被下载之后，那些新应用到切换器菜单的自动添加；

-每个社区在切换器菜单中的位置的增强运营商控制(在它出现的地方，不管用户是否可以移除它)；以及

-双模交互-用户按键(短按和长按)

中心应用管理器组件13被提供在架构10中并且具有管理在HLet 11与本地应用12之间所执行的进程的函数。它还可以适用于管理诸如可以被下载的微件14等非HLet应用或者未被包括在本发明中的其他应用15，并且因此不会被进一步详细地描述。此外，其他本地应用12也存在于该架构中，它们可能不与HLet 11兼容。微件管理器17被提供以管理下载的微件14并且应用管理器组件13与微件管理器17交互使得当微件14被安装时应用管理器组件13被通知。微件与HLet 11不同地被识别，所以应用管理器组件13将知道要把有关微件14的信息传递给微件管理器17。

架构10还具有常规的手持话机操作系统18。例如，该操作系统可以是Symbian、Qualcomm BREW、Android或者Java。在第一实施例中，手持话机所使用的操作系统是Qualcomm BREW。在手持话机中提供了文件存储装置19。操作系统18已经安装了特定于操作系统的进程间通信方法20。没有描述移动电话手持话机特有的硬件组件，诸如射频模块、信号调节电路、电源管理单元，但是它们为本领域的技术人员所熟知。

转向HLet 11到移动手持话机的安装进程以及HLet 11到本地应用12的集成，对图3的流程图进行了参考。

在步骤300中，新的HLet 11由用户下载到移动手持话机。尽管在这个实施例中，HLet由用户下载，但有可能使安装在手持话机被提供给用户之前(即在装运之前)发生。在任何情况下，各个步骤仍然在手持话机中动态地被执行而不需要用户动作。下载通常将包括接着被安装的许多文件(在通用文件夹中)。安装进程可以根据手持话机所利用的操作系统18的不同而不同。各种操作系统全都具有用于安装应用包的众所周知的限定的方法。在HLet 11到手持话机的实际安装开始之前，安装进程可在步骤310中包括应用鉴定(例如检查应用包含正确的证书、证明等以访问手持话机函数)和软件版本控制(覆盖同一应用的先前版本)。

每个HLet安装包将至少包含两个文件-a)可执行的应用和b)优选地为声明其能力和所要求的与本地应用的集成的XML文件的元数据文件。另外的文件也可以包括在安装包中，诸如用作图标的一个或多个图像。

应用管理器13接着将执行各种函数，包括

-了解新应用已经被安装(步骤320)

о在其中操作系统18为Qualcomm BREW的第一实施例中，应用管理器13被登记以收听当新的‘动态应用’被安装时所产生的标准BREW OS通知。Qualcomm的动态应用定义包括HLet应用11和其他下载的应用15但是不包括微件14(其在被称为UIOne的Qualcomm平台的另一部分中形成UI单元)。

-识别已安装的应用为HLet(步骤330)。

在Qualcomm中，这通过在包安装期间检验在模块信息文件(′MIF′)中声明的Applet类型来完成。′IMF′文件为那些熟悉Qualcomm平台的人所熟知。HLet被保留为用于指示HLet分类的参数值(对于出售这些手持话机的任何运营商)。

-在已安装的应用为HLet的情况下，应用管理器13解析与新安装的应用相关联的元文件(步骤340)。

о在用BREW的第一实施例中，应用管理器13在那个已安装的应用的根目录中寻找被称为″config.xml″的单个文件。

о元数据文件声明本地应用12中的哪些需要为Hlet函数包括用户界面链接、那些链接指代什么类型的交互以及要插入的文本标签。文本标签可以是特定于语言的，由此允许标签的不同文本选项根据手持话机的语言设置而被示出给不同的用户。例如，XML文件可以规定当Hlet 11被下载时电话簿和照相机本地应用都将受影响、新的命令″开始聊天(Start Chat)″将要被插入在电话簿中以及哪些API将由于特定的动作而被激活(invoke)(例如每当用户根据″开始聊天″命令按左软键时就调用″startChat″API)。

-应用管理器13接着通知每个本地应用12(其在元数据中被注明-明确地或隐含地)新的HLet 11被安装并且其必须重新构建其用户界面(步骤350)。

-应用管理器13还保持所有已安装的HLet 11的列表(步骤360)。这优选地采用查找表的形式，所述查找表被存储在手持话机内存(memory)中的文件存储装置19中。这在以下两个实例中都是有用的：

о当给手持话机加电时，应用管理器13扫描手持话机内存以寻找所有已安装的HLet 11。有可能的是HLet 11在手持话机掉电的同时被安装(例如当手持话机被刷新时)。在检测到新的HLet 11时，应用管理器13可重新激励本地应用12重新构建它们的菜单选项。

о应用管理器13可充当希望与HLet 11通信的本地应用12的中心函数。这将取决于操作系统的细节，但是在一些情况下对于本地应用12可能需要分辨HLet 11的状态或者运行在操作系统18中的那个HLet 11的进程标识-例如在直接通信不可能的情况下。

遵照这些步骤，HLet 11将被集成到适当的本地应用12中而不需要用户介入(步骤370)。因此，当新的HLet 11被安装时，本地应用的用户界面动态地被构建。HLet 11到适当的本地应用的用户界面的集成改进了移动手持话机的功能，而且还为移动手持话机的用户提供了改进的界面。例如，在HLet 11为Facebook应用的情况下，Facebook应用特有的特征中的许多，诸如用户情绪、头像图片等可被集成到联络簿中相关的联系人条目中。Facebook HLet能够使用Facebook的RESTful API与Facebook交互。在HLet 11为eBay应用的情况下，其允许用户出价并且在拍卖将结束时或者在用户出价被超过时被警告。

本地应用12支持以下用于构建一个集成的用户界面的方法

-对HLet 11进行特定应用编程接口(API)调用的能力。如前所述，存在一组限定的方法，本地应用12可通过这些方法查询并且与HLet应用11交互。API的一个示例是H-API(Hutchison API)。本地应用12可以直接地或者在某些情况下经由应用管理器13发信号通知HLet 11(这取决于在下层的操作系统18中可用的进程间信令方法)。

-响应于调用(来自应用管理器13)以在本地应用12中重新构建菜单选项。

-在某些情况下，在应用之间共享对所存储的文件的访问，例如在应用没有被启动时对更新状态的访问。(例如H-API方法的″IHLET_GET_A VATAR″(稍后将详述)将头像图像存储在由config.xml规定的文件夹中)。

对于从本地应用对HLet进行的H-API调用，有必要使两个应用都在运行。一般而言，诸如BREW的操作系统通过允许本地应用通过指示操作系统(例如经由系统调用)来激活实例而启动另一应用(诸如一个HLet)而支持这种情况。还已知的是参数可以被传递给被激活的应用-例如表明所启动的应用是否应当出现在前台以使用户与其交互或者在后台被启动。无论在哪种情况下，一旦HLet运行，其将能接受H-API调用。

在HLet需要与本地应用共享数据的实例中，HLet应用激活本地应用不一定是可能的或者是所希望的。在某些操作系统环境中，诸如Java Applet等下载的应用可能不具有足够的安全特权以激活系统调用。同样地，移动手持话机根据可用的处理器和内存资源以及维持电池寿命的需要而通常在其性能方面受限制-因此需要对启动和使另一应用运行的成本是否与所要求的动作不相称给予考虑。

图9示出了总体结构和各个组件之间的交互，其中事件(″Brew事件″)可以由本地应用12(″本地UI″)发送到HLet应用11(″HLet″)；通知(″客户端的INotifier″)被HLet用于将事件发送到本地应用；并且通知(″URI″)也被HLet用于激活本地应用。

其中发生这种情况的第一实施例中的一个特定实例是在因特网社区中的一个中的好友改变他们的照片(头像)的时候。下一次手持话机用户启动本地联络簿应用时，联络簿需要示出最新的头像照片，但是其直到那时之前都不需要被更新。因此，HLet可在下一次其被启动时将新的头像照片写入联络簿应用所访问的共享文件夹而不是对于每次更新都激活联络簿来例示(instantiate)。然而，当联络簿应用已经在运行时，H-API调用会被优先地用于立即同步。

通常不容易升级本地应用12，但是这对于利用使用开放式移动联盟设备管理的固件空中下载(FOTA)的实例在理论上也是可能的。按这种方式，如果本地应用12需要利用没有包括在该版本的H-API中的特征，则有可能进行升级。然而，在已知许多本地应用之间的密切交互的条件下，最有可能的是一整套相互关联的本地手持话机应用都将需要被升级并且因此这不会轻松地完成。因此，动态UI构建进程的特定优势在于本地应用12不需要在每次新的HLet应用11被添加至手持话机时都被升级。

由于UIOne的限制，微件14不支持H_API接口。然而，仍然有可能将特定的进程间通信19从HLet 11和本地应用12发送到微件14。在BREW中，这些方法包括NotifyEvent方法和PostURI方法的通知。还仍然有可能将数据保存到微件14可以访问的共享文件夹。

微件14和HLet 11两者都可保持在带有因特网服务的连接状态。因此，数据传输可以在没有用户介入的情况下发生。根据漫游时运营商所征收的数据费用和与数据使用量相关联的成本，将代码添加至微件14或HLet 11以暂停数据传输或者通知用户可能的相关联的费用是所希望的。例如，天气微件包含确定手持话机的漫游状态并且识别用户所驻留的驻留网络是在白名单、灰名单还是在黑名单中的逻辑。当驻留网络被列在白名单中时，微件不通知用户数据使用量，灰名单意味着要向用户征求许可而处在黑名单中时用户被拒绝访问。

参考图8，当用户强制刷新或者将位置添加至天气微件时，该天气微件应用将要求流量管理组件返回设备正在其中漫游的网络是在白名单、灰名单还是黑名单上。

如上文所述，HLet应用11可通过下载被添加至手持话机。HLet应用11被写入以包括H-API函数的库和定义。在H-API中所定义的函数大部分是从关于每个社交网络和社区的细节中提炼的，但其代替地定义大部分社区共有的一组一般概念，其至少包括，

-使用诸如‘添加好友’、‘移除好友’、‘阻止好友’等函数来管理某人在每个社区中的朋友(‘好友’)

-朋友的社区列表的详细资料，诸如‘显示个人资料’、‘获取头像’

-管理某人自己的列表，例如设置头像、设置情绪/状态

-社区管理函数(签到、退出)

-此外，定义了在未定义类属函数时对Hlet在HAPI中进行自定义调用的方法。

本地应用12可以为在H-API中所描述的任何函数对每个HLet应用11进行H-API调用。不是所有的函数都将适用于每个HLet 11并且因此HLet程序设计者将需要把决定如何处理由所包括的H-API定义文件所定义的到来的API调用的代码添加至他们的应用中。

许多选项针对本地应用12与HLet 11之间关于哪些API调用相关的发现进程而存在。主要方法是：

-强制性的API调用。对于HLet程序设计者支持某些API函数是强制性的。因此，本地应用将先验地知道调用这些API函数是受支持的。

-隐含的API调用。当HLet元数据文件声明新的菜单选项必须被添加至本地应用菜单时，其将在用户选择那个选项时包括要激活的方法。隐含地，这个API调用和其他相关联的API调用将需要受HLet支持。

-显式的。(将来的选项)。元数据文件能够声明所有受支持的API或受支持的子集或者支持的类级(profile level)。

-良好的做法。如果HLet程序设计者认为本地应用可以调用不受支持的API函数是有可能的，则包括利用适当的错误消息来响应本地应用的代码是良好的做法。

通过其从本地应用12向HLet应用11发信号通知调用的实际进程是特定于操作系统的，但是一般而言方法存在于所有常见的操作系统中。在第一实施例中，手持话机被构建在Qualcomm的BREW操作系统的顶部，其中发信号通知同步事件。

现将更加详细地描述关于移动通信设备的功能的另外的方面，并且将示意H-API调用和动态用户界面架构的使用如何体现在用户界面中。

已经在上文中描述了切换器12a，但是现在将参考图1和图2提供更多细节。切换器12a是使用户能够快速地启动应用并且接触到因特网上的统一资源定位符(URL)以及实现在运行的应用之间多任务操作的主要方法的应用。可以通过按专用键208或者通过键的敲击(手持话机工业设计许可)在手持话机体验中的任何地方激活切换器12a，并且其可以永久地示出在手持话机的待机显示屏202上。

显示在切换器12a图片轮播(carousel)210中的图标212可以是预安装的应用、下载的应用和URL以及正在运行的其他应用的混合。除了本地应用(诸如联络簿)的选择之外，切换器12a还被设计成包括HLet应用以为与基于因特网的服务的交互提供集成的用户界面。在图2中示出了切换器图片轮播210的示例并且这包括许多图标212，这些图标是图片轮播210和切换器12a的部分。

切换器应用12a是本地应用，其用户界面可根据本发明动态地调整。一旦应用管理器13检测到新的或更新的HLet应用存在于手持话机中，其就将解析相关联的元数据文件以确定新的HLet在切换器12a内的行为并且通知切换器12a该新的HLet的存在。

在第一实施例中，与HLet相关联的元数据可规定关于新的HLet在切换器12a用户界面中的呈现的某些属性，包括

-其在图片轮播中的特定位置

-用户是否能够更改这个位置

-用户是否可将其从切换器中删除以及

-为HLet应用所显示的图标。

应指出的是元数据文件可能不表明在切换器的用户界面中自动地包括HLet应用并且用户可以经由‘用户选择的’路径来添加应用。如果用户随后决定将HLet应用添加至切换器图片轮播中，则切换器应用将需要解析HLet元数据文件以便确定到其用户界面的集成。

HLet应用仍然可以通过其他装置移除-例如由用户经由也可以安装在手持话机中的本地文件管理器程序16来删除该应用。在这种情况下，应用管理器13将检测到HLet应用的移除或缺少并且因此通知切换器12a重新构建其用户界面。

在切换器12a中还显示了运行的应用。如果应用规定了它自己的图标，则切换器12a从那个应用本身得到应用图标，否则从与切换器应用一起被包括的预置图标池得到应用图标。通常，所下载的HLet应用包将包括图标并且要使用的这些图标接着在元数据文件中被注明使得切换器12a可确定要显示的相关图标。

HLet应用可控制那个图标中的图形单元，并且根据需要向切换器提供更新的版本。切换器可支持无限制的图标改变并且当它们的状态改变时将立即更新图标。由于HLet应用不能直接控制本地应用(换句话说，H-API调用是从本地应用到HLet而反之则不然)，所以在第一实施例中所使用的方法是使HLet利用Qualcomm BREW的已知系统方法19将Notify事件通知发送到本地应用，其在本发明中接着提示本地应用经由H-API方法查询Hlet以得到所述改变。BREW和Java(例如经由JSR211)也支持PostURI通知方法，其可同样地被用于从HLet应用向本地应用发信号通知。

一些HLet应用函数可通过切换器图片轮播210直接访问，使用户能够对那个应用执行任务而无需将该应用带到前台。切换器12a中的每个项目都具有上下文选项菜单，其反映了在图片轮播中心(中心位置214)处的当前项的功能。利用动态框架，HLet应用可在选项菜单中登记这些函数，然后当用户经由H-API调用选择它们时可以按照这些函数行动。例如，用户可以登出聊天应用或者使用电子邮件应用检查电子邮件。

当切换器图片轮播210中的项被选中(中心位置214)时，选项菜单可支持用于那个被选择的应用的特定函数。例如，切换器选项菜单能够识别应用是否支持在线服务的签到和退出。这使用户能够快速地签到和退出而无需打开该应用本身。大部分应用将在状态栏上反映它们的登录/登出状态。应用可经由动态构建的用户界面将多个函数登记到选项菜单中，并且用户可以访问这些函数而不用经由H-API调用将那个应用带入前台或者在能够对另一应用执行任务之前等待那个函数完成。

转向移动电话的另一方面，被更常见地用在因特网上的订阅源(feed)可被集成到移动电话中。订阅源是内容来源，其符合被处理以通过浏览器或查看器(viewer)被馈送的特定标准。实质上，订阅源应用是一种类型的查看器，其中在整个手持话机中能找到管理特征和到订阅源的集成。

移动电话中的订阅源应用按选项卡式的类别(tabbed categories)显示订阅源，其中每个选项卡(tab)遵循关于那个选项卡所显示订阅源的来源和管理的不同规则。通常，订阅源查看器将包括本地应用并且可包括与浏览器应用相关联的已知RSS查看器/管理器应用的增强版本。已经知道在现有的移动电话中用户在浏览器中有选项以订阅RSS或原子订阅源(Atom feed)。原子订阅源的结构由RFC4287定义(http://www.ietf.org/rfc/rfc4287.txt)。在增强版本中，也有可能的是可以在HLet应用中将RSS或原子订阅源检测为相关联的因特网服务的部分-例如好友在社交网络的网站或博客网站上的在线日记或相册。

‘我的订阅源’(作为示例给出的标签)是在启动订阅源应用时所示出的初始选项卡。这显示了预载到手持话机上的订阅源和用户已经由浏览器添加的订阅源。

在第一实施例中，已经将附加的功能添加至订阅源查看器使得用户可以使特定的订阅源与联系人相关联。用户可以使订阅源与联络簿本地应用中的或者来自订阅源查看器的联系人相关联。无论在哪种情况下，在两个本地应用之间进行这种关联，为此在这些本地应用中包括了定制的编码(即不是H-API调用)。在订阅源从HLet应用中被识别的情况下，通常的情况是HLet已经知道该订阅源与哪个好友相关联并且因此与联络簿条目的链接可以是自动的。联络簿本地应用可利用H-API调用来确定订阅源状态或同样地HLet应用能够将订阅源数据写入共享文件夹19以供联络簿应用或订阅源查看器利用。

在第一实施例中，联络簿本地应用具有自动地生成的‘联系人订阅源’(作为示例给出的标签)视图并且有可能的是联络簿中明显的所有订阅源按联系人详细资料的名称的字母顺序显示。

包含在订阅源查看器本地应用的‘我的订阅源’视图中的订阅源可被分配到联系人或微件。订阅源管理器将使用OS进程间通信方法19以直接地或者通过微件管理器17通知微件14。这将把那个订阅源的显示和管理传输至微件应用或联络簿应用。

订阅源与最近添加的订阅源一起被显示在顶部，并且用户界面示出了订阅源图像或者那个域的网站头像(Favicon)图像，以及订阅源的标题和对多少未读文章已准备好被查看的指示。

应用对于每个订阅源具有两个其次的级，它是订阅源内的文章列表以及最后是文章详细内容视图。文章列表和文章详细内容两者在由RSS订阅源提供图像的情况下可以支持图像。如果没有图像存在，则使用那个订阅源的默认图像(如果存在该默认图像)。

订阅源内的文章被显示为未读或者已读。用户能够选择将单个或者所有的文章标记为已读或者未读。

添加订阅源是非常简单的，有两种方法对于用户可用。最容易的是通过与浏览器集成的方式，其中用户能够选择订阅源并且直接从浏览器应用UI将其添加至订阅源应用。支持浏览器方式的也是手动方法，其中用户能够输入订阅源的URL。

添加新订阅源的动作提示订阅源应用发起内容更新。

当订阅源被下载到设备时，内容保持不变直到其被下次更新覆盖或者用户选择删除订阅源或订阅源内容。

订阅源应用具有遵循设定的更新时间表(例如每小时更新)自动地更新所有订阅源的能力。当更新进程开始时，订阅源内的新条目就被更新。即使只有一个新条目存在，一些订阅源也将更新所有条目。每个订阅源都可被设置成自动更新或者只在用户请求该动作时才更新。每一订阅源的条目总数被限制为设定的数量，例如20。这是运营商定制的或者是灵活可变的(即在手持话机软件安装设置中的确定的预装运(pre-shipping))。

当创建联系人或者编辑存储在电话中的联系人时，给出选项以将网站订阅源添加至这个联系人。这将从所需的RSS订阅源所提供的信息直接传递到联系人列表和手持话机的订阅源部分中。当订阅源被下载到设备时，内容在这些部分中保持不变直到其被下次更新覆盖或者用户选择删除该订阅源或订阅源内容。

订阅源还可以直接从手持话机的订阅源部分分配到联系人。这也允许用户过滤联系人并且查看关联有RSS订阅源的所有联系人。通过这个机制，有链接到个人网站并且直接被传递关于具有分配的订阅源的个体的信息以及允许用户获得除了由集中式的社交网络提供的信息以外的信息的能力。

转向移动手持话机的另一方面，提供了联络簿本地应用12。电话簿包含联系人列表，其中联系人包括联系人详细资料。电话簿是已经被发展成为起关键作用并且充分利用H-API调用以将来自各个HLet应用和订阅源的信息集合到一起的应用。电话簿是联系人详细资料、在线(presence)信息的中心位置并且用户可从一个位置发起所有形式的通信。

传统地，手持话机上的电话簿应用需要用户输入他们的联系人的详细资料，或者能够通过从SIM卡加载、经由蓝牙或串行电缆等获得联系人。集成的电话簿利用从社交网络获得联系人的附加能力根据这些常规的使用来构建。

电话簿本地应用已经被设计成利用H_API，其实现与许多社交网络的集成。对电话簿的限制是依赖于硬件，但是也将取决于用户希望保持的HLet和联系人的数量。根据上文所描述的架构，经由应用管理器13使电话簿获知HLet应用，如已经描述的那样其可重新构建其用户界面，并且对新的HLet应用进行所需要的H-API调用以添加关于每个HLet应用与其连接的因特网服务中的联系人的详细资料。

对于每个新的社交网络，用户被给予将来自那个网络的联系人集成到电话簿中的选项。在集成期间，在电话簿中为来自该社交网络的每个联系人创建新的联系人记录。

与先前的联系人管理方法(在上文中描述)相比，该电话簿支持外部管理的联系人信息和内容。最初地在添加新的社交网络的时候，用户能够将来自那个社区的联系人输入到电话簿应用中。

在输入期间或之后，用户能够使联系人与联络簿内的现有联系人记录关联(或合并)。例如，你可将Windows Live Messenger的详细资料添加至他们现有的包含他们的电话号码的电话簿联系人中。

通过API，社交网络保留对联系人、联系人详细资料以及相关内容的控制。当用户在社交社区内删除、添加或修正联系人详细资料时，那些改变自动地反映在电话簿中。

由于社交网络的性质，一些联系人详细资料是极其动态的，例如头像图片。如已经描述的那样，如果联络簿和HLet应用两者都已经在运行，则这优选地经由H-API调用来完成，但是这还可通过将新的头像图片保存到文件存储装置19中的已知位置来完成。

参考图6a至图6e，移动手持话机200、400或500的显示屏202被示出。图6a示出了当用户访问联络簿时可以被显示给手持话机的用户的图形用户界面。联络簿示出了已经被添加至联络簿的联系人列表30。在图6a中，该列表示出了许多联系人以及对有关某些HLet应用11的数据对于特定联系人是否可用的指示。例如，图6a中的联系人″Alan Pim″具有有关诸如Facebook等可用于由设备的用户访问的第一类型的通信服务的数据以及有关诸如Windows LiveMessenger等另一类型的通信服务的数据。这图标31和32指示，它们形成该联系人的条目的部分。

联系人具有与其相关联的图像(诸如头像图片)33，如图6b和图6e所示。在这个示例中，图像33是来自联系人的Facebook帐户的头像。将理解的是图像可以来自通过安装HLet应用11而可用的任何通信服务。来自Facebook帐户的图像被保存在也可由联络簿访问的文件存储装置19中的共享文件夹中。当用户通过设备激活他们的Facebook帐户时，用该联系人的当前图像(联系人可能自该图像通过他们的Facebook帐户被改变起具有该图像)更新保存在共享文件夹中的图像。联系人的当前图像在联络簿打开时被显示。在图6d中，联系人″Bob Johnson″没有图像，因此替代地显示了通用图像。联系人不具有图像的情况与HLet应用11没有提供图像有关，例如当诸如Facebook的通信服务的用户不具有与他们的Facebook帐户相关联的头像时。没有可用图像的其他原因是在图像无法下载到手持话机设备或图像没有采用可识别的格式的情况下。

除非应用正在运行，否则本地应用12将不激活″IHLET_GET_AVATAR″API。如果应用没有运行，则本地应用12将经由config.xml计算头像的路径。对于联系人，对应的头像(如果被设置)将由HLet 11保存在config.xml内规定的文件存储装置中的共享文件夹中，其中通过将联系人用户id与用户id_hash(HLetChar*pwzUserID)函数混编(hash)获得文件名。

可以使用以下结构以便在BREW中实现头像取得方法。

·pwszUserID[in]：联系人用户ID

·dwAvataId[out]：BREW资源文件内部的图像的图标ID

·pResLoc[out]：包含图标的BREW资源文件的位置。这应当是完整的BREW路径。内存必须由mallocFun函数分配并且将由本地UI释放。

·pAvataPath[out]：头像的图像路径。pAvataPath的格式应当是utf8并且是完整的BREW路径。内存必须由mallocFun函数分配并且将由本地UI释放。

·ext[in]：未使用。保留以供将来使用。

如果要求连接以便为特定的联系人设置头像，则应用可以选择在设置自定义字符串之前连接。

然而，应用还可以选择在稍后的时间连接。应用还可以选择在事件被接收时启动其自身。

可以使用以下结构以便在BREW中实现头像设置方法。

·pwszUserID[in]：联系人用户ID

·pAvataPath[in]：到头像图像的完整路径。pAvataPath的格式应当是utf8。

·ext[in]：这个参数被设置在config.xml中并且特定于应用。

传统地，联系人记录包括通常由移动设备使用的详细资料，例如电话号码和电子邮件地址。新的电话簿联系人记录能够扩展到包括社交网络的附加详细资料，例如用户名、情绪和头像图片。此外，新的内容特征可用于社交网络，其包括到联系人首页或内容订阅源的链接。当查看联系人时，这个信息能够与在线信息并排被示出。

为支持附加的联系人详细资料和内容，联系人记录已遵循由Hlet应用(及其元数据文件)确定的规则以及经由对上下文敏感的规则被扩展。除了呼叫和消息传递之外，为了补充新的联系人详细资料，使附加的联系方法对用户可用，例如聊天、点对点消息、震动和屏闪。新的联系方法取决于上下文并且仅在从特定的社区选择联系人详细资料时使其对用户可用。

在每个新的社交社区被添加并且集成到电话簿中时，对于同一个人用户有可能具有多个条目。用户可选择保留一个人的多个条目或将联系人记录合并在一起。

通过在移动电话中使用‘合并联系人’特征，用户可从不同的网络记录中选择多个联系人以合并在一起。在用户选择联系人以合并在一起时，该进程遵循有助于加快该程序的规则。图7a至图7j示出了当联系人将被合并时向用户显示的用户界面。这些包括允许用户从客户端(client)或者用户输入的名称为所基于的联系人记录选择名称。除了帮助合并程序之外，这些规则还防止相同类型的联系人记录的合并，例如避免将两个Windows Live Messenger(WLM)记录合并在一起。

当按照合并联系人特征遍历多个社交社区时，假定联系人在每个社区中只出现一次。因此，一旦用户从可能存在于电话簿中的同一个人的多个条目中识别一个匹配，来自那个特定社区的所有可能的匹配就不会被列出或者被放到建议列表的底部。前提是大部分人只保持每个因特网服务的一个身份(即一个Facebook帐户，一个SkypeID等)，并且因此来自因特网服务的剩下的未匹配的记录不太可能涉及已为其进行匹配的联系人。这导致了来自剩余社区的供用户从其中选择的潜在匹配的列表的缩短，并且因此改进了用户界面体验，特别是在具有有限尺寸的显示屏的手持话机上。

联络簿现在可以为遍及所有受支持的因特网服务的所有联系人显示在线信息、优选的联系人详细资料以及迅速答复和发起通信。这在于一个空间给予用户大量信息的单个位置呈现了多个信道，并且实现对最适当的装置的选择以基于联系人在线活动开始与所存储的联系人的通信。应当指出的是这已经被设计成确保其不影响进行正常的语音或者视频通话的能力。

电话簿能够利用电话簿应用与社交网络应用之间的API显示当前的在线状态。这使社交网络应用能够控制在线的状态，其可遵循社交网络具有的任何规则。负担(onus)在于社交网络应用向电话簿应用提供在线状态。联络簿接着可以利用相关的H-API调用从相关联的HLet应用取回在线状态。

由于电话簿支持多个社交网络，所以它也支持对多个在线指示符的指示。

除了联系人记录的正常的按字母顺序的查看之外，电话簿还具有用户可快速访问的被称为‘朋友’的新视图。由用户手动地将联系人记录添加至朋友视图，其中用户完全控制联系人记录被显示的顺序。

通过更丰富的联系人记录列表进一步增强朋友视图，其中常用的名称和电话号码被补充以最新的内容订阅源信息、对于更多社交社区的在线以及更大的头像图片。

新的电话簿联系人记录能够扩展到包括社交网络的附加详细资料，例如用户名、情绪和头像图片。从联系人获得的这些输入的图片可被用于整个手持话机的各个区域。可以在联系人信息被存储的地方显示图片，或者其可以在进行来话呼叫或者去话呼叫时主动被使用。以这种方式，可以规避添加存储在手持话机上的或者由手持话机在存储联系人时所拍摄的照片的费力任务。

在联系人具有多个存储的图片的示例中，存在一种机制可用于允许用户选择这些图像中的哪些是供用户既在查看联系人图像时也在接电话或打电话时通过其被呈现的优选详细资料。这独立于通过激励终端用户而进行呼叫或接收呼叫的信道。最终结果就是用户以最少所要求的努力通过丰富的图像库被呈现，这些图像可以在不同的情况被呈现。

对于一个或多个因特网社区具有比在移动设备上可用的空间更大数量的联系人的实例，需要一个机制来管理合并，并且利用移动设备电话簿(社区朋友管理器)来保持因特网联系人的视图。

社区朋友视图是在移动手持话机上可用的组件并且是用户可以为与移动设备电话簿的合并而选择(或取消选择)的所有因特网社区联系人的视图。在通过这个视图选择因特网社区联系人时，他们被动态地添加(或移除)到移动设备电话簿。合并状态(包括剩余的空闲空间)的实时更新以图表的形式被呈现。

为了支持移动用户的进一步的合并/通知的目的，社区朋友管理器还支持对因特网社区联系人的变化增量(delta)(添加、改变、移除)的识别。相反地，对移动设备电话簿的任何改变都可被反映回到社区朋友视图中。

附加的同步规则可以被添加至社区朋友管理器，其允许对移动设备电话簿的改变被反映回到因特网社区中(因特网社区联系人的添加、移除、修改)。

社区朋友管理器可被一个以上的因特网社区应用使用以管理与移动设备电话簿的同步(IM、社交网络、电子邮件、网络地址簿、桌面地址簿等)。

移动设备的另一方面提供了用户通过可下载的应用共享所访问的页面的链接的可能性。

传统地，当用户正在浏览时，他们可通过使用集成的消息传递应用共享当前页面的索引(例如经由SMS发送链接)。在当前的移动设备中，用户可将链接发送到一般的服务。这种服务必须对应于已经被下载到手持话机并且能够处理由浏览器所发送的URL的HLet应用11。这个进程的结果就是依赖于服务的并且可以对应于被发送到另一用户的消息或者对应于被发送到机器的消息。两个示例是：经由WLM共享这个链接或者将这个链接张贴在我的Facebook墙(Facebook Wall)上。

这个特征的实现需要以下两个步骤：

a)将处理链接的可下载应用将指示能够通过使用XML元数据(如在图3的集成方法中所使用的)来处理URL。通过使用相同的XML元数据，其还将指示哪个命令必须被添加至浏览器UI使得用户能够选择链接并且共享它。

b)每当用户经由浏览器UI激活这个命令时，手持话机将向与该命令一起登记的应用调用特定的H-API。

本发明的具体实现被包括在示例中使得有可能将照片或者来自媒体库或照相机本地应用12的其他类型的媒体数据提交给HLet应用11，诸如Facebook。另外，可以将Windows Live消息从联络簿发送到WLM HLet。消息还可以被发送给Windows Live MessengerHLet应用中的联系人。当新邮件被推送给邮件HLet时，邮件的通知可以出现在状态栏中。

Claims

1.一种移动通信设备，其包括：

用于经由多个独立的通信服务通过因特网协议网络发起通信的装置；

包括用户界面的一个或多个应用；以及

应用管理器组件，其用于协调有关通信服务的新应用的功能到已经存在于所述通信设备上的所述一个或多个应用的用户界面的集成。

2.根据权利要求1所述的设备，其还包括用于安装所述新应用的装置，并且其中所述应用管理器组件适用于识别已经被安装的新应用的类型。

3.根据权利要求2所述的设备，其中所述应用管理器组件适用于通知已经存在于所述通信设备上的所述一个或多个应用中的每一个新应用已经被安装，并且使所述一个或多个应用重新构建它们各自的用户界面以便在所述一个或多个应用的用户界面中包括所述新应用的功能。

4.根据权利要求1或2所述的设备，其中所述移动通信设备包括用于存储有关所述新安装的应用的数据的存储装置。

5.根据权利要求4所述的设备，其中所述存储装置适用于存储新安装的应用的列表。

6.根据权利要求5所述的设备，其中所述列表采用查找表的形式。

7.根据权利要求4或5所述的设备，其中所述存储装置包括一组预定义的方法以许可已经存在于所述通信设备上的所述一个或多个应用查询所述新应用并且与所述新应用交互。

8.根据前述任一项权利要求所述的设备，其中从包括以下各项的集合中选择所述通信服务：VoIP通信、即时消息传递(IM)通信、社交网络社区和通过因特网协议网络的拍卖。

9.根据前述任一项权利要求所述的设备，其中已经存在于所述通信设备上的第一应用包括用于电话服务的联系人列表，并且所述设备还包括用于将有关其他通信服务的用户的数据添加至所述联系人列表的装置。

10.根据权利要求9所述的设备，其中所述设备还包括用于将有关所述其他通信服务的用户的数据与所述联系人列表中的联系人合并的装置。

11.根据权利要求9或10所述的设备，其中有关所述其他通信服务的用户的数据包括与每个用户相关联的图像数据，并且所述新应用适用于从所述通信服务获得最新图像数据并且将所述最新图像数据存储在所述存储装置中，并且其中所述第一应用适用于在用户访问所述第一应用时从所述存储装置访问所述最新图像数据。

12.根据权利要求11所述的设备，其中所述设备包括用于在所述设备的用户经由电路交换电信网络接收信号时显示所述最新图像数据的装置。

13.根据前述任一项权利要求所述的设备，其中所述设备还包括用于通过因特网协议网络连接到通信服务的模块，所述模块包括用于确定所述设备所位于的电路交换和/或分组交换网络的网络服务提供商的标识数据的装置。

14.根据权利要求13所述的设备，其中所述模块还包括：用于将所述标识数据与多个网络服务提供商的预定标识数据进行比较的装置，其中所述多个网络服务提供商分别被分配到第一类别、第二类别或第三类别；以及用于判断所述设备是位于所述第一类别、第二类别还是第三类别中的装置。

15.根据权利要求14所述的设备，其中如果所述判断装置判断所述设备位于属于所述第一类别的网络中，则允许对所述通信服务的访问；如果所述判断装置判断设备位于属于所述第二类别的网络中，则在允许对所述通信服务的访问之前要向所述设备的用户征求许可；并且如果所述判断装置判断设备位于属于所述第三类别的网络中，则拒绝对所述通信服务的访问。

16.根据前述任一项权利要求所述的设备，其中所述设备包括用于为所述新应用提供集成的用户访问机制的共有图形用户界面，并且已经存在于所述通信设备上的应用中的一个包括用于确定所述新应用的当前状态并且用于在所述共有GUI上显示所述当前状态的装置。

17.一种移动通信设备，其包括：

18.一种移动通信设备，其包括：

19.根据权利要求18所述的设备，其中所述多个类别是第一类别、第二类别或第三类别；并且其中如果所述判断装置判断所述设备位于属于所述第一类别的网络中，则允许对所述通信服务的访问；如果所述判断装置判断设备位于属于所述第二类别的网络中，则在允许对所述通信服务的访问之前要向所述设备的用户征求许可；以及如果所述判断装置判断设备位于属于所述第三类别的网络中，则拒绝对所述通信服务的访问。

20.一种将已经被安装在移动通信设备上的有关通信服务的新应用的功能与已经存在于所述移动通信设备上的一个或多个当前应用集成的方法，所述方法包括：

接收新应用的安装包；

在所述移动通信设备上安装所述新应用，所述安装包包括有关所述新应用的集成能力的数据；以及

将所述新应用的功能与已经存在于所述移动通信设备上并且通过来自所述安装包的数据被识别的一个或多个当前应用集成。

21.根据权利要求20所述的方法，其中所述集成步骤包括识别已经被安装的新应用的类型。

22.根据权利要求20或21所述的方法，其中所述集成步骤还包括：确定已经存在于所述移动通信设备上的所述一个或多个当前应用中的哪些需要与所述新应用的功能集成，以及通知需要与所述新应用的功能集成的那些当前应用重新构建它们各自的用户界面。

23.一种供移动通信设备使用的应用管理器组件，其包括：用于经由电路交换和/或分组交换电信网络发送和接收信号的装置和用于经由多个独立的通信服务通过因特网协议网络发起通信的装置，所述应用管理器适用于协调有关通信服务的新应用的功能到已经存在于所述通信设备上的一个或者多个应用的用户界面的集成。