HK1192085A - Automated caller identifier from contact lists of a user's contacts - Google Patents

Description

Automated caller identifier from a contact list of user contacts

The present patent application is a divisional application of the invention patent application with application number 201110043186.5, filed on 16.2.2011, entitled "automated caller identifier from a contact list of a user contact".

Technical Field

The present invention relates to communication network technology, and more particularly to automated caller identifiers from a contact list of user contacts.

Background

Modern communication networks have provided users with a number of features and functions that make it easy, convenient, and inexpensive to contact friends, family, colleagues, and others. A wide variety of devices are available, such as mobile phones, smart phones, Personal Computers (PCs), and other network-enabled devices, which enable users to surf the web to access resources for information and entertainment, send email and instant messages, and communicate with other users using voice calls. Furthermore, as wireless infrastructure expands its range, and as devices become feature rich, smaller, and more portable, users can be contacted virtually anytime and anywhere.

While most users understand the benefits of such enhanced connectivity, which often results in the receipt of a large number of calls and messages competing for the attention of the user, it would be helpful if the name of the caller could be presented to the user at the time the call or message was received. Such a feature may be provided by examining metadata associated with an incoming call or message, such as the sender's phone number. The metadata may be compared to data in the user's contact list and if a match is found, the name of the sender is presented to the user on the display of the mobile phone. As a result of the enhanced connectivity provided by mobile phones, users are increasingly receiving calls or messages from unidentified senders whose names are not included in the user's contact list. Even if not included in the user's contact list, it would be helpful to the user if more of these unidentified senders could be automatically identified when a call or message is received.

This background is provided to introduce the following summary and brief context of the detailed description. This background is not intended to be an aid in determining the scope of the claimed subject matter, nor is it intended to be viewed as limiting the claimed subject matter to implementations that solve any or all of the problems or disadvantages noted above.

Disclosure of Invention

As previously mentioned, some users, particularly enterprise users, may receive many calls or messages on their mobile phones from various senders, some of which may be identified from the user's contact list, while others of which may not. While a user may receive a call or message from an unidentified sender that is not included in the user's contact list, such a sender may sometimes be included in the contact list of one or more of the user's contacts. In one embodiment, to utilize information available in the contact list of the user's contacts, the user's electronic communication device, such as a mobile phone or the like, contains a caller identifier application for identifying unidentified senders. The caller identifier application is configured to search for a contact list residing on the user's communication device. If the sender's name or other identifier is not found, the caller identifier application is also configured to determine if the identity of the unidentified sender is available from the contact list residing on the communication device of those contacts contained in the user's contact list, and read the identity of the sender so that it can be presented to the user.

In a particular embodiment, when a call or message is received on the user's communication device from an unidentified sender, the caller identifier application launches a text-based messaging application and causes it to send an "invisible" text-based message to the user's contacts. The message includes metadata (e.g., a phone number) associated with the call or message received by the user. The invisible SMS message is a short message whose header is programmed in a specific way so that the receiving mobile phone is aware of the reception of the message and does not show a behavior that can be perceived by the user. When the invisible message is received by a corresponding caller identifier application on the mobile phone of one of the user's contacts, the application searches for a contact list that the contact maintains in his or her contacts application. If the metadata provided to the contact's mobile phone is in the contact list, contact details (e.g., name) or contact card (if available) are sent back to the user's mobile phone in a second invisible SMS message. Upon receiving the second invisible SMS message, the caller identifier application causes some or all of the contact details to be displayed on the user's mobile phone or presented to the user in any suitable manner. In this manner, the user's contact list is effectively expanded to include a contact list of his or her contacts, which may be automatically searched without intervention by any of the parties involved.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

Drawings

FIG. 1 shows an illustrative communication environment in which a user of a device and a caller may communicate using network-enabled devices such as mobile phones, PCs, and landline phones;

FIG. 2 shows an illustrative architecture that includes a caller identifier application that may be implemented on a network-enabled communication device such as a mobile telephone;

FIG. 3 shows illustrative interfaces used between various functional components running on a network-enabled device;

FIG. 4 shows an illustrative set of functional components in a caller identifier application and various illustrative features, functions, and interfaces supported by the caller identifier application;

FIG. 5 is a flow diagram of an illustrative workflow that may be used by a caller identifier application resident on a first network-enabled electronic device;

fig. 6-8 show various illustrative screenshots of user interfaces supported by a caller identifier application.

Detailed Description

In the drawings, wherein like reference numerals refer to like elements, FIG. 1 shows an illustrative communications environment 100 in which a user 105_1…NAnd caller 110_1,2…NRespective network-enabled devices 115 may be used_1,2…NCommunicating, network-enabled device 115_1,2…NEach operably coupled to a communication network 120. The devices 115 may comprise any of a variety of devices and platforms that support voice communications, such as a mobile phone,A smart phone, PC, land-line phone, or other mobile or fixed device suitable for voice over network telephony. In this particular exemplary embodiment, the term "user" refers to a user of a current caller identifier application that receives telephone calls, SMS messages, etc. from a person that will be referred to herein as a "sender".

In one embodiment, the current caller identifier application is arranged to execute on a mobile device, such as a mobile phone, a personal digital assistant operable as a telephone, a smartphone, or a mobile device configured to be Microsoft basedOther portable devices (hereinafter collectively referred to as "mobile phones") capable of making or receiving voice calls. However, the principles of the current arrangement may also be adapted for use with other devices, such as Android for example^tmAn operating system, and the like.

Communication network 120 for facilitating communication between user 105 and caller 110 may include portions of one or more network types as shown in fig. 1, including mobile phone network 125, mobile data network 130, public switched telephone network 135, and internet 140. Thus, for example, a given caller 110 may call a given user 105 using a conventional telephone, where the call is carried over portions of both the public switched telephone network 135 and the mobile telephone network 125. Alternatively, another caller 110 may call the user 105 using a PC equipped with VOIP (voice over internet protocol) capabilities, where the call is carried over the internet 140 and the mobile phone network 125. In fact, a given telephone call may be transmitted using a combination of various network types or a single network, as desired.

Service providers 145 are also supported in the communications environment 100. Service provider 145 may be used in a usage scenario where portions of the current caller identifier application functionality are distributed to one or more external, remotely located servers.

Such a use scenario is described in more detail in the text accompanying fig. 13 and 14 below.

FIG. 2 shows an illustrative architecture 200 for facilitating the main functional components of the present arrangement, including that which may be implemented in a mobile phone 115 such as described above₁Etc. on the network-enabled communication device. Although the architecture 200 shown in FIG. 2 is particularly well suited for use with the mobile phone 115₁It is expected that the basic principles it illustrates have general applicability to other platforms such as, for example, PC210 indicated by dashed line 215. In the illustrative embodiment, caller identifier application 205 is present on mobile phone 115 along with contacts application 220, SMS application 250, and other applications as collectively indicated by reference numeral 225₁Is executed. A contacts application 220 that maintains contact information such as addresses, phone numbers, etc. of friends, colleagues, family, etc. may be included in applications that provide functionality other than maintaining contacts. For example, contact lists are often maintained in scheduling applications, which typically support scheduling, calendaring, and task management functions, either individually or in combination. Such a contact or scheduling application may be embedded in, for example, commercially available software, such as Microsoft corporation' sMessaging and collaboration clients.

SMS application 250 supports short message services available on many communication devices that permit short messages (also referred to as text messages) to be sent between mobile phones, other handheld devices, computers, and even standard landline phones. Wireless networks typically implement SMS using a Short Message Service Center (SMSC) that acts as a store-and-forward system for relaying short messages. Messages are stored in the network until the destination communication device becomes available, so the end user can receive or send SMS messages at any time, whether or not a voice call is in progress. Instead of an SMS application, other text-based messaging applications may be employed. Such applications can send text-based messages in other formats, including, for example, MMS messages supported by multimedia messaging services developed by 3GPP (third generation partnership project) for sending multimedia communications between mobile phones and other forms of wireless information devices. Other types of text-based messages that may be employed may be based on any intermediary technology, such as EMS (enhanced messaging service) and variants thereof, such as premium SMS, as well as any future enhancements and developments to these services.

Supporting applications 205, 220, and 225 in architecture 200 are operating system 230 and hardware layer 235. In the exemplary embodiment, operating system 230 is particularly suited for operating on resource-limited devices and may include, for example, Microsoft WindowsThe hardware layer 235 provides the device 115 to the operating system 230 and the applications 205, 220, and 225 thereon₁The abstraction of the physical hardware implemented above. For example, such physical hardware typically includes a processor (e.g., a central processing unit or "CPU"), system memory such as read only memory ("ROM") and random access memory ("RAM"), bus structures, peripheral systems, drivers, display devices, user controls and interfaces, and so forth. The hardware may also include storage media for storing computer-executable instructions (i.e., code), including both removable and non-removable media or media, such as magnetic and optical media, solid-state memory, and other conventional media. Architecture 200 also provides UI240 to support user interactivity and facilitate an efficient user experience, and will typically be embodied as a graphical user interface.

FIG. 3 shows a mobile phone 115₁A number of illustrative interfaces implemented on the various functional components running on the computer. Caller identifier application 205 registers listener 410 with operating system 230, typically through API415, to monitor movesTelephone 115₁On the call. Caller identifier application 205 also typically interfaces with mobile phone 115 through APIs exposed by other applications, respectively₁And other applications executing thereon. For example, as shown in FIG. 3, a representative API420 exposed through the contact scheduling application 220 enables the caller identifier application 205 to call various functions, pass parameters, and exchange data with the scheduling application 220. Similarly, the representative API425 exposed through the SMS application 250 enables the caller identifier application 205 to call various functions, pass parameters, and exchange data with the SMS application 250.

As previously mentioned, some users, particularly business users, may receive many calls or messages on their mobile phones from various senders, some of which may be identified from the user's contact list, while others of which may not. While such unidentified senders may not be included in the user's contact list, they may sometimes be included in the contact list of one or more of the user's contacts. That is, the sender may be one who: one of his contacts with the user has a closer association with the user himself or herself. This is particularly true in situations where the use of social networking services such as Facebook, MySpace, LinkedIn, etc. provided have increased, which facilitate the development of an extended community of individuals.

To take full advantage of the information available on the contact list of the user's contacts, upon receiving a call or message from an unidentified sender, caller identifier application 205 launches SMS application 250 and causes it to send an "invisible" SMS message to the user's contacts. The SMS message includes metadata (e.g., a phone number) associated with the call or message received by the user. An invisible SMS message is a short message whose header is programmed in a specific way so that the recipient mobile phone is aware of the receipt of the message and does not show a behavior that is noticeable by the user. One example of a technique for sending SMS messages in an invisible format is shown in U.S. application publication No. 20060209740. When the invisible message is received by a corresponding caller identifier application on the mobile phone of one of the user's contacts, the application searches for a contact list that the contact maintains in his or her contacts application. If the metadata provided to the contact's mobile phone is in the contact list, contact details (e.g., name) or contact card (if available) are sent back to the user's mobile phone in a second invisible SMS message. Upon receiving the second invisible SMS message, caller identifier application 205 causes some or all of the contact details to be displayed on the user's mobile phone or otherwise presented to the user in any suitable manner. In this manner, the user's contact list is effectively expanded to include a contact list of his or her contacts, which may be automatically searched without intervention by any of the parties involved.

Fig. 4 shows an illustrative set of functional components comprising caller identifier application 205. The components include a user experience layer 505, a business logic layer 510, and a data layer 515. It is specifically noted that the functional components shown in FIG. 4 are merely illustrative and that other components may also be used in various combinations as desired for a given environment and to provide the features and functionality described herein. The functional components in caller identifier application 205 are generally configured to support various features, functions, and interfaces, including supporting a user experience, interacting with other applications, applying logic and rules to implement desired application behaviors, and processing data, as indicated by reference numerals 520, 525, 530, and 535, respectively.

The functional modules in the particular exemplary embodiment of fig. 4 may be implemented at least in part by computer executable code written on a mobile phone 115₁On one or more storage media and executed by one or more processors included in the hardware of the telephone. At this point, therefore, as shownThe arrangement may be viewed as a "thick client" because the code implemented by the functional components is substantially monolithic on the mobile phone 115₁To provide a per-design user experience and application behavior. In an alternative implementation, the functional components are configured in a distributed computing arrangement, and the mobile phone 115₁The code above may be executed from a thin client. In this case, the functional components and associated code execution are distributed across multiple computing platforms, including mobile phone 115₁And one or more servers operated by the service provider 145 as shown in figure 1.

As shown, caller identifier application 205 provides user preferences 520 by receiving a call or message from an unidentified sender₁Manage permissions 520₂And other user experiences 520_NTo support user experience 520. For example, user preferences may include such items as selecting particular contacts whose contact list should be searched, the order in which they should be searched, and the manner in which the results of such searches are presented. Permissions may include allowing receipt of an invisible SMS message to search the user's contact list, selecting a particular individual in the contact list whose identity should not be provided in response to a request from another user, and whether the user should be asked about permission to release contact information to another user each time a query is made. For example, some queries may be automatically authorized based on the contact group. As one example, such active authorization may allow all colleagues of the user to search for contacts in the user's workgroup.

Caller identifier application 205 may also be associated with mobile phone 115₁And other applications executing on the same. In this particular exemplary embodiment, caller identifier application 205 generally interacts with contacts application 220 and SMS application 250. However, interaction with other applications may also be used in a similar manner as discussed herein. In some use cases, caller identifier application 205 will implement a query, such as querying a contact list525₁To identify the user contact associated with the call event and to initiate an SMS or other messaging application to generate a message to be sent to the user contact 525₂Invisible SMS message. The call identifier application 205 may also be integrated with other applications or the like 525_NAnd carrying out interaction.

Caller identifier application 205 typically applies business logic and rules to implement the desired behavior of the application, as indicated by reference numeral 530. Application of business logic and rules typically implements various routines, processes, and workflows in response to receiving incoming or messages monitored by the listener 410 to support the user experience discussed above.

Caller identifier application 205 also supports various data processing functions including receiving a call or message 535₁And such as call metadata 535₂And the like. In some cases, caller identifier application 205 typically stores call data, as well as user preferences and usage history 535 on a temporary or permanent basis₃. Other data processing may also be as indicated by reference numeral 535_NAs indicated, to meet the needs of a given use environment.

Fig. 5 is a flow diagram of an illustrative workflow 800 that may be used by caller identifier application 205 residing on a first network-enabled electronic device. The workflow begins at block 805 where the listener 410 monitors incoming calls or messages from senders received by electronic devices over a communication network. Next, at block 810, the call identifier application resident on the first electronic device obtains metadata associated with the incoming call or message and searches a list of contacts associated with the first electronic device to locate a given individual associated with the metadata at block 815. If a given individual is located at decision block 820, the name or other identifier of the individual is presented to the user of the first electronic device, typically on the display of the first electronic device, at block 823. On the other hand, if no individuals associated with the metadata are found, workflow control passes to block 825 where caller identifier application 205 causes a first invisible text-based message to be sent to other electronic devices associated with at least some of the individuals included in the contact list of the first electronic device. This may be accomplished, for example, via establishing a link through an API to a text-based application resident on the electronic device, such that sending a message requests other electronic devices to search their respective contact lists for individuals associated with the metadata. If at decision step 830, the individual has not been located, then the process terminates at block 833, otherwise control passes to block 835 where the electronic device on which the individual was found sends a second invisible text-based message to the first electronic device containing the identity (e.g., name) of the individual. Finally, at block 840, the person's name or other identifier is presented to the user of the first electronic device, typically on the display of the first electronic device.

Fig. 6-8 show various illustrative screen shots of one example of a UI that may be supported by caller identifier application 205. Of course, the UI may be configured in a variety of different ways and is not limited to the examples shown herein. FIG. 6 shows the mobile phone 115 as it is being used₁An exemplary screenshot 900 of the UI when an incoming call 905 is received. In this example, call data is displayed that includes the caller's telephone number 910 and identity 915 (if known). In this example, call processing is by a mobile phone 115₁Implemented in the usual manner, it compares incoming call data with the user's contact list to obtain and display the identity of the caller. In an alternative implementation, such call processing functionality may be handled by the present caller identifier application 205. In either case, in this example, the caller is not listed in the user's contact list, and thus the identity of the caller is determined to be unidentified or unknown.

The user is provided with typical call processing options for either answering an incoming call or rejecting the answering by interfacing with "answer" or "reject" buttons 920 and 925 displayed on the UI. Is dependent onMobile phone 115₁The buttons 920 and 925 may be implemented using touch-sensitive graphical icons, "soft" keys on a phone, or various other conventional controls.

In accordance with the principles of the present arrangement, fig. 7 illustrates an exemplary screenshot 1000 of the UI when a prompt 1005 is displayed upon initiation of the caller identifier application 205 triggered by an incoming call 905. Prompt 1005 asks whether the user should search the contact list of his or her contacts. In some embodiments, depending on the established user preferences 520₁The prompt may be eliminated and the application will automatically start the search without prompting the user. When the prompt 1005 is displayed, buttons 1010 and 1015 are also displayed so that the user can implement the contact search function as desired.

Fig. 8 shows an exemplary screenshot 1100 showing the results after the caller identifier application 205 has performed a search for the caller's telephone number and has located the caller in the contact list of one of the contacts. When such a caller is located, the caller identifier application will display the name 1115 and the name 1120 of the contact providing the name from its contact list.

Note that for clarity and ease of illustration, in the description above, data, applications, and other executable application components such as the operating system are shown as discrete blocks, or other elements, although it is recognized and emphasized that these applications and components may reside at various times in different storage, memory, or processing components of any hardware host used, and are executed by one or more processors in such host hardware.

In the above described implementation, an invisible text message is sent to the mobile phone of the user's contact to identify the caller. However, in some implementations, for example, the invisible text message may be sent to contacts of the user that are available from other data sources, such as social networks (e.g., Facebook). Such a source may maintain the userAnd the phone numbers of both the contacts of those contacts, thus providing another source of information that can be used to identify the caller. In addition to social networks, other available data sources include mail clients, such as Gmail, MicrosoftAnd WindowsIn this manner, a new social network is effectively created that includes the user, the user's contacts, and the contacts of the user's contacts. In this way, the contact list available in the user's mobile device is transferred from the self-contained closed list to the individual's overall social network with the ability to grow and expand to additional individuals.

The above-described techniques are generally applicable to a wide variety of different mobile devices provided by various manufacturers. However, with some mobile devices, such asThe search originates in the phone, but is actually performed using a cloud-based (e.g., web) service. In particular, the amount of the solvent to be used,is registered toAn application (for example) that maintains user contacts from all sources on the network. Whenever a call from an unidentified number is intercepted, a search is performed online (between the social graph of online phones) instead of the point-to-point mode between phones. That is, the search is over the phone andinter-cloud execution representing the aggregation of all user contacts from all possible social networksAnd (4) collecting. In addition, the method can be used for producing a composite materialThe search may be extended to the cloud by searching not only the user's own cloud but also the associated social networks of his contacts. For example, a contact from Facebook would be made by FacebookAnd (6) searching.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims (6)

1. A method, comprising:

monitoring (805) a call or message received by an electronic device from a sender, wherein the electronic device is associated with a user;

obtaining (810) metadata associated with an incoming call or message;

searching (815) a contact list associated with the user of the electronic device to locate a given individual associated with the metadata;

if no individuals associated with the metadata are found, sending (825) a first invisible text-based message to other electronic devices associated with at least some individuals included in the contact list, the first invisible text-based message including the metadata and requesting the other electronic devices to search their respective contact lists of the at least some individuals for the given individual associated with the metadata;

receiving (835), at the electronic device, a second invisible text-based message comprising the identity of the given individual from one of the other electronic devices; and

presenting (840) the identity of the given individual to the user of the electronic device.

2. The method of claim 1, wherein searching a contact list associated with the user of the electronic device comprises searching a social network of the user.

3. The method of claim 1, wherein searching the respective contact lists of the at least some individuals comprises searching a social network of the at least some individuals.

4. The method of claim 1, wherein searching a contact list associated with the user of the electronic device comprises searching an email client of the user.

5. The method of claim 1, wherein searching the respective contact lists of the at least some individuals comprises searching mail clients of the at least some individuals.

6. A method implemented on a mobile device of a user, comprising:

intercepting calls from unidentified numbers;

searching for individuals associated with the unidentified number using a cloud-based service, the searching including searching not only the user's own cloud but also associated social networks of the user's contacts.