依赖于当前位置更新移动地址簿的应急号码的制作方法

专利名称：依赖于当前位置更新移动地址簿的应急号码的制作方法
技术领域：
本发明 一般地涉及应急通信。
背景技术：
应急服务不是全球通用的，而是会依赖于位置而有所不同。在不同位 置上，应急服务在所提供的服务类型方面有所不同。例如，在一个位置 上，单个应急服务提供通用服务。在另一位置上，特定应急服务提供特定 服务，例如警察、消防、急救以及山地救援。另外，在不同位置上，应急 服务在用户如何联络应急服务或如何获得对应急服务的访问方面也有所不
同。例如，在世界范围内存在多于60个不同的应急服务号码，其中某些 号码长度为一个数位，而某些号码长度为七个数位。
这种通用性的缺乏在用户具有高度移动性的情况下变得更加严重。通 常，用户知道针对一个位置上的应急服务的应急服务信息，而不知道另一 位置上的信息。考虑美国游客到法国旅行度假的示例。由于在美国长大， 该游客知道在紧急情况下应该拨打911。但是，在法国，针对应急服务拨 打911是不起作用的。在紧急事件时，游客不知道是存在像美国一样的单 个应急服务号码可以拨打，还是针对警察和消防具有不同的应急服务号 码。虽然游客知道针对美国的应急服务的应急服务信息在美国处于紧急情 况下是有用的，但是这对于游客在法国时处于紧急情况下没有帮助。


前述内容从以下参考附图对本发明的示例性实施例的更详细描述中将 变得显而易见，其中附图中的类似标号指示不同附图中的相同部件。附图 不一定是按比例绘制的，而是对示出本发明实施例的部分作出强调。
图1A示出一用户示例，该用户具备本地重要的应急服务信息；图IB示出一用户示例，该用户具备对用户位置重要的应急服务的应 急服务信息；
图1C示出一用户地址簿的示例，在用户从第一位置改变到第二位置
的情况下，该用户地址簿利用应急服务信息被更新；
图2A示出示例性拉(pull)体系结构的示例性消息流； 图2B示出示例性推(push)体系结构的示例性消息流； 图3A-3C示出使用动态主机配置协议(DHCP)、会话发起协议 (SIP)和位置-服务翻译(LoST)协议来学习本地重要的应急服务信息的
示例性消息流；
图4A和4B示出以指示应急服务信息对用户位置的重要性的方式呈现 应急服务信息的示例性显示；
图5示出用于提供本地重要的应急服务信息的示例性进程；以及 图6示出用于提供本地重要的应急服务信息的示例性装置。
具体实施例方式
利用蜂窝和因特网协议(IP)技术，可以学习针对用户位置的应急服 务的应急服务信息。即使应急服务的应急服务信息被学习到，用户也可能 不知道在紧急情况下使用该信息。就是说，在用户所知的应急服务的应急 服务信息与针对用户位置学习到的应急服务信息之间存在间隙。
一种解决方案是提供"应急按钮"，用户可以在紧急情况下按下该按 钮。但是，这种方案存在不小心按下应急按钮(例如在手袋或口袋中)并 发出错误的应急呼叫的可能性。
根据本发明的方法提供对用户位置而言在本地重要的应急服务的应急 服务信息。如所指的，该方法利用针对至少一种应急服务的应急服务信息 来更新用户的"联络"地址簿(下称地址簿)。应急服务信息是基于用户 位置的。该方法还以指示应急服务信息对用户位置的重要性的方式来呈现 针对至少一种应急服务的应急服务信息。
图1A-1C示出基于用户位置、利用针对至少一种应急服务的应急服 务信息来更新用户地址簿的示例。
7图1A示出位于位置115的用户105以及应急服务110。用户105的 地址簿120以下面将进一步描述的方式、利用针对应急服务110的应急服 务信息125来更新。但是，地址簿120不会被没有位于位置115的应急服 务的应急服务信息所更新。这样一来，地址簿120被利用基于用户105的 位置的应急服务信息125所更新。由于用户105和应急服务110都位于位 置115，因此在紧急情况下，应急服务110很可能处于将帮助或以其他方 式服务于用户105的位置上。相反，没有位于位置115的应急服务则不可 能处于服务于用户105的位置上。
考虑如下用户拨叫警察的示例。在美国，针对警察的应急服务信息 (例如应急拨号串)是911。就是说，在美国，用户拨打911来呼叫警 察。另一方面，在法国，针对警察的应急服务信息不是应急拨号串911， 而是拨号串112。对于在法国的用户而言，拨打911不具有拨叫本地警察 的相关性或重要性。同样，对于在美国的用户而言，拨打112不具有拨叫 本地警察的重要性。因此，认为应急服务信息的重要性取决于用户位置， 或在本地是重要的。
图1B示出用户135，其与第二应急服务140 —起位于位置145。但 是，第一应急服务142没有位于位置145。用户135的地址簿150利用针 对第二应急服务140的应急服务信息155被更新。由于第一应急服务142 没有位于位置145，因此地址簿150不会被针对第一应急服务142的应急 服务信息157所更新。这样一来，地址簿150通过利用对用户135的位置 145而言重要的应急服务信息155填充地址簿150而被更新。
但是，用户135可能曾经位于第一应急服务142的位置上。在这种情 况下，第一应急服务142的应急服务信息157曾经对用户135的位置而言 是重要的。因此，地址簿150可能已经填充有应急服务信息157。由于用 户135不再位于第一应急服务142的位置上，因此应急服务信息157不再 对用户135的位置145而言是重要的。因此，第一应急服务142的应急服 务信息157被删除，或以其他方式被从地址簿150中移走。这样一来，通 过从地址簿150中移走对用户135的位置145而言不再重要的应急服务信 息157来更新地址簿150。考虑以下示例用户先前位于法国，但现在位于美国。在法国，用户 的地址簿中填充有针对法国警察的应急服务信息。现在在美国，用户的地 址簿中针对法国警察的应急服务信息被移走，并填充以针对美国警察的应 急服务信息。这样一来，通过在用户的地址簿中填充上对用户位置而言重 要的应急服务信息并从用户地址簿中移走对用户位置而言不再重要的应急 服务信息来更新用户的地址簿。
图1C示出用户165，其当前与第二应急服务170 —起位于第二位置 175。由于用户165当前位于第二应急服务170的位置上，因此用户165 的当前地址簿包括针对第二应急服务170的应急服务信息185。
先前，用户165曾位于第一应急服务172所在的第一位置177 (如虚 线所示)。由于用户165先前曾位于第一应急服务172所在的位置上，因 此用户165的先前地址簿180b中曾包括针对第一应急服务172的应急服 务信息187。
这样一来，在用户165从第一位置177移动到第二位置175或以其他 方式发生从第一位置177到第二位置175的改变的情况下，从先前的地址 簿180b更新到当前的地址簿180a。
第一和第二位置(分别为175和177)包括(但不局限于)物理的地 理位置，例如州和国家；以及逻辑位置，例如蜂窝、局域网(LAN)、虚 拟私有网络(VPN) 、 802.11 WiFi热点等等。
此外，第一位置177可能根本不是一个位置。考虑用户在一位置上初 始化或以其他方式激活通信设备(例如移动电话)的示例。在初始化之 前，通信设备的位置对该通信设备而言是未知的。通过初始化通信设备 (例如通过将通信设备注册到服务器)，可以通过公知的技术来确定通信 设备和用户的位置。用户的地址簿利用对用户进行初始化的位置而言在本 地重要的应急服务信息被更新。这样一来，在用户在一位置上被初始化的 情况下，用户的地址簿可以利用针对至少一种应急服务的应急服务信息被 更新。
在某些实施例中，地址簿120 (图1A) 、 150 (图1B) 、 180a和 180b (图1C)可以被实现在通信设备中，该通信设备例如是移动电话、卫星电话、因特网电话以及在固定(桌上型)或移动(膝上型)计算机上 操作的基于软件的电话应用(也被称为"软电话")。这样的通信设备被
图示为示例性的蜂窝电话122 (图1A)、示例性的个人数字助理 (PDA) 152 (图IB)以及示例性的"软电话"182 (图1B和1A)。 通信设备可以提供单向通信(例如从服务提供商到通信设备的通信) 或双向通信(例如到服务提供商和来自服务提供商的通信)。此外，通信 设备可以使用任意物理传输介质，例如无线电波、微波和红外；以及任意 类型的信道或资源接入方法，例如码分多路接入(CDMA)、时分多路接 入(TDMA)和电气与电子工程师学会(IEEE) 802.11 (WiFi)。此外， 通信设备可以采用一种或多种蜂窝技术，例如全球移动通信系统 (GSM)、通用分组无线电服务(GPRS)、通用移动电信系统 (UMTS)、码分多路接入2000 (CDMA 2000)，以及其他第二代 (2G)、第2.5代(2.5G)和第三代(3G)蜂窝技术。
本领域技术人员将容易意识到，本发明的原理不依赖于被实现在特定 通信设备中，也不依赖于特定基本蜂窝技术。因此，本发明的实施例也可 被应用到未来的通信设备以及未来的蜂窝技术，例如即将到来的第四代 (4G)蜂窝技术。
在用户地址簿被实现在通信设备中的实施例中，利用应急服务信息更 新地址簿包括利用应急服务信息更新通信设备。
针对应急服务的应急服务信息可以利用应急服务信息库或存储库被存 储在用户或用户的通信设备中，或者可以利用其他方式被用户所用。在某 些实例中，应急服务信息存储库位于用户位置之内，而在其他实例中，该 存储库位于用户位置之外。此外，应急服务信息存储库可以集中位于单个 位置上，或者分布在多个位置上。
图2A-2B示出通过查询或接收对用户位置而言重要的应急服务信息 来更新用户地址簿的示例。
在图2A中，用户205在一位置上查询(210)针对该位置的应急服务 的应急服务信息。作为响应，应急服务信息存储库215回复(220)针对 该位置的应急服务的应急服务信息。这样一来，用户205的地址簿可以通
10息而被更新。
用户205可以使用诸如因特网协议(IP)之类的通信协议来进行査询 (210)，并且应急服务信息存储库215可以使用该协议来进行回复 (220)。此外，如本领域所知，用户205可以采取单播(即一对一)、 广播(即一对所有)或多播(即一对某些)方式来进行査询(210)，并 且应急服务信息存储库215可以按这些方式来进行回复(220)。此外， 用户205可以使用诸如蜂窝电话或IP电话之类的通信设备来进行査询 (210)，并且从应急服务信息存储库215接收回复。
由于应急服务信息是由用户205从应急服务信息存储库215 "拉"出 的，因此图2A所示通信体系结构可以被称为"拉体系结构"。
在图2B中，应急服务信息存储库255向一位置上的用户265通知 (260)针对该位置的应急服务的应急服务信息。这样一来，用户265的 地址簿可以通过接收对用户265的位置而言重要的应急服务信息而被更 新。
应急服务信息存储库255可以使用诸如因特网协议(IP)之类的通信 协议来通知(260)用户265。此外，如本领域所知，应急服务信息存储 库255可以采取单播(即一对一)、广播(即一对所有)或多播(即一对 某些)方式来通知(260)用户265。此外，用户265可以使用诸如蜂窝 电话或IP电话之类的通信设备来接收来自应急服务信息存储库255的应 急服务信息。
由于应急服务信息是从应急服务信息存储库255 "推"向用户265 的，因此图2B所示通信体系结构可以被称为"推体系结构"。
在某些实施例中，用户的地址簿是利用用户或用户的通信设备使用某 一协议获取的或以其他方式学习到的应急服务信息来更新的，所述协议例 如是用于开放系统互连(OSI)基本参考模型的应用层的协议。
图3A示出使用动态主机配置协议(DHCP)来获取或以其他方式学 习针对用户位置的应急服务的应急服务信息。
一般而言，如请求注释(RFC) 2131 (题为"Dynamic Host Configuration Protocol" ， R. Droms， 1997年3月)所标准化的，DHCP向主机提供配置参数。DHCP被建立在客户端-服务器模型上，其中指定 的DHCP服务器主机向动态配置的主机传递配置参数。如RFC 2132 (题 为"DHCP Options and BOOTP Vendor Extensions" ， S. Alexander禾口 R. Droms， 1997年3月)所标准化的，除了配置参数之外，主机可以通过 DHCP选项请求可选的配置参数并且这些可选的配置参数被提供到主机。
"动态主机配置(DHC)应急拨号串选项"就是一种这样的选项，其使得 客户端能够从本地基础设施请求针对用户位置的(即在本地重要的)应急 服务的应急拨号串，如在draft-polk-dhc-emergency-dialstring-opion-OO.txt
(题为"A Dynamic Host Configuration Protocol Option for the Locally Significant Emergency Calling Dialstring" ， J. Polk禾口B. Rosen ， 2006年2 月)中所提出的。
继续参考图3A，用户302以典型的DHCP方式向DHCP服务器308 发送具有DHC应急拨号串选项306a的DHCPINFORM消息304。 DHC应 急拨号串选项306a请求针对用户位置的应急服务的应急服务信息(由一 空(NULL)的拨号串字段值所指示)。在该示例中，用户302请求应急 拨号串(拨号串数位)310并且包括应急服务标识符(服务ID) 312。应 急服务标识符312标识所请求的应急服务的类型为警察。就是说，用户 302希望学习用于拨叫警察的应急拨号串。
可替换地，在不发送DHCPINFORM消息的情况下，用户可以通过发 送DHCPDISCOVER或DHCPREQURST消息来请求针对用户位置的应急 服务的应急服务信息。与上述情况类似，用户以典型的DHCP方式将具有 DHC应急拨号串选项的DHCPDISCOVER或DHCPREQURST消息发送到 DHCP服务器，以请求针对用户位置的应急服务的应急服务信息。
继续参考图3A，用户302以典型的DHCP方式从DHCP服务器308 接收具有DHC应急拨号串选项306b的DHCPACK消息314。该DHC应 急拨号串选项306b提供针对用户302的位置的应急服务的应急服务信 息。在该示例中，用户302接收针对用户302的位置的警察服务的应急拨 号串(拨号串数位)316。就是说，用户302在给定用户302的位置的情 况下学习用于拨叫警察的应急拨号串。用户302的位置可能对DHCP服务器308是已知的，因为用户302通 知了 DHCP服务器308。例如，用户302发送具有标识用户302的位置的 国家或位置代码的DHCPINFORM消息。可替换地，DHCP服务器308可 以使用RFC 3825 (题为"Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information" ， J. Polk等，2004年 7月)来确定用户302的位置。DHCP服务器308还可以基于由用户302 发送的DHCPINFORM消息和网络拓扑与地理知识；或基于DHCP服务器 308只服务于用户302的位置的事实来确定用户302的位置。
在另一示例中，DHCPINFORM消息304可以包括用于请求针对多于 一个应急服务的应急服务信息的DHC应急拨号串选项。这样一来，用户 302可以学习到针对一种或多种应急服务的应急服务信息。
在又一示例中，DHCPINFORM消息304可以包括用于请求针对任意 应急服务的应急服务信息的DHC应急拨号串选项。就是说，用户302不 需要特别请求针对一特定类型的应急服务的应急服务信息。这样一来，用 户302可以学习到针对一种或多种应急服务的应急服务信息。
图3B示出使用会话发起协议(SIP)来获取或以其他方式学习针对用 户位置的应急服务的应急服务信息。 一般而言，SIP创建、修改和终止与 一个或多个参与者之间的会话(例如因特网电话呼叫、多媒体分布和多媒 体会议)，如请求注释(RFC ) 3261 (题为"Session Initiation Protocol" ， J. Rosenberg等，2002年6月)所标准化的。
在SIP中，注册(Registration)是服务器(例如SIP注册器)学习用 户的当前位置的一种方式。除了传达用户的当前位置之外，在注册期间还 可以使用一个或多个SIP选项标签(tag)和头部来请求和提供针对应急服 务的应急服务信息。
例如，"服务号"选项标签使得用户能够请求针对用户位置的应急服 务的应急服务信息(例如应急号码)。作为响应，包含对用户位置而言在 本地重要的一个或多个应急服务的应急服务信息的"服务号"头部被返 回。
继续参考图3B，用户322以典型的SIP方式向SIP注册器326发送REGISTER消息324。在REGISTER消息324中，Supported头部328包 括"服务号"选项标签330。这样一来，用户322请求SIP注册器326提 供对用户322的位置而言在本地重要的(一个或多个)应急服务的应急服 务信息。就是说，用户322希望学习在给定用户322的位置的情况下将使 用的应急信息(例如应急服务地址)。
用户322以典型的SIP方式接收来自SIP注册器326的"200 OK"消 息332。在"200 OK"消息332中，"服务号"头部334包括针对一种或 多种应急服务的应急服务信息。在图3B所示示例中，"服务号"头部 334包括分别针对警察和消防服务的应急服务地址336a和336b。
"服务号"头部334还可以包括"服务类型"头部参数338，用于标 识应急服务的类型。在图3B所示示例中，"服务类型"头部参数338包 括分别用于标识应急服务类型为警察和消防的应急服务标识符340a和 340b。就是说，用户322学习到针对用户322的位置，将使用哪种应急服 务地址用于警察以及将使用哪种应急服务地址用于消防部门。
用户322的位置对于SIP注册器326可以是己知的，因为用户322可 以在REGISTER消息中通知SIP注册器326。可替换地，SIP注册器326 可以基于SIP注册器326只服务于用户322的该位置的事实来确定用户 322的位置。
图3C示出使用位置-服务翻译(LoST)协议来获取或以其他方式学 习针对用户位置的应急服务的应急服务信息。 一般而言，LoST将服务标 识符和位置信息映射到一个或多个服务通用资源定位符(URL)，如 Internet-Draft draft-ietf-ecrit-lost-04.txt (题为"LoST: A Location-to曙Service Translation Protocol" ， T.Hardie等，2007年2月)所建议的。
用户342以典型的LoST方式向LoST服务器346发送fmdService消 息344。 fmdService消息344请求针对位置353的应急服务的应急服务信 息。在图3C所示示例中，用户342请求针对一应急服务的应急服务信 息，该应急服务所具有的统一资源名(URN) 352将该应急服务标识为警 察。就是说，用户342希望学习在给定位置353的情况下具有URN 352 的应急服务。用户342以典型的LoST方式接收来自LoST服务器346的 findServiceResponse消息354。 fmdServiceResponse消息354提供针对位置 353的应急服务的应急服务信息。在该示例中，用户342接收针对警察的 应急服务信息，其具有定位警察的统一资源标识符(URI) 356或统一资 源定位符(URL)。就是说，用户342学习到针对位置353的具有URN 352的应急服务的URI356。
在另一示例中，findService消息344可以包括多于一个URN 352，其 中每个URN 352标识不同的应急服务。这样一来，用户342可以学习针 对一种或多种应急服务的应急服务信息。
在又一示例中，fmdService消息344可以包括标识任意应急服务的 URN 352。就是说，用户342不需要特别请求针对具有标识一特定应急服 务的URN的应急服务的应急服务信息。因此，用户342可以接收针对具 有任意URI或URL的应急服务的应急服务信息。这样一来，用户342可 以学习到针对一种或多种应急服务的应急服务信息。
如图3A、 3B和3C所示，在某些实施例中，学习针对应急服务的应 急服务信息包括学习应急服务地址，例如应急拨号串、服务号和URN。 另外，在某些实施例中，学习应急服务信息包括学习应急服务标识符，例 如服务ID、服务类型、URI或URL。
以上描述不希望作为由用户(或由用户的通信设备)所学习的应急服 务信息的穷尽列表，而是充当一个示例。本领域技术人员容易意识到，由 用户(或通信设备)所学习的其他信息也处在本发明的各个实施例的设想 之内。
例如，在图3C中，fmdServiceResponse消息354提供与所请求的应 急服务相对应的其他信息。在该示例中，用户342接收displayName 358。在某些实施例中，displayName 358被呈现给用户342 (下文中将更 详细地描述)。
除了使用DHCP、 SIP或LoST协议中的任意一种学习针对应急服务 的应急服务信息之外，可替换地，用户还可以使用前述协议的任意组合来 学习这些信息。由于用户可能有多于一种方式来学习应急服务信息，因此
15用户可能使用第一协议来学习第一应急服务信息并使用第二协议来学习第 二应急服务信息。
考虑以下用户使用DHCP和LoST来学习针对警察服务的应急服务信 息的示例。由于LoST适合于提供统一资源指示符(URI)，因此用户使 用LoST来学习针对警察的URI (例如police@example.com)。由于 DHCP适合于提供应急拨号串，因此用户使用DHCP来学习针对警察的应 急拨号串(例如911)。结果，用户可以使用URI (使用LoST学习到) 或应急拨号串(使用DHCP学习到)来联络警察部门。
因此，由于用户可能有多于一种方式学习应急服务信息，因此用户的 地址簿可以利用使用DHCP、 SIP和LoST协议中的任意一种或组合学习 到的针对应急服务的应急服务信息来更新。
DHCP、 SIP和LoST协议仅仅是作为可以用来学习针对应急服务的应 急服务信息的方式的示例来提供的。本领域技术人员容易意识到，本发明 的原理并不局限于这些示例，而是还可能设想其他方式。例如，应急服务 信息可以使用短消息服务(SMS)、即时消息(IM)或用于OSI网络参 考模型的应用层的其他消息传送技术来学习。在这样的示例中，用户以典 型的SMS方式发送和接收去往和来自SMS服务器的SMS消息，以学习 针对用户位置的应急服务的应急服务信息。
此外，本发明的实施例并不局限于使用应用层协议(例如前面所提到 的那些)来学习应急服务信息。在一个示例中，应急服务信息可以使用链 路层发现协议(LLDP)来学习，该LLDP是允许网络设备广告网络设备 在本地网络上的身份和能力的链路层协议(即，用于OSI基本参考模型的 链路层的协议)。LLDP在电气与电子工程师学会(IEEE)标准802.1AB-2005中被标准化。在另一示例中，应急服务信息可以使用CISCO发现协 议(CDP)来学习，该CDP是由CISCO SYSTEMS开发的允许在CISCO 设备之间共享信息的另一链路层协议。再次重申，本发明的原理的通用性 不会因为前述示例而失去。
即使用户的地址簿利用针对应急服务的应急服务信息被更新(例如通 过学习该信息)，用户在紧急情况下也可能不知道使用该信息。例如，尽管学习单独地拨叫警察和消防服务是有必要的，但是用户也可能错误地使 用针对消防服务的应急服务信息来联络警察服务，如果他认为该信息可以 应用于两者的话。就是说，在用户所知的应急服务信息和针对用户位置学 习到的应急服务信息之间存在间隙。因此，在某些实例中，向用户提供应 急服务信息包括以指示应急服务信息对用户位置的重要性的方式来呈现信 息。
用于以指示应急服务信息对用户位置的重要性的方式来呈现信息的一 种解决方案在于创建"应急按钮"。在紧急情况下，用户将使用应急按钮 来联络应急服务。但是，该解决方案带来不小心按下应急按钮(例如在手 袋或口袋中)并发出错误的应急呼叫的可能性。另一种不会带来这种意外 的呼叫问题的解决方案是无论现有排序如何，都将应急服务信息呈现在 用户地址簿的其他条目之前。
图4A示出地址簿405a，其具有行条目415a、 415b、 ...415n (统称 415)的第一排序410。在图4A所示示例中，在第一排序410中，行条目 415按字母顺序排序。在其他示例(未示出)中，行条目415可以按笔划 (例如针对中文字)、按用户所定义的顺序，或按条目415被输入到地址 簿405a的顺序来排序。
地址簿405a利用应急服务信息(例如使用DHCP学习的应急服务信 息)被更新。应急服务信息被呈现在具有第二排序420的地址簿405b 中。在第二排序420中，应急服务信息行条目425位于行条目415之前。 在图4A所示示例中，尽管条目"Police"是在按字母排序的条目"Alice, Bob, Chris， ... n"之后到来的，但是该应急服务行条目425处于行条目 415之前。以不同方式所呈现的，第一排序410被第二排序420所取代。 这样一来，通过将应急服务信息在用户的地址簿中显示为处于其他行条目 之前的行条目，从而将应急服务信息呈现出来。
参考图4A，可以说第二排序420是这样的排序其呈现出对用户的 位置而言重要的应急服务信息。相反，可以说第一排序410是这样的排 序其没有呈现出应急服务信息。
在第一示例中，图4B示出呈现针对应急服务的应急服务信息包括呈现用于标识该服务的应急服务标识符。在该示例中，第一应急服务标识符
460a标识警察服务，第二应急服务标识符460b标识消防服务。如参考图 4A所述，呈现应急服务信息可以包括将应急服务信息在用户的地址簿中 显示为处于其他行条目之前的行条目。因此，在地址簿455a中，标识警 察和消防服务的标识符(分别为460a和460b)可以被显示为处于其他行 条目465a、 465b、…465n (统称465)之前的行条目。
再次回顾图3C，与应急服务相对应的其他信息(例如displayName 358)也可以被学习。因此，将应急服务标识为纽约警察局(NYPD)的 应急服务标识符(未示出)可以在地址簿455a中被显示为处于其他行条 目之前的行条目。这样一来，所呈现的应急服务信息可能不仅标识一种应 急服务，而且还标识出是哪种应急服务。
在第二示例中，图4B示出呈现应急服务信息还包括呈现定位警察和 消防服务的应急服务地址470a、 470b和470c。在该示例中，应急服务地 址470a使用应急服务拨号串来定位警察。而且在该示例中，应急服务地 址470b使用统一资源标识符(URI)来定位警察。由于该实施例呈现出 应急服务地址和应急服务标识符两者，因此可以帮助用户学习并熟悉针对 应急服务的应急服务地址。
在地址簿455b中，与呈现应急服务标识符460a和460b类似，应急 服务地址470可以被显示为处于其他行条目465之前的行条目。
在某些实例中，单个通用应急服务地址定位若干应急服务。例如，在 美国，应急拨号串911定位公共安全应答点(PSAP) 。 PSAP是通常由国 家或城市控制的代理机构，其负责应答针对警察、消防以及急救服务的应 急协助的911呼叫。因此，在这些实例中，呈现应急服务地址包括呈现用 于PSAP的应急拨号串或URI中的任意一个或组合。
本领域技术人员将容易意识到，本发明的实施例并不局限于以特定形 式呈现应急服务信息。例如，在某些实例中，应急服务信息可以以图形方 式来呈现。在这些实例中，呈现应急服务信息可以取决于用户界面的能 力。在另一示例中，应急服务信息可以以文本形式来呈现。再次重申，在 这些实例中，呈现应急服务信息可以取决于用户界面的能力。在又一示例中，应急服务信息可以经由指示符(例如键、按钮、可视提示或音频提 示)来呈现。如上所述，应该明了，以特定形式来呈现应急服务信息是不 重要的。
图5示出用于提供本地重要的应急服务信息的示例性过程500。过程 500开始于提供本地重要的应急服务信息。过程500利用针对至少一种应 急服务的应急服务信息来更新(505)用户的地址簿。应急服务信息是基 于用户位置的。过程500以指示应急服务信息对用户位置的重要性的方式 将针对至少一种应急服务的应急服务信息呈现(510)在用户的地址簿 中。过程500以提供本地重要的应急服务信息结束。
图6示出用于提供本地重要的应急服务信息的示例性装置600。装置 600包括更新器605，用于利用针对至少一种应急服务的应急服务信息 607来更新用户的地址簿606。应急服务信息607基于用户的位置。装置 600包括耦合到更新器605的呈现器610，用于呈现针对至少一种应急服 务的应急服务信息607。呈现器607以指示信息607对用户位置的重要性 的方式来呈现应急服务信息607。
在图6所示的替换实施例中，更新器605进一步包括去填充器615， 用于从用户的地址簿606中移走对用户的位置不重要的应急服务信息 616。更新器605还包括填充器620，用于利用应急服务信息607来填充用 户的地址簿606。与应急服务信息616相对照，应急服务信息607对用户 位置而言是重要的。
总之，装置600利用应急服务信息607来更新(625)用户的地址簿 606，并呈现(630)应急服务信息607。
虽然已经参考本发明的示例性实施例具体地示出和描述了本发明，但 是本领域技术人员将会理解，在不脱离所附权利要求书所包含的本发明的 范围的情况下，可以在形式和细节上作出各种改变。
应该理解，上述框图、网络图和流程图中的元素可以被实现为软件、 硬件或固件。例如，更新器605和呈现器610 (图6)可以被实现在诸如 移动电话的通信设备中，该通信设备可以是或不是PDA、卫星电话、因 特网电话以及在固定(桌上型)或移动(膝上型)计算机上操作的基于软
19件的电话应用(也被称为"软电话")的一部分。
另外，上述框图和流程图中的元素可以在软件、硬件或固件中以任意 方式被组合或分割。如果被实现在软件中，该软件则可以用能够支持这里 所公开的实施例的任意语言来书写。该软件可以被存储在任意形式的计算
机可读介质上，例如RAM、 ROM、 CD-ROM等等。在操作中，通用或专 用处理器以本领域公知的方式来加载和执行软件。
此外，应该理解，流程图(例如图5)可以包括更多或更少的块、可 以按不同方式排列、或者可以按不同方式表示。应该理解，根据实现方式 可以定义流程图以及示出执行本发明的实施例的流程图的数目。
权利要求
1.一种方法，包括利用针对至少一种应急服务的应急服务信息来更新用户的地址簿，所述应急服务信息基于用户位置；以及以指示所述应急服务信息对用户位置的重要性的方式来呈现针对所述至少一种应急服务的所述应急服务信息。
2. 如权利要求1所述的方法，其中利用所述应急服务信息来更新用户 的地址簿包括从所述用户的地址簿中移走对用户位置不重要的应急服务信息；以及 用对用户位置重要的应急服务信息来填充所述用户的地址簿。
3. 如权利要求1所述的方法，其中更新所述用户的地址簿包括查询所 述对用户位置重要的应急服务信息。
4. 如权利要求1所述的方法，其中更新所述用户的地址簿包括接收所 述对用户位置重要的应急服务信息。
5. 如权利要求1所述的方法，其中更新所述用户的地址簿包括使用如 下协议中的任意一种或组合来学习所述对用户位置重要的应急服务信息 动态主机配置协议DHCP、会话发起协议SIP、或位置-服务翻译LoST协 议。
6. 如权利要求1所述的方法，其中呈现所述应急服务信息包括无论 现有排序如何，都将所述应急服务信息呈现在所述用户的地址簿的其他条 目之前。
7. 如权利要求6所述的方法，其中将所述应急服务信息呈现在所述用户的地址簿的其他条目之前包括将所述应急服务信息显示为在所述用户的地址簿中的其他行条目之前的行条目。
8. 如权利要求1所述的方法，其中呈现所述应急服务信息包括呈现针对所述至少一种应急服务的应急服务信息地址和应急服务标识符。
9. 如权利要求8所述的方法，其中呈现针对所述至少一种应急服务的所述应急服务信息地址包括呈现公共安全应答点PSAP的应急拨号串或统一资源标识符URI中的任意一种或组合。
10. 如权利要求1所述的方法，还包括在所述用户在所述位置上被 初始化的情况下，利用针对所述至少一种应急服务的所述应急服务信息来 更新所述用户的地址簿。
11. 如权利要求1所述的方法，还包括在用户改变位置的情况下， 利用针对所述至少一种应急服务的所述应急服务信息来更新所述用户的地 址簿。
12. 如权利要求1所述的方法，其中利用所述应急服务信息更新所述 用户的地址簿包括更新从如下群组中选出的通信设备中的用户的地址簿 移动电话、卫星电话、因特网电话和软电话。
13. 如权利要求1所述的方法，其中呈现所述应急服务信息包括使用 从如下群组中选出的用户界面来呈现所述应急服务信息基于图形的界 面、基于文本的界面、可视指示符和音频指示符。
14. 一种装置，包括更新器，用于利用针对至少一种应急服务的应急服务信息来更新用户 的地址簿，所述应急服务信息基于用户位置；以及耦合到所述更新器的呈现器，用于以指示所述应急服务信息对用户位 置的重要性的方式来呈现针对所述至少一种应急服务的所述应急服务信 息。
15. 如权利要求14所述的装置，其中所述更新器包括去填充器，用于从所述用户的地址簿中移走对用户位置不重要的应急 服务信息；以及填充器，用于用对用户位置重要的应急服务信息来填充所述用户的地 址簿。
16. 如权利要求14所述的装置，其中所述更新器包括用于査询所述对 用户位置重要的应急服务信息的接口 。
17. 如权利要求14所述的装置，其中所述更新器包括用于接收所述对 用户位置重要的应急服务信息的接口。
18. 如权利要求14所述的装置，其中所述更新器包括用于使用如下协议中的任意一种或组合来学习所述对用户位置重要的应急服务信息的接口动态主机配置协议DHCP、会话发起协议SIP、或位置-服务翻译 LoST协议。
19. 如权利要求14所述的装置，其中所述呈现器被配置为无论现有排 序如何，都将所述应急服务信息呈现在所述用户的地址簿的其他条目之 目ij。
20. 如权利要求19所述的装置，其中所述呈现器还被配置为将所述应 急服务信息显示为在所述用户的地址簿中的其他行条目之前的行条目。
21. 如权利要求14所述的装置，其中所述呈现器被配置为呈现针对所 述至少一种应急服务的应急服务信息地址和应急服务标识符。
22. 如权利要求21所述的装置，其中所述呈现器还被配置为将针对 所述至少一种应急服务的所述应急服务信息呈现为公共安全应答点PSAP 的应急拨号串或统一资源标识符URI中的任意一种或组合。
23. 如权利要求14所述的装置，其中所述更新器还适于在所述用户 在所述位置上被初始化的情况下，利用针对所述至少一种应急服务的所述 应急服务信息来更新所述用户的地址簿。
24. 如权利要求14所述的装置，其中所述更新器还适于在用户改变 位置的情况下，利用针对所述至少一种应急服务的所述应急服务信息来更 新所述用户的地址簿。
25. 如权利要求14所述的装置，其中所述更新器和所述呈现器被实现 在从如下群组中选出的通信设备中移动电话、卫星电话、因特网电话和 软电话，所述通信设备具有从如下群组中选出的用户界面基于图形的界面、基于文本的界面、可视指示符和音频指示符。
26. 编码在一个或多个有形介质中的用于执行的逻辑，当所述逻辑被执行时可操作用于利用针对至少一种应急服务的应急服务信息来更新用户的地址簿，所述应急服务信息基于用户位置；以及以指示所述应急服务信息对用户位置的重要性的方式来呈现针对所述 至少一种应急服务的所述应急服务信息。
27.—种装置，包括用于利用针对至少一种应急服务的应急服务信息来更新用户的地址簿 的装置，所述应急服务信息基于用户位置；以及用于以指示所述应急服务信息对用户位置的重要性的方式来呈现针对 所述至少一种应急服务的所述应急服务信息的装置。
全文摘要
一种方法和相应的装置为用户提供对用户位置(115)而言重要的应急服务信息(125)。用户的地址簿(120)利用针对至少一种应急服务(110)的应急服务信息(125)被更新，所述应急服务信息(125)基于用户的位置(115)，并且针对至少一种应急服务(110)的应急服务信息(125)以指示应急服务信息(125)对用户位置(115)的重要性的方式被呈现。
文档编号H04M1/725GK101632288SQ200880007848
公开日2010年1月20日 申请日期2008年3月11日 优先权日2007年3月15日
发明者詹姆斯·M·帕克 申请人:思科技术公司