Classifications

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

Definitions

• Some embodiments of the invention provide an address harvester that harvests addresses from one or more applications executing on a device. Some embodiments use the harvested addresses to facilitate the operation of one or more applications executing on the device. Alternatively, or conjunctively, some embodiments use the harvested addresses to facilitate the operation of one or more applications executing on another device than the one used for harvesting the addresses.
• the harvested addresses are different in different embodiments.
• they include telecommunication (telecom) addresses that are used for telecommunication messages.
• Examples of such addresses include telephone numbers that are used for phone calls and/or text messages (e.g., text messages sent along the SMS or iMessage text service, etc.), and electronic mail (email) addresses that are used for email messages or text messages.
• the harvested telecom addresses include several telecom addresses (e.g., several email addresses and/or telephone numbers) that are used to send an email message and/or text message to several recipients at once.
• harvested telecom addresses use harvested telecom addresses to predict and display candidate recipient or recipients for a telecom message as a user is inputting the recipient or recipient list for the message.
• the harvested telecom addresses can be used to augment the recipient data storage (e.g., database) that a voice recognition application uses to prepare telecom message or initiate a telecom session (e.g., a phone call or video conference) in response to voice instructions.
• the harvesting system of some embodiments harvests addresses in the physical world.
• harvested addresses include physical addresses that are harvested from email message, text message, calendared events, electronic tickets, etc.
• these harvested addresses include physical addresses that a user of the device browses in a web browser or a map application that executes on the device. Such browsing entails searching for the addresses, viewing the addresses, and/or using the addresses to specify a route to view or navigate.
• Some embodiments use the harvested physical addresses to formulate predictions about future destinations of the device's user, and then provide information to the user based on these predictions. To formulate these predictions, some embodiments employ one or more machine- learning engines to generate additional physical addresses to augment the set of physical addresses that they use to base their predictions.
• Some embodiments employ a ranking engine to compute a ranking score for each harvested address (e.g., each telecom address and each physical address) or each harvested address of a certain type (e.g., physical addresses).
• a decay engine to decay the computed ranking score for a harvested address over time.
• some embodiments use the harvested addresses to facilitate the operation of one or more applications executing on another device than the one used for harvesting the addresses.
• this other device communicatively connects with the harvested device through a network, and it receives the harvested addresses through this connection.
• the two devices are associated with each other (e.g., are associated with the same account) through a cloud server infrastructure that temporarily stores harvested addresses from one device before relaying it to the other device.
• the cloud infrastructure relieves the two devices from having to establish a real time communication session in order to download harvested addresses from one device to the other.
• this infrastructure simplifies the process of creating duplicate, distributed data storages (e.g., databases) on different devices to store addresses that are harvested on different devices.
• Figure 1 illustrates an address harvesting architecture of a device of some embodiments of the invention.
• Figure 2 illustrates examples of ranking and decay engines that some embodiments use to prioritize the storing of the harvested addresses.
• Figure 3 illustrates an example of a harvesting architecture that can use the addresses that are harvested on one device to facilitate the operation of one or more applications executing on another device.
• Figure 4 presents an example that illustrates various telecom addresses being harvested on a device.
• Figure 5 illustrates an architecture for harvesting telecom addresses and storing these addresses in address storages.
• FIGS 8-11 provide four examples of how the harvested addresses can be used to provide predicted recipients for telecom messages.
• Figures 12 and 13 illustrate a matching engine of the device of some embodiments and the process performed by this engine to match user input to telecom addresses stored in the address storage.
• Figure 14 illustrates different sets of records that are retrieved and presented in a sorted order based on different input strings as a user types a recipient's email address.
• Figure 18 illustrates an example of publishing a physical address to the map application, and in the process harvesting this physical address for storage in the address storage.
• Figure 19 illustrates an example of harvesting a physical address in response to a user searching for the address in a map application executing on a mobile device.
• Figure 20 illustrates an example of harvesting a physical address in response to a user identifying a route with the map application of the mobile device.
• Figure 21 illustrates an example of harvesting a physical address in response to a selection of a point of interest (POI) on a map presented by the map application of the mobile device.
• POI point of interest
• Figure 22 illustrates an example of harvesting a physical address from a calendar application.
• Figure 23 illustrates an example of harvesting a physical address from a calendar invitation.
• Figure 24 conceptually illustrates an architecture of some embodiments for storing and decaying addresses.
• Figure 25 illustrates an example of a mobile device that uses the harvested physical addresses to predict future routes, which it presents to a user through a vehicle display.
• Figure 26 illustrates an example of the scrolling through multiple predicted routes that are generated based on harvested data.
• Figure 28 illustrates an example where a mobile device bases its predictions on an address that is harvested on another device.
• Figures 29-31 illustrate several example of how some embodiments present traffic notification based on a harvested or machine generated physical address.
• Figure 32 illustrates the use of the voice recognition function of some embodiments on a mobile device to recognize a recipient e-mail address that was previously harvested and stored in an address history data storage.
• Figure 33 illustrates a vehicle display screen over several stages in which a user activates a messaging function and dictates a message to a recipient.
• Figure 34 conceptually illustrates a multi-device process of some embodiments for distributing harvested data from one device to another across a server infrastructure.
• Figure 35 conceptually illustrates a more detailed example of an architecture of a device of some embodiments that performs such harvesting and prediction.
• Figure 36 illustrates multiple harvested address data storages of a device synchronizing with one or more devices through the server infrastructure.
• Figure 37 is an example of an architecture of a mobile computing device of some embodiments of the invention.
• Figure 38 conceptually illustrates another example of an electronic system with which some embodiments of the invention are implemented.
• Figure 39 illustrates a map service operating environment according to some embodiments.
• Some embodiments of the invention provide an address harvester that harvests addresses from one or more applications executing on a device. Some embodiments use the harvested addresses to facilitate the operation of one or more applications executing on the device. Alternatively, or conjunctively, some embodiments use the harvested addresses to facilitate the operation of one or more applications executing on another device than the one used for harvesting the addresses.
• FIG. 1 illustrates a novel address harvesting architecture 100 of a device of some embodiments of the invention.
• the harvesting architecture 100 includes an address harvester 105, a harvested address data storage 110, several prediction engines 115, and several applications 120- 138.
• the harvested address storage 110 stores addresses that the address harvester 105 harvests from some of the applications.
• the harvested addresses are different in different embodiments. For the embodiments illustrated in Figure 1, they include telecommunication (telecom) addresses for telecommunication messages and physical addresses of locations in the physical world.
• harvested telecom addresses include (1) telephone numbers that are harvested from phone calls and/or text messages (e.g., text messages sent along the SMS or iMessage text service, etc.), and (2) electronic mail (email) addresses that are used for email messages or text messages. Also, in some embodiments, the harvested telecom addresses include several telecom addresses (e.g., several email addresses or telephone numbers) that were used to send an email message or text message to several recipients at once.
• One factor is the identity of the application that provided the content for harvesting to the address processor 205. Certain applications (e.g., messaging applications) result in a higher ranking score for their harvested addresses than other applications (e.g., email applications).
• Another factor in some embodiments is the identity of the person who sent the message that is being harvested. For instance, addresses harvested from telecom messages from individuals in the device's address book or list of favorites are ranked higher than addresses harvested from messages from individuals not in the address books or list of favorites.
• Another factor in some embodiments is whether the message (e.g., email) that is being harvested has been viewed. If so, the address that is harvested from this message (this email) will have a higher ranking than the address that is harvested from a message (e.g., another email) that has not been viewed.
• an address harvester 402 of the device 400 receives a single email address for Jerome Smith that was used for an email message.
• the address harvester 402 in this operation stores the received email address in the harvested address data storage 405.
• the address harvester 402 receives three email addresses (for Jerome Smith, Paul Li, and Emma Smith) that are used for another email message.
• the email addresses for Paul Li and Emma Smith are new and get stored as new email addresses.
• the email address for Jerome was previously captured in the first harvesting operation 410. Accordingly, it does not need to be individually stored again as it is already stored in the harvested address data storage 405.
• the harvested address data storage 405 has not yet created a group number association for the group involving the three numbers captured in the fourth harvesting session.
• the address harvester 402 creates and stores in the harvested address data storage 405 an association to identify the three telephone numbers captured in the fourth stage as an associated group of numbers.
• Different embodiments specify groups differently in the address storage 405 and recognize groups based on different criteria. The creation of groups of associated telephone numbers is further described below.
• the address processor 530 uses (at 610) the query engine 540 to determine whether the received address is stored in either of the individual storages 505 or 510. If not, it directs (at 615) the query engine 540 to create a new record for the received address in either the email address data storage 505 when the address is an email address, or in the telephone number data storage 510 when the address is a telephone number.
• the address processor 530 determines (at 705) that the address was not part of a group message, it ends. Otherwise, it uses (at 710) the query engine 540 to determine whether this group was previously received for another message. For this task, the query engine 540 determines whether the intersection of all the group IDs of all the addresses in the group identified at 705 is an empty set or is a set with one group ID. When the intersection is an empty set, then the query engine ascertains that the group was not previously specified. Otherwise, when the intersection is a single group ID, then the query engine determines that the group was previously specified.
• a record 590 of a group includes a group ID 592 to identify the group, an address array 594 to identify the address ID of each address in the group (where the address ID specifies the address' record in an individual address storage 505 and 510), a time array 594 to specify up to M time values for up to M most recent time instances that the group was received, and a ranking score 596 for the group.
• the user of computer 850 in Figure 8 similarly inputs "J" as the recipient of an email message.
• the input processor 820 relays "J" to the matching engine 825, which then matches it to the individual email for Jerome Smith, as well as the email group Jerome Smith, Paul Li, and Emma Smith.
• the matching engine 825 directs the input processor 820 to present simultaneously two selectable candidate recipient sets, one that includes only Jerome Smith's email, and another that includes the emails of Jerome Smith, Paul Li, and Emma Smith.
• the user of the device 400 at some time after time A inputs "55" as the recipient of a text message.
• the input processor 810 relays "55" to the matching engine 805, which then matches it to the individual telephone number 555-123-4567, as well as the telephone number group that includes this number along with 555-987-6543 and 555-321-5678.
• the matching engine 805 directs the input processor 810 to present simultaneously two selectable candidate recipient sets to the user.
• One recipient set includes only 555-123-4567, while the other includes 555-123-4567, 555-987-6543, and 555-321-5678.
• the user of computer 950 in Figure 9 similarly inputs "55" as the recipient of a text message.
• the input processor 820 relays "55" to the matching engine 825, which then matches it to the individual telephone number 555-123- 4567, as well as the telephone number group that includes this number along with 555-987-6543 and 555-321-5678.
• the matching engine 825 directs the input processor 820 to present simultaneously two selectable candidate recipient sets, one that includes only 555-123- 4567, and another that includes 555-123-4567, 555-987-6543 and 555-321-5678.
• the user of computer 1150 in Figure 11 similarly inputs "555- 9" in an invite list for a video conference.
• the input processor 820 uses the matching engine 825 to match the input to two different invitee sets (one that includes only 555-987-6543, and another that includes 555-987-6543, 555-321-5678 and the email address of Jerome Smith) that it presents simultaneously as two selectable candidate invitee sets to the user.
• the process 1300 cannot find (at 1310) any matching record, it ends. Otherwise, it aggregates (at 1315) any matching individual telecom address or group telecom address. It then directs (at 1320) the input processor to present the aggregated set of matching telecom addresses to the application that supplied the input, so that the application can present this set to the user. As mentioned above, some embodiments present the set of matching telecom addresses to the user with each matching telecom address as a selectable option in a list. Also, some embodiments present the matching telecom addresses in the set based on a particular sorted order. Several manners for presenting matching telecom addresses according to sorted orders will be described further below.
• the process 1300 receives another input from the input processor. It determines (at 1330) whether this input was a selection of one of the matching telecom addresses in the set provided at 1320. If so, the process ends. Otherwise, the process determines (at 1335) whether the combination of the new and old user input specifies an address that still matches one or more records in the address storage. If not, the process ends. Otherwise, the process filters (at 1340) the previously aggregated set of matching telecom addresses to only keep the set of telecom addresses that match the new address or addresses specified by the user input. The filtered set of matching telecom addresses becomes the next aggregated set of matching telecom addresses. The process then returns to 1320 where it directs the input processor to present this new aggregated set of matching telecom addresses to the application that supplied the input, so that the application can present this set to the user.
• the prediction engine e.g., the input processor of Figures 8-11
• the prediction engine identifies the stored individual and group telecom addresses that match the user input. It then puts these matching addresses in a sorted order and presents these addresses according to this order, so that the user can select one of them to complete the input of the recipient list.
• some embodiments compute ranking scores for individual and group telecom addresses and use this ranking score to create the sorted order (e.g., a sorted list) of the matching telecom addresses for the user.
• Different embodiments use different techniques to create a ranking score. For instance, some embodiments base this ranking score on the frequency of use of the individual or group addresses. Others base the ranking score for each telecom address record based on this record's timestamps that shows how recently this record was updated. Still other embodiments compute the ranking score for a telecom address record based on both the frequency of use of the telecom address in sent messages, and its record's timestamps that specify how often the telecom address was used recently.
• the ranking engine 535 periodically examines the telecom address records in the email address, telephone number and/or group address tables and updates the ranking score of each record.
• some embodiments use these timestamps to make decisions regarding the sorted order, while other embodiments use the timestamps to compute real-time scores that they then use to determine the order.
• the timestamps are used to not only quantify how frequently an individual address has been used, but also to quantify how recently the address has been used. The combination of these two factors is referred to as Frecency in the discussion below.
• Frecency For the retrieved telecom address records, some embodiments use the two factors to compute Frecency scores, which are then used to sort the address records for display. Other embodiments, however, use these two factors (i.e., use the Frecency of the address records) to make decisions regarding the sorted order.
• the address harvester stores up to 5 timestamps for each individual telecom address that indicate the 5 most recent instances in time that the address was used.
• the input processor first presents the addresses that have been received 5 times, then presents the addresses that have been received 4 times, then presents the addresses that have been received 3 times, and so on.
• the input processor sorts the addresses that have been received most recently (i.e., that have the latest timestamp) higher on the order.
• the input processor in these embodiments deviates from these sorting rules only (1) for matching address groups, and (2) for addresses that match the input string exactly. As mentioned above, the input processor in some embodiments moves a matching address group along the sorted order to appear next to the highest ordered individual address in the group.
• Jack Lindsey's individual and group addresses are displayed first, followed by John Lin's individual and group addresses, and then followed by Harry Lind's email address.
• Harry is at the bottom of the sorted list because his email has been less frequently used (4 times) than the emails of John and Jack (5 times).
• Jack's email address is higher on the list because Jack's email address has the latest timestamp.
• the second stage 1410 shows that for the new search string "Lin,” the same three individual records and two group records have been retrieved. However, the sorted order in this stage has been modified to put John's individual and group email addresses higher than Jack's because John's last name is a perfect match for the current input string. This perfect match trumps the more recent use of Jack's email address.
• the third stage 1415 shows that the input processor receives a modified set of records for the new search string "Lind.” This set of records no longer includes John Lin's records as Lin no longer is a match of the input string Lind. Also, the third stage shows that the sorted order has been modified to put Harry's individual email addresses higher than Jack's because Harry's last name is a perfect match for the current input string. This perfect match trumps the more recent use of Jack's email address and the more frequent use of Jack's email address.
• Jack's individual and group email addresses higher than Harry's email address in the sorted list because Jack's email address has a higher frequency of use.
• the address harvester of some embodiments harvests and stores physical addresses.
• harvested addresses include physical addresses that are harvested from email message, text message, calendared events, electronic tickets, etc.
• these harvested addresses include physical addresses that a user of the device browses with a web browser or a map application that executes on the device. Such browsing entails searching for the addresses, viewing the addresses, and/or using the addresses to specify a route to view or navigate.
• Figure 16 illustrates the address harvester 105 of a computer 1600 capturing physical addresses in an email and a text message that it receives. Although the addresses are harvested from received messages in this figure, one of ordinary skill will realize that the address harvester 105 harvests physical addresses in sent messages as well in some embodiments.
• the second stage 1604 illustrates a difference between the harvesting emails on computers and on mobile devices in some embodiments. Specifically, unlike the harvester 105 of the mobile device 1500 that does not download and search through an unread email to harvest physical addresses, the harvester 105 of the computer 1600 downloads and searches through an unread email to capture any physical address mentioned in the email. Accordingly, the second stage 1604 shows two harvesting operations 1622 and 1624 that the harvester 105 performs on the unread email 1630 to capture two physical addresses 1662 and 1664 and store these addresses in the address storage 110.
• the harvester 105 does not review all emails but only reviews certain emails. For instance, the harvester 105 of some embodiments does not review any emails that are marked as junk emails (e.g., in junk email folder) but only reviews other emails (e.g., in the inbox folder, in the sent folder, etc.).
• the example illustrated in Figure 17 is shown in four stages 1702, 1704, 1706, and 1708.
• the first stage 1702 shows the email 1630 along with several other emails in an inbox of an email application 1700.
• the email 1630 has not yet been read.
• this email is from a person who is in a list of individuals recognized by the email application.
• the list of recognized individuals includes people who the user of the application has designated as very important people (VIPs) or favorite people. Instead of, or in addition to, these people, the list of recognized individuals includes people who are in the address book, contact list, or other electronic rolodex of the computer.
• VIPs very important people
• the list of recognized individuals includes people who are in the address book, contact list, or other electronic rolodex of the computer.
• the second stage 1704 shows the email 1630 after it has been opened for reading.
• This stage also shows the selection of the physical address 1662 with a location indicator 1720.
• the location indicator is a cursor controlled by a cursor controller, but in other embodiments it can be any location indicator. For instance, it can be a visible or invisible touch indicator of a touch sensitive screen of the device 1700.
• the third stage 1706 shows that the selection of the physical address results in the display of a contextual menu 1722.
• This menu has several options, one of which provides for the viewing of the physical address in a map.
• the third stage 1706 shows the selection of the view map option 1724 in the menu.
• Viewing physical addresses in emails is not the only mechanism for harvesting a physical address and adding it to the address storage with a ranking score to indicate the user's particular interaction with it.
• address records can be created by publishing physical addresses to the maps application, or by viewing, searching, or routing to such addresses in the maps application.
• Figure 18 illustrates an example of publishing a physical address to the map application, and in the process harvesting this physical address for storage in the address storage 110.
• This example shows the address being published to a Bookmark or Recents table 1808 of a maps application through a selection that is made in a web browser that executes on a mobile device 1800.
• a Bookmark table is a table that contains a number of locations on a map that are Bookmarked by the application or a user.
• the Recents table is a table that contains recent locations or routes searched by the map application.
• Figure 18 illustrates its example in three stages 1802, 1804, and 1806 of interactions with the browser 1810.
• the first stage 1802 presents the browser showing a first webpage 1810 of a website of a Tee-Cake Bakery. This stage also shows the user's touch selection of a contact option on this page through a touch-sensitive screen of the device 1800.
• This selection causes the browser to show a second webpage 1812, as shown by the second stage 1804.
• the second webpage 1812 shows contact information about the bakery.
• the user touch selects the address 1816 of the bakery.
• This selection causes the browser to show a contextual menu 1830 that includes an Add to Maps option 1832.
• the third stage 1806 shows the user touch-selecting of the Add to Maps option 1832. It also shows that this selection causes the address of the bakery to be stored in the table 1808 of the maps application.
• the browser directs the map application to store this address in its table 1808, while in other embodiments it directly stores this address in this table.
• the table 1808 in some embodiments is the bookmark table of the maps application, while in other embodiments it is the Recents table of the map application.
• the third stage 1806 shows that in addition to causing the storage of the bakery's address in the table 1808, the selection of the Add to Maps application option 1832 also causes the address to be harvested and added to a harvested address data storage 110. This address is added to the data storage 110 with a high rank because the user made a conscious choice to add it to the Bookmark or Recents table 1808 of the map application.
• the browser when the browser is directed to send this address to the map application, the browser also sends this address to the address harvester of the device, which then stores this address in the data storage 110.
• the address is only stored in the table 1808, but the table 1808 is part of a set of storages (e.g., tables, databases, etc.) that collectively form a harvested address data storage that a set of prediction engines of the device uses to retrieve addresses for formulating prediction.
• the address is first stored in the table 1808, and from this storage, it is then transferred to the address storage 110.
• Figure 19 illustrates an example of harvesting a physical address in response to a user searching for the address in a map application executing on a mobile device 1900. This example is illustrated in three stages 1902, 1904, and 1906 of interactions with the map application 1910. Each of these stages also shows the state of the Recents table 1908 of the map application.
• the second stage 1904 shows the search field 1912 populated with an address "1149 Foothill Road.” It also shows the user selecting the search option 1916 to direct the map application to search for the entered address. The second stage 1904 further shows that the Recents table 1908 still only contains the same two addresses that it contained in the first stage.
• the third stage 1906 shows the map application after it displays the searched address, 1149 Foothill Road. This stage also shows that the search resulted in the addition of this address to the Recents table 1908 of the map application.
• this table is part of a set of storages (e.g., tables, databases, etc.) that collectively form a harvested address data storage or databases.
• the set of prediction engines of the device 1900 retrieve harvested address data from the set of storages in order to formulate predictions.
• the prediction engine(s) instead of having the prediction engine(s) use the Recents table 1908, other embodiments copy the addresses in the Recents table 1908 into a harvested address storage, which is accessed by the prediction engine(s). Similar to the previous example, the address may be added to the address storage with a high rank because the user made a conscious choice to search for it with the map application.
• Figure 20 illustrates an example of harvesting a physical address in response to a user identifying a route with the map application 1900 of the mobile device 1900. This example is illustrated in three stages 2002, 2004, and 2006 of interactions with the map application 1910. Each of these stages shows the state of the Recents table 1908 of the map application.
• the first stage 2002 shows the user touch-selecting the direction tool 1942 of the map application 1910 through a touch-sensitive screen of the device 1900. Similar to the previous example, the first stage shows that the Recents table 1908 only stores two addresses. To input a route, the user selects a route button 1942 that is next to the search field 1912.
• the second stage 2004 shows a page 2050 of the map application.
• This page contains two fields 2052 and 2054 in which the start and end of the route can be specified. It also allows the mode of transit to be selected. The transit modes include transit by walking, by bus, and by car.
• the second stage 2004 shows that the start and end of the route have been designated as the current location of the device and 777 State Street, respectively. It also shows the user selecting the route option 2016 to direct the map application to search for the specified route.
• the second stage 2004 further shows that the Recents table 1908 still only contains the same two addresses that it contained in the first stage 2002.
• the third stage 2006 shows the map application after it displays three routes between the specified start and end location. Specifically, the three routes are shown by lines connecting the two pins that represent the start and end locations.
• This stage 2006 also shows that the destination address has been added to the Recents table 1908 of the map application.
• this table in some embodiments is part of a set of storages (e.g., tables, databases, etc.) that collectively form a harvested address storage from which the device's set of prediction engines retrieve addresses to formulate predictions. Other embodiments, however, copy the addresses in the Recents table 1908 into a harvested address storage, which is accessed by the prediction engine(s).
• Figure 21 illustrates an example of harvesting a physical address in response to a selection of a point of interest (POI) on a map presented by the map application 1900 of the mobile device 1900.
• This example is illustrated in three stages 2102, 2104 and 2106 of interactions with the map application 1910. Each of these stages also shows the state of the Recents table 1908 of the map application.
• POI point of interest
• the first stage 2102 shows that the map application has been opened to display a map 2114.
• the mapped location includes a POI 2112.
• the POI is shown with an icon that provides a visual indication of the type of POI (e.g., a restaurant, a bar).
• the user touch-selects the POI 2112 on the map 2114 presented by the map application 1910.
• the first stage 2102 also shows that the Recents table 1908 only stores two addresses at this point.
• the second stage 2104 shows a banner 2116 opening above the selected POI to provide some information about the POI.
• the banner includes the name of the establishment and the estimated time it takes to reach it using a particular mode of transit.
• On the right-hand side of the banner is an info arrow 2128 that can be selected to display additional information regarding the POI.
• the user selects the info arrow 2128.
• the second stage 2104 further shows that the Recents table 1908 still only contains the same two addresses that it contained in the first stage 2102.
• the third stage 2106 shows an info page 2130 that the map application presents in order to provide additional information about the selected POI.
• This stage 2106 also shows that the selection of the info arrow 2128 and the presentation of the info page 2130 has resulted in the addition of the POFs address to the Recents table 1908 of the map application.
• this table in some embodiments is part of a set of storages (e.g., tables, databases, etc.) that collectively form a harvested address storage from which the device's set of prediction engines retrieve addresses to formulate predictions. In other embodiments, however, the addresses in the Recents table 1908 are copied into a harvested address storage, which is accessed by the prediction engine(s).
• some embodiments specify a ranking score that is specified for new addresses that are copied from the Recents table to the harvested address storage.
• the source of this address i.e., factor that this address has come from the Recents table of the map application and hence was probably viewed recently by a user
• the relative contributions of these addresses to the predictions can be adjusted by appropriately weighting them in comparison with addresses from other sources.
• the address harvester 105 of some embodiments harvests addresses from event invitations.
• Figure 23 illustrates an example of harvesting a physical address from a calendar invitation 2300. This invitation 2300 might have been opened with the calendar application or an email application (e.g., if the calendar is integrated as part of the email application).
• the invitation is shown with (1) the name of the event, the (2) location of the event, (3) the event's start time, and (4) the end time.
• the event includes several options, including showing the map of the location, setting an alarm, accepting the invitation, declining it, etc.
• Each of the start and end time is shown with a date and time.
• the location of the event is shown with its physical address in the body of the invitation.
• the address harvester 105 has extracted the physical address from the invitation and stored this address in the harvested address data storage 110.
• the address harvester 105 might have analyzed or parsed the invitation to identify the location field to extract the physical address.
• each calendared event is associated with time and/or date.
• some embodiments increase the ranking score of a physical address that is harvested from the event appointment or from the event invite in the calendar application. This increase in the ranking score will make it more likely that the physical address will be used to provide useful predictions to a user, e.g., used to provide predicted routes, provide relevant traffic information, provide prioritized list of addresses, etc.
• some embodiments reduce the ranking score of such a physical address or remove it altogether from the address storage.
• some embodiments store ranking scores with the harvested addresses. These ranking scores may be used, for various operations, to determine which addresses a user is most likely to want (e.g., to which address a user would most likely be traveling). Some embodiments use a decay function to modify these rankings over time. The decay function of some embodiments primarily adjusts a ranking score downward over time, as newer addresses are generally considered more likely to be useful, all else being equal. Eventually, the decay function indicates that an address should be removed from the address history.
• Figure 24 conceptually illustrates an architecture 2400 of some embodiments for storing and decaying addresses. In some embodiments, these may be both physical and telecommunications addresses. Other embodiments only rank and perform decaying of one of these types of addresses (e.g., physical addresses) or the other type of addresses.
• the architecture 2400 includes an address harvester 2405, a set of applications 2410, an address extractor 2415, and a decay engine 2420. Furthermore, the system includes map address history 2425 and address history 2430.
• the address harvester 2405 receives both addresses and content from the applications 2410, in some embodiments, and stores both physical and telecommunications addresses in the address history 2430. For example, from scheduling applications (e.g., a calendar application, an electronic ticketing application, etc.), the address harvester directly receives physical addresses to harvest. Furthermore, from electronic messaging applications (e.g., SMS and e-mail applications), the address harvester receives phone numbers and e-mail addresses from which messages are received and to which messages are sent.
• scheduling applications e.g., a calendar application, an electronic ticketing application, etc.
• electronic messaging applications e.g., SMS and e-mail applications
• the address harvester 2405 additionally receives content from these electronic messaging applications. Both e-mails and text messages may include physical addresses as part of their content. Thus, the address harvester 2405 uses the address extractor 2415 to identify addresses (e.g., based on their formatting) in content received from the electronic messaging applications. From these and other applications (e.g., map application), the address harvester also receives in some embodiments indications that the user has searched for, routed to, viewed, etc. certain addresses or certain entities at those addresses.
• addresses e.g., based on their formatting
• the address harvester 2405 stores the received and extracted addresses, and received or deduced information about these addresses, in one or more table in data storage 2430.
• each address entry in the address history data storage 2430 includes various data about the harvesting of the address. For instance, in the example shown, each address includes a sender value, the address, a time stamp, and a source identifier. These values are used by the address harvester 2405 to compute an initial ranking.
• the sender field in some embodiments indicates, for an address harvested out of an electronic message, whether the sender of the message is known. This field may be more gradated in some embodiments. For example, the sender field could be divided into unknown, regular contacts, and more important contacts (which might be determined by user categorization or frequency of received messages).
• the time stamp field stores a time that the address was received by its source application, in some embodiments. For example, addresses received in an e-mail or text message store the time of that text message. Addresses from a web browser store the time that the user selected in the web browser to store the address. The source identifier field stores an indicator of from which of the applications 2410 the address was harvested. In the example, the first listed address is from a text message, while the other two addresses are from e-mails. In some embodiments, additional fields may be stored for at least some types of addresses. For instance, addresses from a calendar event may store the time of the calendar event rather than the time the address was received.
• the ranking in some embodiments, is initially calculated by the address harvester 2405 according to a set of heuristics. These heuristics assign a score to each address based on various factors. As examples, addresses from known senders are scored higher (e.g., assigned a lower number) than addresses from unknown senders. Some embodiments treat addresses from text messages as more important than addresses from e-mail messages. Addresses for a scheduled event may be assigned a low score if the associated event is far off, but a high score if the event is soon upcoming. Some embodiments, rather than storing numerous fields, only store the time stamp and ranking for addresses. The decay engine 2420 periodically re-scores the addresses stored in the address history data storage 2430 according to one or more decay functions.
• This example shows the decay engine 2420 retrieving an address that has a ranking score of 20 (a high ranking) and readjusting the address to a score of 5 (a lower ranking).
• Some embodiments automatically adjust addresses downwards over time until a particular period of time after the time stamp (e.g., one day).
• Some embodiments have different decay functions for different types of addresses. For example, because text messages are a more immediate form of communication, addresses from text messages might start out with a higher ranking than addresses from e-mail, but decay more quickly.
• An address for a scheduled event might start with a very low ranking until shortly before the scheduled event, then be adjusted to a very high ranking for a particular period of time (e.g., 3 hours, 6 hours, 12 hours, 24 hours) before the event, and immediately be removed after the time of the event.
• the architecture 2400 additionally includes a map address history 2425.
• a mapping application operating on the device stores recently used addresses (e.g., search results, destinations to which a route was generated, etc.).
• the address harvester 2405 retrieves these physical addresses from the map address history 2425 and stores the retrieved addresses in the system- wide address history 2430.
• the map history 2425 is maintained separately, and it is accessed separately by the prediction engines of some embodiments. This will be further described by referenced to Figure 36.
• Some embodiments use the harvested physical addresses to formulate predictions about future destinations of the device's user, and then provide information to the user based on these predictions. To formulate these predictions, some embodiments employ one or more machine- learning engines to generate additional physical addresses to augment the set of physical addresses that they use to base their predictions.
• Different embodiments provide different information to the user based on the prediction. Examples of such information include routes to predicted future destinations, traffic data regarding routes to possible future destination, prioritized display of predicted future destinations over other destinations in a list of possible destinations or search queries, etc.
• routes to predicted future destinations include routes to predicted future destinations, traffic data regarding routes to possible future destination, prioritized display of predicted future destinations over other destinations in a list of possible destinations or search queries, etc.
• harvested physical addresses are not used for all of these purposes in some embodiments.
• the harvested physical addresses are used for other predictions and other uses in other embodiments.
• Figure 25 illustrates an example of a mobile device 2500 that uses the harvested physical addresses to predict future routes, which it presents to a user through a vehicle display.
• the mobile device 2500 connects to the interface of the vehicle's electronic information system.
• a mapping application operates on the mobile device 2500, and outputs both a first user interface display 2505 on the mobile device's display screen 2520 and a second user interface display 2510 on the vehicle's display screen 2515.
• the figure illustrates the interior of a vehicle 2550, in which the mobile device 2500 connects via a wired connection 2555 to the vehicle, and outputs a user interface for display on the vehicle screen 2515.
• a wired connection 2555 in other embodiments the mobile device connects with the vehicle's electronic information system through a wireless connection (e.g., through a Bluetooth connection).
• this example and others described below illustrate a single display screen in the vehicle.
• some vehicles include multiple screens, such as a center console dashboard screen and one or more screens in the control cluster in front of the driver. Some embodiments output only a single user interface to the center dashboard screen for such vehicles, while other embodiments output the same user interface to multiple screens, and yet other embodiments output different interfaces to the different screens.
• FIG. 25 further illustrates a harvested address data storage 2540, a route prediction engine 2542, and a vehicle UI module 2544.
• the address data storage 2540 stores harvested physical addresses. Based on these harvested physical addresses, the route prediction engine 2542 formulates one or more predicted routes that the device might take at any given time. This engine provides the vehicle UI module with these formulated routes.
• the vehicle UI module generates the vehicle UI display 2520 and presents this display on the display screen 2515 of the vehicle.
• the prediction engine 2542 is part of a map application that executes on the mobile device 2500.
• the prediction engine formulates one or more predicted routes that the device can take at any given time based on a variety of factors. These factors include physical addresses that are stored in the harvested address data storage 2540 and that are harvested from a variety of sources. For instance, in some embodiments, these addresses are harvested from sent or received emails, text messages, calendar invites, etc. Also, in some embodiments, these addresses are harvested when they are searched, viewed and/or used to compute routes in web browsers and/or the map applications, or other applications (e.g., email applications). These addresses are also harvested in some embodiments from locations of calendared events. As mentioned above, some embodiments employ one or more machine-learning engines to generate additional physical addresses to augment the set of physical addresses that are used to formulate predicted routes.
• the vehicle UI display 2515 provides an indication of multiple predicted routes.
• the indication of multiple routes is provided by indicators 2560, which in these embodiments indicate multiple view pages that display multiple predicted routes. The scrolling through these routes will be further described below by reference to Figures 26 and 27.
• the vehicle UI display 2515 in some embodiments presents the likely routes with a map view on one portion of the display and information about the route (including estimated arrival time, metadata about the source of the route, etc.) on a second portion of the display.
• the route information that is provided in the second portion specifies the source of the data that was used to predict the route's destination as a possible destination of the device and the frequency of travel to this destination.
• the selection (e.g., touch screen selection or keyed selection) of the map view portion of this display causes the mobile device to enter a turn-by-turn navigation mode.
• the mobile device presents a view along the selected route, while also providing instructions for upcoming maneuvers to perform (e.g., as road signs with both text and graphical instructions).
• the navigation mode is initiated through another control that is provided through the vehicle UI display 2515.
• the map application is the application on the mobile device that is responsible for providing the turn-by-turn navigation (i.e., for providing the navigation mode).
• Figure 26 illustrates an example of the scrolling through multiple predicted routes that are generated based on harvested data. This example is illustrated in terms of three operational stages 2610-2620.
• the first stage 2610 shows the vehicle UI display 2520 of Figure 25.
• the indicators 2560 indicate the availability of additional routes.
• the number of indicators is indicative of the number of additional routes.
• three indicators 2560 in the first stage 2610 are indicative in these embodiments of three predicted routes.
• the second stage 2615 shows the user performing a swipe operation on the presentation to navigate to another of the predicted destinations/routes.
• the user can perform such an action because in this example the vehicle display screen 2520 has a touch sensitive screen.
• the vehicle UI module 2544 of some embodiments accept other gestures, or selection of various affordances (e.g., left and right or up and down navigation arrows) in order to cycle through the different options. Accordingly, when the presentation is shown on a non- touch sensitive screen of a vehicle, the user can navigate to the next predicted destination/route through one of the keys, knobs, or other controls of the vehicle.
• the mobile device 2500 presents the next predicted destination/route upon receiving the user's input.
• the third stage 3620 of Figure 26 illustrates the mobile device's presentation 2655, which shows a gym 2660 and a route 2666 to the gym as another predicted destination/route.
• the map application did not initially show the route to the gym in the third stage because the route prediction engine assigned a lower probability to the gym being the actual destination as compared to the destination shown in the first stage 2610.
• Figure 27 illustrates an example of the mobile device automatically scrolling through multiple predicted routes as the device travels along a particular path. This example is illustrated in terms of two operational stages 2705-2710.
• the first stage 2705 shows a position 2722 of the device as it travels along a first predicted route 2724 to a first predicted destination 2720.
• This stage also shows indicators 2560 that specify that the mobile device has identified multiple different predicted routes to multiple different predicted destinations.
• the second stage 2710 shows that once a user passes an intersection 2730, the mobile device reformulates the predicted route and presents a new predicted route 2726 to a new destination 2728.
• the predicted route 2726 might have been one of the routes previously predicted by the mobile device and represented by the indicators 2560.
• the mobile device in some embodiments might have reformulated its predictions and identified the destination 2728 as a new possible destination.
• the mobile device in some cases bases its predictions on an address that is harvested on another device.
• Figure 28 illustrates such an example. This example is identical to the example illustrated in Figure 25, except that the harvested address, 1149 Foothill Road, in Figure 28 was initially captured on a computer 2800 and stored in the address data storage 2840 of this computer. This address then was relayed to the harvested address data storage 2540 of the mobile device 2500 through the server infrastructure. Once relayed to the mobile device 2500, the prediction engine of this device uses this address to identify it as a possible destination for the device.
• This synchronizing of physical addresses across multiple devices is highly useful. For instance, a user can fully explore a location on a map application of a desktop computer. Given that some embodiments in real time or quickly synchronize addresses across devices, the prediction engine of the mobile device of the user can use this address the next time that the user is traveling in his car to provide automatically a route to the explored location.
• FIGS 29-31 illustrates several additional examples of using the harvested physical address.
• the harvested addresses are used to provide travel times and traffic data based on harvested physical addresses or machine-generated physical address.
• some embodiments employ one or more machine-learning engines to generate additional physical addresses to augment the set of physical addresses that are used to be the basis for the predictions.
• Figure 29 illustrates how some embodiments present a traffic notification based on a harvested or machine generated physical address.
• some embodiments focus only on harvested or machine-generated locations that are very likely to be relevant to the user of a device. This is partly because the space for such notifications is often limited on the mobile devices. It is also partly because too many machine-generated notifications can be distracting to a user as the user might not find them always to be of interest.
• the mobile device of some embodiments displays the traffic notification 2905 in a notification center's window 2910 that includes various notifications (such as calendar event reminders) for a user.
• the traffic notification in this example specifies that traffic along highway 101 is heavier than usual.
• the mobile device reports traffic along this highway based on a prediction that the device will travel along this highway soon. This prediction can be based on a predicted destination of the device.
• the predicted destination in some embodiments is generated by a machine learning process that identifies typical locations of the device at different intervals of time.
• the predicted destination may alternatively be a harvested physical address, such as the location of a calendared event.
• the mapping interface 3540 is an interface of the mapping application operating on the device.
• the mapping application uses the destinations and routes from the destination selector 3525 and route generation engine 3527 to present a user with possible easily selectable destinations for navigation. Some embodiments present this data to the user on a vehicle display screen when the device is connected to the vehicle.
• client devices communicate utilizing various data formats separate from a map tile.
• client devices implement Assisted Global Positioning Satellites (A-GPS) and communicate with location services that utilize data formats conforming to location service protocols, such as, but not limited to, Radio Resource Location services Protocol (RRLP), TIA 801 for Code Division Multiple Access (CDMA), Radio Resource Control (RRC) position protocol, or LTE Positioning Protocol (LPP).
• RRLP Radio Resource Location services Protocol
• CDMA Code Division Multiple Access
• RRC Radio Resource Control
• LTE Positioning Protocol LTE Positioning Protocol
• Client devices may also receive GPS signals directly.
• Embodiments may also send data, with or without solicitation from a map service, identifying the client device's capabilities or attributes (e.g., hardware specifications or operating system version) or communication capabilities (e.g., device communication bandwidth as determined by wireless signal strength or wire or wireless network type).
• both voice and data communications are established over wireless network 3910 and access device 3912.
• device 3902a can place and receive phone calls (e.g., using voice over Internet Protocol (VoIP) protocols), send and receive e-mail messages (e.g., using Simple Mail Transfer Protocol (SMTP) or Post Office Protocol 3 (POP3)), and retrieve electronic documents and/or streams, such as web pages, photographs, and videos, over wireless network 3910, gateway 3914, and WAN 1160 (e.g., using Transmission Control Protocol/Internet Protocol (TCP/IP) or User Datagram Protocol (UDP)).
• VoIP voice over Internet Protocol
• SMTP Simple Mail Transfer Protocol
• POP3 Post Office Protocol 3
• WAN 1160 e.g., using Transmission Control Protocol/Internet Protocol (TCP/IP) or User Datagram Protocol (UDP)

Landscapes

• Engineering & Computer Science (AREA)
• Radar, Positioning & Navigation (AREA)
• Remote Sensing (AREA)
• Physics & Mathematics (AREA)
• Automation & Control Theory (AREA)
• General Physics & Mathematics (AREA)
• Health & Medical Sciences (AREA)
• General Health & Medical Sciences (AREA)
• Social Psychology (AREA)
• Acoustics & Sound (AREA)
• Artificial Intelligence (AREA)
• Audiology, Speech & Language Pathology (AREA)
• Human Computer Interaction (AREA)
• Information Transfer Between Computers (AREA)
• Telephonic Communication Services (AREA)

Applications Claiming Priority (7)

Publications (1)

Family

ID=54456444

Family Applications (1)

Country Status (3)

Families Citing this family (9)

Citations (3)

Family Cites Families (13)

• 2014
  • 2014-03-14 CN CN201480013892.7A patent/CN105051495B/zh active Active
  • 2014-03-14 CN CN201910672157.1A patent/CN110388935B/zh active Active
  • 2014-03-14 WO PCT/US2014/029841 patent/WO2014145134A1/en active Application Filing
  • 2014-03-14 EP EP14725819.8A patent/EP2972104A1/en not_active Withdrawn

Patent Citations (3)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events