WO2012050549A1

WO2012050549A1 - System and method for contextual phone number auto-complete lookup

Info

Publication number: WO2012050549A1
Application number: PCT/US2010/002767
Authority: WO
Inventors: Steven Lee Cooper
Original assignee: Thomson Licensing
Priority date: 2010-10-14
Filing date: 2010-10-14
Publication date: 2012-04-19

Abstract

A method/system for assisting dialing, including receiving at least one entry from an input device, accessing contextual information, using a processor to determine a likely candidate from a list using the at least one entry and the contextual information, displaying the candidate to assist a user in completing the input, receiving a confirmation signal from the input device, and using the candidate to perform a dialing operation.

Description

SYSTEM AND METHOD FOR CONTEXTUAL PHONE NUMBER AUTO- COMPLETE LOOKUP

BACKGROUND

"Plain old telephone service" (POTS) telephones and, more recently, mobile and "voice over internet protocol" (VoIP) telephones provide users the ability to communicate with enormous convenience. However, as the technology has advanced and grown, so too has the user base grown. One estimate puts the number of global telephone subscriptions at nearly 6 billion. An obstacle to the ease of use of the telephone has grown hand in hand with its user base. With the growth of the telephone, longer phone numbers were required to provide service to all of the users. In the U.S., the once-commonplace seven-digit number for local calls has given way to a ten-digit format, where users are required to enter an area code as well.

This presents difficulties to the average user. In some studies, it has been reported that the human brain has a short term memory capacity for an average of seven digits.

Increasing the length of a phone number to ten makes the task of entering an unfamiliar phone number substantially more difficult. This problem is compounded when dialing internationally, where the combination of a two-digit country code with a potentially lengthy national number produces an unmanageably tedious phone number, presenting challenges both to a user's memory as well as patience.

SUMMARY

A method for assisting dialing is shown that includes receiving at least one entry from an input device, using a processor to determine a likely candidate from a list using the at least one entry, displaying the candidate to assist a user in completing the input, receiving a confirmation signal from the input device, and using the candidate to perform a dialing operation.

Furthermore, a system for providing dialing assistance is shown that includes an input module configured to receive a numerical input, a memory configured to store a list of numbers, a processor configured to select a likely candidate from the list of numbers using the numerical input, and a display configured to display the likely candidate. BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments disclosed herein can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:

FIG. 1 is a block/flow diagram illustrating an exemplary telephone network according to the present principles.

FIG. 2 is a diagram illustrating an exemplary telephone according to the present principles.

FIG. 3 is a block/flow diagram illustrating an exemplary method making telephone calls using automatically completed numbers based on a user's input.

FIG. 4 is a diagram illustrating an exemplary telephone interface.

FIG. 5 is a block/flow diagram illustrating an exemplary telephone system according to the present principles.

It should be understood that the drawings are for purposes of illustrating the concepts and are not necessarily the only possible configuration for illustrating the embodiments. To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.

DETAILED DESCRIPTION

The present principles provide systems and methods for phone number lookup and auto-completion. In order to make the user's experience easier and more pleasant when dialing a telephone number, the present principles provide phones with the ability to look up partially dialed numbers in a table or database of recent or saved numbers. In an exemplary embodiment, the remainder of a likely number is displayed to the user, while allowing the user to continue entering additional digits to refine the lookup. The autocomplete lookup can be configured by the user to select for numbers that match the user's preferred criteria, such that the suggested numbers reflect those numbers which the user is actually most likely to want to dial.

The functions of the various elements shown in the figures can be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions can be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which can be shared. Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and can implicitly include, without limitation, digital signal processor ("DSP") hardware, read-only memory ("ROM") for storing software, random access memory ("RAM"), and non-volatile storage. Moreover, all statements herein reciting principles, aspects, and embodiments, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).

Thus, for example, it will be appreciated by those skilled in the art that the block diagrams presented herein represent conceptual views of illustrative system components and/or circuitry embodying the principles of the embodiments. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudocode, and the like represent various processes which can be substantially represented in computer readable media and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

Referring now in specific detail to the drawings in which like reference numerals identify similar or identical elements throughout the several views, and initially to FIG. 1, an exemplary telephone system is shown which includes a wide variety of telephone devices. A "plain old telephone service" (POTS) phone 102 is connected directly to the telephone network 104 via copper wires. A mobile or cellular phone 106 is connected to the telephone network 104 via a wireless communications tower 108. A "voice over internet protocol" (VoIP) phone 110 connects first to a multimedia terminal adaptor (MTA) 1 12, which in turn communicates over the Internet 114 with a remote VoIP server 116. The VoIP server 116 then interfaces with the telephone network 104.

Due to the long history of the telephone network and the constant innovation in voice communication techniques, there are many different technologies in use. However, as technology improves the sophistication of new telephones, the amount of storage available increases, such that it is now possible to store, for example, the telephone numbers for all incoming and outgoing calls.

Referring now to FIG. 2, an exemplary telephone is shown according to the present principles. The telephone 200 includes a display 202 which can be any visual display ranging from a full-color LCD screen to a simple alphanumeric display. The telephone 200 can further include, for example, input options such as an arrow pad 204 having directional buttons and a selection button to allow a user to navigate through a user interface (UI) on display 202. The telephone 200 can also further include, for example, keypad 206 which allows the user to enter numbers and even letters using a multi-tap or "T9" predictive text scheme, similar to the techniques used for text messaging. The keypad 206 can also include special-purpose buttons 208, one of which can be programmed as an "autocomplete" button. Alternatively or in addition, the handset can feature a touch screen interface, allowing a user to directly interact with the display 202.

The flexibility in UI options available in a telephone 200 provides for many possible embodiments, and it is expected that those having ordinary skills in the art would be able to implement the inventive principles in a manner consistent with and appropriate to any possible UI input or display.

When a user begins to dial a number with the keypad 206, the telephone uses the entered digits to perform a lookup operation on the stored telephone numbers. The telephone refers to a list of all of the numbers which begin with the digits the user has entered and selects one number from the list to display to the user based on a set of selection criteria. The user can then choose to accept the auto-complete number or can instead choose to continue dialing, thereby allowing the phone to further refine the search.

Referring now to FIG. 3, an exemplary method for phone number lookup is shown. At block 302 the user enters a digit. This digit is then used to perform a lookup of stored numbers, producing a list of matches at block 304. At this point, contextual information can be accessed at block 305. This information can include temporal or geographic information and can be acquired from external sources such as a cell phone tower or satellite. A single number from the list is then automatically selected according to a criterion at block 306. Examples of such criteria are discussed below. Next, the selected number is displayed to the user at block 308. The user now has the option of entering input at block 310. If the user enters another digit at block 312, the new digit is used to further refine the lookup at block 304. Otherwise it is determined whether the user has accepted the selected number at block 314. If the user has not accepted the number, further user input is received at block 310. If the user does accept the selected number, the number is dialed at block 316.

A number can be selected according to one of several different criteria, and the particular method for selection can be configured by the user. For example, the most recently dialed number that matches the user's input might be selected. Alternatively, the number of the most recent incoming call could be selected, based on a stored call history. Another option is to select the most frequently dialed number, such that numbers which the user calls frequently and are therefore more likely the desired number will be preferred. It is also possible to combine certain of these criteria, e.g., by selecting the number which most frequently dialed in. The user can select the particular criteria in the telephone's configuration settings and, furthermore, can provide additional preferences. The user has the ability to select particular criteria or kinds of criteria, and further to change how those criteria are applied. For example, the user might set the phone to display the most frequently dialed number only from a certain time range, such as the previous six months or one year. As a result of such a configuration, calls older than, e.g., six months might not be counted toward the total— thereby keeping the suggested numbers relevant to the user's current usage. In this way, autocompletion will adapt to changes in the user's calling patterns.

Context sensitive criteria are also possible. For example, if the user always calls certain numbers in the evening, those numbers might be given preference during the hours of 6:00PM to 9:00PM. Thus, for a user who always calls family after work, the telephone would automatically suggest family numbers during those hours, even if the user more frequently dials other numbers during business hours. The telephone can also be

geographically sensitive. For example, many mobile phones include GPS positioning capabilities, allowing them to pinpoint their geographic locations. Hence, if the user calls particular numbers at home or at the office, those numbers could be preferentially selected when the user is in the appropriate respective locations. The criteria described herein are described solely for the sake of illustration and should not be construed as limiting.

Context sensitive criteria can furthermore be configured by the user to enhance the user's experience. For example, the user can adjust the range of geographical sensitivity according to the user's needs. If the user lives in a dense city, a range of one mile can be needed to distinguish between "home" and "office," whereas a user who lives in the suburbs or country could have a much larger geographical range for geographical grouping. As such, the user can have the ability to set a radius, thereby calibrating the geographical sensitivity of the selection criterion. Additionally, a user who works odd hours can prefer to sort calls differently for time sensitive selection. The user can also choose to put the phone into a "vacation mode," which could override the usual selection algorithm to give preference to those numbers which are dialed outside of the user's work. Users can also establish their own modes and categories of numbers, allowing the user to have fine-grained control over the phone's auto-complete function.

In addition to allowing the phone to automatically glean what information it can from the user's call history, the user can explicitly provide information such as working schedule, including days of the week worked and hours. In this manner, the user can establish a customizable selection algorithm that is tailored to the user's particular needs. Referring now to FIG. 4, an exemplary user interface is shown illustrating the present principles from the user's perspective. When the user begins to dial a number, the digits entered appear up on the display, as shown in 402. The phone then performs a lookup operation, as described above, and automatically completes the number according to the best match. It is preferable to distinguish the suggested digits from the digits which the user has entered. One exemplary technique for distinguishing can be to use a small marker to indicate a cursor position. Another exemplary technique is to display the suggested digits with an inverted background, as shown in 404. If the user accepts a suggested number, the indication distinguishing dialed digits from autocomplete digits is removed, as shown in 406.

When the user begins to enter a number and an autocomplete suggestion is displayed, the telephone can further refer to a stored directory of contacts to determine whether additional information regarding that number is available. For example, in 404 and 406, the suggested number is associated with a stored contact for "Jenny," and the user interface therefore displays the word "Jenny" as a part of step 308 to assist the user in verifying that the suggested number is the number that the user intended to dial. As the user enters additional digits and the autocomplete suggestion is refined in step 306, the textual display can be updated in step 308 to reflect the current suggestion.

As an alternative to displaying the suggested number, the interface can instead display only the textual phrase associated with the predicted number. Referring to 408, a display is shown which, rather than displaying the full suggested number, only displays the textual information associated with the number. Continuing the above example, 408 shows the name "Jenny" as being the most likely number based on the entered digits, but does not fill in the remaining numbers. If the user elects to call the suggested number, the display then fills in the remaining digits and proceeds to 406.

To accept a suggested number, the user can press a button on the phone that is distinct from the standard "dial" button. For example, on most mobile phones, the phone will not dial until the user explicitly instructs it to do so. However, this creates ambiguity in the presence of an autocomplete feature, as there is no good way to determine with a single button whether the user wishes to dial only the digits entered or wishes to dial the autocomplete number. As such, the user can press, for example, a dedicated button for this purpose, for example one of the special purpose buttons 206 described above, a select button such as that shown in arrow pad 204, or by dialing the # or * key. It is also possible to simply designate a "dial" or "hang up" button as having the function of selecting an autocomplete suggestion, though it would be helpful to inform the user of this behavior in advance. Once the autocomplete suggestion has been accepted, the user can then press the "dial" button to place the call.

In a further embodiment, the user has the option of cycling through the full list of matching numbers. For example, by pressing a designated key, such as the "right" or "down" arrow in arrow pad 204, the user can instruct the telephone to select the next-best match according to the given criterion. In many cases, entering a few digits will limit the list of matching numbers to a small number, making it practical for the user to scroll through all of the options in most circumstances. Another possibility is to display the suggested numbers in a list, allowing the user to scroll through the list and select a particular option.

A further option for autocompletion is to automatically provide an area code. As noted above, many areas now require the use of an area code even when dialing locally. If the user is unfamiliar with a local area code, or simply does not wish to dial the code in every call, it is advantageous to include a mechanism for automatically entering such an area code. In the case of a mobile telephone 106, the telephone can acquire the local area code from the cell tower 108. In the case of a VoIP telephone 110, the phone can be configured to acquire local area code information from the MTA 112. Alternatively, the telephone can be configured by the user through a manually changed setting to include a particular local area code. Then, upon a user's selection of autocomplete mode, the phone can automatically insert the local area code, or can give preference to those numbers which match the local area code when making suggestions.

Such user configuration provides a wide variety of options for autocompletion. For example, the user has the ability to instruct the phone to automatically prepend or append an arbitrary sequence of digits to the entered digits upon pressing an autocomplete button. This allows the user to quickly use a commonly dialed area code or extension.

Referring now to FIG. 5, a block/flow diagram is shown which provides an illustrative system for a telephone 502. The telephone includes a display 504, which provides for the user feedback as to what digits have been entered as well as autocomplete suggestions, as shown above with respect to FIG. 3. The telephone also includes an input 506 that allows the user to enter digits and provide additional commands with respect to autocompletion. The input 506 and the display 504 are controlled by an interface module 508 that receives user inputs and creates a UI. The interface module 508 is in turn controlled by a processor 510. When the user enters digits to the input 506, the interface module 508 passes those digits onto the processor 510, which searches memory 512 for stored numbers which match. The processor 510 then selects a best match according to a criterion and passes that match to the interface module 508 which, in turn, displays the suggested autocompletion on display 504.

The memory 512 can store numbers in a variety of ways. The below tables show tables stored according to the present principles. Table 1 is a call history that includes a time-ordered list of all incoming and outgoing calls, with columns representing the date, time, phone number, geographical coordinates, and whether the call was incoming or outgoing. The call history of Table 1 is particularly efficient for selection of a number according to which number was used most recently as well as selection based on geography. An alternative arrangement for the call history stores, instead of objective geographical coordinates, regions that are defined by the user or by political borders or census data. For example, a user might define certain ranges of coordinates as corresponding to "Home" or "Work," or a preprogrammed system might distinguish between calls made from Long Island and those made from Manhattan.

Table 1

Another exemplary table is shown in Table 2, which maintains information relating to call frequency. Using the same call history as that shown in FIG. 1, FIG. 2 illustrates a table which counts every call for each number. Additional modifications can include only incrementing the call number for outgoing calls. Selecting such an option would prevent frequent callers from overtaking the user's own calls. Additionally, the user can set a time limit for the call frequency, such that old calls are not counted in the number of calls. If such a time limit is set, the processor will periodically (e.g., every day) review the call history shown above in Table 1 and subtract from the count in Table 2 every time a particular call record falls outside the time limit. As such, multiple tables can be stored, allowing for efficient lookup according to a plurality of selection criteria.

Some updates and changes to the table take place periodically, whereas others take place as the device is used. As discussed above, for example, the tables can be reviewed daily to ensure that they are in accordance with the user's preferences, trimming out expired entries. Other changes take place as the user makes and receives calls, as frequency counts are changed and entries are added. Additionally, the user can make explicit changes to the tables, for example by merging in new call histories from other sources or by explicitly removing a number from the autocomplete tables.

For example, if a user leaves a particular place of employ, the user might remove all of the numbers relating to the user's former job as being unnecessary. The user might remove all numbers having a particular prefix (e.g., 516-867-xxxx), or could instead remove individual numbers. In this manner, the user can override the auto-complete function to prevent unwanted numbers from appearing without having to wait for the table entries to be removed due to age.

With the additional advent of cloud computing, it becomes possible to store call histories and autocomplete configuration options across multiple phones. It is now possible to have one phone number which simultaneously rings any number of phones, effectively allowing a user to treat a plurality of locations as being tied to a single phone number. In such a situation, it can be advantageous to store call histories at an internet server such as a VOIP server 116 or in the mobile telephone network 108. With a shared call history, additional selection criteria become available for determining which number to suggest for autocompletion. In addition to the stored information described above, a table can furthermore include an entry that describes which of the user's phones was used to make or receive the call. Then this information can be used to select according to a criterion for the particular phone the user is dialing from. So, for example, the phone might suggest the most frequently dialed number overall, or instead the user might configure the phone to suggest the most frequently dialed number that that particular phone has used. This allows the autocomplete lookup to distinguish between the most frequently dialed numbers when the user is at work versus when the user is dialing from a home phone, even if the two phones share a common phone number.

The "cloud" approach has various advantages as compared to storing a call history on the phone itself. By storing such information in the cloud, the on-board memory

requirements of the phone are decreased, thereby decreasing the hardware cost. The cloud approach further provides extra security, as the data is safe from accidental deletion. Even if the phone were to be destroyed in a fire, the call histories would be preserved as a result of having been stored at a distant location. A further security benefit lies in the fact that call histories, which the user might prefer to keep private, are not stored on the phone itself and thus would not be susceptible to being accessed by a thief.

A further advantage from the perspective of the phone service provider is that it allows said provider to treat autocompletion as a service, such that the provider can charge a user for the ability to store their call histories remotely. By offloading these features to the cloud, the service providers acquire substantial flexibility in determining payment plans for ongoing features.

Having described preferred embodiments for systems and methods for phone number autocompletion (which are intended to be illustrative and not limiting), it is noted that modifications and variations can be made by persons skilled in the art in light of the above teachings. It is therefore to be understood that changes can be made in the particular embodiments disclosed which are within the scope as outlined by the appended claims. While the forgoing is directed to various embodiments, other and further embodiments can be devised without departing from the basic scope thereof.

Claims

Claims:

1. A method for assisting dialing, comprising:

accessing contextual information in response to receipt of data from an input device; and

determining a likely candidate from a list using the at least one entry and the contextual information.

The method of claim 1, further comprising:

displaying the candidate to assist a user in completing the input;

receiving a confirmation signal from the input device; and

using the candidate to perform a dialing operation.

3. The method of claim 2, further comprising:

receiving an additional entry from the input device; and

determining a new candidate from the list using the at least one entry and the additional entry.

4. The method of claim 2, further comprising displaying a textual phrase associated with the likely candidate.

5. The method of claim 2, further comprising removing an entry from the list.

6. The method of claim 2, wherein the list is stored in cloud storage.

7. The method of claim 2, wherein the likely candidate is determined according to a frequency criterion.

8. The method of claim 2, wherein the contextual information includes temporal information.

9. The method of claim 2, wherein the contextual information includes geographic information.

10. A system for providing dialing assistance, comprising:

an input module configured to receive an alpha-numerical input;

a memory configured to store a list of sequences;

a processor configured to collect contextual information and to select a likely candidate from the list of sequences using the alphanumerical input and the contextual information; and

a display configured to display the likely candidate.

1 1. The system of claim 10, wherein the processor is further configured to select a new candidate from the list upon receiving additional input.

12. The system of claim 10, wherein the display is further configured to display a textual phrase associated with the likely candidate.

13. The system of claim 10, wherein the likely candidate is selected according to a frequency criterion.

14. The system of claim 10, wherein the contextual information includes temporal information.

15. The system of claim 10, wherein the contextual information includes geographical information.

16. A system for providing dialing assistance, comprising:

an input module configured to receive an alphanumerical input;

a memory configured to store a list of sequences;

a display configured to display a textual phrase associated with the likely candidate.

17. The system of claim 16, wherein the processor is further configured to select a new candidate from the list upon receiving additional input.

18. The system of claim 16, wherein the likely candidate is selected according to a frequency criterion.

19. The system of claim 16, wherein the contextual information includes temporal information.

20. The system of claim 16, wherein the contextual information includes geographical information.