CN105051495B - 一种预测设备的目的地的方法以及用于获取地址的设备 - Google Patents

一种预测设备的目的地的方法以及用于获取地址的设备 Download PDF

Info

Publication number
CN105051495B
CN105051495B CN201480013892.7A CN201480013892A CN105051495B CN 105051495 B CN105051495 B CN 105051495B CN 201480013892 A CN201480013892 A CN 201480013892A CN 105051495 B CN105051495 B CN 105051495B
Authority
CN
China
Prior art keywords
address
equipment
physical address
group
acquired
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201480013892.7A
Other languages
English (en)
Other versions
CN105051495A (zh
Inventor
A·B·克拉克
J·菲诺
S·赫兹
E·乌尔卡诺
M·范欧斯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Apple Inc
Original Assignee
Apple Computer Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US14/081,850 external-priority patent/US20140365505A1/en
Application filed by Apple Computer Inc filed Critical Apple Computer Inc
Priority to CN201910672157.1A priority Critical patent/CN110388935B/zh
Publication of CN105051495A publication Critical patent/CN105051495A/zh
Application granted granted Critical
Publication of CN105051495B publication Critical patent/CN105051495B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G01MEASURING; TESTING
    • G01CMEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34Route searching; Route guidance
    • G01C21/36Input/output arrangements for on-board computers
    • G01C21/3605Destination input or retrieval
    • G01C21/3608Destination input or retrieval using speech input, e.g. using speech recognition
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01CMEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34Route searching; Route guidance
    • G01C21/36Input/output arrangements for on-board computers
    • G01C21/3605Destination input or retrieval
    • G01C21/3617Destination input or retrieval using user history, behaviour, conditions or preferences, e.g. predicted or inferred from previous use or current movement
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01CMEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34Route searching; Route guidance
    • G01C21/36Input/output arrangements for on-board computers
    • G01C21/3605Destination input or retrieval
    • G01C21/362Destination input or retrieval received from an external device or application, e.g. PDA, mobile phone or calendar application
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01CMEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34Route searching; Route guidance
    • G01C21/36Input/output arrangements for on-board computers
    • G01C21/3688Systems comprising multiple parts or multiple output devices (not client-server), e.g. detachable faceplates, key fobs or multiple output screens

Abstract

本发明的一些实施例提供了一种地址获取器,该地址获取器从在设备上执行的一个或多个应用程序中获取地址。一些实施例使用所获取的地址来促进在设备上执行的一个或多个应用程序的操作。另选地或结合地,一些实施例使用所获取的地址来促进在另一个设备上执行的一个或多个应用程序的操作,该另一个设备不同于用于获取地址的设备。在一些实施例中,预测系统使用所获取的地址来制定预测,然后将该预测提供至该预测系统从其获取地址的同一组应用程序。

Description

一种预测设备的目的地的方法以及用于获取地址的设备
背景技术
随着技术的兴起,从一个位置行驶到另一位置越来越容易。人们不再需要拿出纸质地图并尝试想出如何从A点到达B点。相反地,人们可仅使用在其移动设备上操作的电子地图来来获得两个地址之间的方向。尽管此类地图使用起来很简单,但人们仍必须输入不同的地址。输入地址可能看起来很容易,但当考虑需要从中检索地址的多个不同来源时就其本身而言可能是很繁琐的。例如,为了找到电子邮件中的地址,人们必须打开邮件应用程序并整理电子邮件以找到具有地址的电子邮件。地址通常在电子邮件的正文中。因此,最可能的情况是,人们必须找到并打开电子邮件,然后浏览邮件以找到地址。然后,在此之后,必须将地址从电子邮件拷贝到另一个应用程序,诸如地图应用程序或网络浏览器。如果人们不记得该地址,则在下一次需要该地址时,他或她必须重复上述相同过程。
发明内容
本发明的一些实施例提供了一种地址获取器,该地址获取器从在设备上执行的一个或多个应用程序中获取地址。一些实施例使用所获取的地址来促进在设备上执行的一个或多个应用程序的操作。另选地或结合地,一些实施例使用所获取的地址来促进在另一个设备上执行的一个或多个应用程序的操作,该另一个设备不同于用于获取地址的设备。
例如,在一些实施例中,预测系统使用所获取的地址来制定预测,然后将该预测提供至该预测系统从其获取地址的同一组应用程序。在其他实施例中,预测系统将预测提供至不同组应用程序,该不同组应用程序可与或可不与用于获取的该组应用程序重叠。
在不同实施例中,所获取的地址是不同的。在一些实施例中,它们包括用于电信消息的电信地址。此类地址的实例包括用于电话呼叫和/或文本消息(例如,随SMS或iMessage文本服务发送的文本消息)的电话号码,以及用于电子邮件消息或文本消息的电子邮件地址。
一些实施例获取电话号码和电子邮件两者,而其他实施例仅获取这些类型的电信地址中的一个电信地址。另外,在一些实施例中,所获取的电信地址包括用于同时向若干个接收人发送电子邮件消息和/或文本消息的若干个电信地址(例如,若干个电子邮件地址和/或电话号码)。
在用户正在输入消息的接收人或接收人列表时,一些实施例使用所获取的电信地址来预测并显示电信消息的一个或多个候选接收人。另选地或结合地,所获取的电信地址可用于增强接收人数据存储装置(例如,数据库),语音识别应用程序响应于语音指令使用该接收人数据存储装置来准备电信消息或发起电信会话(例如,电话呼叫或视频会议)。
除获取电信消息之外或代替该获取,一些实施例的获取系统还获取物理世界中的地址。此类所获取的地址的实例包括从电子邮件消息、文本消息、日历标注的事件、电子票务等获取的物理地址。另选地或结合地,这些所获取的地址包括在设备上执行的网络浏览器或地图应用程序中由设备的用户浏览的物理地址。此类浏览需要搜索地址、查看地址和/或使用该地址来指定用于进行查看或导航的路线。
一些实施例使用所获取的物理地址来制定有关设备用户的未来目的地的预测,然后基于这些预测来向用户提供信息。为了制定这些预测,一些实施例采用一个或多个机器学习引擎来生成附加物理地址以增强用于作为其预测基础的一组物理地址。
不同的实施例基于预测向用户提供不同的信息。此类信息的实例包括到所预测的未来目的地的路线、有关到可能的未来目的地的路线的交通数据、所预测的未来目的地在可能目的地或搜索查询的列表中优先于其他目的地的显示,等等。普通技术人员将认识到,在一些实施例中,所获取的物理地址并不用于所有这些目的。普通技术人员还将认识到,在其他实施例中,所获取的物理地址用于其他预测和其他用途。
一些实施例采用排序引擎来计算针对每个所获取的地址(例如,每个电信地址和每个物理地址)或每个某种类型的所获取的地址(例如,物理地址) 的排序分值。除了排序引擎之外,一些实施例还使用衰减引擎来随时间衰减针对所获取的地址的所计算的排序分值。
如上所述,一些实施例使用所获取的地址来促进在另一个设备上执行的一个或多个应用程序的操作,该另一个设备不同于用于获取地址的设备。在一些实施例中,该另一个设备通过网络可通信地与所获取的设备连接,并且其通过该连接来接收所获取的地址。例如,在一些实施例中,两个设备通过云服务器基础结构彼此相关联(例如,与同一账户相关联),该云服务器基础结构在将来自一个设备的所获取的地址转发至其他设备之前暂时对其进行存储。
这样,云基础结构使两个设备免于必须建立实时通信会话以便将所获取的地址从一个设备下载到另一个设备。换句话讲,该基础结构简化了在不同设备上创建重复分布式数据存储装置(例如,数据库)以存储在不同设备上所获取的地址的过程。结合从每个设备上的多个应用程序获取地址数据,该稳固分布式数据存储装置在多个设备上同步,使得一些实施例的地址获取架构很强大,因为其能够快速建立驻留在多个设备上并且可增强每个设备上的多个应用程序的操作的大量地址存储装置。
上述发明内容旨在用作对本发明的一些实施例的简单介绍。其并非意味着对在本文档中所公开的所有发明主题进行介绍或概述。随后的具体实施方式以及在具体实施方式中所参照的附图将进一步描述发明内容中所述的实施例以及其它实施例。因此,为了理解该文档所述的所有实施例,需要全面审阅发明内容、具体实施方式和附图。此外,受权利要求书保护的题材不被发明内容、具体实施方式及附图中的示例性细节所限定,而是被所附权利要求所限定,这是因为受权利要求书保护的题材在不脱离本题材的实质的情况下能够以其它特定形式体现。
附图说明
在所附的权利要求中阐述了本发明的新型特征。然而,出于说明的目的,在以下附图中阐释了本发明的若干个实施例。
图1示出了本发明的一些实施例的设备的地址获取架构。
图2示出了一些实施例用于对存储所获取的地址进行优先排序的排序引擎和衰减引擎的实例。
图3示出了可使用在一个设备上所获取的地址来促进在另一个设备上执行的一个或多个应用程序的操作的获取架构的实例。
图4呈现了示出在设备上所获取的各种电信地址的实例。
图5示出了用于获取电信地址并将这些地址存储在地址存储装置中的架构。
图6和图7示出了一些实施例的地址获取器所执行的两个过程。
图8-11提供了所获取的地址如何可用于提供电信消息的预测接收人的四个实例。
图12和图13示出了一些实施例的设备的匹配引擎和由该引擎执行以使得用户输入与存储于地址存储装置中的电信地址匹配的过程。
图14示出了基于在用户键入接收人电子邮件地址时的不同输入字符串按照排序顺序检索并呈现的不同组记录。
图15和图16呈现了地址获取器捕获电子邮件和文本消息中的物理地址的若干个实例。
图17示出了基于在地图中查看该地址来调节所获取的物理地址的排名。
图18示出了将物理地址发布至地图应用程序以及在该过程中获取该物理地址以用于存储在地址存储装置中的实例。
图19示出了响应于用户在移动设备上执行的地图应用程序中搜索地址来获取物理地址的实例。
图20示出了响应于用户利用移动设备的地图应用程序来识别路线以获取物理地址的实例。
图21示出了响应于对由移动设备的地图应用程序所呈现的地图上的兴趣点(POI)的选择来获取物理地址的实例。
图22示出了从日历应用程序获取物理地址的实例。
图23示出了从日历邀请来获取物理地址的实例。
图24概念性地示出了一些实施例的用于存储和衰减地址的架构。
图25示出了使用所获取的物理地址来预测未来路线的移动设备的实例,该路线通过车辆显示器呈现给用户。
图26示出了滚动通过基于所获取的数据所生成的多条预测路线的实例。
图27示出了在移动设备沿特定路径行驶时设备自动滚动通过多条预测路线的实例。
图28示出了基于在另一个设备上所获取的地址来进行其预测的移动设备的实例。
图29-31示出了一些实施例如何基于所获取的或机器生成的物理地址来呈现交通通知的若干个实例。
图32示出了在移动设备上使用一些实施例的语音识别功能来识别先前所获取的并存储在地址历史数据存储装置中的接收人电子邮件地址。
图33示出了在用户启用消息功能并将消息口述至接收人的几个阶段的车辆显示屏。
图34概念性地示出了一些实施例的用于将所获取的数据通过服务器基础结构从一个设备分发到另一个设备的多设备过程。
图35概念性地示出了执行此类获取和预测的一些实施例的设备架构的更详细的实例。
图36示出了通过服务器基础结构与一个或多个设备同步的设备的多个所获取的地址数据存储装置。
图37为本发明的一些实施例的移动计算设备的架构的实例。
图38概念性地示出了实现本发明的一些实施例所利用的电子系统的另一个实例。
图39示出了根据一些实施例的地图服务操作环境。
具体实施方式
在本发明的以下详细描述中,提出并描述了本发明的许多细节、实例和实施例。然而,对于本领域的技术人员来说将清楚和显而易见的是,本发明并不限于所述实施例,并且本发明可在没有使用所讨论的一些具体细节和实例的情况下被实施。
本发明的一些实施例提供了一种地址获取器,该地址获取器从在设备上执行的一个或多个应用程序中获取地址。一些实施例使用所获取的地址来促进在设备上执行的一个或多个应用程序的操作。另选地或结合地,一些实施例使用所获取的地址来促进在另一个设备上执行的一个或多个应用程序的操作,该另一个设备不同于用于获取地址的设备。
图1示出了本发明的一些实施例的设备的新型地址获取架构100。在该架构中,在设备上执行的多个应用程序为由该架构所捕获的所获取地址的来源和使用方。如图1所示,获取架构100包括地址获取器105、所获取的地址数据存储装置110、若干个预测引擎115和若干个应用程序120-138。
如下文进一步描述的,所获取的地址存储装置110对地址获取器105 从一些应用程序中所获取的地址进行存储。在不同实施例中,所获取的地址是不同的。对于图1所示的实施例中,所获取的地址包括用于电信消息的电信地址和物理世界中的位置的物理地址。
所获取的电信地址的实例包括(1)从电话呼叫和/或文本消息(例如,随 SMS或iMessage文本服务发送的文本消息等)中获取的电话号码,以及(2) 用于电子邮件消息或文本消息的电子邮件地址。另外,在一些实施例中,所获取的电信地址包括用于同时向若干个接收人发送电子邮件消息或文本消息的若干个电信地址(例如,若干个电子邮件地址或电话号码)。
所获取的物理地址的实例包括从电子邮件消息、文本消息、日历标注的事件、电子票务等获取的物理地址。在图1所示的实施例中,这些所获取的地址包括设备的用户在设备上执行的网络浏览器或地图应用程序中使用的物理地址。此类使用需要搜索地址、查看地址、使用地址来指定进行查看或导航的路线等。
应用程序120-134是所获取的地址数据存储装置110中的所获取的地址的贡献方和使用方,以及由预测引擎115所提供的预测的使用方。具体地,在图1中,应用程序包括电子邮件应用程序120、文本消息应用程序 122、日历应用程序124、记事本应用程序126、票务应用程序128、地图应用程序130、视频会议应用程序132、浏览器应用程序134、语音识别应用程序136和通知应用程序138。除了语音识别应用程序136和通知应用程序 138之外,图1所示的实施例中的其他应用程序也是所获取的地址数据存储装置110中的所获取的地址的贡献方。如下文进一步描述的,语音识别应用程序136仅为所获取的地址数据存储装置110中的所获取的数据的使用方,而通知应用程序138仅为预测引擎115生成所获取的数据的预测的使用方。
地址获取器105包括若干个地址获取引擎150。一组地址获取引擎150 获取并存储应用程序用于发送电信消息的电信地址。例如,每当应用程序中的一个应用程序(例如,电子邮件应用程序120、消息应用程序122、视频会议应用程序132、日历应用程序124)使用一个电子邮件地址或若干个电子邮件地址来发送电子邮件或邀请(例如,用于视频会议或日历标注的事件)时,应用程序将电子邮件地址或地址提供至获取引擎150中的一个获取引擎,该获取引擎转而将一个或多个所接收的地址存储在所获取的地址数据存储装置110中。类似地,每当应用程序中的一个应用程序(例如,消息应用程序122、视频会议应用程序132等)使用一个电话号码或若干个电话号码来发送文本消息或邀请(例如,用于视频会议)时,应用程序将一个或多个电话号码提供至获取引擎150,该获取引擎转而将一个或多个所接收的电话号码存储在所获取的地址数据存储装置110中。因此,为了存储电信地址,一个或多个获取引擎充当用于接收电子邮件地址和电话号码并将所接收的电子邮件地址和电话号码存储在所获取的地址数据存储装置110中的处理器。
另一组地址获取引擎150获取并存储来自以下来源的物理地址:(1)由电子邮件应用程序120发送和/或接收的电子邮件消息,(2)由文本应用程序 122发送和/或接收的文本消息,(3)由日历应用程序124日历标注的事件, (4)由票务应用程序128存储的电子票务,和(5)由记事本应用程序126所准备的记事本。获取引擎150还获取网络浏览器134或地图应用程序130搜索、查看和/或使用以计算路线的物理地址。
在一些实施例中,用于检测物理地址的获取引擎150使用识别文档中的格式化数据(例如,物理地址)的数据检测过程。一个此类过程为由Apple Inc.出售的设备的操作系统所使用的数据检测器服务。该数据检测器服务在美国专利5,946,647中有所描述。
在一些实施例中,每当应用程序接收到特定电子文档或事件(例如,电子邮件、文本消息、日历事件或记事本)时,应用程序将所接收的文档或事件提供给获取引擎150中的一个获取引擎。获取引擎150继而对所接收的文档或事件执行数据检测或使用设备的数据检测服务来执行数据检测,以确定其是否包含物理地址。如果其包含物理地址,则获取引擎150将有关所识别的物理地址的数据返回至应用程序,并且将所识别的物理地址的副本存储在所获取的地址数据存储装置110中。
另外,在应用程序创建特定电子文档或事件(例如,创建电子邮件、文本消息、日历事件或记事本)时,在一些实施例中,应用程序与获取引擎 150中的一个获取引擎进行交互以在电子文档或事件创建之后或在其创建时将其内容提供给该引擎。获取引擎150继而对所接收的内容执行数据检测或使用设备的数据检测服务来执行数据检测,以确定其是否包含物理地址。如果其包含,则获取引擎150将有关所识别的物理地址的数据返回至应用程序,并且将所识别的物理地址的副本存储在所获取的地址数据存储装置110中。
除了使用数据检测器之外,地址获取器105将其一个或多个地址获取引擎150用作用于解析由一个或多个应用程序所存储的物理地址的解析器。例如,在一些实施例中,获取引擎150可解析被指定为由日历应用程序进行日历标注的事件的位置(如果有的话),而另一获取引擎150可解析票务应用程序存储票务的事件的位置。这些引擎150将它们通过此类解析获得的任何物理地址存储在所获取的地址数据存储装置110中。
除了此类所解析的和所获取的物理地址,一些实施例的地址获取器 105还获取用户在网络浏览器134或地图应用程序130中进行搜索、查看和 /使用以计算路线的地址。在一些实施例中,浏览器134或地图应用程序 130使用应用程序数据存储装置(例如,数据库)来存储此类物理地址以便促进它们的一些操作,例如提供由应用程序搜索或查看的最近位置的列表。因此,在一些这样的实施例中,获取引擎150从浏览器134或地图应用程序130的应用程序数据存储装置检索物理地址,并且将所检索的地址存储在所获取的地址数据存储装置110中。
预测引擎115使用存储在所获取的地址数据存储装置110中的所获取的地址来制定用于不同应用程序的不同类型的预测。例如,在一些实施例中,在用户正在输入消息的接收人或接收人群组时,一个或多个预测引擎 115使用所获取的电信地址来预测并显示电信消息的候选接收人或候选接收人群组。
因此,每当用户正在键入将由电子邮件应用程序120、消息应用程序 122、视频会议应用程序132或日历应用程序124发送的电子邮件或邀请的电子邮件地址时,预测引擎115将尝试将用户的输入与所获取的地址数据存储装置110中的一个或多个电子邮件地址和/或地址组匹配,并且将其找到的任何匹配电子邮件地址或地址组呈现给用户。假设所呈现的候选中的一个所呈现的候选为用户想要输入的内容,则用户然后可选择候选电子邮件地址或地址组来加快输入一个或多个电子邮件地址。
类似地,每当用户正在键入将由消息应用程序122或视频会议应用程序132所发送的消息或邀请的电话号码时,预测引擎115将尝试将用户的输入与所获取的地址数据存储装置110中的一个或多个电话号码和/或电话号码组匹配,并且将其找到的任何匹配候选号码或号码组呈现给用户。在一些实施例中,在消息应用程序122将文本消息发送至电子邮件地址时,一个或多个匹配的候选电话号码组可包括电子邮件地址。假设所呈现的候选中的一个所呈现的候选为用户想要输入的内容,则用户可选择候选号码或号码组来加快输入一个或多个号码。
另外,在一些实施例中,一个或多个预测引擎115使用所获取的物理地址来制定有关设备用户的未来目的地的预测,然后基于这些预测来向用户提供信息。为了制定这些预测,一些实施例采用一个或多个机器学习引擎来生成附加物理地址以增加它们用于作为其预测基础的一组物理地址。
不同的实施例向用户提供不同的所制定的预测或相关的信息。如下文进一步描述的,此类所制定的预测或相关的信息的实例包括所预测的未来目的地、到所预测的未来目的地的预测路线、有关到所预测的未来目的地的所预测的路线的交通数据、针对日历标注的事件所计算的初始行驶时间、针对日历标注的事件的所调整的行驶时间、所预测的未来目的地在可能目的地或搜索查询的列表中优先于其他目的地的显示等等。在一些实施例中,预测引擎115制定所有这些预测实例。然而,普通技术人员将认识到,在其他实施例中,所获取的物理地址并不用于制定所有此类预测。此外,普通技术人员还将认识到,在其他实施例中,所获取的物理地址用于其他预测。
如图1所示,预测引擎115将其所制定的预测或相关联的信息提供至应用程序120-138。例如,在一些实施例中,预测引擎115将预测的未来目的地和/或到所预测未来目的地的预测路线提供至地图应用程序130。基于此类预测,地图应用程序130将到所预测的未来目的地的预测路线显示为可选导航选项,如于2013年11月15日提交并且题为“Warning forFrequently Traveled Trips Based on Traffic,”的美国非临时专利申请14/081,899和于2013年6月9日提交的美国临时专利申请61/832,928中所描述的,所述两个专利申请以引用方式并入本文。地图应用程序130还可使用所预测的未来目的地来生成并显示所预测的未来目的地在可能目的地或搜索查询的列表中的优先显示。另选地,地图应用程序130可从预测引擎115中获得所预测的未来目的地的该优先显示。
除了接收对所预测的未来目的地的所预测的路线之外,预测引擎115 还可提供沿呈现给用户的每条所预测的路线或沿用户所选择的所预测的路线的交通信息。为了识别此类交通,在一些实施例中,预测引擎115使用通过网络(例如,蜂窝网络或互联网)可通信地连接至设备的交通服务器。在一些实施例中,预测引擎115还使用外部服务器来识别各位置之间的路线,而在其他实施例中,该预测引擎使用在设备上执行的路由引擎来识别路线。
在一些实施例中,预测引擎115基于事件的位置和对到所预测的目的地的所预测的路线的选择来计算或调整到日历标注的事件的行驶时间。例如,用户约定下午1点在旧金山聚餐。上午11点,用户在圣何塞,并且地图绘制应用程序130将所预测的目的地和/或到所预测的目的地的所预测的路线的列表呈现给用户。用户从该列表中选择库比蒂诺作为导航目的地或者选取到库比蒂诺的所预测的导航路线。
基于该选择,地图应用程序130提供到库比蒂诺的导航指令,而预测引擎115计算从库比蒂诺到旧金山的行驶时间,并且指示日历应用程序124 将该行驶时间指定在那一天的日历标注的事件的列表中。用于指定日历标注的事件的行驶时间的若干方式在于2013年11月15日提交的并且名称为“Specifying Travel Times for Calendared Events”的美国非临时专利申请 14/081,945和于2013年6月8日提交的美国临时专利申请号61/832,848中有所描述,所述两个专利申请以引用方式并入本文。在一些实施例中,预测引擎115基于所预测的路线信息并基于随预测路线信息的交通信息来计算从库比蒂诺到旧金山的行驶时间。
如果已指定针对在旧金山的午餐约定的行驶时间,则预测引擎115确定该事件的行驶时间是否应基于多种因素诸如到库比蒂诺的所选择的路线、到库比蒂诺的所预测的路线和沿这些路线中的一个或多个路线的交通信息进行调整。在必须要调整行驶时间时,预测引擎115指示日历应用程序124调整事件时间。另外,在计算或调整行驶时间之前,在一些实施例中,预测引擎115首先确保有足够的时间从圣何塞行驶到库比蒂诺然后从库比蒂诺行驶到旧金山,并且仍满足在旧金山下午1点的事件时间。在没有足够时间的情况下,预测引擎115指示地图应用程序130、日历应用程序 124或通知管理器138向用户提供可能没有足够的时间在旧金山进行下午1 点的午餐的通知。
如图1所示,并非所有应用程序同时促进地址获取并使用根据地址获取所定制的预测。例如,一些实施例使用记事本应用程序126来获取地址,但不向该应用程序提供基于所获取的地址所定制的预测。另外,在一些实施例中,语音识别应用程序136并不促进地址获取,但其得益于该获取。具体地,在这些实施例中,所获取的电信地址可用于增强接收人数据存储装置(例如,数据库),该语音识别应用程序136响应于语音指令用于准备电信消息或发起电信会话(例如,电话呼叫或视频会议)。尽管并非所有应用程序有助于地址获取,但由于多个应用程序促进该数据存储,因此图1 的地址获取架构可快速构建所获取的地址数据存储装置110。该架构还稳固地增强许多这些应用程序的功能,因为其提供所获取的数据和可根据该数据所定制的预测的丰富集合。
为了对存储所获取的地址进行优先排序,并且为了保持该优先顺序,一些实施例采用排序引擎来计算所获取的地址的排序分值并采用衰减引擎来使所获取的地址的所计算的排序分值随时间衰减。图2示出了此类排序引擎和衰减引擎的实例。具体地,该图示出了设备的地址获取架构200。该架构包括若干地址获取引擎150、所获取的地址数据存储装置110和衰减引擎215。
架构200使用不同的地址获取引擎150来处理不同类型地址的获取。在该架构中,在一些实施例中,每个地址获取引擎150用于获取仅一种类型的地址(例如,电子邮件地址或电话号码),而在其他实施例中,一个地址获取引擎150可获取多于一种类型的地址(例如,电子邮件地址和电话号码)。在其他实施例的其他获取架构中,一个地址获取引擎150用于获取所有类型的地址(例如,所有电信地址和物理地址)。
如图2所示,地址获取引擎150包括地址处理器205和排序引擎210。一些实施例中,地址处理器205从一个来源接收内容以获取地址,或者在其他实施例中,地址处理器205从多个来源接收内容以获取地址。在一些实施例中,由地址处理器205所接收的一些或全部内容为需要存储在所获取的地址数据存储装置110中的所获取的地址。在这些实施例或其他实施例中,地址处理器205需要获取(例如,解析和分析)其接收以提取需要存储在所获取的地址数据存储装置110中的地址的一些或全部内容。例如,在电子邮件应用程序和消息应用程序使用邮件地址和电话号码发送消息时,地址处理器205从这些应用程序中接收此类电信地址。另选地,例如在准备或接收电子邮件和文本消息继而获取以从这些消息中提取物理地址时,该处理器205或另一个处理器从电子邮件应用程序和消息应用程序中接收此类消息。
对于每个所获取的地址,地址处理器205确定地址是否已存储在所获取的地址数据存储装置110中。如果该地址已存储在所获取的地址数据存储装置中,则地址处理器205可更新先前存储的记录以考虑重复获取该地址。否则,地址处理器205制定记录以用于将地址存储在所获取的地址数据存储装置110中。一些实施例针对不同类型的所获取的地址创建不同类型的记录,而其他实施例针对所有类型的所获取的地址创建相同类型的记录。下文进一步描述此类记录的实例。
在创建或更新用于所获取的地址数据存储装置110的地址记录中,地址处理器205使用排序引擎210来计算针对地址记录的新的或经更新的排序分值。在一些实施例中,特定类型的地址的排序分值仅为与已获取的地址的次数相关的计数,而另一类型的另一地址的排序分值基于一组因素。在其他实施例中,针对所有类型的地址的所有排序分值为与已获取的地址的次数相关的计数,而在其他实施例中,针对所有类型的地址的所有排序分值基于多种因素,这些因素可针对不同类型的地址相同或不同。
在不同实施例中,使用不同因素来计算排序分值。一个因素为向地址处理器205提供用于获取的内容的应用程序的身份。某些应用程序(例如,消息应用程序)比其他应用程序(例如,电子邮件应用程序)产生针对其所获取的地址的更高的排序分值。对于电信消息,一些实施例中的另一个因素为发送被获取的消息的人的身份。例如,从来自设备的通讯录或收藏夹的列表中的个人的电信消息中获取的地址比从来自非通讯录或收藏夹的列表中的个人的消息中获取的地址具有更高排名。一些实施例中的另一个因素为被获取的消息(例如,电子邮件)是否已被查看。如果该被获取的消息已被查看,则从该消息(该电子邮件)获取的地址将比从未被查看的消息(例如,另一电子邮件)获取的地址具有更高排名。
衰减引擎215连续地或周期性地评论所获取的地址数据存储装置110 中的一些或所有所获取的地址的排序分值。只要有必要,其降低所获取的地址数据存储装置110中的所获取的地址的排序分值。在一些实施例中,衰减引擎215在其评论一个或多个该地址的记录时降低所获取的地址的排序分值。
例如,在一些实施例中,衰减引擎215对一些或所有所获取的地址的排序分值应用线性衰减函数。在一些实施例中,衰减引擎215并不调整一些所获取的地址的排序分值。换句话讲,在一些实施例中,衰减引擎215 并不检查一些所获取的地址以调整它们的排序分值。例如,在一些实施例中,一些所获取的地址的排序分值仅为已被获取的地址的几倍。在一些这样的实施例中,衰减引擎215并不调整排序分值。
一些实施例使用在一个设备上所获取的地址来促进在另一个设备上执行的一个或多个应用程序的操作。为此,一些实施例在不同设备上创建重复分布式数据存储装置(例如,数据库)以存储在不同设备上获取的地址。
图3示出了可使用在一个设备上获取的地址来促进在另一个设备上执行的一个或多个应用程序的操作的获取架构300的实例。具体地,其示出通过云服务器基础结构315彼此相关联(例如,与同一账户相关联或向同一账户注册)的两个设备305和310,该云服务器基础结构在将从一个设备所获取的地址转发至其他设备之前暂时对其进行存储。设备305和310以及服务器基础结构315通过网络320(诸如互联网或其他网络)可通信地彼此耦接。
如上所述,设备305和310具有关联,该关联允许它们共享所获取的地址数据。在一些实施例中,由于两个设备与云服务器基础结构的一个账户(例如,Apple Inc.所提供的一个iCloud账户)相关联或与两个相关联账户相关联,因此该关联被创建。在一些实施例中,当该两个设备被指定为由一个用户共同拥有时,该关联被自动创建。
在一些实施例中,每个设备305或310可为许多不同类型设备中的一个设备,诸如台式计算机、膝上型计算机、智能电话、平板电脑或任何其他电子设备。在图3所示的实例中,每个设备采用地址获取架构325,该地址获取架构类似于图1的获取架构100,如下文进一步描述的。
因此,每个设备305或310从在设备上执行的多个应用程序120-134 中获取电信地址和物理地址。每当设备获取新地址时,其将该地址路由至云服务器基础结构315,该云服务器基础结构继而将新地址路由至其他相关联的设备。在图3所示的实例中,由设备305所获取的地址通过云服务器基础结构315路由至设备310。
为了检测新的所获取的地址并将这些地址路由至服务器基础结构 315,每个设备305或310具有网络同步器330。除了该同步器330之外,每个设备的地址获取基础结构也与图1的基础结构100相同。在一些实施例中,每个设备还具有类似于上文参考图2所述的排序引擎和衰减引擎。
每当将新地址添加到设备的地址存储装置110时,设备的网络同步器 330检测新的所获取的地址并通过设备的网络接口335将有关该新地址的信息转发至服务器基础结构315。另外,在一些实施例中,每当设备的地址获取引擎105获取先前获取的地址并更新先前所获取的地址的先前创建的记录时,网络同步器330检测对先前创建的记录的更新并将有关该更新的信息转发至服务器基础结构315。在设备的衰减引擎调整所获取的地址的排序分值时,一些实施例的网络同步器330将经更新的分值转发至服务器基础结构315以用于分发至其他设备。然而,在其他实施例中,此类经更新的排序分值不通过服务器基础结构315在设备之间转发,因为每个设备具有负责执行这些调整的其自身的衰减引擎。
在图3所示的实例中,所获取的地址从设备305到设备310的路由在六个阶段中示出。在第一阶段中,网络同步器330检测所获取的地址的添加,并将一个或多个分组发送至服务器基础结构315以转发包括所获取的地址记录的所有经同步的数据字段的数据元组。
在第二阶段中,服务器基础结构315的网络同步器350通过网络接口 345从设备305接收一个或多个分组。服务器基础结构315包括一个或多个服务器。在一些实施例中,该基础结构包括用于处理网络分组并将这些分组路由至应用服务器的一个或多个网络服务器。在一些实施例中,网络接口345包括网络服务器,并且网络同步器350为负责管理在一组相关联设备之间分发所获取的地址数据(例如,新记录和记录更新)的应用服务器。在一些实施例中,设备305或310的网络同步器330和350和服务器基础结构使用Apple Inc.的普遍存在的键值存储机制来在一组相关联设备之间同步所获取的地址数据。下文进一步描述该键值存储机制。
如图3所示,服务器基础结构315的网络同步器350将任何新接收的所获取的地址数据存储在临时数据存储装置355中。其对该数据进行存储直到确定设备310可用于接收其从设备305所接收的所获取的地址数据。这样,云基础结构使两个设备305或310免于必须建立实时通信会话以将所获取的地址从一个设备下载到另一个设备。通过免除在两个设备之间建立实时通信会话的需要,基础结构简化了在不同设备上创建重复分布式数据存储装置(例如,数据库)以存储在不同设备上所获取的地址的过程。
一旦网络同步器350确定设备310能够用于接收所获取的地址数据,则该网络同步器(1)在第四阶段中,从临时存储装置355检索该数据(5)并且在第五阶段中,发送一个或多个分组以将包括所接收的获取的地址数据的所有经同步的字段的数据元组转发至设备310。在第六阶段中,设备310的网络同步器335接收一个或多个分组并将数据元组存储在所获取的地址数据存储装置110中。
通过这样分发所获取的地址数据,图3的获取架构300在不同设备上创建重复分布式数据存储装置(例如,数据库)以将所获取的地址存储在不同设备上。与从每个设备上的多个应用程序获取地址数据相结合,该稳固分布式数据存储装置在多个设备上进行同步,使得一些实施例的地址获取架构很强大,因为其能够快速建立驻留在多个设备上并且能够增强每个设备上的多个应用程序的操作的许多地址存储装置。
尽管参考图1-3的上述架构从各种不同应用程序中获取各种不同地址(例如,不同类型的电信消息和物理地址),但普通技术人员将认识到一些实施例可能不从所有这些各种不同的应用程序中获取所有这些不同的地址。另外,一些实施例对其他类型的文档诸如文字处理文档等执行其地址获取。
I.电信消息
A.获取电信地址
如上所述,一些实施例的地址获取器获取并存储用于发送电信消息(诸如电子邮件和文本消息)的电信地址(例如,电子邮件地址和电话号码)。此类地址的实例包括用于发送个人电子邮件消息、群组电子邮件消息、个人邀请(例如,对音频或视频会议或者日历标注的事件的邀请)和/或群组邀请的个人电子邮件地址或群组电子邮件地址。此类地址的其他实例包括用于发送个人文本消息、群组文本消息、个人邀请(例如,对视频会议的邀请)和/或群组邀请的个人电话号码和群组电话号码。
图4呈现了示出在设备400上获取的各种电信地址的实例。对于在该实例中示出的实施例,设备为智能电话,但在其他实施例中,其可为任何其他设备。该实例示出了捕获六个不同类型的电信地址并将所获取的地址存储在所获取的地址数据存储装置405中的六个不同的获取操作410-420。
在第一获取操作410中,设备400的地址获取器402接收用于电子邮件消息的针对Jerome Smith的单个电子邮件地址。该操作中的地址获取器 402将所接收的电子邮件地址存储在所获取的地址数据存储装置405中。在第二获取操作412中,地址获取器402接收用于另一个电子邮件消息的三个电子邮件地址(针对Jerome Smith、Paul Li和Emma Smith)。针对Paul Li 和Emma Smith的电子邮件地址是新的并被存储为新的电子邮件地址。然而,针对Jerome的电子邮件地址先前在第一获取操作410中被捕获。因此,无需再次对其进行单独存储,因为其已存储在所获取的地址数据存储装置405中。
然而,所获取的地址数据存储装置405尚未创建针对涉及Jerome、 Paul和Emma的电子邮件地址的群组的群组电子邮件关联。因此,即使先前存储了Jerome的电子邮件,但是地址获取器402创建关联并将其存储在所获取的地址数据存储装置405中以将针对Jerome、Paul和Emma的电子邮件识别为相关联的电子邮件群组。不同的实施例在所获取的地址数据存储装置405中不同地指定群组。另外,不同的实施例在不同时间指定若干个电子邮件之间的群组关联(例如,一些实施例在一组电子邮件第一次用于电信消息时创建群组,而其他实施例在第n次(例如,第2次)检测到该组电子邮件时创建群组)。下文进一步描述相关联的电子邮件群组的创建。
在第三获取操作414中,地址获取器402接收用于文本消息的单个电话号码(555-123-4567)。该操作中的地址获取器402将所接收的电话号码存储在所获取的地址数据存储装置405中。在第四获取操作416中,地址获取器402接收用于另一个文本消息的三个电话号码。两个电话号码(555-987- 6543和555-321-5678)为新的并且被存储为新的电话号码。然而,一个电话号码(555-123-4567)之前在第三获取操作414中被捕获。因此,无需再次对其进行单独存储,因为其已存储在所获取的地址数据存储装置405中。
然而,所获取的地址数据存储装置405尚未创建针对涉及在第四获取会话中捕获的三个号码的群组的群组号码关联。因此,即使先前存储了一个号码,但是地址获取器402创建关联并将其存储在所获取的地址数据存储装置405中以将在第四阶段中捕获的三个电话号码识别为相关联的号码的群组。不同的实施例在地址存储装置405中有不同地指定群组并且基于不同的标准来识别群组。下文进一步描述相关联的电话号码的群组的创建。
在第五获取操作418中,地址获取器402接收用于向三个个体发送视频会议邀请的两个电话号码和一个电子邮件地址。电话号码(555-987-6543 和555-321-5678)和电子邮件地址(Jerome Smith)均先前分别在第四获取操作 416和第一获取操作410中被获取并存储在所获取的地址数据存储装置405 中。然而,所获取的地址数据存储装置405尚未创建针对涉及该两个电话号码和电子邮件地址的群组的群组关联。因此,地址获取器402创建关联并将其存储在所获取的地址数据存储装置405中以将两个电话号码和电子邮件地址识别为相关联电子邮件地址和号码的群组。
最后,在第六获取操作420中,地址获取器402捕获用于向另一个人发送日历事件邀请的新的电子邮件地址。具体地,地址获取器402提取电子邮件地址及其相关联的数据(例如,与电子邮件地址相关联的姓名(如果有的话))并且将它们存储在所获取的地址数据存储装置405中。如下文将在下一实例中描述的,地址可与其他信息存储在一起,该其他信息诸如对用于地址群组的其他相关联的地址的排序、引用等。
图5示出了用于获取电信地址并将这些地址存储在三个地址存储装置中的架构500。在该架构中,电信地址获取器502将所接收的个人电信地址或群组电信地址存储在三个地址存储装置中,该三个地址存储装置分别为个人电子邮件地址存储装置505、个人电话号码存储装置510和群组地址存储装置515。获取引擎502包括(1)用于处理来自应用程序550的地址的地址处理器530和(2)用于计算地址的排序分值的排序引擎535。
将参考图6和图7来描述获取引擎502的操作,图6和图7示出了在一些实施例中地址获取器结合数据存储装置505,510和515的一组一个或多个查询引擎540(下文称为查询引擎)执行的两个过程600和700。
获取引擎502执行其接收的每个电信地址的过程600。当地址处理器530从应用程序550接收电信地址时,过程600开始(在605处)。在一些实施例中,每当应用程序550发送电子邮件消息或文本消息时,其将所使用的每个电子邮件地址或电话号码提供至地址处理器530。在将电子邮件或文本消息发送至多个接收人时,地址处理器530成批地或相继地接收多个此类电子邮件地址或电话号码,并且针对每个个人地址执行一次过程600。
地址处理器530继而使用(在610处)查询引擎540来确定所接收地址是否存储在个人存储装置505或510中。如果所接收的地址未存储在个人存储装置505或510中,则其指示(在615处)查询引擎540在电子邮件地址数据存储装置505中(当地址为电子邮件地址时)或在电话号码数据存储装置510中(当地址为电话号码时)创建针对所接收的地址的新记录。
在615处,一些实施例中的地址处理器530使用排序引擎535来计算地址的排序分值。如下文进一步所述的,在之后使这些地址与用户输入匹配以向用户提供用于完成消息的接收人列表的建议时,使用个人地址记录和群组地址记录的排序分值来创建优先排序的地址列表以用于显示。
不同的实施例使用不同的技术来创建排序分值。例如,一些实施例以地址组的使用频率作为排序分值的基础。其他实施例实时地评估时间阵列中的值以确定用于确定地址记录在优先排序列表中的顺序的值,而不是使用排序分值。在615之后,过程600结束。
图5示出了电子邮件地址存储装置505中的记录504的一个实例。如该实例所示的,该记录504包含用于识别记录的地址ID 570、用于识别接收人的姓名(如果有的话)的名称572、电子邮件地址574、时间阵列 576、排序分值578和群组阵列580。针对最多至N个最近先前实例的最多至N个(例如,最多至五个)时间值,在该实例中时间阵列576包括电子邮件地址用于发送电子邮件消息。群组阵列580包括每个群组的群组ID,其中电子邮件地址为用于向个人的群组发送电子邮件或文本消息的若干个电子邮件地址和/或电话号码的一部分。在一些实施例中,电话号码的记录在电话号码存储装置510中的记录包含与电子邮件地址记录568相同的字段,而在其他实施例中,电话号码记录略有不同(例如,不具有名称字段572)。
当查询引擎540确定(在610处)个人地址存储装置505或510中的一个个人地址存储装置已包含所接收地址的记录时,地址处理器530(在612处) 指示查询引擎更新其数据存储装置中的先前创建的地址记录以便反映其已再次被接收到。在一些实施例中,该更新涉及更新地址记录的时间阵列以反映当前接收个人地址的时间。另外,对于该更新,一些实施例中的地址处理器530(1)基于对该地址的重复接收使用一些实施例中的排序引擎535来计算新的排序分值,并且(2)指示查询引擎540使用该新的分值来更新该地址在先前指定的记录中的排序分值。在612之后,过程600结束。
地址处理器530执行图7的过程700以维护群组地址数据存储装置 515。对于其接收的每个地址,地址处理器530执行该过程,但在一些实施例中,其针对群组中的所有地址同时执行过程700。首先,地址处理器530 确定(在705处)所接收的地址是否为在电子邮件或文字信息中发送的一组地址的一部分。在一些实施例中,地址处理器530仅确定其是否从应用程序接收到连同当前地址一起的随该地址发送的其他地址。在一些实施例中,地址处理器530通过检查当前地址于其中发送的批处理文件来进行此过程。在其他实施例中,该过程通过将在应用程序用于调用处理器的消息中的所接收的地址的时间戳或者通过将在地址存储装置中的所接收的地址的新近更新的记录的最近时间戳与其他新近所接收的地址或新近更新的地址记录的时间戳进行比较来进行确定。当两个或更多个地址具有相同时间戳或非常接近的时间戳时,地址处理器530识别出这些地址为一个群组消息的一部分。
当地址处理器530确定(在705处)地址并非群组消息的一部分时,其结束。否则,其使用(在710处)查询引擎540来确定先前是否接收到针对另一消息的群组。对于该项任务,查询引擎540确定在705处所识别的群组中的所有地址的所有群组ID的交集是空集还是具有一个群组ID的集合。当交集为空集时,查询引擎确定先前未指定群组。否则,当交集为单一群组 ID时,则查询引擎确定先前已指定该群组。
当群组先前不存在时,地址处理器530指示(在720处)查询引擎540在群组地址数据存储装置515中创建针对群组的新的记录,然后结束。群组记录的一个实例在图5中示出。如该图所示,群组的记录590包括用于识别群组的群组ID 592、用于识别群组中的每个地址的地址ID的地址阵列 594(其中地址ID指定个人地址存储装置505和510中的地址的记录)、用于指定针对接收群组的最多至M个最近时间实例的最多至M个时间值的时间阵列594,和针对群组的排序分值596。
在创建该群组中,一些实施例中的地址处理器530使用排序引擎535 来计算群组的排序分值。不同的实施例使用不同的技术来创建排序分值。例如,一些实施例以地址组的使用频率作为排序分值的基础。如下文进一步所述的,在之后使这些地址匹配于用户输入以向用户提供用于完成消息的接收人列表的建议时,使用个人地址记录和群组地址记录的排序分值来创建优先排序的地址列表以用于显示。其他实施例实时评估时间阵列596 中的值以确定用于确定地址记录在优先排序列表中的顺序的值,而不是使用排序分值。另外其他实施例计算仅针对个人地址的实时值,并且当它们的个人地址在列表上向上移动时,使列表上的群组地址在优先排序列表中向前移动;为了针对相同个人地址在不同群组地址之间优先排序,一些实施例使用群组的最近时间值。
当过程700确定(在710处)在群组地址数据存储装置515中已存在该群组时,过程700指示(在715处)查询引擎540更新该群组记录以指示已再次接收到该群组。在一些实施例中,该更新涉及更新群组的时间阵列以反映当前接收群组消息的时间。另外,在一些实施例中,该更新涉及更新群组的排序分值。为了更新该分值,在一些实施例中,地址处理器530使用排序引擎535。在715之后,过程700结束。
B.使用所获取的电信地址
图8-图11提供了所获取的地址如何可用于提供电信消息的预测接收人的四个实例。在这些实例中的每个实例中,在一个设备上获取地址并且通过服务器基础结构将其转发至另一个设备。另外,这些实例中的每个实例示出使用所获取的电信地址来对获取地址的设备提供建议并对通过服务器基础结构接收所获取的地址的另一个设备提供建议。在这些实例中,所获取的地址为在图4中所示的实例中所捕获的地址。
图8-图11示出地址获取器402,其在设备400上捕获若干个电信地址 (若干个电子邮件、若干个电话号码、电子邮件群组和电话号码群组)并且在时间A之前将所捕获的电信地址存储在所获取的地址数据存储装置405 中。另外,这些附图中的每个附图示出具有匹配引擎805和输入处理器810 的设备400。
输入处理器810接收用户的电信地址输入,并将该输入转发至匹配引擎805。用户输入可通过独立键盘或屏幕式键盘、通过语音识别界面或通过其他输入界面来接收。在一些实施例中,匹配引擎805为数据存储装置的查询引擎的一部分,并且输入处理器810为接收用户输入并使用匹配引擎 805来制定与用户输入相匹配的所存储的电信地址的列表以呈现给用户的预测引擎。在一些实施例中,输入处理器810、匹配引擎805(在一些实施例中,其为数据存储装置的查询引擎)和/或数据存储装置405为用于获取并存储地址的一个地址获取模块的一部分,并且在用户准备电信消息的接收人列表时,其用于使所存储的地址与用户输入相匹配。然而,这些模块在图 8-图11(以及类似图12的其他附图)中单独示出以强调它们的单独功能。
即使在用户输入不完整的情况下,输入处理器810也转发用户输入。例如,在图8-图11所示的实例中,用户已输入电子邮件地址的一部分(例如,字母J)或号码的一部分(例如,55)。输入处理器810将该输入转发至匹配引擎805。继而,匹配引擎805尝试找到与由输入处理器所转发的输入的一部分相匹配的一个或多个个人电信地址或一个或多个群组电信地址。如下文进一步描述的,利用用户在其指定电子邮件或文本消息的一个或多个接收人时提供的每个附加字符或地址,该匹配变得越来越精确,因为随着输入处理器810得到更多用户输入,所以其将该输入转发至匹配引擎805。
在图8-图11所示的实例中,从设备400接收所获取的地址的每个设备 850,950,1050或1150也具有匹配引擎825和输入处理器820,其执行类似于匹配引擎805和输入处理器810的操作。这些其他设备850,950,1050和 1150中的每个设备具有通过服务器基础结构从地址存储装置405接收并存储所获取的地址的地址存储装置855,955,1055或1155。具体地,在这些实例中,设备850,950,1050和1150从地址存储装置405接收所获取的电信地址并在时间B之前将这些地址存储在它们的地址存储装置855,955,1055和 1155中。
在图8所示的实例中,设备400的用户在时间A之后的某个时间输入“J”作为电子邮件消息的接收人。响应于该输入,输入处理器810将“J”转发至匹配引擎805,该匹配引擎继而使其匹配于Jerome Smith的个人电子邮件以及电子邮件群组Jerome Smith、Paul Li和Emma Smith。因此,匹配引擎805指示输入处理器810将两个可选择的候选接收人组同时呈现给用户。一个接收人组仅包括Jerome Smith的电子邮件,而另一个接收人组包括JeromeSmith、Paul Li和Emma Smith的电子邮件。
在时间B之后的某个时间处,图8中的计算机850的用户类似地输入“J”作为电子邮件消息的接收人。响应于该输入,输入处理器820将“J”转发至匹配引擎825,该匹配引擎继而使其匹配于Jerome Smith的个人电子邮件以及电子邮件群组Jerome Smith、Paul Li和Emma Smith。因此,匹配引擎825指示输入处理器820同时呈现两个可选择的候选接收人组,一个接收人组仅包括Jerome Smith的电子邮件,并且另一个接收人组包括 Jerome Smith、Paul Li和Emma Smith的电子邮件。
在图9所示的实例中,设备400的用户在时间A之后的某个时间输入“55”作为文本消息的接收人。响应于该输入,输入处理器810将“55”转发至匹配引擎805,该匹配引擎继而使其匹配于个人电话号码555-123- 4567以及包括该号码连同555-987-6543和555-321-5678的电话号码群组。因此,匹配引擎805指示输入处理器810将两个可选择的候选接收人组同时呈现给用户。一个接收人组仅包括555-123-4567,而另一接收人组包括 555-123-4567、555-987-6543和555-321-5678。
在时间B之后的某个时间,图9中的计算机950的用户类似地输入“55”作为文本消息的接收人。响应于该输入,输入处理器820将“55”转发至匹配引擎825,该匹配引擎继而使其匹配于个人电话号码555-123- 4567以及包括该号码连同555-987-6543和555-321-5678的电话号码群组。因此,匹配引擎825指示输入处理器820同时呈现两个可选择的候选接收人组,一个接收人组仅包括555-123-4567,并且另一个接收人组包括555- 123-4567、555-987-6543和555-321-5678。
在图10所示的实例中,设备400的用户在时间A之后的某个时间输入“J”作为日历邀请的接收人。响应于该输入,输入处理器810再次使用匹配引擎805来使用户输入匹配于两个不同的接收人组(一个接收人组仅包括 Jerome Smith的电子邮件,并且另一接收人组包括Jerome Smith、Paul Li和 Emma Smith的电子邮件),该输入处理器将该两个不同的接收人组作为两个可选择的候选接收人组同时呈现给用户。
在时间B之后的某个时间,图10中的计算机1050的用户类似地输入“J”作为另一个日历邀请的接收人。再次,响应于该输入,输入处理器 820使用匹配引擎825来使用户输入匹配于两个不同的接收人组(一个接收人组仅包括Jerome Smith的电子邮件,并且另一个接收人组包括Jerome Smith、Paul Li和Emma Smith的电子邮件),该输入处理器将该两个不同的接收人组作为两个可选择的候选接收人组同时呈现给用户。
在图11所示的实例中,设备400的用户在时间A之后的某个时间输入“555-9”作为文本消息的接收人。响应于该输入,输入处理器810将“555-9”转发至匹配引擎805,该匹配引擎继而使其匹配于个人电话号码 555-987-6543以及包括该号码连同555-321-5678和Jerome Smith的电子邮件的地址群组。因此,匹配引擎805指示输入处理器810将两个可选择的候选接收人组同时呈现给用户。一个接收人组仅包括555-987-6543,并且另一哥接收人组包括555-987-6543、555-321-5678以及Jerome Smith的电子邮件地址。
在时间B之后的某个时间,图11中发计算机1150的用户在视频会议的邀请列表中类似地输入“555-9”。响应于该输入,输入处理器820使用匹配引擎825来使该输入匹配于两个不同的被邀请者组(一个被邀请者组仅包括555-987-6543,并且另一个被邀请者组包括555-987-6543、555-321- 5678和Emma Smith的电子邮件),该输入处理器将该两个不同的被邀请者组作为两个可选择的候选被邀请者组同时呈现给用户。
在上述实例中,在地址匹配期间,从一个应用程序使用的地址中获取的个人电信地址或群组电信地址在另一应用程序中可用。另外,一组电信地址可包括电话号码和电子邮件地址两者。然而,其他实施例可不创建包括电话号码和电子邮件地址的群组。另外,其他实施例可限制将匹配候选电信地址呈现给进行匹配的应用程序或将该应用程序指定为在与匹配候选地址从其中获取的应用程序相同的应用程序类别内。
图13概念性地示出了使用一些实施例的匹配引擎来使用户输入匹配于存储在地址存储装置中的电信地址的过程1300。如图12所示,一些实施例的设备的匹配引擎1200通过检查上文参考图5所述的三个地址存储装置 505,510和515来执行该过程。
如图13所示,该过程首先接收(在1305处)输入。在上述实例中,输入处理器将用户输入转发至匹配引擎1200。过程1300继而尝试(在1310处) 使该输入匹配于地址存储装置中的一个或多个记录。如上所述,匹配记录可以是个人电信地址或群组电信地址。
如果过程1300无法找到(在1310处)任何匹配记录,则其结束。否则,其聚集(在1315处)任何匹配个人电信地址或群组电信地址。然后其指示(在1320处)输入处理器将聚集的一组匹配电信地址呈现给提供输入的应用程序,使得应用程序可将该组电信地址呈现给用户。如上所述,一些实施例将该组匹配电信地址呈现给用户,其中每个匹配电信地址作为列表中的可选择选项。另外,一些实施例基于特定排序顺序来呈现该组中发匹配电信地址。下文将进一步描述用于根据排序顺序呈现匹配电信地址的几种方式。
在1325处,过程1300从输入处理器接收另一输入。其确定(在1330 处)该输入是否为对在1320处所提供的组中的匹配电信地址中的一个匹配电信地址的选择。如果是,则该过程结束。否则,该过程确定(在1335处)新的用户输入和旧的用户输入的组合是否指定仍匹配地址存储装置中的一个或多个记录的地址。如果不是,则该过程结束。否则,该过程对先前聚集的一组匹配电信地址进行滤除(在1340处)以仅保留与新地址或用户输入所指定的地址相匹配的一组电信地址。经滤除的一组匹配电信地址成为下一个聚集的一组匹配电信地址。该过程继而返回到1320,在此其指示输入处理器将该新聚集的一组匹配电信地址呈现给提供输入的应用程序,使得应用程序可将该一组电信地址呈现给用户。
本领域的技术人员将认识到,其他实施例不同地实施匹配过程1300。例如,过程1300维护当前聚集的一组匹配地址并且基于附加的用户输入对该一组地址进行滤除。然而,在其他实施例中,过程1300不对此类组进行维护并且无需确定(在1330处)用户是否选择了候选地址中的一个候选地址。相反,在这些实施例中的一些实施例中,该过程在1320之后终止,并且在每次用户输入新字符或新地址时从起点重新开始。在这些实施例中的一些实施例中,总体匹配过程维护在每次迭代中所检索的地址以移除不再适用的任何记录,因为其不再匹配当前的总体搜索查询。
C.排序呈现经检索的获取的电信地址
当用户输入电子邮件或文本消息的接收人的列表的一部分时,一些实施例的预测引擎(例如,图8-图11的输入处理器)识别与用户输入相匹配的所存储的个人电信地址和群组电信地址。然后其以排序顺序排列这些匹配地址并按照该顺序呈现这些地址,使得用户可选择它们中的一者来完成输入接收人列表。
如上所述,一些实施例计算针对个人电信地址和群组电信地址的排序分值并使用该排序分值来为用户创建匹配电信地址的排序顺序(例如,排序列表)。不同的实施例使用不同的技术来创建排序分值。例如,一些实施例以个人地址或群组地址的使用频率作为排序分值的基础。基于每个电信地址记录的时间戳,其他实施例作为该记录的排序分值的基础,该时间戳显示最近何时更新了该记录。另外其他实施例基于发送消息中的电信地址的使用频率以及指定最近电信地址的使用频率的其记录的时间戳来计算该电信地址记录的排序分值。在一些实施例中,排序引擎535周期性地检查电子邮件地址、电话号码和/或群组地址表格中的电信地址记录并更新每个记录的排序分值。
其他实施例实时评估地址记录的时间戳值以便确定优先排序列表中的地址记录的顺序,而不是使用排序分值。另外其他实施例计算仅针对个人地址的实时值,并且当它们的个人地址在列表上向上移动时,使列表上的群组地址在优先排序的列表中向上移动;为了针对相同个人地址在不同群组地址之间优先排序,一些实施例使用群组的最近时间值。
更具体地,对于个人电信地址,一些实施例使用这些时间戳来作出有关排序顺序的决策,而其他实施例使用时间戳来计算它们接下来用于确定顺序的实时分值。在一些实施例中,时间戳不仅用于量化个人地址的使用频率,而且还用于量化使用地址的时间上的接近程度。这两个因素的组合在下文的论述中被称为Frecency。对于所检索的电信地址记录,一些实施例使用两个因素来计算Frecency分值,该Frecency分值继而用于将地址记录进行排序以用于显示。然而,其他实施例使用这两个因素(即,使用地址记录的Frecency)来作出有关排序顺序的决策。
例如,在一些实施例中,地址获取器存储针对每个个人电信地址的最多至5个时间戳,该最多至5个时间戳指示使用地址的时间方面的5个最近的实例。为了对所检索的电信地址进行排序,输入处理器首先呈现已被接收 5次的地址,然后呈现已被接收4次的地址,再呈现已被接收3次的地址,依此类推。在已被接收相同N次的每个群组内,输入处理器对最近已被接收(即,具有最新的时间戳)的地址在顺序上排序更高。仅针对(1)匹配地址群组,以及(2)准确匹配输入字符串的地址,这些实施例中的输入处理器违背这些排序规则。如上所述,一些实施例中的输入处理器按照排序顺序移动匹配地址群组以出现在靠近群组中的最高排列的个人地址的位置。
图14示出了上述方法和上述两个例外。具体地,在三个阶段 1405,1410和1415中,其示出了基于在用户键入接收人的电子邮件地址时的三个不同输入字符串按照排序顺序检索并呈现的三组记录。该图示出了输入处理器基于由接收用户输入的UI模块所提供的输入字符串来从匹配引擎接收每组记录。
第一阶段1405示出了匹配输入字符串“Li”的三个个人记录和两个群组记录。个人记录为John Lin、Jack Lindsey和Harry Lind的电子邮件地址,而群组记录为包括JohnLin和Chuck Flower的电子邮件地址的第一群组,以及包括Jack Lindsey和Alex Flower的电子邮件地址的第二群组。 John和Jack的电子邮件地址已被各自接收过五次,而Harry的电子邮件地址之前仅被接收过四次。另外,Jack的电子邮件地址具有最新时间戳。
因此,基于上述规则,Jack Lindsey的个人地址和群组地址首先被显示,之后是John Lin的个人地址和群组地址,然后再是Harry Lind的电子邮件地址。Harry在排序列表的底部,因为他使用电子邮件的频率(4次)不及John和Jack使用电子邮件的频率(5次)高。Jack的电子邮件地址在列表上排序更高,因为Jack的电子邮件地址具有最新时间戳。
第二阶段1410针对新的搜索字符串“Lin”示出了已检索到相同的三个个人记录和两个群组记录。然而,该阶段中的排序顺序已被修改以使 John的个人电子邮件地址和群组电子邮件地址比Jack的个人电子邮件地址和群组电子邮件地址排序更高,因为John的姓氏完美匹配当前输入字符串。该完美匹配胜过Jack的电子邮件地址的最近使用。
第三阶段1415示出了输入处理器接收新搜索字符串“Lind”的经修改的一组记录。该组记录不再包括John Lin的记录,因为Lin不再匹配输入字符串Lind。另外,第三阶段示出了排序顺序已被修改以使Harry的个人电子邮件地址比Jack的个人电子邮件地址排序更高,因为Harry的姓氏完美匹配当前输入字符串。该完美匹配胜过Jack的电子邮件地址的最近使用和Jack的电子邮件地址的较频繁使用。普通技术人员将认识到,其他实施例可将Jack的个人电子邮件地址和群组电子邮件地址比Harry的电子邮件地址以更高排序呈现在排序列表中,因为Jack的电子邮件地址更频繁使用。
II.物理地址
A.获取物理地址
如上所述,一些实施例的地址获取器获取并存储物理地址。此类所获取的地址的实例包括从电子邮件消息、文本消息、日历标注的事件、电子票务等获取的物理地址。另选地或结合地,这些所获取的地址包括设备的用户利用在设备上执行的网络浏览器或地图应用程序来浏览的物理地址。此类浏览需要搜索地址、查看地址和/或使用地址来指定进行查看或导航的路线。
图15和图16呈现了地址获取器105捕获电子邮件和文本消息中的物理地址的若干个实例。图15示出了智能电话1500的地址获取器105捕获其接收的电子邮件和文本消息中的若干个物理地址。尽管在图15中从所接收消息中获取地址,但普通技术人员将认识到,在一些实施例中,地址获取器105也获取发送消息中的物理地址。另外,尽管在该图中示出了智能电话,但在一些实施例中,计算机、平板电脑或任何其他电子设备的地址获取器105也执行相同的捕获操作。
图15示出了地址获取器105在三个不同阶段1502,1504和1506中对所接收的电子邮件1530和文本消息1532执行的三个获取操作1520,1522和 1524。其还示出了其不执行的一个获取操作1528。
第一阶段1502示出了地址获取器105对电子邮件1530的部分下载版本执行第一获取操作1520。为了节省带宽消耗,一些实施例的邮件应用程序并不全文下载电子邮件,直到电子邮件被选择以用于评论。相反,邮件应用程序下载电子邮件的一部分以提供对电子邮件内容的充分预览。
图15示出了在已选择电子邮件以用于评论之前所下载的电子邮件的一部分1540。具体地,该部分1540包括一些电子邮件标题信息和电子邮件主体的一部分。该图还示出了在选择电子邮件以用于评论之前未下载的该电子邮件的一部分1542(例如,主体的剩余部分)。如该图所示的,这两部分均包含该实例中的物理地址。如进一步所描述的,地址获取器105捕获已下载部分1540中的地址1550并将该物理地址存储在地址存储装置110 中。表示获取器的第一获取操作的箭头1520以图形方式示出了该捕获。如通过划掉箭头1528所示出的,获取器不捕获和存储物理地址1552,因为该地址在电子邮件的邮件应用程序未下载的部分中。
第二阶段1504示出了对电子邮件1530的选择及其后续下载以用于显示在设备1500上。该电子邮件一旦被下载,地址获取器105便捕获第二获取操作1522中的物理地址1552并将该地址存储在地址存储装置110中。第三阶段1506示出了地址获取器105执行第三获取操作1524。在该操作中,获取器捕获文本消息1532中的物理地址1554并将该地址存储在地址存储装置110中。
图16示出了计算机1600的地址获取器105捕获其接收的电子邮件和文本消息中的物理地址。尽管在该图中从所接收的消息中获取地址,但普通技术人员将认识到,在一些实施例中,地址获取器105也获取发送消息中的物理地址。
图16示出了地址获取器105在两个不同阶段1602和1604中对所接收的电子邮件1630和文本消息1632执行的三个获取操作1620,1622和 1624。第一阶段1602类似于图15的第三阶段1506,因为在该阶段1602期间,获取器捕获文本消息中的物理地址1660并将该地址存储在所获取的地址数据存储装置110中。
另一方面,在一些实施例中,第二阶段1604示出了获取计算机上的电子邮件和获取移动设备上的电子邮件之间的差异。具体地,与移动设备 1500的不下载和搜索未读邮件来获取物理地址的获取器105不同,计算机 1600的获取器105下载并搜索未读邮件以捕获电子邮件中所提到的任何物理地址。因此,第二阶段1604示出了获取器105在未读电子邮件1630上执行以捕获两个物理地址1662和1664并将这些地址存储在地址存储装置 110中的两个获取操作1622和1624。在一些实施例中,获取器105不评论所有电子邮件,而仅评论某些电子邮件。例如,一些实施例的获取器105 不评论标记为垃圾邮件(例如,在垃圾邮件文件夹中)的任何电子邮件,而仅评论其他电子邮件(例如,在收件箱文件夹中、在发件箱文件夹中等)。
如下文进一步描述的,一些实施例生成排序分值并使该排序分值与每个所获取的物理地址相关联,以便区分可为多个的所获取的物理地址。此类排序基于多种标准。在一些实施例中,这些标准包括作为地址的来源的消息的类型、文本消息或电子邮件的发送方的身份、与地址的用户交互等。下文将进一步描述这些标准。
此类标准一方面有助于将从电子邮件中获取的物理地址与随机个体区分开来,并且另一方面将从电子邮件中获取的物理地址与好友区分开来。这些标准也将用户查看的物理地址与用户未查看的物理地址区分开来。图 17呈现了进一步解释此类标准的实例。具体地,其示出了基于在地图中查看该地址来调节所获取的物理地址的排序。
图17中所示的实例在四个阶段1702,1704,1706和1708中示出。第一阶段1702示出了邮件应用程序1700的收件箱中的电子邮件1630连同若干个其他电子邮件。如符号1710所指示的,电子邮件1630尚未读取。另外,如星标符号1712所指示的,该电子邮件来自在由邮件应用程序所识别的个人列表中的一个人。在一些实施例中,所识别的个人的列表包括应用程序的用户将其指定为非常重要的人(VIP)或最喜爱的人的一个人。代替这些人或除这些人之外,所识别的个人的列表包括通讯录、联系人列表或计算机的其他电子名片簿中的人。
第一阶段1702示出了地址存储装置110包括物理地址1662,如在图 16中所述的,该物理地址即使在读取电子邮件1630之前也被获取。由于该电子邮件来自所识别的列表上的人,因此其以较高排名排列在地址存储装置110中。为了说明性目的,每个物理地址的排序通过其在表格1740上的位置概念性地示出。表格中的最上面一行表示最高排名。
第二阶段1704示出了已打开以用于读取之后的电子邮件1630。该阶段还示出了利用位置指示符1720来选择物理地址1662。在该实例中,位置指示符为由光标控制器控制的光标,但在其他实施例中,其可为任何位置指示符。例如,其可为设备1700的触敏屏的可见或不可见触摸指示符。
第三阶段1706示出了选择物理地址使得显示上下文菜单1722。该菜单具有若干个选项,该若干个选项中一个选项被提供用于在地图中查看物理地址。第三阶段1706示出了在菜单中选择查看地图选项1724。
第四阶段1708示出了选择查看地图选项1724,从而产生地图1726在上下文菜单1722中的缩略图显示。所显示的地图通过利用标针1728标记位置来示出物理地址的位置。第四阶段还示出了在地图中查看物理地址,使得所获取的物理地址在地址存储装置110中排名较高。该较高排名在第四阶段中概念性地示出,其中针对地址1662的记录移动至表格1740上的较高位置。在一些实施例中,可选择缩略图地图1726。该选择使得浏览器或地图绘制应用程序显示更大版本的地图。在一些实施例中,选择缩略图地图和查看更大地图进一步提高所获取的物理地址1662的排序分值。下文将提供查看地图绘制应用程序中的更大版本的地图的实例。
查看电子邮件中的物理地址并非用于获取物理地址并以某个排序分值将其添加至地址存储装置中的唯一机制,该排序分值指示与其进行的特定用户交互。可通过将物理地址发布至地图应用程序或通过在地图应用程序中查看、搜索、或路由至此类地址来创建此类地址记录。
图18示出了将物理地址发布至地图应用程序以及在该过程中获取该物理地址以存储在地址存储装置110中的实例。该实例示出了通过在移动设备1800上执行的网络浏览器中进行选择,来将地址发布至地图应用程序的书签或最近记录表格1808。书签表格为包含在地图上由应用程序或用户加书签的多个位置的表格。最近记录表格为包含由地图应用程序搜索的最近位置或路线的表格。
图18示出了其在与浏览器1810进行交互的三个阶段1802,1804和 1806中的实例。第一阶段1802呈现了浏览器显示Tee-Cake面包店的网站的第一网页1810。该阶段还示出通过设备1800的触敏屏对该网页上的联系人选项的用户触摸选择。
该选择使得浏览器示出第二网页1812,如第二阶段1804中所示的。第二网页1812示出有关面包店的联系人信息。如第二阶段1804中所示的,用户触摸选择面包店的地址1816。该选择使得浏览器显示包括添加至地图选项1832的上下文菜单1830。
第三阶段1806示出了对添加至地图选项1832的用户触摸选择。其还示出了该选择使得面包店的地址被存储在地图应用程序的表格1808中。在一些实施例中,浏览器指示地图应用程序将该地址存储在其表格1808中,而在其他实施例中,其直接将该地址存储在该表格中。在一些实施例中,表格1808为地图应用程序的书签表格,而在其他实施例中,其为地图应用程序的最近记录表格。
除了使得面包店地址被存储在表格1808中之外,第三阶段1806还示出了对添加至地图应用程序选项1832的选择还使得地址被获取并添加至所获取的地址数据存储装置110中。该地址以较高排名添加至数据存储装置 110中,因为用户作出将其添加至地图应用程序的书签或最近记录表格 1808的有意识的选择。
在一些实施例中,当浏览器被指示将该地址发送至地图应用程序时,浏览器也将该地址发送至设备的地址获取器,该地址获取器继而将该地址存储在数据存储装置110中。在其他实施例中,地址仅存储在表格1808中,但表格1808为共同形成所获取的地址数据存储装置的一组存储装置(例如,表格、数据库等)的一部分,设备的一组预测引擎使用该所获取的地址数据存储装置来检索用于制定预测的地址。在其他实施例中,首先将地址存储在表格1808中,然后将其从该存储装置传送至地址存储装置110中。
图19示出了响应于用户在移动设备1900上执行的地图应用程序中搜索地址来获取物理地址的实例。该实例在与地图应用程序1910进行交互的三个阶段1902,1904和1906中示出。这些阶段中的每个阶段还示出了地图应用程序的最近记录表格1908的状态。
第一阶段1902示出了通过设备1900的触敏屏对地图应用程序1910的搜索字段1912的用户触摸选择。为了简化论述,第一阶段1905示出了最近记录表格1908仅存储两个地址。即,最近已使用地图来仅搜索这两个地址。这里,用户选择搜索字段1912来输入搜索地址。
第二阶段1904示出了利用地址“山麓小丘路1149号”来填充的搜索字段1912。其还示出了用户选择搜索选项1916以指示地图应用程序搜索输入地址。第二阶段1904进一步示出了最近记录表格1908仍仅包含与在第一阶段所包含的地址相同的两个地址。
第三阶段1906示出了在显示搜索地址山麓小丘路1149号之后的地图应用程序。该阶段还示出了该搜索使得向地图应用程序的最近记录表格 1908添加该地址。在一些实施例中,该表格为共同形成所获取的地址数据存储装置的一组存储装置(例如,表格、数据库等)或数据库的一部分。在一些实施例中,设备1900的一组预测引擎从该组存储装置中检索所获取的地址数据以便制定预测。然而,其他实施例将最近记录表格1908中的地址复制到由一个或多个预测引擎所访问的所获取的地址存储装置中,而不是使一个或多个预测引擎使用最近记录表格1908。类似于前述实例,地址可以较高排名添加至地址存储装置中,因为用户作出利用地图应用程序对其进行搜索的有意识的选择。
图20示出了响应于用户利用移动设备1900的地图应用程序1900识别路线以获取物理地址的实例。该实例在与地图应用程序1910进行交互的三个阶段2002,2004和2006中示出。这些阶段中的每个阶段示出了地图应用程序的最近记录表格1908的状态。
第一阶段2002示出了通过设备1900的触敏屏对地图应用程序1910的方向工具1942的用户触摸选择。类似于前述实例,第一阶段示出了最近记录表格1908仅存储两个地址。为了输入路线,用户选择紧挨搜索字段1912 的路线按钮1942。
第二阶段2004示出了地图应用程序的页面2050。该页面包含两个字段2052和2054,在该两个字段中可指定路线的起点和终点。其还允许对交通模式进行选择。交通模式包括步行、乘公交车和乘汽车出行。第二阶段 2004示出了已将路线的起点和终点分别指定为设备的当前位置和州大街 777号。其还示出了用户选择路线选项2016来指示地图应用程序搜索所指定的路线。第二阶段2004进一步示出了最近记录表格1908仍仅包含与在第一阶段2002中所包含的地址相同的两个地址。
第三阶段2006示出了在显示所指定的起点和终点位置之间的三条路线之后的地图应用程序。具体地,三条路线由连接表示起点位置和终点位置的两个标针的线示出。该阶段2006还示出了已将目的地地址添加至地图应用程序的最近记录表格1908中。如上所述,在一些实施例中,该表格为共同形成所获取的地址存储装置的一组存储装置(例如,表格、数据库等) 的一部分,其中设备的一组预测引擎从该所获取的地址存储装置检索地址以制定预测。然而,其他实施例将最近记录表格1908中的地址复制到由一个或多个预测引擎所访问的获取地址存储装置中。
在前述实例中,地址从目的字段而非起点字段提取。本领域的普通技术人员将理解,也可以类似方式从起点字段中提取地址(例如,在用户已指定起点地址的情况下)。起点或终点地址也可以较高排名添加至地址存储装置中,因为用户作出利用地图应用程序进行地址搜索的有意识的选择。
图21示出了响应于对由移动设备1900的地图应用程序1900所呈现的地图上的兴趣点(POI)的选择来获取物理地址的实例。该实例在与地图应用程序1910进行交互的三个阶段2102,2104和2106中示出。这些阶段中的每个阶段还示出了地图应用程序的最近记录表格1908的状态。
第一阶段2102示出了已打开地图应用程序以显示地图2114。地图标注位置包括POI 2112。该POI以提供POI类型(例如,餐厅、酒吧)的视觉指示的图标被示出。如第一阶段2102所示的,由地图应用程序1910来呈现地图2114上的用户触摸选择POI 2112。第一阶段2102还示出了最近记录表格1908此刻仅存储地址。
第二阶段2104示出了横幅2116在所选择的POI上方打开以提供有关 POI的一些信息。横幅包括设施的名称和使用特定交通模式到达该设施的估计时间。横幅的右侧是信息箭头2128,可选择该信息箭头来显示有关 POI的附加信息。在该第二阶段2104中,用户选择信息箭头2128。第二阶段2104进一步示出了最近记录表格1908仍仅包含与在第一阶段2102中所包含的地址相同的两个地址。
第三阶段2106示出了地图应用程序呈现以提供有关所选择的POI的附加信息的信息页2130。该阶段2106还示出了选择信息箭头2128并呈现信息页2130使得POF地址添加至地图应用程序的最近记录表格1908中。如上所述,在一些实施例中,该表格为共同形成所获取的地址存储装置的一组存储装置(例如,表格、数据库等)的一部分,其中设备的一组预测引擎从该所获取的地址存储装置检索地址以制定预测。然而,在其他实施例中,最近记录表格1908中的地址被复制到由一个或多个预测引擎所访问的所获取的地址存储装置中。
在将新地址从最近记录表格复制到所获取的地址存储装置时(如上对于图19-21的一些实施例所描述的),一些实施例指定针对从最近记录表格复制到所获取的地址存储装置的新地址所指定的排序分值。另选地,在将地址从最近记录表格直接提供至设备的一组预测引擎的实施例中(如上对于图 19-21的其他实施例所描述的),该地址的来源(即,该因素是该地址来自地图应用程序的最近记录表格并由此最近可能被用户查看的因素)可作为基于这些地址制定预测的因素。例如,这些地址对预测的相对贡献可通过将其与来自其他来源的地址进行比较而适当权衡以进行调整。
图22示出了从日历应用程序2200获取物理地址的实例。如图所示,日历应用程序已被打开至日视图2205。另选地,日历应用程序可被打开至不同视图诸如周视图、月视图等。日视图2205包括在一列上列出时间并且在下一列列出预定事件列表的表格。为了简化描述,该视图仅列出一个预定的事件2210。具体地,其列出了预定在该日上午9点的在特定位置的牙医预约。位置以其物理地址在列表中示出。这里,地址获取器105已提取地址并将其存储在地址数据存储装置110中。在一些实施例中,一旦事件已通过日历应用程序进行预定,地址获取器105便获取地址,这是因为日历应用程序向其通知具有特定位置的事件已被创建。在其他实施例中,地址获取器105迭代通过日历应用程序的事件列表以识别不同预定事件中的地址。地址获取器105继而将每个新地址添加至所获取的地址数据存储装置110。
结合事件列表或代替该事件列表,一些实施例的地址获取器105从事件邀请中获取地址。图23示出了从日历邀请2300获取物理地址的实例。该邀请2300可已利用日历应用程序或邮件应用程序打开(例如,在日历作为邮件应用程序的一部分被集成的情况下)。
如图23所示,邀请以(1)事件的名称,(2)事件的位置,(3)事件的开始时间,以及(4)结束时间来显示。事件包括若干个选项,包括显示位置的地图、设定闹钟、接受邀请、拒绝邀请等。每个开始时间和结束时间以日期和时间来显示。事件的位置以其在邀请主体中的物理地址来显示。在该实例中,地址获取器105已从邀请中提取物理地址并将该地址存储在所获取的地址数据存储装置110中。例如,地址获取器105可对邀请进行分析或解析来识别位置字段以提取物理地址。
在前述两个实例中,每个日历标注的事件与时间和/或日期相关联。在事件接近时,一些实施例将从日历应用程序中的事件预约或从事件邀请中获取的物理地址的排序分值提高。排序分值的这种提高将使物理地址更有可能向用户提供有用预测,例如用于提供预测路线、提供相关交通信息、提供优先排序的地址列表等。一旦事件过去,一些实施例降低此类物理地址的排序分值或将其从地址存储装置中完全地移除。
B.计算排序分值并衰减地址的排序分值
如上所指出的,一些实施例将排序分值与获取地址一起存储。对于各种操作,这些排序分值可用于确定用户最有可能想要哪些地址(例如,用户将最有可能前往哪些地址)。一些实施例使用衰减函数来随时间修改这些排序。一些实施例的衰减函数首先随时间向下调整排序分值,因为通常认为较新地址更有可能是有用的,所有其他地址不变。最后,衰减函数指示应将地址从地址历史中移除。
图24概念性地示出了一些实施例的用于存储和衰减地址的架构 2400。在一些实施例中,这些地址可以是物理地址和电信地址。其他实施例仅排序并执行对这些类型的地址(例如,物理地址)或其他类型的地址中的一个地址的衰减。如图所示,架构2400包括地址获取器2405、一组应用程序2410、地址提取器2415和衰减引擎2420。此外,系统包括地图地址历史2425和地址历史2430。
在一些实施例中,地址获取器2405接收来自应用程序2410的地址和内容两者,并且将物理地址和电信地址两者存储在地址历史2430中。例如,地址获取器从日程安排应用程序(例如,日历应用程序、电子票务应用程序等)直接接收物理地址来获取。此外,地址获取器从电子消息应用程序 (例如,SMS应用程序和电子邮件应用程序)接收从其接收消息并将消息发送至其的电话号码和电子邮件地址。
地址获取器2405另外接收来自这些电子消息应用程序的内容。电子邮件和文本消息可包括作为其内容的一部分的物理地址。因此,地址获取器 2405使用地址提取器2415来识别从电子消息应用程序所接收的内容中的地址(例如,基于其格式化)。在一些实施例中,地址获取器还从这些应用程序和其他应用程序(例如,地图应用程序)中接收用户已搜索、导航至、查看等某些地址或这些地址处的某些实体的指示。
在一些实施例中,地址获取器2405将所接收的和所提取的地址以及所接收的或所推导的有关这些地址的信息存储在数据存储装置2430中的一个或多个表格中。如图所示,地址历史数据存储装置2430中的每个地址条目包括有关地址获取的各种数据。例如,在所示的实例中,每个地址包括发送方取值、地址、时间戳和源标识符。地址获取器2405使用这些值来计算初始排名。
在一些实施例中,对于从电子消息中获取的地址,发送方字段指示消息的发送方是否为已知的。在一些实施例中,该字段可顺次排列。例如,发送方字段可被划分成未知联系人、常用联系人和较重要联系人(其可由用户排序或接收消息的频率来确定)。
在一些实施例中,时间戳字段存储由其源应用程序所接收的地址的时间。例如,在电子邮件或文本消息中所接收的地址存储该文本消息的时间。来自网络浏览器的地址存储用户在网络浏览器中选择以存储地址的时间。源标识符字段存储从哪个应用程序2410获取地址的指示符。在该实例中,首先列出的地址来自文本消息,而其他两个地址来自电子邮件。在一些实施例中,可针对至少一些类型的地址来存储附加字段。例如,来自日历事件的地址可存储日历事件的时间,而不是接收地址的时间。
在一些实施例中,由地址获取器2405初始根据一组启发法来计算排名。这些启发法基于各种因素来向每个地址分配一个分值。例如,来自已知发送方的地址比来自未知发送方的地址分值更高(例如,被分配更小的编号)。一些实施例将来自文本消息的地址视为比来自电子邮件消息的地址更重要。如果相关联的事件很久远,则预定事件的地址可被分配低的分值,但如果事件即将发生,则预定事件的地址可被分配高的分值。一些实施例仅存储时间戳和地址排名,而非存储多个字段。
衰减引擎2420根据一个或多个衰减函数周期性地对存储在地址历史数据存储装置2430中的地址进行重新评分。该实例示出了衰减引擎2420检索具有排序分值为20(较高排名)的地址并将该地址重新调整至分值为5(较低排名)。一些实施例随时间自动向下调整地址直到时间戳(例如,某一天) 之后的特定时间段。一些实施例针对不同类型的地址具有不同的衰减函数。例如,由于文本消息为较直接的通信形式,因此来自文本消息的地址可以比来自电子邮件的地址以更高的排名开始,但也衰减更快。另一方面,预定事件的地址可以很低的排名开始直到即将临近预定事件之前,然后可在事件之前的特定时间段(例如,3个小时、6个小时、12个小时、24 小时)内被调整至很高的排名,并且在事件时间之后立即移除。
架构2400还包括地图地址历史2425。在一些实施例中,在设备上操作的地图绘制应用程序存储最近记录的地址(例如,搜索结果、针对其生成路线的目的地等)。在一些此类实施例中,地址获取器2405从地图地址历史 2425中检索这些物理地址并将所检索的地址存储在系统范围地址历史2430 中。另选地,地图历史2425被单独地维护,并且由一些实施例的预测引擎单独访问。这将参考图36进一步描述。
C.基于所获取的物理地址来制定预测
一些实施例使用所获取的物理地址来制定有关设备用户的未来目的地的预测,然后基于这些预测来向用户提供信息。为了制定这些预测,一些实施例采用一个或多个机器学习引擎来生成附加物理地址以增加它们用于作为其预测基础的一组物理地址。
不同的实施例基于预测向用户提供不同的信息。此类信息的实例包括到所预测未来目的地的路线、有关到可能未来目的地的路线的交通数据、所预测未来目的地在可能目的地或搜索查询的列表中优先于其他目的地的显示,等等。普通技术人员将认识到,在一些实施例中,所获取的物理地址并不用于所有这些目的。普通技术人员还将认识到,在其他实施例中,所获取的物理地址用于其他预测和其他用途。
图25示出了使用所获取的物理地址来预测未来路线的移动设备2500 的实例,该路线通过车辆显示器呈现给用户。在该实例中,移动设备2500 连接至车辆的电子信息系统的接口。地图绘制应用程序在移动设备2500上操作,并且将第一用户界面显示2505输出在移动设备的显示屏2520上并将第二用户界面显示2510输出在车辆的显示屏2515上。
该图示出了车辆2550的内部,其中移动设备2500经由有线连接2555 连接到车辆并且输出用于在车辆屏幕2515上显示的用户界面。尽管该实例示出了有线连接2555,但在其他实施例中,移动设备通过无线连接(例如,通过蓝牙连接)来与车辆的电子信息系统进行连接。另外,该实例和下文所述的其他实例示出了车辆中的单个显示屏。然而,一些车辆包括多个屏幕,诸如中央控制台仪表板屏幕和位于驾驶员前方的控件群中的一个或多个屏幕。一些实施例仅将单个用户界面输出至此类车辆的中央仪表板屏幕,而其他实施例将相同的用户界面输出至多个屏幕,并且另外的其他实施例将不同界面输出至不同屏幕。
该图还示出了移动设备2500和仪表板屏幕2515的放大视图。如图所示,两个视图显示同一位置的地图,但位于不同用户界面的上下文内。图 25进一步示出了所获取的地址数据存储装置2540、路线预测引擎2542和车辆UI模块2544。地址数据存储装置2540存储所获取的物理地址。基于这些所获取的物理地址,路线预测引擎2542制定设备可能在任何给定时间采用的一条或多条预测路线。该引擎将这些制定的路线提供给车辆UI模块。车辆UI模块生成车辆UI显示2520并将该显示呈现在车辆的显示屏 2515上。
在一些实施例中,预测引擎2542为在移动设备2500上执行的地图应用程序的一部分。在这些实施例或其他实施例中,预测引擎制定设备可基于多种因素来制定设备可能在任何给定时间采用的一条或多条预测路线。这些因素包括存储在所获取的地址数据存储装置2540中并从多种来源获取的物理地址。例如,在一些实施例中,这些地址是从发送或接收的电子邮件、文本消息、日历邀请等中获取的。另外,在一些实施例中,这些地址是在网络浏览器和/或地图应用程序或其他应用程序(例如,邮件应用程序) 中对其进行搜索、查看和/或将其用于计算路线时所获取的。在一些实施例中,还从日历标注的事件的位置来获取这些地址。如上所述,一些实施例采用一个或多个机器学习引擎来生成附加物理地址以增加用于制定预测路线的一组物理地址。
在预测引擎识别多于一条预测路线时,车辆UI显示器2515提供对多条预测路线的指示。在图25所示的实例中,对多条路线的指示由指示符 2560来提供,在这些实施例中,该指示符指示显示多条预测路线的多个视图页面。下文将参考图26和图27进一步描述滚动通过这些路线。
如图25所示,在一些实施例中,车辆UI显示器2515将可能路线连同地图视图一起呈现在显示器的一部分上,并且将有关路线的信息(包括估计到达时间、有关路线来源的元数据等)呈现在显示器的第二部分上。在该实例中,在第二部分中所提供的路线信息将用于预测路线目的地的数据的来源指定为设备的可能目的地和到该目的地的行驶频率。
在一些实施例中,对该显示器的地图视图部分的选择(例如,触摸屏选择或键控选择)使得移动设备进入逐向导航模式。在一些实施例的逐向导航模式中,移动设备沿所选择的路线呈现视图,同时还提供用于后续操控执行的指令(例如,如道路标志连同文本指令和图形指令)。在一些实施例中,导航模式通过由车辆UI显示器2515所提供的另一控件来启动。另外,在具有生成和/或呈现预测路线的地图应用程序的一些实施例中,地图应用程序为移动设备上的负责提供逐向导航(即,用于提供导航模式)的应用程序。
图26示出了滚动通过基于所获取的数据生成的多条预测路线的实例。该实例在三个操作阶段2610-2620中被示出。第一阶段2610示出了图25的车辆UI显示器2520。如上所述,指示符2560指示附加路线的可用性。在一些实施例中,指示符的数量指示附加路线的数量。在该实例中,第一阶段2610中的三个指示符2560指示在这些实施例中的三条预测路线。
第二阶段2615示出了用户对呈现内容执行轻扫操作以导航到另一预测目的地/路线。由于在该实例中车辆显示屏2520具有触敏屏,因此用户可执行此类动作。除了轻扫手势之外,一些实施例的车辆UI模块2544接受其他手势或对各种示能表示的选择(例如,左右或上下导航箭头)以便循环通过不同的选项。因此,在呈现内容显示在车辆的非触敏屏上时,用户可通过按键、旋钮或车辆的其他控件中的一者导航至下一预测目的地/路线。
不管用户如何导航至下一预测目的地/路线,移动设备2500在接收到用户的输入时呈现下一预测目的地/路线。图26的第三阶段3620示出了移动设备的呈现内容2655,其显示健身房2660和到作为另一预测目的地/路线的健身房的路线2666。在第三阶段中,地图应用程序初始并未显示到健身房的路线,因为路线预测引擎为健身房分配了相比于第一阶段2610所示的目的地作为实际目的地的更低的概率。
图27示出了在移动设备沿特定路径行驶时设备自动滚动通过多条预测路线的实例。该实例在两个操作阶段2705-2710被示出。第一阶段2705示出了设备在其沿第一预测路线2724行驶至第一预测目的地2720的位置 2722。该阶段还示出了指定移动设备已识别到多个不同预测目的地的多条不同预测路线的指示符2560。
第二阶段2710示出了一旦用户经过十字路口2730,移动设备便重新制定预测路线并呈现到新目的地2728的新的预测路线2726。在一些实施例中,预测路线2726可能已经是移动设备先前预测并由指示符2560表示的路线中的一条路线。另选地,一旦用户经过十字路口2730,在一些实施例中,移动设备就可能已重新制定其预测并将目的地2728识别为新的可能目的地。
在一些实施例中,在某些情况下,移动设备基于在另一个设备上获取的地址来进行其预测。图28示出了这样的一个实例。该实例与图25所示的实例相同,不同的是图28中的所获取的地址山麓小丘路1149号初始在计算机2800上被捕获并存储在该计算机的地址数据存储装置2840中。该地址继而通过服务器基础结构转发至移动设备2500的所获取的地址数据存储装置2540。一旦转发至移动设备2500,该设备的预测引擎便使用该地址来将其识别为设备的可能目的地。
物理地址在多个设备之间的同步是非常有用的。例如,用户可充分探索台式计算机的地图应用程序上的位置。给定在设备之间实时地或快速同步地址的一些实施例,用户的移动设备的预测引擎可在下次用户驾驶车辆出行时使用该地址以自动提供到所探索位置的路线。
III.所获取的地址的其他用途
图29-图31示出了使用所获取的物理地址的若干个附加实例。在这些实例中,所获取的地址用于基于所获取的物理地址或机器生成的物理地址来提供行驶时间和交通数据。如上所述,一些实施例采用一个或多个机器学习引擎来生成附加物理地址以增加用于预测基础的一组物理地址。
图29示出了一些实施例如何基于所获取的或机器生成的物理地址来呈现交通通知的若干个实例。为了呈现此类通知,一些实施例仅关注很有可能与设备的用户相关的所获取的地址或机器生成的地址。其部分因为此类通知的空间通常限于移动设备上。其还部分因为太多机器生成的通知可能分散用户的注意力而导致用户通常可能无法找到所感兴趣的事物。
如图29所示,一些实施例的移动设备在包括各种通知(诸如日历事件提醒)的通知中心窗口2910中为用户显示交通通知2905。该实例中的交通通知指定沿公路101的交通比平时拥挤。移动设备基于对设备不久将沿该公路行驶的预测来报告沿该公路的交通。该预测可基于设备的预测目的地。在一些实施例中,预测目的地由机器学习过程来生成,该机器学习过程在不同时间间隔识别设备的典型位置。在一些实施例中,预测目的地另选地可为所获取物理地址,诸如日历标注的事件的位置。
一旦将位置预测为目的地,一些实施例的移动设备便到该位置的路线以及沿该路线的交通拥堵进行识别。在一些实施例中,交通数据指定交通比平时畅通、比平时拥堵或与平时一样。基于该交通数据,一些实施例的移动设备提供图29的交通通知2905。
图30示出了所获取的物理地址的另一场景。日历应用程序列出若干个事件3005和3010。这些事件的位置地址被获取并存储在地址存储装置中。基于所获取的地址和当前位置,日历应用程序将指示采用或避开路线的交通状况呈现给每个事件。为了识别此类交通状况,一些实施例的移动设备识别设备的当前或未来目的地和日历标注的事件的位置之间的预测路线。在一些实施例中,预测路线具有交通数据。如图30所示,基于该数据,移动设备显示针对每个日历标注的事件的交通状况。在一些实施例中,移动设备还基于该数据来计算并显示针对事件的行驶时间。
图31示出了所获取的物理地址的另一使用案例场景。日历应用程序列出若干个事件3105和3110。这些事件的位置地址被获取并存储在地址存储装置中。基于所获取的地址,日历应用程序创建新事件3115来考虑事件 3105和3110之间的行驶时间。例如,行驶时间事件3115以从事件3105的位置行驶到事件3110的位置将花费的估计时间在日历中列出。
所获取的地理地址的另一用途涉及它们在增加语音识别操作中的使用。如上所述,一些实施例的语音识别应用程序使用所获取的电信地址来识别电子消息的预期接收人。例如,用户可利用语音命令来从具有此类语音识别能力的移动设备发送电子邮件或文本消息。用户将需要指定用于这些消息的一个或多个接收人,除非回复先前的消息。为了有助于识别由用户口述的接收人,一些实施例的语音识别应用程序使用所获取的地址。
图32示出了在移动设备3200上使用一些实施例的语音识别功能来识别先前获取的并存储在地址历史数据存储装置中的接收人电子邮件地址。该图示出了移动设备的四个阶段3205-3220,在该四个阶段中用户启用语音识别应用程序、使用语音识别来打开电子邮件应用程序并口述接收人姓名。
第一阶段3205示出了便携式设备3200的主页。在这种情况下,用户选择按钮3225以便启用语音识别。第二阶段3210示出了移动设备上的语音识别应用程序已开始,因为其提示用户口述用户希望应用程序所做的事情。如图所示,用户说出“电子邮件”,其被语音识别应用程序解译为打开移动设备上的电子邮件客户端以便发送新的电子邮件的请求。
因此,第三阶段3215示出了新的电子邮件打开,并且语音识别应用程序询问用户应将消息发送给谁。此外,在该阶段处,用户以“Jerome Smith”回复。在这种情况下,JeromeSmith并非用户联系人中的一个用户联系人,因此不存在存储在用户联系人中的映射到名称Jerome Smith的电子邮件地址。然而,在该实例中,用户先前已接收到来自Jerome Smith的电子邮件,因此地址历史数据存储装置包括“Jerome Smith”以及对应的电子邮件地址。如加亮部分3230所示的,在第四阶段3220处,语音识别应用程序已在新的电子邮件的收件人行中填充Jerome Smith的电子邮件地址。
一些实施例的语音识别应用程序还利用通过移动设备所连接到的车辆的用户界面的输入来进行。图33示出了在用户启用消息功能并向接收人口述消息的四个阶段3305-3320的车辆显示屏。第一阶段3305示出了一些实施例的车辆显示屏主页,其由连接至该车辆显示屏的移动设备驱动。在这种情况下,用户选择消息控件3323以便激活便携式设备的消息(例如,SMS) 特征部。
第二阶段示出了一些实施例的消息界面3300。消息界面3300包括提示3325(其也可经由车辆扬声器输出为音频)、用于在不发送消息的情况下关闭消息界面的取消控件3330,以及用于向消息应用程序指示已完成口述的完成控件3335。在第二阶段3310中,消息特征部请求消息的接收人,并且用户口述“Jerome”。
第三阶段3315示出了消息特征部使用一些实施例的所获取的数据来识别数据被发送到的电信地址(例如,电话号码、电子邮件)。在这种情况下,尽管用户没有任何名为Jerome的联系人,但文本消息先前已接收到与电话号码相关的名称Jerome Smith。因此,消息界面3300现在请求用户向 Jerome Smith口述消息。如加亮部分3340所示的,在一些实施例中,接收人为用户可选择以改变消息的接收人的可选择项。另外,在该阶段,用户口述消息“十分钟后到达”。第四阶段3320示出了所得的消息,其具有用于允许用户发送消息的控件3345。
IV.在多个设备之间分发所获取的地址
如上所述,一些实施例具有用于分别存储物理地址数据、电子邮件地址数据、电话存储数据以及群组邮件和电话地址数据的四个数据存储装置。为了在连接至图3的服务器基础结构的多个相关联设备之间同步这些数据存储装置,一些实施例创建用于这些存储装置中的三个存储装置的键值存储,这些键值存储为物理地址存储、电子邮件地址存储和电话号码存储。这些实施例将群组数据存储装置中的记录存储在电子邮件地址存储和电话号码存储中。
更具体地,在一些实施例中,设备和存储基础结构将所获取的数据存储在一个或多个键值存储中。一些实施例的设备和存储基础结构将数据存储在三个单独的键值存储中。在一些实施例中,每个存储为存储在设备上的表格。在一些实施例中,存在用于电话号码的一个存储、用于电子邮件的第二存储和用于物理地址的第三存储。在一些实施例中,键值存储装置中的一个或多个键值存储装置包括用于个人和群组两者的条目。例如,用于电话号码的键值存储装置包括针对个人电话号码和群组电话号码(例如,由用户选择以同时发送SMS消息的多个号码)的条目。针对个人电话号码的条目各自识别单个电话号码,而针对群组电话号码的条目各自识别多个电话号码。在一些实施例中,群组可重叠。
在键值存储机制中,存在存储在每个存储位置中的多个键。每个键为一个记录。一些实施例的键为基于(例如)与键相关联的数据值的散列值。键值为包含所有参数(有时称为“字段”)和记录的这些参数的值的对象。例如,一些实施例的电子邮件键值存储装置中的键值包括参数诸如名称、电子邮件地址、使用地址的最近时间、使用地址的第二最近时间等。这些参数值可分别为数据诸如“John Smith”、“JSMITH@EXAMPLE.COM”、“2013年5月30日12:52PM”、“2013年5月30日11:12AM”。“12AM May 30th,2013”,respectively.一些实施例的记录包含何时最后使用地址的多个时间的记录。例如,一些实施例最后五次将记录存储在与所使用的键值相关联的地址的键值中。在一些实施例中,如果地址(例如,电子邮件地址或电话号码)与多个群组相关联,则设备针对地址所属的每个群组在该数据类型的键值存储装置中添加条目。在一些实施例中,群组键值作为相同类型的单个键值存储在同一键值存储装置中。识别电话号码组的键值存储在电话号码键值存储装置中,因为同一存储中的单独条目作为单个电话号码来存储。识别电子邮件组的键值存储在电子邮件地址键值存储装置中,因为同一存储中的单独条目作为单个电子邮件地址来存储。识别物理地址组的键值存储在物理地址键值存储装置中,因为同一存储中的单独条目作为单个物理地址来存储。
在一些实施例中,设备的每个键值存储装置通过网络基础结构与和网络基础结构上的账户相关联的所有设备同步。当记录被添加到设备中时,其使得新记录由网络同步器添加至所有相关联的设备。类似地,当条目被修改时(例如,当用户更改与姓名条目相关联的电话号码时),网络同步器将该修改通过网络基础结构传送至相关联的设备。如上相对于图3所描述的,在一些实施例中,网络同步器通过网络的服务器基础结构来工作以对不必全部与用户在其上对记录作出修改的设备同时开启的设备进行更新。
为了创建并维护键值存储,这些实施例中的一些实施例则使用Apple Inc的普遍存在键值存储技术以在处于同步状态中的所有相关联的设备上维护三个键值存储。该技术在美国公布的专利申请2012/0310880和 2012/0185448中有所描述。这两个公布的专利申请以引用方式并入本文。
图34概念性地示出了一些实施例的用于将所获取的数据通过服务器基础结构从一个设备分发到另一个设备的多设备过程3400。该图包括三列,第一列3401概念性地示出了过程3400中由设备执行的步骤,用户在该设备上创建或修改键值存储中的条目。第二列3402概念性地示出了过程3400 中的由服务器基础结构执行的步骤。第三列3403概念性地示出了过程3400 中的由第二设备执行的步骤,该第二设备通过服务器基础结构(从第一设备中)接收新创建或修改的条目。
过程3400在第一设备处接收(在3410处)新的键值记录或对键值存储的现有键值记录的修改。在一些实施例中,该修改改变键值对的值和/或字段。例如,与用于电子邮件地址的记录相关联的参数可改变。在一些实施例中,一种类型的修改为删除键值。
过程3400继而将所接收的数据(新的或经修改的键值数据)上载(在 3412处)到服务器基础结构。在一些实施例中,修改作为初始键散列值和经修改的键/值对而被上载。在其他实施例中,修改作为初始键值记录和识别对记录的副本所作的更改的数据而上载。其他实施例提供允许在相关联的设备上执行修改的其他数据组。
过程3400继而由服务器基础结构在列3402中继续进行。过程3400接收(在3420处)来自第一设备的新的键值或键值修改数据。如上所述,在不同实施例中,修改可以不同形式接收。过程3400将新的键值或修改数据存储在临时存储装置中(在3422处)。在一些实施例中,服务器基础结构维护设备的键值存储装置的副本。在一些此类实施例中,服务器基础结构在接收到数据时添加新的键值或修改键值。然而,在一些实施例中,网络服务器充当修改数据的渠道并且不自身维护设备的所有键值存储装置的副本。在此类实施例中,服务器仅存储其在临时存储装置中接收的数据直到能够将其下载到一个或多个接收设备。过程3400继而将新的键值或对键值的修改发送(在3424处)至具有相关键值存储装置的副本的每个相关联的设备。在当接收到服务器基础结构时相关联设备未连接到服务器基础结构的情况下,过程3400等待直到相关联的设备连接到网络,然后将修改数据发送至相关联的设备。
过程3400继而在下载相关联的设备时接收(在3430处)来自服务器基础结构的新的键值或修改数据。如上所述,在不同的实施例中,修改数据可以不同形式来实现。过程3400继而在下载相关联设备的键值存储装置中添加或修改(在3432处)键值。然后过程3400结束。
V.获取和预测架构
在一些实施例中,所获取的电信地址和物理地址由预测引擎使用,该预测引擎利用这些所获取的地址来更好地通知其他应用程序所作的决策。图35概念性地示出了执行此类获取和预测的一些实施例的设备的架构3500 的更详细的实例。
架构3500包括地址获取器3505、地址提取器3510、一组应用程序 3515、目的地识别器3520、目的地选择器3525、路线生成引擎3527、通知管理器3530、交通监控器3535、地图绘制界面3540、一组附加预测引擎 3540、语音识别模块3545和一组通信应用程序3550。此外,获取架构还包括所获取的地址数据存储装置3555和机器生成的地址数据存储装置3560。
在一些实施例中,地址获取器3505接收来自应用程序3515的地址和内容两者,并且将物理地址和电信地址两者存储在所获取的地址数据存储装置3555中。例如,地址获取器3505从日程安排应用程序(例如,日历应用程序、电子票务应用程序等)直接接收待获取的物理地址。此外,地址获取器3505从电子消息应用程序3550(例如,SMS应用程序3552和邮件应用程序3554)接收与传入内容相关联的电话号码和电子邮件地址。
地址获取器3505另外接收来自这些电子消息应用程序3550的内容。电子邮件和文本消息可包括作为其内容的一部分的物理地址。因此,地址获取器3505使用地址提取器3510来识别从电子消息应用程序3550所接收的内容中的地址(例如,基于其格式化)。在一些实施例中,所有所获取的地址均以排序方式存储在所获取的地址数据存储装置3555中,如上文参考图 24所描述的。在其他实施例中,仅一些类型的所获取的地址(例如,物理地址)被排序或具有相关联的排序分值。
除获取地址之外,目的地生成器3520还生成地址并将这些地址存储在机器生成的地址数据存储装置3560中。在一些实施例中,目的地生成器 3520使用机器学习引擎来分析由设备所记录的过去位置数据,以便识别目的地区域。即,设备包括在不同时间确定设备的纬度和经度坐标的位置识别引擎(例如,全球定位系统引擎)。基于分析这些坐标,一些实施例的目的地生成器3520识别在超过阈值时间段内设备所在的位置(例如,城市、物理地址)。
目的地生成器3520将这些位置存储在机器生成的地址数据存储装置 3560中。一些实施例的目的地生成器3520还使用机器学习引擎来使用设备行驶于其间的不同目的地区域之间(例如,不同的预测目的地位置之间)的所识别中间位置来创建不同目的地区域之间的关联。路线生成引擎3527继而可使用这些关联来限定目的地区域之间的特定路线,如下文进一步所述的。
架构3500包括多种所获取的地址和机器生成地址的使用方。一些实施例的语音交互模块3545在响应于语音指令准备消息或发起电话呼叫时,使用潜在的接收人数据存储装置。除其他应用程序之外,语音识别模块3545 被SMS应用程序3552和电子邮件应用程序3554所使用,其使用所获取的电信地址来填充这些应用程序的接收人字段。如图所示,如上所述,这些应用程序还将数据馈送到获取器3505。
在一些实施例中,目的地选择器3525基于机器生成的地址数据存储装置3560和/或所获取的地址数据存储装置3555中的所获取的地址生成不同时间的预测目的地。在一些实施例中,目的地选择器3525根据各种标准对多个可能目的地进行排序。例如,如果机器生成的地址数据识别出设备每天在特定时间到达的位置,则目的地选择器3525预测设备的用户将在当前日期的特定时间想要到达该位置。一些实施例的目的地选择器3525将这些预测目的地发送至路线生成引擎3527,该路线生成引擎生成到目的地的路线。在一些实施例中,路线生成引擎自身生成路线,而在其他实施例中,其采用(可通信地耦接到设备的)外部服务器来生成路线。
在一些实施例中,路线生成器3527仅获取两个位置并基于这两个位置生成路线或使路线生成。例如,在一些实施例中,路线生成器3527接收设备的当前位置和设备的预测目的地。在其他实施例中,如上所述,路线生成器不仅基于两个端点位置,还基于目的地识别器利用端点位置所识别的中间位置来生成路线(或使路线生成)。一些实施例的目的地识别器3520、目的地选择器3525和路线生成器3527在于2013年11月15日提交并且名称为“Warning for Frequently Traveled Trips Based on Traffic,”的美国非临时专利申请号14/081,899和于2013年6月9日提交的美国临时专利申请号 61/832,928中进一步详细描述,该两个专利申请以引用方式并入本文。
在一些实施例中,路线生成器3527使用交通监控器3535来确定沿任何所生成的路线的交通。交通监控器与可通信地耦接到设备的一个或多个交通监控服务器进行交互,以便获得有关所生成的路线的实时交通数据。在一些实施例中,交通监控器为外部路线生成器的一部分,并且每条所生成的路线伴随沿路线的当前交通出现。
若干个应用程序使用引擎3525的预测目的地和来自路线生成引擎 3527的随后生成的路线。例如,在一些实施例中,路线生成引擎3527通知一些实施例的通知管理器3530将交通信息置于通知中心,如图29,30和31 所示。对于一些此类通知,路线生成引擎3527将其数据提供给一个或多个其他模块(例如,日历应用程序)并且这些其他应用程序将数据(例如,取决于交通数据的行驶时间)提供给通知管理器以便通知管理器生成所需的通知中心通知(例如,日历事件)和显示。
地图绘制界面3540为在设备上操作的地图绘制应用程序的界面。在一些实施例中,地图绘制应用程序使用来自目的地选择器3525和路线生成引擎3527的目的地和路线以将可能很容易选择的目的地呈现给用户以用于导航。当设备连接至车辆时,一些实施例在车辆显示屏上将该数据呈现给用户。
此外,一些实施例的地图绘制界面3540使用语音交互模块3545来在地图绘制应用程序中执行用于位置搜索的语音识别。在这种情况下,语音交互模块3545可使用所获取的地址数据存储装置3555来通知搜索。地图绘制应用程序的用于所获取的地址的一些用途在提于2013年11月15日提交并且名称为“Mapping Application with Several UserInterfaces”的美国非临时专利申请14/081,896和于2013年6月8日提交的美国临时专利申请号 61/832,818中进一步详细描述,该两个专利申请以引用方式并入本文。
如图35所示,数据存储装置3555中的所获取的地址还可用于驱动各种其他预测引擎3565以制定各种其他预测。这些预测引擎继而利用其预测来驱动一个或多个应用程序3515。
VI.同步多个所获取的数据存储装置
在一些实施例中,设备具有多个所获取的地址数据存储装置并使这些多个数据存储装置通过服务器基础结构与一个或多个设备同步。图36示出了一种此类方法。具体地,其示出了一些实施例的两个设备3605和3655。这些设备中的每个设备(3605或3655)具有用于在设备上执行的地图应用程序的一个特定的所获取的地址数据存储装置,以及用于在设备上执行的一个或多个其他应用程序的另一个通用的所获取的地址数据存储装置。每个设备使用服务器基础结构(例如,基础结构315)来使其每个所获取的地址数据存储装置与相关的设备(3610或3655)的其他类似的数据存储装置同步。在设备上执行的预测引擎继而可从驻留在设备上的任一数据存储装置中检索所获取的地址。
为简单起见,图36示出了两个用户设备3605和3655,但在一些实施例中,所获取的地址在任何数量的相关联的用户设备之间共享。如图所示,用户设备3605包括地图应用程序3610。地图应用程序3610包括所获取的地址数据存储装置3615,该所获取的地址数据存储装置用于保存最近访问的地图信息,诸如最近搜索结果、在设备上显示的最近地图区域、最近放置的标针、最近路线等。类似地,用户设备3655包括具有所获取的地址数据存储装置3665的地图应用程序3660。
每个设备3605和3655还分别包括设备级的所获取的地址数据存储装置3620和3670。所获取的地址数据存储装置保存各种物理地址,包括从电子邮件和文本消息的主体中获取的,从日历标注的预约的位置中捕获的,基于与电子邮件、浏览器等中地址的用户交互而捕获的。
如图所示,地图应用程序3610和3660各自包括所获取的地址重复处理器(所获取的地址重复器或所获取的地址去重复器)3625和3675,以及预测引擎3690和3692。每个预测引擎(例如3690)可基于从其设备数据存储装置(例如,3615和3620)检索的地址来制定一个或多个预测。例如,在一些实施例中,每个预测引擎基于预测引擎通过地址重复处理器从其设备的数据存储装置(例如,3615或3620)检索的所获取的地址来制定有关预测目的地或到目的地的预测路线的预测。
所获取的地址重复处理器3625从两个数据存储装置(例如,3615和 3620)检索期望的所获取的地址(例如,具有某一排名的地址和/或在某一时间段获取的地址),对其进行相互比较以识别重复地址,从每个所识别的重复对中去除一个地址,并将没有任何重复的地址列表提供至预测引擎。在一些实施例中,预测引擎首先从其设备的两个存储装置检索地址,然后将这些地址提供给重复处理器以用于其删除任何重复副本。预测引擎继而可基于从两个数据存储装置检索的地址列表来制定其预测(例如,识别预测目的地或路线)。
图36还示出了一些实施例(1)使彼此相关联的用户设备(例如,在远程存储装置和计算服务中向同一用户注册)之间的地图应用程序地址数据存储装置3615和3665同步,以及(2)使相关联的用户设备之间的通用地址数据存储装置3620和3670同步。如上所述,该同步由服务器基础结构(例如,在该图中未示出的基础结构315)来促进。另外,在一些实施例中,设备和服务器基础结构使用上述键值存储机制(例如,普遍存在的键值存储机制)。
VII.电子系统
上文所述的特征和应用程序中的许多者可被实施为被指定为在计算机可读存储介质(还称为计算机可读介质)上记录的一组指令的软件过程。在这些指令由一个或多个计算或处理单元(例如,一个或多个处理器、处理器的内核或者其它处理单元)执行时,这些指令使得一个或多个处理单元能够执行指令中所指示的动作。计算机可读介质的实例包括但不限于 CD-ROM、闪存驱动器、随机存取存储器(RAM)芯片、硬盘驱动器、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM) 等。计算机可读介质不包括无线地传送或通过有线连接的载波和电信号。
在本说明书中,术语“软件”意在包括驻留在只读存储器中的固件或者存储在磁性存储设备中的应用程序,所述应用程序可被读取到存储器中以用于由处理器进行处理。另外,在一些实施例中,可在保留不同的软件发明的同时,将多个软件发明实现为更大应用程序的子部分。在一些实施例中,还可将多个软件发明实施为独立的应用程序。最后,共同实施本文所述的软件发明的单独应用程序的任何组合均在本发明的范围内。在一些实施例中,当被安装以在一个或多个电子系统上操作时,软件应用程序限定执行和施行软件应用程序的操作的一个或多个特定机器具体实施。
一些实施例的地图应用程序在移动设备例如智能电话(例如,)和平板电脑(例如,)上操作。图37是此类移动计算设备的架构3700的实例。移动计算设备的实例包括智能电话、平板电脑、膝上型电脑等。如图所示,移动计算设备3700包括一个或多个处理单元3705、存储器接口3710和外围设备接口3715。
外围设备接口3715耦接到各种传感器和子系统,所述子系统包括相机子系统3720、一个或多个无线通信子系统3725、音频子系统3730、I/O子系统3735等。外围设备接口3715能够实现处理单元3705与各种外围设备之间的通信。例如,取向传感器3745(例如,陀螺仪)和加速度传感器3750 (例如,加速度计)耦接到外围设备接口3715,以促进取向和加速功能。
相机子系统3720耦接到一个或多个光学传感器3740(例如,电荷耦合设备(CCD)光学传感器、互补金属氧化物半导体(CMOS)光学传感器等)。与光学传感器3740耦接的相机子系统3720促进相机功能,诸如图像和/或视频数据捕获。无线通信子系统3725用于促进通信功能。在一些实施例中,无线通信子系统3725包括射频接收器和发射器,以及光学接收器和发射器(图37中未示出)。一些实施例的这些接收器和发射器被实现为在一个或多个通信网络上操作,所述通信网络诸如GSM网络、Wi-Fi网络、蓝牙网络等。音频子系统3730耦接到扬声器以输出音频(例如以输出语音导航指令)。另外,音频子系统3730耦接到麦克风以促进支持语音的功能,诸如语音识别(例如,用于搜索)、数字记录等。
I/O子系统3735涉及输入/输出外围设备(诸如显示器、触摸屏等)和处理单元3705的数据总线之间通过外围设备接口3715的传输。I/O子系统 3735包括触摸屏控制器3755和其它输入控制器3760以促进输入/输出外围设备和处理单元3705的数据总线之间的传输。如图所示,触摸屏控制器 3755耦接到触摸屏3765。触摸屏控制器3755使用任何多点触敏技术来检测触摸屏3765上的接触和移动。其它输入控制器3760耦接到其它输入/控制设备,诸如一个或多个按钮。一些实施例包括接近触敏屏和对应控制器,该对应控制器可检测替代触摸交互或除触摸交互之外的接近触摸交互。
存储器接口3710耦接到存储器3770。在一些实施例中,存储器3770 包括易失性存储器(例如,高速随机存取存储器)、非易失性存储器(例如,闪存存储器)、易失性存储器和非易失性存储器的组合和/或任何其他类型的存储器。如图37中所示,存储器3770存储操作系统(OS)3772。OS 3772包括用于处理基础系统服务和用于执行硬件相关任务的指令。
存储器3770还包括用于促进与一个或多个附加设备进行通信的通信指令3774;用于促进图形用户界面处理的图形用户界面指令3776;用于促进图像相关的处理和功能的图像处理指令3778;用于促进输入相关(例如,触摸输入)的过程和功能的输入处理指令3780;用于促进音频相关的过程和功能的音频处理指令3782;以及用于促进相机相关的过程和功能的相机指令3784。上述指令仅是示例性的,并且在一些实施例中,存储器3770包括附加指令和/或其他指令。例如,用于智能电话的存储器可包括用于促进电话相关的过程和功能的电话指令。另外,存储器可包括用于地图应用程序以及其他应用程序的指令。以上所识别的指令不需要作为独立的软件应用程序或模块来实施。可在包括在一个或多个信号处理电路和/或专用集成电路中的硬件和/或软件中实现移动计算设备的各种功能。
虽然图37中所示的部件被示出为独立的部件,但是本领域的普通技术人员将认识到,可将两个或更多个部件集成到一个或多个集成电路中。另外,两个或更多个部件可由一条或多条通信总线或信号线耦接在一起。另外,虽然已将许多功能描述为由一个部件执行,但是本领域的技术人员将认识到,可将相对于图37所述的功能拆分到两个或更多个集成电路中。
图38概念性地示出了实现本发明的一些实施例所利用的电子系统 3800的另一个实例。电子系统3800可为计算机(例如,台式计算机、个人计算机、平板电脑等)、电话、PDA或任何其它种类的电子或计算设备。此类电子系统包括各种类型的计算机可读介质以及用于各种其它类型的计算机可读介质的接口。电子系统3800包括总线3805、一个或多个处理单元 3810、图形处理单元(GPU)3815、系统存储器3820、网络3825、只读存储器3830、永久性存储设备3835、输入设备3840以及输出设备3845。
总线3805总体表示在可通信地连接电子系统3800的许多内部设备的所有系统、外围设备、以及芯片组总线。例如,总线3805可通信地将一个或多个处理单元3810与只读存储器3830、GPU 3815、系统存储器3820以及永久性存储设备3835连接在一起。
一个或多个处理单元3810从这些各种存储器单元检索要执行的指令和要处理的数据以便执行本发明的过程。在不同实施例中,一个或多个处理单元可为单核处理器或者多核处理器。一些指令被传送至GPU 3815并且由该GPU执行。GPU 3815可卸载各种计算指令,或补充由一个或多个处理单元3810提供的图像处理。在一些实施例中,此类功能可使用Corelmage 的内核着色语言来提供。
只读存储器(ROM)3830存储一个或多个处理单元3810以及电子系统的其他模块所需的静态数据和指令。另一方面,永久性存储设备3835是读写存储器设备。该设备是即使在电子系统3800关闭时也存储指令和数据的非易失性存储器单元。本发明的一些实施例将海量存储设备(诸如磁盘或光盘及其对应的硬盘驱动器、集成式闪存存储器)用作永久性存储设备3835。
其他实施例将可移动存储设备(诸如软盘、闪存存储器设备等,及其对应的驱动器)用作永久性存储设备。与永久性存储设备3835一样,系统存储器3820也是读写存储器设备。然而,与存储设备3835不同,系统存储器3820为易失性读写存储器,诸如随机存取存储器。系统存储器3820 存储处理器运行时所需的一些指令和数据。在一些实施例中,本发明的过程存储在系统存储器3820、永久性存储设备3835和/或只读存储器3830 中。一个或多个处理单元3810从这些各种存储器单元检索要执行的指令以及要处理的数据,以便执行一些实施例的过程。
总线3805还连接至输入设备3840和输出设备3845。输入设备3840使得用户能够将信息传送至电子系统并且选择至电子系统的命令。输入设备 3840包括字母数字键盘和指向设备(也称为“光标控制设备”)、相机 (例如网络摄像头)、麦克风或用于接收语音命令的类似设备等等。输出设备3845显示电子系统所生成的图像或者以其他方式输出数据。输出设备 3845包括打印机以及显示设备诸如阴极射线管(CRT)或液晶显示器(LCD),以及扬声器或类似的音频输出设备。一些实施例包括同时充当输入设备和输出设备的设备诸如触摸屏。
最后,如图38中所示的,总线3805还通过网络适配器(未示出)将电子系统3800耦接到网络3825。以此方式,计算机可以是计算机网络(诸如局域网(“LAN”)、广域网(“WAN”)或内联网)的一部分,或者可以是网络的网络(诸如互联网)的一部分。电子系统3800的任何或所有部件均可与本发明结合使用。
一些实施例包括将计算机应用程序指令存储在机器可读或计算机可读介质(或者称为计算机可读存储介质、机器可读介质或机器可读存储介质)中的电子部件,诸如微处理器、存储装置以及存储器。此类计算机可读介质的一些实例包括RAM、ROM、只读光盘(CD-ROM)、可刻录光盘 (CD-R)、可重写光盘(CD-RW)、只读数字通用光盘(例如,DVD-ROM、双层DVD-ROM)、各种可刻录/可重写DVD(例如,DVD-RAM、DVD- RW、DVD+RW等)、闪存存储器(例如,SD卡,迷你(mini)SD卡、微型 SD卡等)、磁性和/或固态硬盘驱动器、只读和可刻录盘、超密度光盘、任何其他光学或磁性介质以及软盘。计算机可读介质可存储计算机应用程序,该计算机应用程序可由至少一个处理单元来执行并且包括用于执行各种操作的指令集。计算机应用程序或者计算机代码的实例包括机器代码,例如由编译器所产生的机器代码,以及包括可由计算机、电子部件或微处理器使用解译器来执行的更高级别代码的文件。
虽然上述讨论主要涉及执行软件的微处理器或多核处理器,但一些实施例由一个或多个集成电路来执行,该一个或多个集成电路诸如专用集成电路(ASIC)或现场可编程门阵列(FPGA)。在一些实施例中,此类集成电路执行存储在电路自身上的指令。此外,一些实施例执行存储在可编程逻辑设备(PLD)、ROM或RAM设备中的软件。
如本说明书以及本专利申请的任何权利要求所使用的,术语“计算机”、“服务器”、“处理器”及“存储器”均是指电子设备或其它技术设备。这些术语不包括人或者人的群组。出于本说明书的目的,术语显示或正在显示意指在电子设备上进行显示。如本说明书以及本专利申请的任何权利要求所使用的,术语“计算机可读介质”以及“机器可读介质”被完全限制为以可由计算机读取的形式存储信息的有形物理对象。这些术语不包括任何无线信号、有线下载信号以及任何其它短暂信号。
各种实施例可在地图服务操作环境内操作。图39示出了根据一些实施例的地图服务操作环境。地图服务3930(还称为地图绘制服务)可为通过各种通信方法和协议与地图服务3930通信的一个或多个客户端设备3902a- 3902c提供地图服务。在一些实施例中,地图服务3930提供地图信息以及其它地图相关的数据,诸如二维地图图像数据(例如,利用卫星图像的道路的鸟瞰图)、三维地图图像数据(例如,具有三维特征诸如建筑物的横贯地图)、路线和方向计算(例如,轮渡路线计算或步行的两点之间的方向)、实时导航数据(例如,二维或三维逐向视觉导航数据)、位置数据 (例如,在客户端设备当前所在的位置)以及其它几何形状数据(例如,无线网络覆盖、天气、交通信息、或附近的兴趣点)。在各种实施例中,地图服务数据可包括用于不同国家或地区的本地化标签。本地化标签可用于在客户端设备上以不同语言呈现地图标签(例如,街道名称、城市名称、兴趣点)。客户端设备3902a-3902c可通过获得地图服务数据来利用这些地图服务。客户端设备3902a-3902c可实施各种技术以处理地图服务数据。客户端设备3902a-3902c然后可将地图服务提供至各种实体,包括但不限于用户、内部软件或硬件模块和/或客户端设备3902a-3902c外部的其他系统或设备。
在一些实施例中,由分布式计算系统中的一个或多个节点来实现地图服务。可为每个节点分配一个或多个服务或地图服务的部件。可为一些节点分配相同的地图服务或地图服务的相同部件。在一些实施例中,加载平衡节点将访问或请求分配至地图服务内的其他节点。在一些实施例中,地图服务被实施为单个系统,诸如单个服务器。服务器内的不同模块或硬件设备可实施由地图服务提供的各种服务中的一个或多个服务。
在一些实施例中,地图服务通过生成各种格式的地图服务数据来提供地图服务。在一些实施例中,一种格式的地图服务数据是地图图像数据。地图图像数据将图像数据提供至客户端设备,使得客户端设备可处理该图像数据(例如,将该图像数据渲染和/或显示为二维或三维地图)。无论是二维形式还是三维形式的地图图像数据都可指定一个或多个地图图块。地图图块可为较大地图图像的一部分。将地图的地图图块组装在一起产生原始地图。可从地图图像数据、路由数据或导航数据或任何其他地图服务数据生成图块。在一些实施例中,地图图块为基于光栅的地图图块,其中图块尺寸的范围为大于和小于常用的256像素乘256像素图块的任何尺寸。基于光栅的地图图块可以任何数量的标准数字图像表示来编码,所述标准数字图像表示包括但不限于位图(.bmp)、图形交换格式(.gif)、联合图像专家小组(.jpg、.jpeg等)、便携式网络图形(.png)或标记图像文件格式(.tiff)。在一些实施例中,地图图块为使用矢量图形来编码的基于矢量的地图图块,所述矢量图形包括但不限于可缩放矢量图形(.svg)或绘图文件(.drw)。一些实施例还包括具有矢量数据和光栅数据的组合的图块。关于地图图块的元数据或其他信息还可包括在地图图块内或连同地图图块一起被包括,从而将另外地图服务数据提供至客户端设备。在各种实施例中,利用各种标准和/或协议对地图图块进行编码以用于传输,该标准和/或协议中的一些标准和/或协议在以下实例中进行描述。
在各种实施例中,根据缩放级别,该地图图块可由不同分辨率的图像数据构造而成。例如,对于低缩放水平(例如,世界或全球视图),地图或图像数据的分辨率不需要如处于高缩放水平(例如,城市或街道水平) 时的分辨率那样高。例如,当在全球视图中时,可能不需要渲染街道级别物像,因为此类对象将是如此小以至于在许多情况下都是可以忽略的。
在一些实施例中,地图服务在对图块进行编码以用于传输之前执行各种技术来分析地图图块。这种分析可优化针对客户端设备和地图服务两者的地图服务功能。在一些实施例中,根据基于矢量的图形技术来对地图图块进行复杂度分析,并使用复杂和非复杂层来构造地图图块。也可针对可被渲染为图像纹理并通过依赖于图像掩码来构造的常用图像数据或模式来对地图图块进行分析。在一些实施例中,地图图块中的基于光栅的图像数据包含与一个或多个纹理相关联的某些掩码值。一些实施例还针对可与包含样式标识符的某些地图样式相关联的指定特征来对地图图块进行分析。
在一些实施例中,其他地图服务依赖于与地图图块分离的各种数据格式来生成地图服务数据。例如,提供位置数据的地图服务可利用符合位置服务协议的数据格式,所述位置服务协议包括但不限于无线电资源位置服务协议(RRLP)、用于码分多址(CDMA)的TIA801、无线电资源控制(RRC) 位置协议或LTE定位协议(LPP)。实施例还可从客户端设备接收或请求识别设备能力或属性(例如,硬件规格或操作系统版本)或通信能力(例如,由无线信号强度或有线或无线网络类型确定的设备通信带宽)的数据。
地图服务可从内部或外部源获得地图服务数据。例如,可从外部服务或内部系统、存储设备或节点获得地图图像数据中所使用的卫星影像。其他实例可包括但不限于GPS助理服务器、无线网络覆盖数据库、企业或个人目录、天气数据、政府信息(例如,建筑物更新或道路名称改变)或交通报告。地图服务的一些实施例可更新地图服务数据(例如,无线网络覆盖)以用于分析来自客户端设备的未来请求。
地图服务的各种实施例可响应于地图服务的客户端设备请求。这些请求可针对特定地图、或地图的一部分。一些实施例将对地图的请求格式化为对某些地图图块的请求。在一些实施例中,请求还为地图服务提供用于路线计算的开始位置(或当前位置)和目的位置。客户端设备还可请求地图服务渲染信息,诸如地图纹理或样式表。在至少一些实施例中,请求还为实施逐向导航的一系列请求中的一个请求。对其它几何形状数据的请求可包括但不限于对当前位置、无线网络覆盖、天气、交通信息或附近兴趣点的请求。
在一些实施例中,地图服务分析客户端设备请求以优化设备或地图服务操作。例如,地图服务可识别出客户端设备的位置在通信较差(例如,弱无线信号)的区域中并发送更多的地图服务数据以在通信丢失的情况下提供客户端设备或者发送指令以利用不同的客户端硬件(例如,取向传感器)或软件(例如,利用无线位置服务或Wi-Fi定位服务而不是基于GPS 的服务)。在另一个实例中,地图服务可针对基于矢量的地图图像数据来分析客户端设备请求并且根据图像的复杂度来确定基于光栅的地图图像数据更好地优化地图图像数据。其他地图服务的实施例可对客户端设备请求执行类似分析,并且因此上述实例并非旨在进行限制。
客户端设备(例如,客户端设备3902a-3902c)的各种实施例在不同的便携式多功能设备类型上实施。客户端设备3902a-3902c通过各种通信方法和协议来使用地图服务3930。在一些实施例中,客户端设备3902a-3902c 从地图服务3930获得地图服务数据。客户端设备3902a-3902c请求或接收地图服务数据。客户端设备3902a-3902c然后处理地图服务数据(例如,渲染和/或显示该数据)并且可将该数据发送至设备上的另一个软件或硬件模块或者发送至外部设备或系统。
根据一些实施例的客户端设备实施用于渲染和/或显示地图的技术。可以各种格式诸如上文所述的地图图块来请求或接收这些地图。客户端设备可在二维或三维视图中渲染地图。客户端设备的一些实施例显示所渲染的地图,并允许提供输入的用户、系统或设备操纵地图中的虚拟相机,从而根据虚拟相机的位置、取向和视场来改变地图显示。实施各种形式和输入设备以操纵虚拟相机。在一些实施例中,触摸输入通过某些单个或组合手势(例如,触摸并保持或轻扫)来操纵虚拟相机。其他实施例允许操纵设备的物理位置以操纵虚拟相机。例如,可将客户端设备从其当前位置向上倾斜以操纵虚拟相机向上旋转。在另一个实例中,可将客户端设备从其当前位置向前倾斜以向前移动虚拟相机。可实施客户端设备的其他输入设备,包括但不限于听觉输入(例如,所讲出的字词)、物理键盘、鼠标和/ 或操纵杆。
一些实施例提供对虚拟相机操纵的各种视觉反馈,诸如在从二维地图视图过渡至三维地图视图时显示可能的虚拟相机操纵的动画。一些实施例还允许用于选择地图特征或对象(例如,建筑物)以及将对象突出显示的输入,从而生成维持虚拟相机对三维空间的感知的模糊效果。
在一些实施例中,客户端设备实现导航系统(例如,逐向导航)。导航系统提供可向用户显示的方向或路线信息。客户端设备的一些实施例请求来自地图服务的方向或路线计算。客户端设备可从地图服务接收地图图像数据和路线数据。在一些实施例中,客户端设备实现逐向导航系统,该逐向导航系统基于从地图服务和/或其它位置系统诸如全球定位卫星(GPS)接收的位置信息和路线信息来提供实时路线和方向信息。客户端设备可显示反映客户端设备的当前位置的地图图像数据,并实时更新该地图图像数据。导航系统可提供听觉或视觉方向以沿循某条路线。
虚拟相机被实施为根据一些实施例操纵导航地图数据。在一些实施例中,客户端设备允许设备调整虚拟相机显示取向以朝向路线目的地偏置。一些实施例还允许虚拟相机通过模拟虚拟相机的惯性运动来导航转弯。
客户端设备实施各种技术以利用来自地图服务的地图服务数据。一些实施例实施一些技术以优化对二维和三维地图图像数据的渲染。在一些实施例中,客户端设备本地存储渲染信息。例如,客户端存储针对包含样式标识符的图像数据提供渲染方向的样式表。在另一个实例中,可存储常用的图像纹理以减少从地图服务传输的地图图像数据的量。不同实施例中的客户端设备实现渲染二维和三维地图图像数据的各种建模技术,建模技术的示例包括但不限于:从二维建筑物占有面积数据生成三维建筑物;对二维和三维地图对象建模以确定客户端设备通信环境;生成用于确定从某个虚拟相机位置是否可看到地图标签的模型;以及生成用于在地图图像数据之间平滑转变的模型。在一些实施例中,客户端设备还以某些技术来对地图服务数据排序或优先排序。例如,客户端设备检测虚拟相机的运动或速度,如果运动或速度超过某些阈值,则加载并渲染出某些区域的详细程度较低的地图数据。其它实例包括:将基于矢量的曲线渲染为一系列点,针对与地图服务具有较差通信的区域预先加载地图图像数据,基于显示缩放水平来调节纹理,或根据复杂性来渲染地图图像数据。
在一些实施例中,客户端设备利用与地图图块分离的各种数据格式来进行通信。例如,一些客户端设备实施辅助全球定位卫星(A-GPS)并与位置服务进行通信,该位置服务利用符合位置服务协议的数据格式,所述位置服务协议诸如但不限于无线电资源位置服务协议(RRLP)、用于码分多址 (CDMA)的TIA 801、无线电资源控制(RRC)定位协议或LTE位置协议 (LPP)。客户端设备还可直接接收GPS信号。实施例还可在或不在来自地图服务的恳求下发送识别客户端设备的能力或属性(例如,硬件规格或操作系统版本)或通信能力(例如,由无线信号强度或有线或无线网络类型所确定的设备通信带宽)的数据。
图39示出了用于地图服务3930和客户端设备3902a-3902c的操作环境 3900的一个可能的实施例。在一些实施例中,设备3902a,3902b和3902c 通过一个或多个有线或无线网络3910进行通信。例如,无线网络3910诸如蜂窝网络可通过使用网关3914与广域网(WAN)诸如互联网进行通信。在一些实施例中,网关3914提供面向分组的移动数据服务,诸如通用分组无线业务(GPRS),或允许无线网络将数据传输至其他网络诸如广域网的其他移动数据服务。同样,接入设备3912(例如,IEEE 802.11g无线接入设备)提供对WAN 1160的通信访问。设备3902a和3902b可为能够与地图服务进行通信的任何便携式电子或计算设备。设备3902c可为能够与地图服务教学通信的任何非便携式电子或计算设备。
在一些实施例中,语音通信和数据通信两者通过无线网络3910和接入设备3912来建立。例如,设备3902a可通过无线网络3910、网关3914以及WAN 1160来拨打和接收电话呼叫(例如,使用互联网语音协议(VoIP) 协议)、发送和接收电子邮件消息(例如,使用简单的邮件传输协议 (SMTP)或邮局协议3(POP3))以及检索电子文档和/或数据流,诸如网页、照片和视频(例如,使用传输控制协议/互联网协议(TCP/IP)或用户数据报协议(UDP))。同样,在一些具体实施中,设备3902b和3902c可通过接入设备3912和WAN 1160来拨打和接收电话呼叫、发送和接收电子邮件消息以及检索电子文档。在各种实施例中,所示客户端设备中的任一个客户端设备可使用根据一个或多个安全协议建立的永久性连接来与地图服务3930和/或其他一个或多个服务3950进行通信,所述安全协议诸如安全套接层 (SSL)协议或传输层安全(TLS)协议。
设备3902a和3902b还可以其他方式建立通信。例如,无线设备3902a 可通过无线网络3910与其他无线设备(例如,其他设备3902b、移动电话等等)进行通信。同样,设备3902a和3902b可通过使用一个或多个通信子系统诸如来自华盛顿柯克兰的蓝牙特别兴趣小组公司(Bluetooth Special Interest Group,Inc.(Kirkland,Washington))的通信来建立对等通信 3940(例如,个人局域网)。设备3902c还可与设备3902a或3902b建立对等通信(未示出)。也可实现其它通信协议和拓扑结构。设备3902a和 3902b还可从GPS卫星3960接收全球定位卫星(GPS)信号。
设备3902a,3902b和3902c可通过一个或多个有线和/或无线网络3912 或3910与地图服务3930进行通信。例如,地图服务3930可将地图服务数据提供给渲染设备3902a,3902b和3902c。地图服务3930还可与其他服务 3950通信以获得用于实施地图服务的数据。地图服务3930以及其他服务 3950还可从GPS卫星3960接收GPS信号。
在各种实施例中,地图服务3930和/或一个或多个其它服务3950被配置为处理来自任何客户端设备的搜索请求。搜索请求可包括但不限于对企业、地址、住宅位置、兴趣点、或它们的一些组合的查询。地图服务3930 和/或一个或多个其它服务3950可被配置为返回与多种参数相关的结果,这些参数包括但不限于输入到地址栏或其它文本输入字段中的位置(包括缩写和/或其它速记符号)、当前地图视图(例如,用户可能在驻留在一个位置中时在多功能设备上查看一个位置)、用户的当前位置(例如,在当前地图视图并不包括搜索结果的情况下)以及当前路线(如果存在的话)。在各种实施例中,基于不同的优先级权重,这些参数可影响搜索结果的组成(和/或搜索结果的排序)。在各种实施例中,所返回的搜索结果可为基于特定标准所选择的结果的子集,该特定标准包括但不限于搜索结果(例如,特定兴趣点)已被请求的次数、对与搜索结果相关联的质量的衡量 (例如,最高用户或编辑评论评级)、和/或搜索结果的评论量(例如,搜索结果被评论或评级的次数)。
在各种实施例中,地图服务3930和/或一个或多个其他服务3950被配置为提供自动完成的搜索结果,所述自动完成的搜索结果显示在客户端设备上,诸如在地图绘制应用程序内。例如,在用户在多功能设备上输入一个或多个搜索关键字时,自动完成的搜索结果可填充屏幕的一部分。在一些情况下,该特征可节省用户时间,因为可在用户输入完整的搜索查询之前显示所需的搜索结果。在各种实施例中,自动完成的搜索结果可为由客户端设备上的客户端找到的搜索结果(例如,书签或联系人)、由地图服务3930和/或一个或多个其他服务3950在其他地方(例如,从互联网)找到的搜索结果,和/或它们的一些组合。与命令的情形一样,可由用户经由语音或通过键入来输入任何搜索查询。多功能设备可被配置为在本文所述的任何地图显示内以图形方式显示搜索结果。例如,针状或其他图形指示符可将搜索结果的位置指定为兴趣点。在各种实施例中,响应于用户对这些兴趣点中的一个兴趣点的选择(例如,触摸选择诸如触击),该多功能设备被配置为显示与所选择的兴趣点有关的附加信息,该附加信息包括但不限于评级、评论或评论片段、操作时长、存储状态(例如,开始营业、永久性关闭等)和/或兴趣点的店面的图像。在各种实施例中,可在响应于用户对兴趣点的选择而显示的图形信息卡上显示任何此类信息。
在各种实施例中,地图服务3930和/或一个或多个其他服务3950提供一个或多个反馈机制以接收来自客户端设备3902a-1602c的反馈。例如,客户端设备可向地图服务3930和/或一个或多个其它服务3950提供关于搜索结果的反馈(例如,指定评级、评论、暂时或永久企业歇业、错误等的反馈);这种反馈可用于更新关于兴趣点的信息,以便在未来提供更准确或更新的搜索结果。在一些实施例中,地图服务3930和/或一个或多个其他服务3950可将测试信息(例如,A/B测试)提供至客户端设备以确定哪个搜索结果是最佳的。例如,客户端设备可以随机的时间间隔接收并向用户呈现两个搜索结果并且允许用户指示最佳结果。客户端设备可基于所选择的测试技术向地图服务3930和/或一个或多个其他服务3950报告测试结果以改进未来的搜索结果,所述测试技术诸如A/B测试技术,在该A/B测试技术中,将基线控制样本与各种单变量测试样本进行比较以便改进结果。
虽然已参考许多特定细节描述了本发明,但本领域的普通技术人员将认识到,可在不脱离本发明的实质的情况下以其它特定形式来体现本发明。因此,本领域的普通技术人员将理解,本发明不受前述示例性细节的限制,而是将由所附的权利要求所限定。

Claims (18)

1.一种预测设备的目的地的方法,所述方法包括:
从在所述设备上执行的多个应用程序中提取多个第一物理地址并且将所述多个第一物理地址存储在所述设备的数据存储装置中,其中所述设备是通过网络相关联的一组设备中的第一设备;
从服务器设备接收多个第二物理地址,所述多个第二物理地址是从所述一组设备中的第二设备提取的;
由所述第一设备的网络同步器将第一数据存储装置与驻留在所述第二设备上的第二数据存储装置同步;
基于至少一个因素来对所述第一数据存储装置中所存储的多个第一物理地址和多个第二物理地址中的每一个进行排序;
基于所述同步,生成不同于所述多个第一物理地址的机器生成的物理地址;
基于所述机器生成的物理地址,生成所述第一设备的预测目的地;
提供所预测的目的地到在所述第一设备上执行的应用程序;以及
显示(i)所述第一设备的表示,(ii)在所显示的地图上的所述预测的目的地的表示,(iii)显示关于所述预测的目的地的信息的显示区域,和(iv)用于发起进行去往所述预测的目的地的导航呈现的至少一个控件。
2.根据权利要求1所述的方法,其中所述多个应用程序包括电子票务应用程序,并且所提取的物理地址包括从由所述票务应用程序所存储的电子票中所指定的事件的位置中获取的地址。
3.根据权利要求1所述的方法,其中所述多个应用程序包括电子邮件应用程序、文本消息应用程序、日历应用程序、地图绘制应用程序和网络浏览应用程序。
4.根据权利要求1所述的方法,其中所述多个应用程序包括电子邮件应用程序,其中所述物理地址为从由所述第一设备的用户查看的电子邮件消息中获取的地址。
5.根据权利要求4所述的方法,其中所述电子邮件消息存储在所述用户的收件箱文件夹或发件箱文件夹中而非垃圾邮件文件夹中。
6.根据权利要求1所述的方法,其中所述至少一个因素包括:从其提取地址的应用程序的身份、地址的源的身份、对于从其提取地址的消息是否已被查看的判断、衰减因素、频率因素,或它们的组合。
7.根据权利要求6所述的方法,其中所述至少一个因素为第一组因素中的至少一个,所述方法进一步包括基于第二组因素来降低针对所述多个物理地址中的每个物理地址的排名,所述第二组因素包括与所述物理地址相关联的时间戳和源标识符。
8.根据权利要求7所述的方法,其中降低特定物理地址的所述排名包括基于自所述物理地址的所述时间戳的值所经过的时间长度来降低所述排名。
9.根据权利要求1所述的方法,其中所述多个应用程序包括地图绘制应用程序,其中所提取的物理地址包括由所述地图绘制应用程序接收并搜索的地址。
10.一种用于获取地址的设备,包括:
用于从在所述设备上执行的多个应用程序中提取多个第一物理地址并且将所述多个第一物理地址存储在所述设备的数据存储装置中的装置,其中所述设备是通过网络相关联的一组设备中的第一设备;
用于从服务器设备接收多个第二物理地址的装置,所述多个第二物理地址是从所述一组设备中的第二设备提取的;
用于由所述第一设备的网络同步器将第一数据存储装置与驻留在所述第二设备上的第二数据存储装置同步的装置;
用于基于至少一个因素来对所述第一数据存储装置中所存储的多个第一物理地址和多个第二物理地址中的每一个进行排序的装置;
用于基于所述同步生成不同于所述多个第一物理地址的机器生成的物理地址的装置;
用于基于所述机器生成的物理地址生成所述第一设备的预测目的地的装置;
用于提供所预测的目的地到在所述第一设备上执行的应用程序的装置;以及
用于显示(i)所述第一设备的表示,(ii)在所显示的地图上的所述预测的目的地的表示,(iii)显示关于所述预测的目的地的信息的显示区域,和(iv)用于发起进行去往所述预测的目的地的导航呈现的至少一个控件的装置。
11.根据权利要求10所述的设备,其中所述多个应用程序包括电子票务应用程序,并且所提取的物理地址包括从由所述票务应用程序所存储的电子票中所指定的事件的位置中获取的地址。
12.根据权利要求10所述的设备,其中所述多个应用程序包括电子邮件应用程序、文本消息应用程序、日历应用程序、地图绘制应用程序和网络浏览应用程序。
13.根据权利要求10所述的设备,其中所述多个应用程序包括电子邮件应用程序,其中所述物理地址为从被所述设备的用户查看的电子邮件消息中获取的地址。
14.根据权利要求13所述的设备,其中所述电子邮件消息存储在所述用户的收件箱文件夹或发件箱文件夹中而非垃圾邮件文件夹中。
15.根据权利要求10所述的设备,其中所述至少一个因素包括:从其提取地址的应用程序的身份、地址的源的身份、对于从其提取地址的消息是否已被查看的判断、衰减因素、频率因素,或它们的组合。
16.根据权利要求15所述的设备,其中所述至少一个因素为第一组因素中的至少一个,所述设备进一步包括用于基于第二组因素来降低针对所述多个物理地址中的每个物理地址的排名的装置,所述第二组因素包括与所述物理地址相关联的时间戳和源标识符。
17.根据权利要求16所述的设备,其中用于降低特定物理地址的所述排名的装置包括用于基于自所述物理地址的所述时间戳的值所经过的时间长度来降低所述排名的装置。
18.根据权利要求10所述的设备,其中所述多个应用程序包括地图绘制应用程序,其中所提取的物理地址包括由所述地图绘制应用程序接收并搜索的地址。
CN201480013892.7A 2013-03-15 2014-03-14 一种预测设备的目的地的方法以及用于获取地址的设备 Active CN105051495B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910672157.1A CN110388935B (zh) 2013-03-15 2014-03-14 获取地址

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
US201361800908P 2013-03-15 2013-03-15
US61/800,908 2013-03-15
US201361832853P 2013-06-08 2013-06-08
US201361832850P 2013-06-08 2013-06-08
US61/832,850 2013-06-08
US61/832,853 2013-06-08
US201361832928P 2013-06-09 2013-06-09
US61/832,928 2013-06-09
US201361875753P 2013-09-10 2013-09-10
US61/875,753 2013-09-10
US14/081,850 US20140365505A1 (en) 2013-06-08 2013-11-15 Harvesting Addresses
US14/081,850 2013-11-15
PCT/US2014/029841 WO2014145134A1 (en) 2013-03-15 2014-03-14 Harvesting addresses

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN201910672157.1A Division CN110388935B (zh) 2013-03-15 2014-03-14 获取地址

Publications (2)

Publication Number Publication Date
CN105051495A CN105051495A (zh) 2015-11-11
CN105051495B true CN105051495B (zh) 2019-07-23

Family

ID=54456444

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201480013892.7A Active CN105051495B (zh) 2013-03-15 2014-03-14 一种预测设备的目的地的方法以及用于获取地址的设备
CN201910672157.1A Active CN110388935B (zh) 2013-03-15 2014-03-14 获取地址

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN201910672157.1A Active CN110388935B (zh) 2013-03-15 2014-03-14 获取地址

Country Status (3)

Country Link
EP (1) EP2972104A1 (zh)
CN (2) CN105051495B (zh)
WO (1) WO2014145134A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10655979B2 (en) 2013-06-08 2020-05-19 Apple Inc. User interface for displaying predicted destinations
US9317813B2 (en) 2013-03-15 2016-04-19 Apple Inc. Mobile device with predictive routing engine
US9303997B2 (en) 2013-03-15 2016-04-05 Apple Inc. Prediction engine
US20140365459A1 (en) 2013-06-08 2014-12-11 Apple Inc. Harvesting Addresses
EP3362920A4 (en) * 2016-01-14 2018-12-05 Samsung Electronics Co., Ltd. Method and system for automatically managing content in an electronic device
CN108241746B (zh) 2018-01-09 2020-08-04 阿里巴巴集团控股有限公司 可视化公益活动的实现方法和装置
CN112115373B (zh) * 2020-11-23 2021-02-12 腾讯科技(深圳)有限公司 基于区块链的文件送达管理方法、装置、设备以及介质
CN113592401A (zh) * 2021-07-30 2021-11-02 上海寻梦信息技术有限公司 地址推荐方法、系统、设备及存储介质
CN116007642A (zh) * 2021-10-22 2023-04-25 华为终端有限公司 一种目的地导航方法及设备

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1692671A (zh) * 2002-10-10 2005-11-02 松下电器产业株式会社 信息取得方法、信息提供方法及信息取得装置
CN101297337A (zh) * 2005-09-29 2008-10-29 微软公司 采用开放和闭合世界建模方法从局部轨迹预测目的地的方法
JP2010230624A (ja) * 2009-03-30 2010-10-14 Nissan Motor Co Ltd 情報提供装置及び情報提供方法
CN102235865A (zh) * 2010-04-27 2011-11-09 神达电脑股份有限公司 利用个人导航装置预测路径的方法及相关的个人导航装置
CN102667403A (zh) * 2009-12-02 2012-09-12 三菱电机株式会社 导航装置
CN102692235A (zh) * 2011-03-20 2012-09-26 微软公司 对动态端点的导航
WO2012169152A1 (ja) * 2011-06-07 2012-12-13 日本電気株式会社 移動目的地予測装置、移動目的地予測方法および移動目的地予測プログラム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5946647A (en) * 1996-02-01 1999-08-31 Apple Computer, Inc. System and method for performing an action on a structure in computer-generated data
JP3698716B2 (ja) * 2003-02-25 2005-09-21 松下電器産業株式会社 アプリケーションプログラムの予測方法及び移動体端末
JP3669702B2 (ja) * 2003-02-25 2005-07-13 松下電器産業株式会社 アプリケーションプログラムの予測方法及び移動体端末
US7831384B2 (en) * 2004-10-29 2010-11-09 Aol Inc. Determining a route to destination based on partially completed route
US20060179277A1 (en) * 2005-02-04 2006-08-10 Flachs Brian K System and method for instruction line buffer holding a branch target buffer
EP1944724A1 (en) * 2007-01-11 2008-07-16 Harman Becker Automotive Systems GmbH Method for destination setting for a navigation system
US8798914B2 (en) * 2009-01-13 2014-08-05 Qualcomm Incorporated Navigating at a wireless device
US8392116B2 (en) * 2010-03-24 2013-03-05 Sap Ag Navigation device and method for predicting the destination of a trip
US9163952B2 (en) * 2011-04-15 2015-10-20 Microsoft Technology Licensing, Llc Suggestive mapping

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1692671A (zh) * 2002-10-10 2005-11-02 松下电器产业株式会社 信息取得方法、信息提供方法及信息取得装置
CN101297337A (zh) * 2005-09-29 2008-10-29 微软公司 采用开放和闭合世界建模方法从局部轨迹预测目的地的方法
JP2010230624A (ja) * 2009-03-30 2010-10-14 Nissan Motor Co Ltd 情報提供装置及び情報提供方法
CN102667403A (zh) * 2009-12-02 2012-09-12 三菱电机株式会社 导航装置
CN102235865A (zh) * 2010-04-27 2011-11-09 神达电脑股份有限公司 利用个人导航装置预测路径的方法及相关的个人导航装置
CN102692235A (zh) * 2011-03-20 2012-09-26 微软公司 对动态端点的导航
WO2012169152A1 (ja) * 2011-06-07 2012-12-13 日本電気株式会社 移動目的地予測装置、移動目的地予測方法および移動目的地予測プログラム

Also Published As

Publication number Publication date
EP2972104A1 (en) 2016-01-20
CN105051495A (zh) 2015-11-11
WO2014145134A1 (en) 2014-09-18
WO2014145134A4 (en) 2014-11-27
CN110388935B (zh) 2023-04-28
CN110388935A (zh) 2019-10-29

Similar Documents

Publication Publication Date Title
CN105051495B (zh) 一种预测设备的目的地的方法以及用于获取地址的设备
US10769217B2 (en) Harvesting addresses
CN105191387B (zh) 用于具有逐向导航模式的地图绘制应用程序的方法和装置
JP5871976B2 (ja) ナビゲータとしてのモバイルイメージング装置
EP1987683B1 (en) User-defined private maps
CN104335268B (zh) 用于为地图视图改变提供三维过渡动画的方法、系统和装置
CN107710197A (zh) 在通信网络上共享图像和图像相册
US20070200713A1 (en) Method and system for communicating with multiple users via a map over the internet
EP2262258A2 (en) Mobile terminal, server device, information processing system, display control method, and program
CN105793809A (zh) 通信用户界面系统和方法
CN104981681A (zh) 显示位置预览
CN110020218A (zh) 服务信息展示方法及装置
CN107004007A (zh) 多元搜索及搜索中的多任务
JP5979771B1 (ja) 経路検索システム、経路検索装置、経路検索方法、プログラム、及び情報記憶媒体
CN109313746A (zh) 到电子邮件系统中的位置集成
US20200293998A1 (en) Displaying a countdown timer for a next calendar event in an electronic mail inbox
US20140351680A1 (en) Organizing unstructured research within a document
Shih Augmented-Life Phone Organizer

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant