HK1217853B - Intelligent sim selection supporting rich context of input factors - Google Patents

Description

Smart SIM selection with rich context supporting input factors

background

Mobile phones that accommodate multiple Subscriber Identity Module (SIM) cards are becoming increasingly popular. However, the user experience for such phones has fallen far short of expectations. For example, many of these phones still feature user interfaces and logic that were originally developed for a single SIM card, with multiple SIM functionality added as an afterthought. Others simply fail to accommodate the user expectations of handling multiple SIM cards.

For example, having more than one SIM card in a phone is a great feature, but there must be some mechanism for switching between SIM cards. One such mechanism uses a default SIM card technique. For example, if each SIM card has a phone book, the default SIM card can be selected based on the phone book where the number to be dialed is located. However, this overly simplistic approach ignores many usage scenarios and factors in which the user may want to enter the desired SIM card, as described herein.

Therefore, there is a lack of technology that can intelligently select a SIM card according to various communication situations.

Summary of the Invention

This Summary is provided to introduce some 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.

A wide variety of factors can be incorporated into determining which SIM card to use when communicating. As described herein, the SIM selection engine can consider a wide variety of factors, including the nature of the contact, contact information, related message content, past user behavior, time of day, location, and more. The flexibility of each technology allows SIM selection to evolve beyond the concept of a global default SIM, enabling a more granular level of selection of the appropriate SIM card based on the circumstances at hand.

Each technique can effectively predict which SIM the user will select and present the predicted options. However, as described herein, the user can override the prediction as desired.

In one embodiment, a method implemented at least in part by a computing system includes selecting a default SIM card; displaying a user interface depicting multiple contact details of a contact and an activatable user interface element for initiating communication with a specific contact detail of the contact; receiving activation of the user interface element; initiating communication with the specific contact detail via the default SIM card in response to the activation of the user interface element; and presenting a different SIM card as the default for another contact detail of the contact.

In another embodiment, a system for implementing a default SIM card includes a processor; a memory coupled to the processor; a SIM card default engine configured to output a default SIM card; and a default SIM card table, wherein the default SIM card table includes a mapping between contact information and a default SIM card, wherein the default SIM card table supports different default SIM cards for different contact information of the same contact.

In another embodiment, one or more computer-readable storage media include computer-executable instructions that cause a computer to perform a method for selecting a default SIM card for contact information associated with a contact, the method comprising: receiving a plurality of input factors including a source of the contact information; selecting a default SIM card for the contact information based on the source of the contact information, wherein the selection is further supported by factors including a SIM card on which the contact information is located, a SIM card from which the contact information was imported, and a most recent SIM card involved in communication activity with the contact information; and subsequently overriding the selected default SIM card for the contact information, wherein the overriding is supported by factors including an explicit selection received from a user interface and a signal strength associated with the default SIM card.

As described herein, various other features and advantages may be incorporated into the technology as desired.

BRIEF DESCRIPTION OF THE DRAWINGS

1 is a block diagram of an example system that implements a user interface for multiple SIM cards.

2 is a flow chart of an exemplary method presenting different user interface paradigms for interacting with multiple SIM cards.

3 is a block diagram illustrating an example system that implements a user interface paradigm selection engine to select a user interface paradigm.

4 is a flow chart of an exemplary method for selecting a user interface paradigm based on input factors.

5 is a block diagram illustrating an overview of exemplary navigation relationships between exemplary user interface types used in various communication scenarios.

6 is a wireframe of an exemplary main user interface implementing a SIM-detached user interface paradigm.

7 is a wireframe of an exemplary main user interface implementing a SIM aggregated user interface paradigm.

8 is a wireframe of an exemplary primary user interface implementing a hybrid between SIM-aggregated and SIM-separated user interface paradigms.

9 is a wireframe of an exemplary call history user interface implementing the SIM-split user interface paradigm.

10 is a wireframe of an exemplary call history user interface implementing the SIM aggregated user interface paradigm.

11 is a wireframe of an exemplary session list user interface implementing the SIM-split user interface paradigm.

12 is a wireframe of an exemplary conversation list user interface implementing a SIM aggregated user interface paradigm.

13 is a wireframe of an exemplary conversational user interface implementing the SIM aggregated user interface paradigm.

14 is a wireframe of an exemplary SIM indicator-switcher user interface set.

15 is a flow diagram of an example methodology that receives an indication that a call was made from a SIM card other than a selected SIM card.

16 is a block diagram of an example system that selects a default SIM card.

17 is a block diagram of exemplary tables associated with contacts and a default SIM.

18 is a screenshot of an exemplary user interface for a default SIM card showing contact information when initiating a call from a contact card user interface.

19 is a flow chart of an exemplary method for placing a call via the user interface described herein.

FIG20 is a diagram of an exemplary computing system in which some described embodiments may be implemented.

FIG. 21 is an example mobile device that can be used with the techniques described herein.

FIG. 22 is an exemplary cloud support environment that may be used in conjunction with the techniques described herein.

Detailed description

Example 1 - Exemplary Overview

The techniques described herein can be used in various multi-SIM scenarios and can provide improved communication techniques for multiple SIM cards. The user interface and the flow between them can better parallel common user scenarios. This can result in an overall superior user experience with greater internal consistency, fewer errors, and more efficient communication.

Both SIM-separated and SIM-aggregated user interface paradigms can be supported. The user can set preferences to control whether the user interface is aggregated. However, intelligent selection of user interface paradigms can select different paradigms based on anticipated user expectations.

The user can control whether communications are separated for each SIM or whether they are presented in an aggregated list to easily view communications from multiple SIMs at once. For example, a line-centric user can use a SIM-separate user interface paradigm, while a person-centric user can use a SIM-aggregated user interface paradigm.

The user can independently select different user interface paradigms for different communication types via preferences. For example, the user can choose to aggregate two SIM cards in the user interface for phone calls, but maintain separate user interfaces (e.g., entry points, conversation lists, etc.) for messaging.

Users can utilize the technology to easily switch between roles (eg, work, home, etc.) and maintain privacy.

The technology may be helpful to those who wish to provide users with more intelligent handling of communications in multiple SIM card scenarios. Beneficiaries may include those who develop software for devices that support multiple SIM cards. End users may also benefit from the technology because they can communicate more intuitively and conveniently.

According to the SIM-split user interface paradigm, the calling and messaging experiences for different SIM cards are separated by SIM card on a single device. This experience can simulate having two phones in one phone. Separate entry points into the two phone or messaging applications can be supported (e.g., via two different tiles as described herein).

Any number of techniques can be used to provide easily identifiable information that distinguishes between active or SIM cards. A name, number, color, icon, or a combination thereof can be associated with a specific SIM card. For example, a work SIM card can be associated with one color (e.g., blue), while a home SIM card can be associated with another color (e.g., red). The tile for the home line, as well as background call notifications, lock screen counts, and the accent color for any app that refers to the home SIM card, can be depicted in the home SIM card color.

The friendly name may be provided or selected by the user to differentiate between the two SIM cards and may be used throughout various user interfaces.

When communication is initiated, an appropriate default SIM card may be selected based on a number of factors as described herein, including communication activity. The SIM card default may be easily identified in the user interface, and a SIM card indicator-switch may be used to switch to another SIM card.

Various other features may be implemented and combined as described herein.

Example 2 - Example System Implementing a User Interface for Multiple SIM Cards

FIG1 is a block diagram of an exemplary system 100 that implements a user interface for multiple SIM cards as described herein.

For contextual purposes, FIG1 illustrates that a communication device 110 can access communication networks 105A, 105B via respective SIM cards 135A, 135B. The communication device 110 can be obtained or purchased with or without the SIM cards 135A, 135B, which fit into SIM card slots 130A, 130B. As described herein, some SIM cards can be software-based, so the card slots 130A, 130B are not strictly required.

Networks 105A, 105B may be provided by the same or different operators; likewise SIM cards 135A, 135B may be associated with the same or different operators.While two SIM cards are shown in this example, the technology may support additional SIM cards.

In this example, the communication device 110 can display any of a variety of user interfaces. A user interface paradigm selection engine 120 can select a user interface paradigm, which can be implemented by user interface definitions 122. Both SIM aggregation definitions 125 and SIM separation definitions 127 can be supported to display a user interface (e.g., on a display of the device 110) that implements the SIM aggregation paradigm, the SIM separation user interface paradigm, or both. As described herein, the engine 120 can control which user interface type is displayed and according to which paradigm. Although the engine 120 is depicted as a discrete component, in practice, the user interface functionality can be integrated throughout the communication device 110 and can be implemented via an operating system, applications, or a combination thereof, implemented in hardware, software, or both.

The stored SIM configuration data 140 may include a SIM card label 145 (e.g., SIM card number, friendly name, etc.). Information from the configuration data 140 may be displayed in a user interface. Other configuration settings may include one or more paradigm preferences 147 of the user regarding which user interface paradigm is preferred, which may be different for different communication types (e.g., calls and messages). Although the information is shown as being stored together in the examples, in practice, the data may be distributed throughout the system.

Further information for the user interface can be extracted from call history 150 and session history 170. As described herein, defaults engine 160 can take input from call history 150 and session history 170 to determine default values (e.g., SIM card defaults). Alternatively, a running table of default values per contact can be maintained. A combination of these techniques can be used. For example, default values can be set based on history with a contact and then overridden as the user deems appropriate.

Although the engine 120 and the SIM configuration data 140 are shown in separate boxes, in practice, the component boundaries may vary. For example, each component may be provided as part of a phone operating system, an application, etc. Other arrangements are possible while still implementing the described technology.

In practice, systems such as system 100 shown here may be more complex, with additional functionality, more SIM cards, more networks, and so on.

Any of the system 100 and other systems described herein can be implemented in conjunction with any of the hardware components described herein, such as the computing system described below (e.g., processing unit, memory, etc.). In any of the examples described herein, inputs, outputs, and tools can be stored in one or more computer-readable storage media or computer-readable storage devices. The techniques described herein are general to the specifics of the operating system or hardware and can be applied in any of a variety of environments to utilize the features described.

Example 3 - Exemplary User Interface Example

In any of the examples herein, the user interface can implement a SIM-separated user interface paradigm, a SIM-aggregated user interface paradigm, or both.

The user interface can implement the SIM-split user interface paradigm by separating (or separating) communications, contacts, or communication events for each SIM card into different user interface elements, lists, screens, etc. In the SIM-split user interface paradigm, the user interface elements, lists, screens, etc. can be limited to a single SIM card (e.g., depicting only information for a single SIM card). Another way a user interface can implement the SIM-split user interface paradigm is by presenting different user interface elements for navigating to the SIM-split user interface (e.g., one user interface element for navigating to the SIM-split user interface for a first SIM, and another user interface element for navigating to the SIM-split user interface for a second SIM). Thus, there can be multiple separate user interfaces or elements for a corresponding number of SIM cards represented. The SIM-split user interface can be limited to information related to communications transmitted or received via a single SIM card.

The user interface can implement the SIM aggregation user interface paradigm by presenting communications, contacts, or communication events for multiple SIM cards in a single instance of a user interface element, list, screen, etc. Another way the user interface can implement the SIM aggregation user interface paradigm is by presenting a single user interface element for navigating to a SIM aggregation user interface that aggregates multiple SIM cards (e.g., a user interface element for navigating to a SIM aggregation user interface that presents communications, contacts, or communication events for both a first SIM and a second SIM). Thus, the SIM aggregation user interface can display information related to at least one communication transmitted or received via the first SIM card and information related to at least one communication transmitted or received via a different second SIM card.

Because the SIM-separated user interface paradigm effectively presents different communication lines to the user, it is sometimes referred to as a "line-centric" user interface. On the other hand, the SIM-aggregated user interface paradigm can transparently blend different communication lines and group information based on people or contact numbers. Therefore, the SIM-aggregated user interface paradigm is sometimes referred to as a "person-centric" user interface.

Users can utilize their preferred user interface paradigm. For example, a line-centric user may value the distinction between the two lines and may utilize them for different situations (e.g., work vs. personal, or domestic vs. international). A person-centric user may communicate with the same group of people via both lines and may not strongly differentiate between the two lines, simply choosing the best option based on the situation.

The user interface may contain both SIM separate user interface paradigm elements and SIM aggregate user interface paradigm elements.For example, certain types of communications may be aggregated while other types of communications may be separate.

Example 4 - Exemplary SIM Aggregated Version of User Interface Elements

In any of the examples herein, various SIM-aggregated versions of user interface elements may be presented in a user interface that implements the SIM-aggregated user interface paradigm. While some examples are listed in Table 1 below, other examples may be implemented by aggregating lists, messages, indications, or other information or functionality across multiple SIMs.

Table 1 - SIM aggregate versions of user interface elements

Example 5 - Exemplary User Interface Preferences

In any of the examples herein, one or more stored user interface paradigm preferences may be implemented. Such preferences may indicate whether the user wishes to configure the user interface for a SIM-separated or SIM-aggregated scenario. To aid understanding of the preferences, they may be displayed with friendly names such as "link," "aggregate," "merge," and the like. Separate stored preferences may be implemented for different communication types (e.g., a preference for calls and a preference for messaging).

The user interface paradigm can be changed according to the stored paradigm preferences. In this way, the same user interface type can be presented according to two different user interface paradigms at different times (e.g., on the same device, depending on the preferences). As described herein, factors other than user preferences can also be taken into consideration.

The indication of the example preferences may be received from a setup user interface or during one of the types of user interfaces described herein (eg, a call history or conversation list user interface).

Example 6 - Exemplary Method for Presenting Different User Interface Paradigms for Multiple SIM Cards

FIG2 is a flow chart of an exemplary method 200 presenting different user interface paradigms for interacting with multiple SIM cards, such as may be implemented in the system shown in FIG1. As with other methods described herein, the order of the actions may not be significant (e.g., the actions may be reversed, etc.).

At 210, a first user interface implementing a SIM detach user interface paradigm is presented. The first user interface can be any of the various user interface types described herein.

At 240, a second user interface implementing the SIM aggregation user interface paradigm is presented. While direct navigation from the first user interface to the second user interface may be supported, additional user interfaces may be presented between the two user interfaces. The first user interface and the second user interface may be of the same user interface type. Alternatively, two different user interface types may be presented.

User input may be received via the user interface, and in response to the input, navigation to another user interface may be enabled, or one or more communication actions may be performed via the appropriate SIM.

As described herein, any number of factors may be taken into consideration when selecting which paradigm to present. For example, selecting a user interface paradigm may be based at least on stored user interface paradigm preferences, the user interface type being displayed, etc. As described herein, some user interface types may be presented according to a particular paradigm even if the user interface preferences indicate a different paradigm.

As described herein, in certain situations, a user interface may morph from one user interface paradigm to another.A hybrid user interface may implement both SIM-separated and SIM-aggregated paradigms.

Method 200 and any of the other methods described herein may be performed by computer-executable instructions stored on one or more computer-readable media (eg, storage or other tangible media) or stored in one or more computer-readable storage devices.

Example 7 - Exemplary User Interface Example Selection

3 is a block diagram illustrating an exemplary system 300 that implements a user interface paradigm selection engine for selecting a user interface paradigm. In this example, a communication device 305 (e.g., the communication device 110 of FIG. 1 ) includes a user interface paradigm selection engine 320 that accepts one or more input factors 310 and applies rules 322 to select a user interface paradigm 350. The engine 320 can support both a SIM-separated user interface paradigm and a SIM-aggregated user interface paradigm.

As described herein, input factors 310 may include one or more user interface paradigm preferences 147, the type of user interface to be displayed 349, etc. In practice, selected user interface paradigm 350 may include a reference to one of user interface definitions 122 (e.g., as shown in FIG. 1 ), which is then used to present a user interface according to the selected user interface paradigm.

The engine 320 may then select the appropriate example 350 via application of rules 322 as described herein.

FIG. 4 is a flow diagram of an exemplary method 400 for selecting a user interface paradigm based on input factors, such as may be implemented in the system shown in FIG. 3 .

At 420 , one or more input factors as described herein are received.

At 430 , a user interface paradigm is selected based on the input factors.

In practice, a user interface that implements the selected user interface paradigm is then displayed on the display.Any of the user interface types or features described herein may be implemented accordingly.

Example 8 - Exemplary Input Factors, Rules, and Example Selection

The input factors for selecting between the user interface paradigms described herein can take any of a variety of forms. For example, user preferences (such as one or more user interface paradigm preferences that can be used to indicate a SIM-separated user interface paradigm or a SIM-aggregated user interface paradigm) can serve as input factors. The type of user interface displayed (e.g., any of the user interface types described herein) can serve as input factor 310.

Selection rules can support various scenarios and provide intelligent selection of user interface paradigms. For example, the user's preferences can be respected, and different preferences for different user interface types can be supported (e.g., one preference for calls and one preference for messages).

Furthermore, in certain scenarios, it may be desirable to override a user's preferences. For example, when presenting a conversational user interface, a SIM aggregated user interface paradigm may be presented even when the paradigm preference indicates a SIM separate paradigm. The same may be true for the address book (e.g., to present contacts from both SIMs in an aggregated user interface). Rules may be configured as needed to implement the desired behavior for the user interface paradigm selection.

The rules may be implemented in conjunction with a table such as that shown in Table 2 below to determine which user interface paradigm to display. The table may be stored in memory and consulted when displaying a user interface. In practice, the user interface type may be stored as a user interface type identifier. The user interface paradigm may be stored as an identifier, where a special identifier is used to indicate "according to user preference." Alternatively, the user interface paradigm identifier may be updated when preferences change. The rule may select a user interface paradigm based on the table. In this example, the conversational user interface is presented based on the SIM-aggregated user interface paradigm, regardless of user preference. Other arrangements are possible (e.g., the address book is aggregated regardless of user preference). User preferences may be set globally or per user interface type.

UI Type UI Examples Call History Based on user preferences Session SIM aggregation Session Summary Based on user preferences

Table 2 - Table used with rules for determining user interface paradigms

Example 9 - Example Activation

In any of the examples herein, an activatable user interface element can take the form of a displayed or implied user interface element that can be activated by a user. Such an element can take the form of a tile, button, area, item in a list, shape, slider, etc., presented as part of a graphical user interface. The user interface element can include text or an icon to indicate functionality.

Activation (e.g., of an activatable user interface element) can take the form of user input indicating selection (e.g., of an activatable user interface element). For example, in a touch-enabled system, a tap, hover, or other touch gesture can be received. Other systems may support click, hover, voice activation, wink, wink, etc.

Example 10 - Exemplary Contact Information

In any of the examples herein, various number types (e.g., home, mobile, work, etc.) may be supported. Contact information may take the form of a contact or a number associated with the contact. For example, the contact information may be a phone number or user address of the contact, such as the contact's work number, the contact's mobile number, or the contact's home number. As described herein, being able to distinguish between different contact information for a single contact may be useful when engaging in communications (e.g., using a work SIM to call a contact using their work number).

Example 11 - Exemplary Communication

In any of the examples herein, the supported communication types may include calls, messaging, etc. Calls may be voice calls, video calls, etc. Messaging may take the form of text messaging, SMS messaging, MMS messaging, OTT messaging, etc. and may also support extended content (e.g., audio, video, images, etc.).

Participating in such communications may include making or receiving calls, sending or displaying text messages, etc. The number may include a phone number or other code for making calls. The user address may include a social network address or other code for sending messages.

Example 12 - Exemplary SIM Card

In any of the examples herein, a SIM (Subscriber Identity Module) card (or simply "SIM") can take the form of any size SIM card (e.g., mini-SIM, micro-SIM, full-size, etc.). These cards are typically used in mobile phones operating on the Global System for Mobile Communications (GSM) network. However, other communication devices (e.g., tablets, hybrids, etc.) and other networks can be supported.

Although the term "SIM" is used, this language is intended to include a Universal Integrated Circuit Card (UICC), a virtual SIM card, a Removable User Identity Card (R-UIM), or any other hardware or software that can be used to provide an independent identity on a communication device. For example, such an identity can be identified by an International Mobile Subscriber Identity (IMSI) or the like. CDMA implementations, including hybrid CDMA/GSM implementations, may also be supported.

Example 13 - Exemplary Non-SIM Implementation

In any of the examples herein, the techniques described as being specific to SIM cards can equally be applied to other scenarios that provide separate communication links, such as voice over Internet protocol (VOIP), social network communications, and the like. In this case, both line aggregation and line separation user interface paradigms can be supported, where lines are defined as one or more SIM cards, one or more non-SIM lines, or both. Hybrid environments can be supported. For example, SIM cards can be aggregated with VOIP usernames, etc. Multiple VOIP lines (e.g., home, work, etc.) can be supported. In such an implementation, usernames, user addresses, etc. can be used instead of phone numbers. The operator in such an implementation can be the service or line provider.

Example 14 - Exemplary Multiple SIM Cards

In any of the examples herein, the present technology can support multiple SIM cards. For convenience, the term "dual SIM" is sometimes used, and two SIM cards are shown. However, multiple SIM cards (i.e., any number more than one) can be supported. Some SIM cards support more diverse features than others. The technology herein can support SIM cards with different functionalities.

Example 15 - Exemplary SIM Card Tag

In any of the examples herein, a SIM card label may take the form of a text string, a number, a color, or other indication that identifies a particular SIM card from among multiple SIM cards. For example, a simple default SIM card label may be a number (e.g., "1," "2," etc.) or a letter (e.g., "C" for CDMA, "G" for GSM, etc.). The carrier name associated with the SIM card (e.g., "T-Mobile," "AT&T," etc.) may be used in place of or in addition to the number.

Friendly names (eg, "Home," "Work," etc.) may be supported as labels to help users easily identify which SIM card is which.

When multiple SIM card labels are displayed, they may indicate different SIM cards installed on the communication device. In some cases, it may be desirable to use two labels to indicate SIM cards in a single user interface element. For example, a single-digit number (e.g., "1") and an operator name (e.g., "Operator X") or a friendly name (e.g., "Home") may be presented in a single user interface element.

Example 16 - Exemplary Color Indications

In any of the examples herein, a SIM card can be configured to be associated with a color. As a result, user interface elements associated with the SIM card can be depicted using the color associated with the corresponding SIM card. Color selection can be achieved through user preference, system selection, etc. as described herein.

Example 17 - Exemplary User Interface Type

In any of the examples herein, the user interface type can take the form of any of a variety of user interfaces used in communication scenarios for presenting information, collecting information, or both. Such user interface types can include a home screen, call history, recent calls, contact cards (e.g., profiles), conversation lists (e.g., conversation summaries, threads, etc.), conversations, lock screen, address book, call in progress, incoming calls, keypad, etc.

As described herein, the same user interface type may be presented as either a user interface paradigm that implements SIM separation or a user interface paradigm that implements SIM separation, depending on various factors. In some cases, a user interface type may be presented as implementing some, all, or none of its elements according to one or another paradigm, depending on various factors.

Example 18 - Overview of Exemplary Navigation Relationships

FIG5 is a block diagram illustrating an overview of exemplary navigational relationships between exemplary user interface types 500 used in various communication scenarios supported by examples herein.

From the primary user interface 510, the device can navigate to the call history 550, the conversation list 560, or otherwise (eg, in response to activation of a user interface element on the primary user interface 540).

From the conversation list user interface 560 , navigation to the conversation user interface 562 can be supported (eg, in response to activation of a user interface element on the conversation list user interface 560 ).

As a result of activation of a user interface element in call history user interface 550, a call may be placed at 555. Therefore, call history user interface 550 is sometimes referred to as a "call origination" or "call incoming" user interface.

As a result of activating a user interface element in the conversation user interface 562, a message can be sent at 565. Therefore, the conversation list user interface 560 is sometimes referred to as a "message initiation" or "message incoming" user interface. The message is actually sent from within the conversation user interface 562.

Although ordered navigation is shown in this example, in practice, navigation in different directions and navigation directly to a desired user interface type can be supported for user convenience. For example, if a notification about an incoming message is shown, activation of the notification can navigate directly to the conversations 562 user interface without presenting the conversations list 560 user interface.

Additional user interfaces may be supported. For example, a contact card user interface may be implemented that can be reached from a call history or session. Such a contact card user interface may be used to initiate a call.

Example 19 - Exemplary Main User Interface

In any of the examples herein, a primary user interface may be supported. Such a user interface may present various possible functionalities via different user interface elements and is typically presented in response to receiving an indication that a primary interface is to be presented (e.g., by activating a home button, etc.). For example, different tiles, icons, etc. may be presented through which a user may access communication functionality.

FIG6 is a wireframe diagram of an exemplary primary user interface 600 implementing a separate SIM user interface paradigm. In this example, the primary user interface presents a separate SIM user interface paradigm for call initiation user interface elements 610A and 610B, which are associated with respective SIM cards. In response to activation of element 610A, a user interface implementing the separate SIM user interface paradigm for the respective associated SIM card is presented, from which a call can be placed (e.g., a call history user interface). Because elements 610A and 610B can be used to initiate calls, they are sometimes referred to as "call incoming" user interface elements. As shown, user interface elements 610A and 610B can be implemented as tiles.

Similarly, message initiation UI elements 620A and 620B may be associated with respective SIM cards and presented according to the SIM-separate UI paradigm. In response to activation of one of the elements 625, a conversation list UI implementing the SIM-separate UI paradigm of the respective associated SIM card is presented.

To help distinguish the user interface elements 610A, 610B, 620A, 620B, they can be depicted in the color associated with the SIM card being represented. So, one or more user interface elements 610A, 620A for initiating communication via a first SIM card can be depicted in the color associated with the first SIM card (e.g., SIM 1), while one or more user interface elements 610B, 620B for initiating communication via a second SIM card can be depicted in the color associated with the second SIM card.

Different icons associated with call communications may be depicted with (e.g., depicted within) the call elements 610A, 610B (e.g., handset, phone, voice icon, etc.), while different icons associated with message communications may be used on (e.g., depicted within) the message elements 620A, 620B (e.g., message balloons, emoticons, etc.).

Additionally or alternatively, one or more SIM card labels 615A as described herein may be included on interface elements 610A, 610B, 620A, 620B.

Information related to activatable functionality can be presented in user interface elements 610A, 610B, 620A, and 620B according to the SIM-separated user interface paradigm. For example, in call elements 610A and 610B, an indication or number of missed calls for the associated SIM card can be displayed. Similarly, an indication or number of new voicemail messages can be displayed. In message elements 620A and 620B, an indication or number of unread messages for the associated SIM card can be displayed.

In practice, various other user interface elements for accessing additional features, such as a calendar 630 , an address book 640 , and others 650 , may be presented as part of the main user interface 600 .

FIG7 is a wireframe of an exemplary main user interface 700 implementing a user interface paradigm for SIM aggregation. User interface 700 can be similar to the user interface shown with respect to FIG6 , except that only a single user interface element 710 for initiating a call is shown, even if there are multiple active SIM cards in the phone (e.g., user interface elements 610A and 610B for the user to initiate a call have been collapsed into a single user interface element 710). Thus, a single user interface element represents multiple SIM cards. Activating user interface element 710 initiates communication without explicitly specifying a SIM card.

In response to activation of the call element 710, a call history user interface is presented that implements a SIM aggregated user interface paradigm for multiple SIM cards. Such aggregated SIM cards or their call histories are sometimes referred to as being "linked".

Similarly, a single message initiation user interface element 720 may be presented for multiple SIM cards. In response to activation of the message element 720, a conversation list user interface is presented that implements the SIM aggregation user interface paradigm for multiple SIM cards. Likewise, such SIM cards or their conversation lists are sometimes referred to as being "linked."

In some cases, a default SIM card will be selected for aggregated voice or text elements. To help identify the functionality of user interface elements 710, they can be depicted using a color associated with the default SIM card, which can be the same or different for each element. As shown in Figure 6, different icons can be used to distinguish between calls and messages. Additionally or alternatively, one or more SIM card labels identifying the default SIM card can be included on user interfaces 710, 720.

Information related to the activatable functionality can be presented in user interface elements 710 and 720 according to the SIM aggregation user interface paradigm. For example, in the call element 710, an indication or number of missed voice calls for each SIM card (e.g., if multiple SIM cards are combined) can be displayed. Similarly, an indication or number of new voicemail messages (e.g., if multiple SIM cards are combined) can be displayed. In the message element 720, an indication or number of unread messages for each SIM card (e.g., if multiple SIM cards are combined) can be displayed.

In some cases, a hybrid of user interface paradigms can be presented. FIG8 is a wireframe of an exemplary main user interface 800 that implements a hybrid between SIM-aggregated and SIM-separated user interface paradigms. Call user interface element 810 can function like call user interface element 710 of FIG7 , while message user interface elements 820A, 820B can function like message user interface elements 620A, 620B of FIG6 . Thus, user elements that implement a SIM-aggregated user interface for user calls and a SIM-separated user interface for messaging can be presented as part of the same user interface, or vice versa. In this example, user interface 800 is configured to aggregate user interface elements for one type of communication (e.g., calls) and separate user interface elements for another type of communication (e.g., messages). The opposite configuration can also be easily supported.

Example 20 - Exemplary Separate User Interface Elements

In any of the examples herein, when different user interface elements are displayed based on the SIM card separation scenario, the user interface elements can be resized (e.g., to different sizes) and moved within the user interface as needed (e.g., placed in different arbitrary locations within the main user interface). As described herein, the user interface elements can continue to display different information for the associated SIM card (e.g., the number of missed calls, etc.).

Example 21 - Exemplary Signal Strength Plot

Some user interface elements (such as signal strength) can be presented in any user interface type. Such elements can be depicted consistently for different SIM cards separately, regardless of the configuration settings. An example is shown in Figure 6.

Alternatively, a single signal strength meter may be shown (eg, for the default SIM). Through the SIM switching functionality described herein, different signal strength meters may be displayed (eg, for a selected SIM card).

Example 22 - Exemplary Call History User Interface

In any of the examples herein, a call history user interface may be supported. This call history may relate to voice calls, video calls, and the like, and may be used to engage in communications with listed contacts. FIG9 is a wireframe diagram of an exemplary call history user interface 900 implementing a SIM-split user interface paradigm. In this example, the list of calls 920A-N is limited to calls from a single SIM card and listed in reverse chronological order. The representation of call 920 may include displayed contact information (e.g., name, communication action type, time, number type, etc.).

As described herein, user interface 900 can be presented (e.g., on a primary user interface) in response to activation of a user interface element representing a single SIM. The single SIM can be indicated via label 904 appearing in a prominent position, thereby confirming which SIM card was selected by the previous activation.

As described herein, a SIM indicator-switch user interface element set can be presented to facilitate switching SIM cards. Indicator-switch 910 can be customized for call history (e.g., it can state "Return call using," etc.). Any call from user interface 900 can be made using the SIM indicated by indicator-switch 910.

Within the list of calls 920A-N, certain special events (such as missed call 924) may be depicted with a distinctive color, such as a color associated with an individual SIM card.

By activating a user interface element associated with a number, a call can be placed to the contact indicated in the list (e.g., name and number type equivalent to the number). For example, activation of user interface element 922 or elsewhere in representation 920A of the call can be used. A separate depiction of element 922 and representation 920A is not required. For example, activating representation 920A of the call may be sufficient. Alternatively, activating representation 920A of the call can navigate to the contact card of the indicated contact.

Additional user interface elements 960 may be presented. For example, an address book user interface element, a voicemail user interface element, a search user interface element, a keypad user interface element, etc. may be presented. Separately, a user interface element may be provided that links the histories of multiple SIM cards. In one implementation, a secondary user interface element may be activated that displays less frequently used features (e.g., delete all messages, settings, etc.). The list may include a "link history" command that changes the configuration so that the call history of the SIM card is aggregated with the call history of another SIM card. As a result, the call history may be changed to implement a SIM-aggregated user interface paradigm, and the main user interface may collapse two user interface elements into one to initiate a call. For example, the next time tiles are displayed as part of the home screen, only one tile will be displayed for multiple (e.g., two) SIM cards. In the SIM-aggregated user interface paradigm, instead of having a separate activatable user interface element for each SIM card, one activatable user interface element may represent multiple SIM cards.

The configuration may be stored as settings indicating that a SIM aggregated user interface is to be presented for each SIM (eg, for a call).As described herein, linking may be performed separately for call communications and message communications.

Before linking occurs, information can be displayed to educate the user about the behavior associated with the linked user interface. If necessary, the user can be given the option to cancel the link.

User interface 900 can also be presented as a user interface example that implements SIM aggregation. Figure 10 is a wireframe of an exemplary call history user interface that implements the user interface example of SIM aggregation. Some elements of the user interface can remain unchanged, but other elements can be depicted differently depending on the example.

For example, a generic indication 1004 (eg, "phone") may be used instead of SIM-specific labels. The list of calls 1020A-1020N may include at least one call 1020A for a first SIM card and at least one call 1020B from a second SIM card.

Within the list of calls 1020A-N, certain special events (such as missed call 1024) may be depicted with a distinctive color, such as a color associated with the SIM card associated with the event (e.g., within user interface 1000, different colors indicate different SIM cards).

A label 1026 may be included within the representation of call 1020B to indicate the SIM card used for the call.

A call may be initiated in a manner similar to that described with respect to FIG9 . The call may be answered using the SIM indicated in the SIM indicator-switch. User interface 1000 may be modified to implement a user interface paradigm for SIM separation (e.g., via an unlink feature) in a manner similar to that used for linking.

Example 23 - Exemplary Default SIM for Aggregated User Interface

In any of the examples described herein, for the aggregated user interface, the default SIM can be based on user preference, the first SIM placed in the device, a default card slot (e.g., where the SIM is inserted on the hardware), the SIM that was used first, etc. Such a SIM is sometimes referred to as a "primary" SIM.

The default can also be the last SIM used (for a given communication type), either globally or for a specific interface type. So, if the last call was on the first SIM, the default for calls could be the first SIM. If the last message was on the second SIM, the default for messaging could be the second SIM. In some cases, a clear default may not be determined by rules, so the primary SIM could become the default.

A default SIM may also be selected based on input conditions as described herein.

Example 24 - Exemplary Conversation List User Interface

In any of the examples herein, a conversation list user interface can be supported as a user interface paradigm that implements either a SIM-separated or SIM-aggregated interface. The conversation list user interface can present a summary list of conversations (e.g., messages grouped by contact or number). Because a conversation can be conceived as a string or thread of linked messages that make up a conversation (e.g., with a contact or contact), the conversation list is sometimes referred to as a "thread." FIG11 is a wireframe of an exemplary conversation list user interface that implements the SIM-separated user interface paradigm. In the example, the list of conversations 1120A-N is limited to those for a single SIM and listed in reverse chronological order. As described herein, user interface 1100 can be presented in response to activation of a user interface element representing the single SIM (e.g., on a primary user interface). The single SIM can be indicated by a label 1104 that appears in a prominent position, confirming which SIM card was selected by an earlier activation.

In the list of conversations 1120A-N, certain special events, such as unread messages 1124 (eg, unread in the conversation application interface), may be depicted in a distinctive color, such as a color associated with a single SIM card.

A message to a contact indicated in the list can be initiated by activating a user interface element associated with the contact. For example, activation of a location in representation 1120A or a separate user interface element can be used. Other arrangements are also possible.

Additional user interface elements 1160 may be presented. For example, a user interface element may be provided that links conversation lists for multiple SIM cards. In one implementation, a secondary user interface element may be activated that displays a list of lesser-used features (e.g., deleting all messages, settings, etc.). The list may include a "link conversation lists" command that changes the configuration so that the conversation list for one SIM card is aggregated with the conversation list for another SIM card. Thus, the conversation list user interface may be changed to implement a SIM-aggregated user interface paradigm, and the primary user interface may collapse the two user interface elements into one for initiating a message. This configuration may be stored as a setting indicating that a SIM-aggregated user interface is to be presented for each SIM card (e.g., for messages).

User interface 1100 may alternatively implement the SIM aggregated user interface paradigm. Figure 12 is a wireframe of an exemplary conversation list user interface 1200 that implements the SIM aggregated user interface paradigm. Some elements of the user interface may remain unchanged, but other elements may be described differently according to the paradigm.

For example, a generic indication of messaging 1204 can be used instead of a SIM-specific label. A list of conversations 1220A-1220N can include at least one message 1220A from a first SIM card in one summary conversation and at least one message 1220B from a second SIM card in another summary conversation. The conversations themselves do not need to be grouped together in the list, but this can be done.

In the list of conversations 1220A-N, certain special events, such as unread messages 1224, may be depicted in a distinctive color, such as a color related to the SIM card associated with the message (eg, different colors indicate different SIM cards within user interface 1000).

A tag 1226 may be included in the representation of the conversation 1220B to indicate the SIM card of the message.

The message may be initiated similarly to that described in Figure 11. The user interface 1200 may be modified to implement the user interface paradigm of SIM separation in a manner similar to that used for linking (eg, through an unlink feature).

Example 25 — Exemplary Conversational User Interface

In any of the examples herein, a conversational user interface may be presented. Although, in the examples, only SIM aggregation user interface example implementations are shown, SIM isolation implementations are also possible and may be controlled by user preferences or other factors as described herein.

The conversation user interface can present a conversation as a thread of messages grouped by contact (e.g., name, number, etc.). As described herein, the conversation user interface can depict the entire conversation even if it spans multiple SIM cards (e.g., different SIM cards are used for messages). In this way, a conversation can be shown in a single conversation user interface for messages communicated through multiple SIM cards.

Figure 13 is a wireframe of an exemplary conversation user interface 1300 implementing a SIM aggregation user interface paradigm. In this example, a list of messages 1320A-E from multiple SIM cards is aggregated and listed in chronological order. As described herein, user interface 1300 can be presented in response to activation of a user interface element representing the conversation (e.g., on a conversation list user interface). SIM aggregation user interface 1300 can be presented regardless of whether the SIM card is aggregated for other user interfaces (e.g., even if a user preference indicates that a SIM-split user interface for messaging should be presented). In this way, the continuity of the conversation can be maintained regardless of the previously displayed user interface paradigm. The split paradigm preference can indicate whether the conversation should be aggregated regardless of the messaging preference.

In the case of aggregation, the default SIM may be based on user preference, the first SIM placed in the device, a default card slot (e.g., where the SIM is inserted on the hardware), the first SIM used, etc. Alternatively, a default SIM may be used that is independent of the contact details as described herein.

In implementations of SIM isolation, various techniques can be used to easily communicate which row to use for each message. For example, in other examples, labels indicating a single SIM card can be presented. Messages 1320A-E can be presented in a color associated with the corresponding SIM card (e.g., a first message can be a first color, while a second message on a different SIM card can be a second, different color).

By typing a message in the text message box 1330 and activating the send user interface element 1345, the message can be sent to the indicated contact. Other user interface elements 1340 can provide additional functionality (e.g., attaching a picture, taking notes, etc.). Although not shown, a virtual keyboard can be activated to assist in typing the message.

SIM card indicator-switcher user interface assembly 1310 can both indicate which SIM card will be used to send the message and accept SIM card switching. In practice, interface assembly 1310 can be positioned in a different location (e.g., top right) and may or may not be near text message box 1330. The description "send using" can be used in conjunction with the indicator-switcher. If the conversation is ongoing on a single SIM card, a message sent by or received from another SIM card causes the user interface to change significantly from the SIM-separated user interface paradigm to the SIM-aggregated user interface paradigm.

A method for presenting a conversational user interface across multiple SIM cards may include displaying a first message communicated with a first SIM card and a second message communicated with a second SIM card in the same user interface. For example, the message may be received via a receiving SIM other than the SIM used to send the message to the contact. Furthermore, the received message may be displayed as part of the conversational user interface.

Similarly, if a text message is sent using the conversational user interface using a SIM card other than the default SIM, after sending the message, the message may be shown as part of the conversational user interface (eg, part of a conversation displayed in the user interface).

Example 26 - Exemplary Lock Screen User Interface

In any of the examples herein, a lock screen user interface may be supported. Such a user interface may depict a summary of information that allows the user to glance at the interface and determine the communication status without having to enter an unlock code. Such functionality is sometimes referred to as an "above lock" functionality.

For example, signal strength, current date and time, upcoming appointments, etc. may be shown.

The lock screen can implement the SIM split user interface paradigm by presenting separate numbers or indicators for the separate SIM cards, such as missed call indicators, new voice message indicators, unread text message indicators, etc. Such information can be labeled with one or more SIM card labels indicating which SIM it is associated with.

The lock screen can implement a SIM aggregation user interface paradigm by presenting a missed call indicator, a new voice message indicator, an unread text message indicator, and the like in a combined number or indicator format. As described herein, call and text functions can be separated or aggregated separately. For example, calls can be aggregated while messaging can be separated, or vice versa.

Example 27 - Exemplary Other User Interface Types

For the sake of brevity, a complete description of other user interface types is not presented. User interface features described as used in other user interface types can be used with such user interfaces.

Examples include an incoming call user interface (e.g., displaying the label of the SIM receiving the call), a call in progress user interface (e.g., displaying the labels of the SIMs involved in the call and highlighting user interface elements in a color associated with the SIMs involved), a keypad user interface (e.g., displaying a SIM indicator-switcher as described herein), an address book (e.g., which can be aggregated or split), and the like.

The recent call and recent contact user interface can function in a similar manner to the call history user interface by listing recent activities.Such recent calls or recent contacts can be presented as part of an address book.

In an aggregated scenario, a user interface such as a keypad may use SIM defaults as described herein (eg, for aggregated call history).

Background user interface techniques can be used to display calls, recently received messages, new voicemails, and the like in the background. For example, a pop-up bar at the edge (e.g., top) of the user interface can be used. One or more SIM card labels can be included in the bar to indicate the SIM card in question. The bar can be a color associated with the SIM card in question.

Example 28 - Exemplary SIM Card Switching

In any of the examples herein, a default or current SIM card can be switched to another SIM card. For example, during various user interfaces described herein, an indication can be received indicating that the default SIM card is to be switched to another, selected SIM card. In response to such an indication, a communication (e.g., to a selected contact) can be initiated using a SIM card other than the default SIM card (e.g., the selected SIM card).

Example 29 - Exemplary SIM Indicator-Switcher User Interface Set

In any of the examples herein, the SIM indicator-switch can take the form of a SIM indicator-switch user interface set or other mechanism as described herein. As described herein, such a SIM indicator-switch or other mechanism can appear as part of a call history user interface, etc. The user interface can be presented consistently across both SIM-separated and SIM-aggregated user interface paradigms.

FIG14 is a wireframe diagram of an exemplary SIM indicator-switcher user interface set 1400. The set may include multiple SIM user interface elements 1410A-B corresponding to supported SIM cards (e.g., one element for each SIM card). For example, a dual-SIM implementation may have two SIM user interface elements. The user interface elements may include a label indicating the represented SIM card. In one implementation, a simple number (e.g., "1") is used as the label indicating the SIM card. Other short or single-character labels (e.g., "W" for work) are also possible.

Additional labels with optional descriptions 1426 may also be included. Additional labels and descriptions 1426 may be customized for a particular use case while maintaining a consistent user interface across user experiences. The labels and/or descriptions may be depicted in a color associated with the SIM card associated with the element.

SIM user interface elements 1410A-B may indicate the current (e.g., default) SIM card (e.g., the SIM card to be used when engaging in communications) by clearly depicting it. For example, it may be highlighted, bolded, blinking, etc. It may also be depicted in a color associated with the represented SIM card. One or more user interface elements 1410A for non-current SIM cards may be depicted plainly. For example, they may be colorless, grayed out, solid, non-blinking, etc.

Thus, in effect, one of the elements 1410B is uniquely depicted (eg, in a color associated with the SIM card), while the other 1410A is not (eg, is grayed out). Switching SIM cards can be accomplished by activating a non-unique element in the set.

Activation of a user interface element associated with a non-current SIM card may switch to the selected SIM card (e.g., the SIM card associated with the activated user interface element). Such activation may also participate in the communication (e.g., to avoid additional activation). However, in some cases, it may be desirable to wait for additional activation (e.g., when sending a message). Once the SIM card is activated, the display may be changed to reflect the activation (e.g., the current SIM card is changed).

Example 30 - Exemplary SIM Switching Alternative

In any of the examples herein, SIM switching can be accomplished in a variety of other ways. For example, in any of the user interfaces shown herein, instead of showing a separate SIM indicator-switch, special activation of a listed contact can be supported. Special activation (e.g., of a contact) results in an option being displayed to engage in communication using a different SIM (e.g., the SIM being listed as a selectable option).

The special activation may take the form of a tap and hold activation (e.g., of a contact). Alternatively, a special user interface element (e.g., a chevron) may be displayed (e.g., approaching a contact). In response to the special activation, a different SIM card may be listed as a selectable option, thereby causing a SIM card switch.

Other possible techniques include arbitrary activation of the displayed list of SIM card tabs; activation of the SIM card tab to switch or cycle between SIM cards; activation of the SIM card tab to result in a pop-up list of SIM cards from which a SIM card can be selected, etc. Swipes, swipes, bumps, shakes, voice commands, etc. may also be used.

Other user interface elements may be used to achieve similar results.

Example 31 - Exemplary SIM card switching method

FIG15 is a flow chart of an exemplary method 500 presenting a user interface for switching SIM cards that can be implemented, for example, via a user interface as shown in FIG14 . Because the user interface of FIG14 can be used with various user interface types described herein, method 1500 can also be used across various user interface types. For example, both calls and messages are supported.

At 1510, a set of user interface elements (e.g., one for each SIM card) are displayed as shown in Figure 14. Elements associated with the default SIM are depicted differently.

At 1520, an indication of another SIM card is received via a user interface element associated with the non-default SIM card.

At 1530, communication is initiated using the other SIM card.

The indication that the default SIM card will be overwritten and the selected alternative SIM card can be achieved through one user interface interaction (e.g., activation such as a tap). Communication can also be initiated in response to the activation. Thus, a single activation can indicate three communication actions.

Example 32 - Exemplary SIM card import and export

In any of these examples, the import and export functionality for multiple SIM cards can be supported. For example, source and destination information can be received, and the contacts to be imported or exported can be indicated. Subsequently, contacts can be imported from or exported to a SIM card.

The source or destination may be specified by a SIM card tag, a user account (a user account with contacts associated therewith, etc.), or the like.

In any of the examples herein, the source of the contact (eg which SIM card it originated from) may be stored and subsequently used as a default when processing that contact.

Example 33 - Exemplary SIM card defaults

In any of the examples herein, a SIM card default may be implemented. As described herein, this default may be selected based on various input factors. The default may be presented as the currently selected SIM, but as described herein, a different SIM may be selected to actually initiate communication.

SIM card defaults can be set individually for each contact method. For example, the default for a work number can be different from the default for a mobile number. SIM card defaults can be presented in any of the user interface types described herein. Where more than one contact method is presented, a different SIM card can be presented in the user interface for another contact method. For example, a contact card can present an indication of the default SIM card for a contact method (e.g., on a SIM indicator-switch). Because a contact card can have two different contact methods, it can cause two different default SIMs to be presented. Thus, each phone number on a contact card has its own SIM default, which can be an independently selected and indicated SIM card.

However, when a default is sent for the first contact method on a contact, it can be propagated to the other contact methods of the same contact. For example, if the first call to a given contact is on the first SIM, the other numbers of that given contact can default to the first SIM. Subsequent calls to the contact on a different contact method (such as work) can then change the default (for example, if the call is made on the second SIM, the default becomes the second SIM). Thus, independent, contact-by-contact default SIM selection can be achieved. Therefore, in the absence of other factors to the contrary, the first SIM used to communicate with a contact can be used as one of the preferred numbers for the entire group of numbers of that contact, but this preference can easily be overridden by future actions.

The default SIM card may be selected based on any of a number of factors. Contacts may be stamped upon the occurrence of specific events.

For example, the default may be selected as the SIM card on which the contacts reside. When the SIM card is inserted, the contacts may be imprinted with the default.

The default SIM card can be selected as the SIM card from which contacts are imported. When importing contacts, the contacts can be imprinted with the default.

The default SIM card may be selected as the most recent SIM card involved in communication activities with the contact (e.g., received calls, missed calls, outgoing calls, incoming calls, outgoing messages, etc.) When engaged in such communications, the contact may be imprinted with the default.

As described herein, a different SIM card other than the default SIM card may be used. For example, the default may be indicated in a SIM indicator-switch and switched accordingly.

Overriding a default may result in a change of the default for subsequent sessions. In some cases, a default may be overridden without actually participating in a communication (e.g., by selecting another SIM card without making a call).

An earlier default indication (eg, importing) may be overridden by a subsequent user communication action (eg, receiving or making a call).

A default SIM can be selected based on input conditions independently of the contact details. Such a default SIM can override the default SIM for the contact details or be used as the default in aggregated interface scenarios. For example, an overriding default SIM can be selected based on whether the SIM card does not receive a signal from the operator (e.g., whether it is in coverage). In this way, in response to determining that the SIM card does not receive a signal, another SIM can be selected as the default. The original default can be stored and subsequently used in response to determining that the SIM card receives a signal again. Therefore, if user behavior suggests that a SIM that is currently not working should be selected as the default, this selection can be overridden with a SIM that is able to communicate. The reason for a non-working SIM may be that it does not exist, there is no signal (or insufficient signal), etc.

The relative signal strength may also override the default SIM (eg multiple SIMs are used to make a call and one of these SIMs has a better signal strength than the others).

The physical orientation of the device may also override the default SIM (eg, turning the phone flat on one side or the other will cause it to select a specific SIM or rotating the phone to have a specific end) will cause it to select a specific SIM.

Stored information about billing arrangements or plans (e.g., provided by the user or the network) can override the default SIM (e.g., defaulting calls to international numbers for a SIM with a better international plan, defaulting calls to a SIM with free night calls during night hours, etc.).

Identification of the wireless network to which the device is connected can be used to override the default SIM. For example, if it is determined that the device is connecting to a home wireless network, the default SIM will be overwritten with the home SIM.

If the Do Not Disturb feature is invoked, the default SIM card can be overwritten with a specific SIM card (e.g., a home SIM card).

Various other factors may be used when determining whether to overwrite the default SIM. For example, a calendar, roaming instructions, physical location, schedule availability (e.g., whether a work appointment or personal appointment is currently indicated), etc. may be used.

FIG16 is a block diagram of an exemplary system 1600 for selecting a default SIM card. In this example, a communication device 1605 includes a SIM card default engine 1620 that accepts as input any one or more of the factors 1610 described herein and outputs a default SIM card identifier 1650. As described herein, such factors may include receiving a default change via a SIM indicator-switch as described herein.

Example 34 - Exemplary SIM Card Default Priority

In any of the examples presented here, a default SIM can be selected based on a priority order. For example, if there has been any communication activity for a contact or contact, the SIM involved in that communication activity can be used. If there is no communication activity, other factors can be considered. For example, if the contact is on a given SIM card, that SIM card can be used as the default. If the contact was imported from a given SIM card, that SIM card can be used as the default. If none of these conditions hold, a SIM can simply be selected (e.g., priority, first SIM card, global default SIM card, etc.).

Example 35 - Example SIM card default based on associated account

In any of the examples herein, the SIM card default may be selected based on a source account associated with the contact (e.g., the account from which the contact originated.) Such source accounts may include social networks, email servers, and the like.

A contact may be associated with a particular source account because it originates from that account or otherwise has a connection to that account. In reality, a phone book may include a union of accounts and sources that are persisted in the cloud and synced to the phone. For example, social media accounts may be integrated into the phone book. The connection to a particular account may be used as a weighting factor when selecting which SIM card to use. The fact that a number originates from a particular account may be given significant weight in the determination, but other associations are also possible. Furthermore, since a number may originate from multiple accounts, the degree or amount of past communication activity or associations may be considered to select which account to predominate.

The nature of the account can be considered to determine whether the account is typically associated with work or personal activities. For example, some social networks are known for being personal, while others are known for being used for work. Some email servers (e.g., Microsoft Exchange Server, etc.) are associated with work activities. A stored mapping between account source names or identifiers and activity types (e.g., work, personal) can be consulted. Based on this mapping, a default SIM card can be selected (e.g., a SIM card with a name or other association that indicates the activity type). Similarly, user preferences can be provided to indicate whether a particular account is a work account or a personal account.

In another example, past activity on SIMs associated with the same account can also be used to determine the default SIM. For example, it can be determined whether there has been communication activity with other contacts from a particular account. Based on a threshold or a dominant amount of activity (e.g., a majority, 60%, 90%, or 100%, etc.) occurring on a given SIM, the default SIM for contacts from the same account can be selected as that given SIM. In other words, if there is a tendency to use a particular SIM to place calls to contacts from a particular network, then calls to other contacts from the same network may be made on the same SIM.

Example 36 - Example SIM card default based on number type identification

In any one of the examples herein, the SIM card default may be selected based on an identification of the type of callee number. For example, if the number appears to be a work number (e.g., 1-800, virtual number, or with an extension), this may result in the work SIM being selected as the default.

Example 37 - Exemplary SIM card defaults based on content

In any of the examples herein, a SIM card default can be selected based on the content of messages associated with a contact or contact method. For example, voicemail messages from a certain number can be checked, or text messages sent to or from that number can be checked. The message content can be scanned against a dictionary to determine whether it is a work message or a personal/family message.

In one specific example, messages containing the word "urgent" or marked as "urgent" may favor the selection of a working SIM. To illustrate the flexibility of the various technologies in handling multiple input factors, a message designated as urgent may override a billing preference in light of a detected weak signal strength, as it may be desirable to ensure that the message is sent quickly and/or reliably, even if this may result in increased costs.

Example 38 - Example SIM card default based on callee location

In any of the examples herein, a SIM card default may be selected based on the detected location of the callee. For example, the address or area code may be considered to determine whether the communication is a local call or a long distance call (or other cost differentiating indicator). The SIM card used for local calls may be selected as the default.

Example 39 - Exemplary SIM card defaults based on communication type

In any of the examples herein, a SIM card default may be selected based on a preference indicating that a particular SIM is desired for a particular communication type. For example, a SIM may be preferred for voice, text messaging, or both.

Example 40 - Example SIM card default based on name association

In any of the examples herein, a SIM card default may be selected based on a name association. For example, if the contact's last name matches the device user's last name, the SIM associated with personal (e.g., family) communications (e.g., based on a name or other association) may be used as the default SIM.

Example 41 - Example SIM card defaults based on associations of time of day

In any of the examples herein, the default SIM card selection can be based on a correlation with the time of day. For example, a day can be divided into various time periods (e.g., hours, etc.). It can be determined that communications during a particular time period are predominantly conducted on a given SIM card. If so, when a call is made during that time period (e.g., later in the day), the default SIM card can be set to that given SIM card. Similarly, the day of the week can be used to select the default SIM card.

The time of day can be used as an input to the overall determination. For example, past communications may be prioritized, but in the absence of information on this factor, if other calls are observed to be predominantly made on a given SIM during that time period, that given SIM may be selected as the default. Once a communication has been made using the selected default, that default may then be confirmed and used as the default for future communications.

If there is a work appointment around the current time (e.g. made with a work account), the work SIM may be selected as the default SIM. The same applies for personal appointments.

Example 42 - Exemplary SIM Card-Activity Type Association

In any of the examples herein, a SIM card may be associated with a particular activity type (e.g., work, personal, etc.). Such an association may be determined based on the friendly name of the SIM card (e.g., "work") or the activity on the SIM card (e.g., calling a "home" contact, a family member, etc.). Billing information may also be considered.

It is also possible to simply designate a particular SIM as a work or home/personal SIM via user preferences.

Example 43 - Exemplary Default SIM Table

FIG17 is a block diagram of an exemplary table 1700 that associates contact information with a default SIM card and can be used in any example implementing SIM card defaulting as described herein. In this example, table 1700 stores a relationship 1730 between contact information 1730A and default SIM card 1730B. As described herein, upon a communication event, the default SIM card can be imprinted (e.g., stored). In practice, identifiers (e.g., for contact information, contact person, number type, etc.) can be used instead of textual names or numeric labels.

For example, once a call to a contact is made with a given SIM, the identifier of the given SIM may be stored in association with the identifier of the contact. Subsequently, the given SIM may be used as the default SIM and displayed as described herein.

The table can be enhanced to store defaults for specific interfaces. For example, different defaults can be stored for call history, dialers, new conversations, and recognized phone numbers (e.g., when the number is extracted from a web page or other content and edited before the call). Defaults can also be set based on communication type (e.g., messaging), resulting in defaults based on communication type or contacts at a more granular level (e.g., communication type and contact information).

In fact, table 1700 does not need to be implemented as a separate table, but can be implemented as part of another table (eg, an address book table, a SIM card configuration table, etc.).

Example 44 - Exemplary Contacts User Interface with Default SIM Card

18 is a screen shot of an exemplary user interface 1800 showing the default SIM card for a contact when a call is initiated from the contact card user interface. In this example, a contact profile 1810 may depict information about the contact, such as pictures, social network activity, and the like.

User interface 1800 may be displayed as part of a contact card and may include SIM indicator-switches 1810A, 1810N that include an indication of a default SIM card. The default SIM card may vary by number type.

SIM card label 1824 may be displayed as highlighted to indicate the selected (e.g., default) SIM card with which communications will be initiated upon activation of the corresponding number type (e.g., a first SIM card may be used by default to initiate communications with mobile numbers, and a second, different SIM card may be used by default to initiate communications with work numbers). Label 1824 and adjacent text may be presented in a color associated with the default SIM card. A contact number (e.g., in conjunction with "Use") may be used as an optional description for use with the SIM indicator-switch.

Once contact 1820A or 1820N is activated, a call is made using the SIM card indicated by the corresponding SIM indicator-switch 1810A, 1810N. For example, communication to a non-default SIM may be initiated by first using indicator-switch 1810A (to select a non-default SIM), observing the resulting change in 1820 (e.g., to indicate a different SIM), and then tapping or otherwise activating 1820A.

Upon activating the depiction of the non-default SIM card tab in the switches 1810A, 1810N, communication to the contact may be initiated through the activated non-default SIM card.

Additional user interface elements 1860 appropriate to a contact card user interface may be included.

Example 45 - Exemplary Communication Scenario: Valid Call Placing

19 is a flow chart of an exemplary method 1900 for placing a call via a user interface as described herein. Valid call placement may be accomplished via the method 1900.

At 1910, a user interface is presented having activatable user interface elements representing respective SIM cards. For example, the user interface of Figure 6 may be presented. A first user interface may be presented that includes a first activatable user interface element representing call initiation for a first SIM card and a second activatable user interface element representing call initiation for a second SIM card.

At 1920, a first activation of one of the activatable user interface elements (e.g., either 620A or 620B) is received. Such activation may indicate a desired call initiation, but may also indicate a desired, selected SIM card (e.g., by virtue of the fact that a user interface element for a given SIM card is activated). In this manner, a single activation may simultaneously indicate both the initiation of a communication and the SIM card to be used to conduct the communication.

At 1930, in response to receiving the first activation, a user interface having an activatable user interface element representing the corresponding contact is presented. For example, the user interface of FIG. 9 (e.g., call history) can be presented, which includes multiple user interface elements for making a call using the SIM card selected at 1920. Depending on whether the first activatable user interface element or the second activatable user interface element is activated, the user interface can implement a SIM-split user interface paradigm for the selected SIM card.

At 1940, a second activation is received (eg, of call 922 or 920A represented in the call history). The activation indicates a particular contact.

At 1950, in response to receiving the second activation, a call is placed via the selected SIM to the selected contact (eg, the number associated with the call).

The user interface interaction for initiating the communication may consist of a first activation and a second activation.By supporting communication initiation with only two activations, a more efficient communication initiation may be achieved regardless of the SIM number.

Through the user interface, an indication can be received (e.g., via the SIM indicator-switcher described herein) that the selected SIM card (e.g., which will be referred to as the default SIM card) is to be switched to a different SIM card. Thus, a call is made using a different SIM card.

Example 46 - Exemplary Communication Scenario: Session Screening

The features described herein can be used in a session filtering scenario for a single SIM while still supporting SIM-aggregated sessions. For example, referring back to FIG. 2 , a first user interface can include a session list user interface that presents a summary of multiple sessions according to a SIM-separated user interface paradigm (e.g., as described herein). For example, the first user interface can be presented in response to activation of an activatable user interface element for messaging for a particular SIM card.

In response to activating a particular session among the plurality of sessions, a second user interface (eg, a session user interface as described herein) may be displayed and present a message list for the particular session according to the SIM aggregate user interface paradigm.

Example 47 - Exemplary SIM Card Colors

In any of the examples herein, features can be used to help represent color selections for SIM cards. For example, if a user selects an accent color for a communication device (e.g., to be used throughout the device's user interface to provide color uniformity across the user interface), the accent color can be associated with one of the SIM cards (e.g., the primary SIM card, e.g., SIM1). The user interface can be improved by changing the default (e.g., accent) color to a color preferred by the user.

A lookup table of aesthetically pleasing colors in combinations of (e.g., complementary) corresponding colors can be referenced to select a color for the second SIM card based on the color associated with the first SIM card. In this way, a color that complements the accent color of the user interface for the communication device can be selected as the color associated with the SIM card. Furthermore, the user interface can be improved by changing the selected color to any color the user prefers.

Example 48 - Exemplary consistent user interface

Multiple user interfaces can be displayed to accommodate multiple SIM cards, where the user interfaces both indicate the default SIM card and allow switching the default SIM card. The user interfaces can display the default SIM card in the same and consistent manner and accept switching in the same and consistent manner. For example, a SIM card indicator-switcher can be used across user interfaces, including the call history user interface, keypad user interface, conversation user interface, and contact card user interface. This solution provides a consistent experience for users regardless of the communication scenario.

The user interface can further be consistent across user interfaces that implement either the SIM split or SIM aggregate user interface paradigm. For example, the call history user interface can implement an indicator-switch indicating whether it implements the SIM split or SIM aggregate user interface paradigm. The conversation user interface can do the same.

Example 49—Exemplary Advantages

The present technology can display and provide quick access to communications separated by lines. The technology can provide a high-level indication of which line is being used when a communication is received and when displaying the communication history. The present technology can provide easy and intuitive access to switching lines whenever a user can initiate or respond to a communication. The present technology can provide an integrated experience across communication lines while still maintaining and displaying the line history of the corresponding communication line. The present technology can provide the ability to easily switch between separate and aggregated paradigms for each communication type.

The technology described herein addresses the needs of social circle dual-SIM phone users and provides them with a simple model for isolating their communications based on phone lines. Social circle users are people who want to separate different parts of their lives. A common example is separating work and personal life and maintaining different identities and different communication points for different sets of users. Often, communications with one of the social circles are lower priority (for example, when the user is at work, personal is lower priority), and maintaining the privacy of the personal number is important.

Because the techniques described herein allow a user to easily determine which SIM card is involved in both incoming and outgoing communications, the user can easily separate identities and maintain privacy as desired.

Example 50 - Exemplary Computing Device

FIG20 illustrates a generalized example of a suitable computing system or environment 2000 in which several of the described inventions may be implemented. Computing system 2000 is not intended to impose any limitations on scope of use or functionality, as these innovations may be implemented in various general-purpose or special-purpose computing systems. A communication device as described herein may take the form of the described computing system 2000.

Referring to Figure 20, computing environment 2000 includes one or more processing units 2010, 2015 and memory 2020, 2025. In Figure 20, this basic configuration 2030 is included within the dashed line. Processing units 2010, 2015 execute computer-executable instructions. A processing unit can be a general-purpose central processing unit (CPU), a processor in an application-specific integrated circuit (ASIC), or any other type of processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. For example, Figure 20 shows a central processing unit 2010 and a graphics processing unit or co-processing unit 2015. Tangible memory 2020, 2025 can be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.) accessible by the processing unit(s), or some combination of the two. Memory 2020, 2025 stores software 2080 in the form of computer-executable instructions suitable for execution by the processing unit(s) that implements one or more of the inventions described herein.

The computing system may have additional features. For example, the computing environment 2000 includes storage 2040, one or more input devices 2050, one or more output devices 2060, and one or more communication connections 2070. An interconnection mechanism (not shown), such as a bus, controller, or network, interconnects the various components of the computing system 2000. Typically, operating system software (not shown) provides an operating environment for other software executed in the computing system 2000 and coordinates the activities of the various components of the computing system 2000.

Tangible storage 2040 may be removable or non-removable and include magnetic disks, magnetic tapes or cartridges, CD-ROMs, DVDs, or any other medium that can be used to store information in a non-transitory manner and accessed within computing system 2000. Storage 2040 stores instructions for software 2080 that implement one or more of the inventions described herein.

The input device(s) 2050 may be a touch input device (such as a keyboard, mouse, pen, or trackball), a voice input device, a scanning device, or another device that provides input to the computing system 2000. For video encoding, the input device(s) 2050 may be a camera, a graphics card, a TV tuner card, or a similar device that accepts video input in analog or digital form, or reads video samples into a CD-ROM or CD-RW of the computing system 2000. The output device(s) 2060 may be a display, a printer, a speaker, a CD burner, or another device that provides output from the computing system 2000.

Communication connection 2070 allows communication to another computing entity via a communication medium. The communication medium conveys information such as computer-executable instructions, audio or video input or output, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, the communication medium may utilize electrical, optical, RF, or other carriers.

The various innovations may be described in the general context of computer-readable media. Computer-readable media is any available tangible medium that can be accessed within a computing environment. By way of example and not limitation, for computing system (2000), computer-readable media includes memory (2020, 2025), storage (2040), and any combination thereof.

Each innovation can be described in the general context of computer-executable instructions (such as those included in program modules that are executed in a computing system on a target real or virtual processor (e.g., ultimately executed in hardware). In general, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. As described in various embodiments, the functionality of these program modules can be combined or split between these program modules. The computer-executable instructions for each program module can be executed in a local or distributed computing system.

The terms "system" and "device" are used interchangeably herein. Unless the context clearly indicates otherwise, the terms do not imply any limitation on the type of computing system or computing device. In general, a computing system or computing device can be local or distributed and can include any combination of special-purpose hardware and/or general-purpose hardware with software that implements the functionality described herein.

For purposes of presentation, this detailed description uses terms such as "determine" and "use" to describe computer operations in a computing system. These terms are high-level abstractions for operations performed by a computer and should not be confused with actions performed by a human. The actual computer operations corresponding to these terms vary depending on the implementation.

Example 51 - Exemplary Mobile Device

FIG21 is a system diagram depicting an exemplary mobile device 2100, which includes various optional hardware and software components, generally shown at 2102. Any component 2102 in the mobile device can communicate with any other component, but not all connections are shown for ease of illustration. The mobile device can be any of a variety of computing devices (e.g., a cell phone, a smartphone, a handheld computer, a personal digital assistant (PDA), etc.) and can enable wireless two-way communication with one or more mobile communication networks 2104, such as cellular, satellite, or other networks. Voice over IP scenarios (e.g., over WiFi or other networks) are also supported. The communication devices described herein can take the form of the described mobile device 2100.

The illustrated mobile device 2100 may include a controller or processor 2110 (e.g., a signal processor, microprocessor, ASIC, or other control and processing logic) for performing tasks such as signal encoding, data processing, input/output processing, power control, and/or other functions. An operating system 2112 may control the allocation and use of components 2102 and support one or more applications 2114. Applications 2114 may include common mobile computing applications (e.g., email applications, calendars, contact managers, web browsers, messaging applications), or any other computing applications. Functionality 2113 for accessing application storage may also be used to retrieve and update applications 2114.

The illustrated mobile device 2100 may include memory 2120. Memory 2120 may include non-removable memory 2122 and/or removable memory 2124. Non-removable memory 2122 may include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. Removable memory 2124 may include flash memory or a subscriber identity module (SIM) card, which is well-known in GSM communication systems, or other well-known memory storage technologies, such as "smart cards." Memory 2120 may be used to store data and/or code for running an operating system 2112 and applications 2114. Example data may include web pages, text, images, sound files, video data, or other data sets sent to and/or received from one or more network servers or other devices via one or more wired or wireless networks. Memory 2120 may be used to store subscriber identifiers such as an International Mobile Subscriber Identity (IMSI) and device identifiers such as an International Mobile Equipment Identifier (IMEI). Such identifiers may be transmitted to a network server to identify the user and device.

The mobile device 2100 may support one or more input devices 2130 such as a touch screen 2132, a microphone 2134, a camera 2136, a physical keyboard 2138, and/or a trackball 2140, and one or more output devices 2150 such as a speaker 2152 and a display 2154. Other possible output devices (not shown) may include piezoelectric or other tactile output devices. Some devices may provide more than one input/output function. For example, the touch screen 2132 and the display 2154 may be combined in a single input/output device.

The wireless modem 2160 may be coupled to an antenna (not shown) and may support two-way communication between the processor 2110 and external devices, as is well understood in the art. The modem 2160 is shown generally and may include a cellular modem and/or other radio-based modem (e.g., Bluetooth 2164 or Wi-Fi 2162) for communicating with the mobile communication network 2104. The wireless modem 2160 is typically configured to communicate with one or more cellular networks, such as GSM or CDMA networks for data and voice communications within a single cellular network, between cellular networks, or between a mobile device and a public switched telephone network (PSTN).

The mobile device 2100 may also include at least one input/output port 2180, a power source 2182, a satellite navigation system receiver 2184 such as a global positioning system (GPS) receiver, an accelerometer 2186, and/or a physical connector 2190, which may be a USB port, an IEEE 1394 (FireWire) port, and/or an RS-232 port. The components 2102 shown are not required or all-inclusive, any components may be deleted, and other components may be added.

Example 52 - Exemplary Multi-Server Environment

In example environment 2200, cloud 2210 provides services to connected devices 2230, 2240, and 2250 with various screen capabilities. Connected device 2230 represents a device with a computer screen 2235 (e.g., a medium-sized screen). For example, connected device 2230 may be a personal computer, such as a desktop computer, laptop computer, notebook, netbook, etc. Connected device 2240 represents a device with a mobile device screen 2245 (e.g., a small-sized screen). For example, connected device 2240 may be a mobile phone, smartphone, personal digital assistant, tablet computer, etc. Connected device 2250 represents a device with a large screen 2255. For example, connected device 2250 may be a television screen (e.g., a smart TV) or another device connected to a television (e.g., a set-top box or game console), etc. One or more of connected devices 2230, 2240, and 2250 may include touchscreen capabilities. A touchscreen can accept input in different ways. For example, a capacitive touch screen detects touch input when an object (e.g., a fingertip or stylus) distorts or interrupts the current flowing through the surface. As another example, a touch screen may use an optical sensor and detect touch input when a light beam from the optical sensor is interrupted. For input to be detected by some touch screens, physical contact with the screen surface is not required. Devices without screen capabilities may also be used in example environment 2200. For example, cloud 2210 may provide services to one or more computers (e.g., server computers) that do not have displays.

Services may be provided by the cloud 2210 through the service provider 2220, or through other online service providers (not depicted). For example, cloud services may be customized to correspond to the screen size, display capabilities, and/or touchscreen capabilities of a particular connected device (e.g., connected devices 2230, 2240, 2250).

In example environment 2200, cloud 2210 uses, at least in part, a service provider 2220 to provide the techniques and solutions described herein to various connected devices 2230, 2240, 2250. For example, service provider 2220 can provide a centralized solution for various cloud-based services. Service provider 2220 can manage service subscriptions for users and/or devices (e.g., connected devices 2230, 2240, 2250 and/or their respective users).

Example 53 - Exemplary Implementation

Although some operations of the disclosed methods are described in a particular sequential order for ease of presentation, it should be understood that this description encompasses rearrangement unless specific language set forth below requires a particular ordering. For example, in some cases, operations described sequentially may be rearranged or performed concurrently. Furthermore, for the sake of clarity, the accompanying figures may not illustrate the various ways in which the disclosed methods can be used in conjunction with other methods.

Any of the disclosed methods can be implemented as computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media disks, volatile memory components (such as DRAM or SRAM), or non-volatile memory components (such as a hard drive)) and executed on a computer (e.g., any commercially available computer, including smartphones or other mobile devices containing computing hardware). Any of the computer-executable instructions for implementing the disclosed techniques and any data created and used during the implementation of the disclosed embodiments can be stored on one or more computer-readable media (e.g., non-transitory computer-readable media). The computer-executable instructions can be, for example, a dedicated software application or portion of a software application that is accessed or downloaded via a web browser or other software application (such as a remote computing application). Such software can be executed, for example, on a single local computer (e.g., any suitable commercially available computer) or in a network environment using one or more network computers (e.g., via the Internet, a wide area network, a local area network, a client-server network (such as a cloud computing network), or other such network).

For the sake of clarity, only certain selected aspects of each software-based implementation are described. Other details known in the art have been omitted. For example, it should be understood that the disclosed technology is not limited to any particular computer language or program. For example, the disclosed technology can be implemented by software written in C++, Java, Perl, JavaScript, Adobe Flash, or any other suitable programming language. Similarly, the disclosed technology is not limited to any particular computer or hardware type. Certain details of suitable computers and hardware are well known and therefore need not be elaborated in this disclosure.

Furthermore, any of the software-based embodiments (including, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed via suitable communication means, including, for example, the Internet, the World Wide Web, an intranet, a software application, cables (including fiber optic cables), magnetic communication means, electromagnetic communication means (including RF, microwave, and infrared communication), electronic communication means, or other such communication means.

The disclosed methods, apparatus, and systems should not be considered limiting in any way. Instead, the present disclosure is directed to all novel and non-obvious features and aspects of the various disclosed embodiments (alone and in various combinations and subcombinations with each other). The disclosed methods, apparatus, and systems are not limited to any specific aspect or feature or combination thereof, nor do the disclosed embodiments require the presence of any one or more specific advantages or the resolution of any problems.

Non-transitory computer readable media

Any computer-readable media herein may be non-transitory (eg, memory, magnetic storage, optical storage, etc.).

Storing on a computer readable medium

Any of the storing actions described herein may be implemented by storing in one or more computer-readable media (eg, computer-readable storage media or other tangible media).

Any of the things described as being stored may be stored in one or more computer-readable media (eg, computer-readable storage media or other tangible media).

Method in computer readable medium

Any of the methods described herein can be implemented by computer-executable instructions in (e.g., encoded on) one or more computer-readable media (e.g., computer-readable storage media or other tangible media). Such instructions can cause a computer to perform the method. The techniques described herein can be implemented in various programming languages.

Method in a computer readable storage device

Any of the methods described herein can be implemented by computer-executable instructions stored in one or more computer-readable storage devices (eg, memory, magnetic storage, optical storage, etc.) Such instructions can cause a computer to perform the method.

Exemplary combinations

Various combinations can be supported. For example, an incoming call user interface can be combined with a call in progress user interface (e.g., after accepting an incoming call). A call in progress user interface can be combined with a background call in progress user interface (e.g., if the call is transferred to the background).

The user interface during the call can be combined with (for example if navigation to the main user interface has occurred during the call) the main user interface. In such a case, the user interface during the background call can also be displayed.

The user interface for initiating communication may also be combined with any other user interface.

Alternatives

The technology from any example can be combined with the technology described in any one or more other examples. The word "exemplary" is used herein, which is intended to indicate an example rather than an ideal embodiment. In view of the many possible embodiments to which the principles of the disclosed technology can be applied, it should be recognized that the illustrated embodiments are merely examples of the disclosed technology and should not be used as limitations on the scope of the disclosed technology. Instead, the scope of the technology of the present disclosure is covered by the subsequent claims. We claim as our invention all that falls within the scope and spirit of these claims.

Claims (10)

1. A method at least partially implemented by a computing system, the method comprising: Select the default SIM card; A user interface that displays multiple contact methods for a contact, as well as an active user interface element for initiating communication with a specific contact method of the contact. Receive activation of the user interface element; In response to activation of the user interface element, communication with the specific contact method is initiated via the default SIM card; and For another contact method for the aforementioned contact, different SIM cards will be presented as the default. 2. The method as described in claim 1, characterized in that: Selecting the default SIM card includes selecting the SIM card most recently used by the contact. 3. The method as described in claim 2, characterized in that it further comprises: The default SIM card is distributed to different contact methods of the contact. 4. The method as described in claim 1, characterized in that: Selecting a default SIM card includes choosing the SIM card involved in communication activities with the specific contact method. 5. The method as described in claim 1, characterized in that it further comprises: Determine whether communication occurring within a specific time period takes place on a given SIM; and Selecting the default SIM card includes selecting the given SIM; or The selected default SIM card is covered based on the billing schedule. 6. The method as described in claim 1, characterized in that it further comprises: Determine that the contact person's last name matches the device user's last name; Selecting a default SIM card includes selecting a SIM card associated with a personal activity in response to determining that the contact's last name matches the device user's last name. 7. The method as described in claim 1, characterized in that it further comprises: The selected default SIM card is covered based on the billing schedule. 8. The method as described in claim 1, characterized in that it further comprises: Store the mapping between contact information and the default SIM card in a table; The table above is for selecting the default SIM card. 9. A system for implementing a default SIM card, the system comprising: processor; Memory coupled to the processor; The SIM card default engine is configured to output the default SIM card; and A default SIM card table, wherein the default SIM card table includes a mapping between contact information and default SIM cards, and wherein the default SIM card table supports different default SIM cards for different contact information of the same contact. 10. The system as described in claim 9, characterized in that: The SIM card default engine is configured to select the default SIM based on communication activity with the contact.