Seamless call transitions.

Various user interfaces and other technologies can be implemented to make smooth transitions between calls of different types. Technologies can be implemented to give the impression of a single call that is improved from one type of call to another. A new application can be registered so that the control in an appropriate user interface appears to be activated when a smooth call transition is possible. The transition for third-party applications can thus be supported. Multi-platform implementations can be supported.

(57) Abstract

Various user interfaces and other technologies for seamlessly transitioning between calis of different types can be implemented. The technologies can be implemented to give the impression of a single cali that is upgraded from one cali type to another. A new application can register so that an appropriate user interface control appears for activation when seamless cali transition is possible. Transitioning for third party applications can thus be supported. Cross-platform implementations can be supported.

PATENT TITLE No. 366247

<td>Headlines):</td><td>MICROSOFT TECHNOLOGY LICENSING, LLC</td>

<td>Home:</td><td>One Microsoft Way, Redmond, Washington, 98052, USA</td>

<td>Denomination:</td><td>FLUID CALL TRANSITIONS.</td>

<td>Classification:</td><td>CIP: H04M3 / 42; H04L29 / 06; H04N7 / 14; H04W4 / 00; H04W36 / 36; H04W4 / 16 CPC: H04W36 / 365; H04L65 / 1083; H04M3 / 42161; H04N7 / 147; H04W4 / 16</td>

<td>Inventor (s):</td><td>SYED MANSOOR JAFRY; KERRY D. WOOLSEY; CASEY DVORAK; TONY HE; PETER BERGLER</td>

Number:

MX / a / 2016/002182

REQUEST

International Presentation Date:

August 2014

PRIORITY

Country:

Date:

Number:

August 2013

13/970,504

Validity: Twenty years

Expiration Date: August 18, 2034

Issue Date: July 3, 2019

The reference patent is granted based on articles 1^to, 2^to fraction V, 6^to Section III, and 59 of the Industrial Property Law.

In accordance with article 23 of the Industrial Property Law, the present patent is valid for twenty non-extendable years, counted from the date of submission of the international application and will be subject to the payment of the fee to keep the rights in force .

Who subscribes to this title does so based on the provisions of articles 6^to fraction III, 7^to BIS 2 and 59 of the Industrial Property Law; 1st, 3rd articles^to fraction V subsection a), sub subsection ii), 4^to and 12^to sections I and III of the Regulations of the Mexican Institute of Industrial Property; articles 1^to, 3^to, 4^to, 5^to fraction V subsection a), sub subsection ii), 16 fractions I and III and 30 of the Organic Statute of the Mexican Institute of Industrial Property; I^to, 3^to and 5^to subsection a) and the second to last paragraph of the Agreement that delegates powers to the Deputy Directors General, Coordinator, Divisional Directors, Regional Office Holders, Divisional Deputy Directors, Departmental Coordinators and other subordinates of the Mexican Institute of Industrial Property.

This document is signed with an advanced electronic signature (FAITHFUL), based on Articles 7 BIS 2 of the Industrial Property Law; 3rd of its Regulations, and 1 section III, 2 section V, 26 BIS and 26 TER of the Agreement establishing the guidelines for the use of the Electronic Payment and Services Portal (PASE) of the Mexican Institute of Industrial Property, in the procedures indicated.

DIVISIONAL SUB-DIRECTOR OF PATENT FUND EXAMINATION OF MECHANICAL, ELECTRICAL AND INDUSTRIAL DESIGNS AND USEFUL MODELS

<img file="MX366247B_D0001.tif" />

PEDRO DAVID FRAGOSO LÓPEZ

Original string:

PEDRO DAVID FRAGOSO LOPEZ | 00001000000405457619 | Administration Service

Tax ^ 052 || MX / 2019/61319 | MX / a / 2016/002182 | PCT patent title | 1048 | SEF | Page (s) | z6e1cPRy6uBjl6TQz7cKYefTlc4 =

Digital stamp:

EUI9tRjmpHXm3l1gSq9dYo83UvCJBBEgOz8ILQ6hHXBkdGLDFmQfO / Q1NAwwydogHstl85s9ihr5MgbaeJvJHIocS7 5yxLnbhS2dlfJzQfc + OIRNtp3aprhZwKZ25XI9IAwBD4J2Y7mTI8bp8IWhRNXC / fKPoYb2Fw27R23AkgZ3vXI / nUX3 8VUTw8U AeWoh f6f J kXRq04ufZYkjTyvL + te3g VRZ6kYkA4d4Fy5oucOYfdzSB J KKeph70cLs Fadu3 DI ppBCBoJ5hpC kK16z + == uLzyfBPFg8EgGb8mx6avaA9Qvkb2EOvEu2¡WfdTQ2EksWvdvU¡21bR6KUFYN9CuyxQ

<img file="MX366247B_D0002.tif" />

FLUID CALL TRANSITIONS

Background of the invention

Mobile phones now have some functionality and applications that provide a wide variety of ways to communicate. For example, a simple device can now support calls from conventional telephones, voice calls over Internet Protocol (VolP), video calls and the like. However, such functionality has not been particularly well integrated, and new users have not realized that they have this functionality.

Since users may face obstacles when trying to take advantage of different modes of communication, there is always room for improvement.

Brief Description of the Invention

This brief description includes the introduction of a selection of short and simple concepts, which are described in more detail in the Detailed description section of the invention. This brief description is not intended to identify the key or essential characteristics of the content of the claims, nor is it intended to be used to limit the scope of the content of the claims.

The technologies may include a method implemented, at least in part, by a communication device, the method consists of the following: While making a first call of a first type of call with the communication device, determine whether a smooth transition to a second call of a second type of call is possible, in which determining whether a smooth transition is possible comprises confirming if a communication application of the second type of call is available on the communication device; which responds by determining that fluid transition is possible, presenting an option in the user interface for a smooth transition; and responds by activating the option in the user interface, to flow smoothly to the second call of the second type of call.

The technologies may include a communication device consisting of: one or more processors; memory that stores an executable audio calls application, an executable video calls application and application registration information indicative of whether the executable video calls application supports smooth transitions; and a call controller configured for a smooth transition of calls from the audio calls application to the video calls application.

Technologies may include one or more computer-readable storage media that have encoded executable instructions on the computer causing a computer system to perform a method that consists of: During an audio call with a remote device, determine if the network conditions support a video call, confirming that the communication application that supports smooth transitions to a video call is registered on a local communication device, and verifying that the remote device supports a video call from a video calling application; responds to the determination that the network conditions will support the video call that a communication application supports smooth transitions to a video call that is registered in the communication device, and that the remote device supports a video call with a video application called , starting the video call with the remote device through the video calling application; removing the audio for the video call; in response to verifying the connectivity of the called video, smoothly transiting the called audio to the called video, where the flowing smoothly comprises: i) not suppressing the audio of the called video; ii) display video of the called video; and ii) abandon the audio call.

As described here, a variety of other features and advantages can be incorporated into the technologies as desired.

Brief description of the drawings

Figure 1 is a block diagram of an illustrative system that implements fluid call transitions.

Figure 2 is the flow chart of an illustrative method that implements fluid call transitions.

Figure 3 is a block diagram of an illustrative system configured to determine whether fluid call transitions are possible.

Figure 4 is the flow chart of an illustrative method for determining whether fluid call transitions are possible.

Figure 5 is the user interface scheme with illustrative progress call that implements a smooth call transition.

Figure 6 is a flow chart of an illustrative method of transitioning a call.

Figure 7 is a flowchart of an illustrative method for registering a communication application to carry out fluid call transitions.

Figure 8 is a block diagram of a table that stores a preferred communication application.

Figure 9 is the schematic of an illustrative user interface configuration choosing a preferred application for a type of call.

Figure 10 is a diagram of an illustrative computing system in which some described modalities can be implemented.

Figure 11 is an illustrative mobile device that can be used in conjunction with the technologies described herein.

Figure 12 is an illustrative cloud support environment that can be used in conjunction with the technologies described herein.

Detailed description of the invention

Example 1 - Illustrative Summary

The technologies described in this document can be used for various fluid call transition scenarios, and the adoption of technologies can provide improved communication techniques through different types of calls. User interfaces can better facilitate smooth call transitions. Other features described in this document can be implemented to adapt the call experience to user preferences. It can be a completely superior user experience with smooth transitions between call types.

In addition, technologies can support various communication applications and implement multi-platform fluid call transitions.

Several other features can be implemented and combined as described in this document.

Example 2 - Illustrative system that implements fluid call transitions

Figure 1 is the block diagram of an illustrative system 100 that implements fluid call transitions as described herein.

For context purposes, Figure 1 shows that the communication device 110 participates in the communication with another (e.g., remote) communication device 190 via one or more networks 180.

In the example, a communication device 110 includes a call controller 120 and a contact database 125. The configuration data of the transitions 130 may include a preferred application for use with a particular type of call. A call transition state 137 can track the transition state of the call as described in this document.

The communication device 110 can support two simultaneous calls 172, 174 of different call types with another communication device 190. As shown, the calls can be presented in two different applications, a telephone call application 140A in communication with its counterpart 140B and other (e.g., non-telephone call) communication application 145A in communication with its counterpart 145B. The different applications 140A, 145B may be of different application types. As described in this document, multi-platform operations can be supported. Calls can pass through one or more networks 180. For example, calls 172, 174 can be made over the same, or different, networks 180. Calls can pass through different physical or logical communication channels.

As described in this document, a transition between two calls 172 and 174 can be fluently made to give the impression that only one call is involved (e.g., the call or communication is not interrupted). Several techniques, such as starting the second call in the background, holding the first call, removing the audio from the second call, inhibiting the reproduction of the second call as a second call, and finally, moving to the second call can be applied to implement smooth call transitions.

Although several components are shown in separate boxes, in practice, the boundaries of the components may vary. For example, the components may be provided as part of a telephone operating system, call controller, or the like. Other arrangements are possible as long as the technology continues to be implemented.

In practice, the systems shown here, such as system 100, can be more complicated, with additional functionalities, more communication applications and the like.

System 100 and any other system described in this document may be implemented together with any of the hardware components described herein, such as the computer system or mobile devices described below (e.g., containing one or more processors, memory, and Similar). In any of the examples in this document, the inputs, outputs, preferences and applications may be stored in one or more computer-readable storage media or computer-readable storage devices. The technologies described in this document can be generic to those specific to operating systems or hardware and can be applied in any variety of environments to take advantage of the features described.

Example 3 - Illustrative method that implements fluid call transitions

Figure 2 is the flow chart of an illustrative method 200 for implementing fluid call transitions and can be implemented, for example, in the system shown in Figure 1.

Method 200 is generally carried out after the first call (e.g., with a telephone call application) that has already been established. In practice, a user interface is displayed with the call in progress while the first call is made.

At 210, it is determined whether a smooth transition to a second call of a second type of call is possible (eg, different from the first call). This determination can be made while the first call of the first type of call is made. As described in this document, this determination can be based on the capabilities of the other communication device, network conditions and the like. At this point, the second call does not need to be established.

At 220, in response to the determination that a fluid call transition is possible, an option is presented in the user interface of the communication device to initiate the fluid call transition. As described in this document, such an option may take the form of a graphic button that is enabled when determining the possibility of a smooth call transition. The option can be presented as part of a user interface with the call in progress (e.g. e.g., while the first call is made).

Although not shown, the method may include obtaining consent from the other communication device as described in this document.

At 230, in response to the activation of the option in the user interface, the first call of the first type of call flows smoothly to a second call of the second type of call. The second call can be established (eg, as part of the transition process or in advance) while the first call is maintained. Thus, for a user of the communication device, the two calls appear to be a single call (e.g., uninterrupted). A typical scenario is to transit a phone call to a VolP call (e.g., with or without video), but other transitions are possible as described here.

During the smooth transition, two calls can be held simultaneously with the same (eg, or other) communication device.

Several techniques can be used during the fluid transition. For example, the second call can be initiated, audio removed and connectivity confirmed. Subsequently, the audio can be deleted and the first call abandoned.

During the transition to the second call, any of the characteristics of calls of the second type may be available. As described in this document, these features may include video, shared screen or other functionality provided by the communication application in charge of the second call. Consequently, the user interface can be improved to provide or indicate such features.

A typical use case for method 200 is to transit a telephone call from a conventional telephone (eg, switched circuit, cellular, or the like) to an Internet protocol call (VolP). VolP calls can support video and other features as desired. However, technologies can support transitions between other types of calls or transitions in the other direction.

Method 200 and any of the other methods described in this document may be performed by computer-executable instructions (e.g., causing a computer system to perform the method) stored in one or more computer-readable media (e.g. ., storage or other tangible media) or stored in one or more computer-readable storage devices.

Example 4 - Illustrative communication device that implements fluid call transitions

Figure 3 is a block diagram showing an illustrative system 300 configured to determine whether fluid call transitions are possible. In the example, a communication device 305 (e.g., the communication device 110 of Figure 1) comprises a telephone call application 340A, one or more applications 345A-349A, a contact database

325 and a network status indicator 355.

Several techniques can be used to determine if a smooth call transition is possible. In some cases, several different types of calls can be supported, and different types of calls can be determined individually (e.g., a smooth transition to a video call may not be possible, but a smooth transition to VolP without video).

As described in this document, determining whether a smooth call transition to a particular type of call is possible may depend on the status indicator of network 355, which indicates whether the conditions in network 380 will support the type of call. The registration information of the 360 ​​application can also be checked to determine if an application that supports fluid transitions is registered. Different applications can be registered for different types of calls as described in this document. The information 360 may indicate whether a particular application supports fluid transitions (e.g., by type of call).

The determination may also depend on the capabilities of the other communication device 390. A technique for determining the capabilities of the other communication device 390 is to store the information locally (eg, associated with the contact database 325). For example, if a device is known to have video capabilities, an entry can be noted in the database (e.g. eg based on phone number or other address) to indicate that the device has video capabilities. The communication device 305 can periodically update the local storage by communicating with the application service 385 (e.g., to determine whether the contacts in the contact database 387 match those of the local database 325).

However, a user can have multiple devices that use the same address or username for a particular communication service. Accordingly, the capabilities can be determined by communicating with a communication application of counterpart 345B in the other communication device 390. Or, an application service 385 can actively update the status of the tracked devices (e.g. e.g., if they are connected, what software version do they have, etc.)

In some cases, communication applications 345A-349A are not present. Or, communication applications of a particular type are not present. In such a case, even if a fluid call transition is not immediately possible, an option can be presented in the current user interface by means of which an appropriate communication application can be obtained as described in this document. Consequently, fluid transition may then be possible. Thus, users can be carefully informed that transition functionality is possible on their device.

Similarly, if an application is presented but not configured or activated, an option can be presented in the current user interface through which the communication application can be configured or activated. Again, users can be carefully informed that transition functionality is possible on their device.

Example 5 - Illustrative method that implements fluid call transitions

Figure 4 is a flow chart of an illustrative method 400 for determining whether fluid call transitions are possible and can be implemented, for example, in the system shown in Figure 3. Although other arrangements are possible, in practice, the Method 400 is generally invoked during communications with another device by means of a call of the first type of call. The method can be implemented to preserve the fluid nature of the call transition. For example, a simple option may be presented in the user interface during a call when a smooth transition is possible instead of requesting navigation to a special or separate user interface.

In any of the examples mentioned here, (e.g., before method 400 begins, during method 400, or the like) it can be determined whether a communication application of the second type of call is available (e.g. , installed, registered, configured to be active or similar) on the local communication device. As described in this document, if multiple communication applications are available supporting a particular type of call, a favorite or preferred application for the type of call can be stored. The preferred application can then be used through the fluid transition process. The determination may also include determining whether the application supports fluid transitions (eg, towards a particular type of call).

If a communication application of the second type of call is not available, an option can be displayed in the current user interface, as described in this document, to obtain the application, activate it, configure it or the like. Otherwise, in response to the determination that a communication application of the second type of call is available, the method may continue. This confirms whether a communication application of the second type of call is available on the local communication device.

In 410, it is determined whether another communication device accepts a second call of the second type of call. As described in this document, such determination can be made in several ways.

Determining whether another device supports calls can be achieved by consulting local information about the other communication device. For example, a local contact database (e.g., an address book) can be checked to see if the other communication device (e.g., the number with which it can be found via a caller ID or that has been marked) or a user associated with the other communication device (e.g. For example, the user is stored in the local contacts associated with the current call number) has an account with a service provider that supports calls of the second type of calls. If so, it can be assumed that the other device supports such calls. The address book can be improved, or complemented, to indicate whether fluid transitions are possible. Information such as the type of platform, version of the platform, type of application, version of the application and the like, can be stored, consulted or both, to determine if the other device can implement fluid transitions.

Other techniques include direct verification with (eg, consulting) the other communication device. Such verification can be done when communication between the local and the remote application is initiated (eg, back-end versions of the application) that supports calls of the second type. For example, if a preferred application is indicated for a particular type of call, you can check to see if the other device has an instance, or background receiver, instead of the application. Or, the call controller or other software can store such information to avoid having to invoke applications.

Another technique is to consult an application service (e.g., a server associated with the communication application admitting the second type of call) to see if the number or contact is recognized (e.g., associated with the other device). Recognition may include if the number or contact is registered, active or both.

Μ χ »»

To facilitate the determination, a so-called application programming interface can be defined for communication applications through which the local communication application can be queried to provide an answer about whether the other device has the appropriate capabilities. The entries may include a type of call, a user identifier (e.g., number, address or the like), or both.

At 420, it is determined whether a current network is enabled to accept a call of the second type of call. For example, if connectivity to certain types of networks is unavailable or unstable, the type of call may not be possible. The communication device may store one or more indicators of the network status or indicators of the network connectivity condition to indicate the status of the respective networks. Such networks may include wireless data connections provided by mobile operators (e.g., 3G, 4G, 4G LTE, WiMAX or the like), Wi-Fi connections or the like. Different status indicators can be stored for different networks. Thus, determining whether a smooth transition is possible may comprise determining whether a network connectivity condition indicator indicates that the second type of call is possible.

If both determinations indicate the possibility of a smooth transition to a call of the second type of call (e.g., the other device has the capability and the network will support the second type of call), then an option can be provided to initiate the call. transition as described in this document. Other conditions may be incorporated in the determination.

Example 6 - Illustrative call types

In any of the examples presented here, technologies can support a plurality of different types of calls. One type of call that is almost ubiquitous in contemporary communication devices is the standard telephone call (mobile telephony) (eg, switched or managed through a mobile telephone operator infrastructure), which is sometimes called a “ cell phone call ”, although the underlying technology may not be cellular. Other types of calls include VolP calls, and in some implementations they can be further divided into VolP voice-only calls, VolP video calls and the like. RCS or RCS-e call types can also be supported.

Technologies can support a variety of ways of designating call types. For example, calls initiated by different communication applications that share certain characteristics can be considered as the same type of call (eg, Skype and Viber calls are considered as the type of video calls). Or, such calls can be implemented as different call types (e.g. eg, one type of call for a Skype call and another type of call for a Viber call).

In practice, different types of calls can be made through different channels or over different networks. However, some, or all stages may share the same network infrastructure.

Example 7 - Illustrative types of communication application

In addition to a communication application (“api”) that supports standard telephone calls, in any of the examples shown here, a wide variety of other types of communication application (eg, non-phone call applications). In practice, these types of communication applications can be provided by different parties (e.g., from third parties) (e.g. eg, provided and maintained by an entity other than the entity that provides and maintains the software for the telephone operating system, call controller, telephone call application or the like). Examples of types of applications that can be supported include video applications, VolP applications (eg, which can support video) and the like.

In practice, these types of applications may be associated with the service providers that create the software to achieve communications and maintain the servers that facilitate connections or other functionality. For example, the Skype ™ application provided by Microsoft Corporation, the Viber application provided by Viber Media Inc., the Tango ™ application provided by TangoME, Inc., and others are available applications that can be supported. Several RCS and RCS-e applications provided by mobile phone operators can also be supported.

In addition, within a particular service, there may be different current applications for different platforms or hardware versions. For example, the Skype ™ application can be implemented in several operating systems. In this way, a single service provider can create communication applications to be implemented on different platforms (eg, operating systems). For example, a Skype ™ communication application can be offered on various Windows® operating systems created by Microsoft Corporation, the OS and Mac OS operating systems created by Apple Inc., the AndroidTM operating system created by Google Inc. and the like. For convenience purposes, such a collection of applications is sometimes called a "family of applications" associated with a communication service.

Thus, the counterpart application on the other device does not need to be the same current application. The counterpart application can be used on a different platform to establish communications. The technologies described here can distinguish the different versions and platforms to determine whether fluid call transitions are possible and then, accordingly, implement them.

Applications can serve as ends for calls. Thus, a smooth transition can transit from a set of endpoints (e.g., phone call applications) to another set of endpoints (e.g., applications in a family of applications associated with a communication service).

Example 8 - Illustrative self-detection of capabilities

Self-detection of communication applications installed on the other communication devices that support smooth call transitions can be implemented to determine if there is any intersection with the applications on the local device. If both devices have a common application that supports transitions of fluid calls to a call of the second type of call, the shared application can be designated as the one to be used. If multiple applications are shared, user preferences can be consulted. In some cases, the application supports fluid transitions will depend on the platforms or versions of the application.

In this way, it can be determined that the parties participating in the first call can subscribe to the same service. A fluid improvement can then be made to a type of call supported by the service.

Example 9 - Illustrative implementation: improve video calling

The technologies described in this document can be implemented to improve from a voice phone call to a video call. In this case, the first type of call is a phone call (e.g., audio without video), and the second type of call is a video call (e.g., usually, video and audio via VolP) . Indicative video language and icons can be used through the user interface to indicate that a call can be enhanced to video using the fluid call transition technologies described in this document. In this way, the smooth transition improves an audio call to a video call.

Thus, for example, when two parties are participating in a cell phone call, they can improve the cell phone call to a video call by flowing smoothly to the type of video called.

This implementation can be done with a system comprising an executable audio application called and an executable video application called. The call controller can be configured to seamlessly transit a call from an audio application called to a video application called.

Example 10 - Illustrative implementation: improve VolP

The technologies described in this document can be implemented to improve a cell phone call to a VolP call. In these cases, the first type of call is a cell phone call (eg, audio without video) and the second type of call is a VolP call. Indicative language of VolP can be used through the user interface to indicate that a call can be improved to VolP using the fluid call transition technologies described in this document. In this way, the smooth transition improves from a cell phone call to a VolP call.

Thus, for example, when two parties are participating in a cell phone call, they can improve the VolP call to a video call by flowing smoothly to the type of VolP call.

This implementation can be done with a system comprising an executable application of telephone calls and an executable application of VolP calls. The call controller can be configured to seamlessly transit a call from a telephone call application to a VolP call application.

Example 11 - Illustrative option in the user interface that invokes a smooth call transition

In any of the examples shown here, an option can be presented in the user interface by means of which a smooth call transition can be invoked. As described in this document, this option may be presented conditionally based on the possibility of the call transition.

Figure 5 is a schematic of an illustrative user interface with call in progress 500 and includes an element of the user interface enabled 535 to initiate the transition. In practice, the user interface element 535 may appear disabled (e.g., gray, faded or similar) when it is unavailable and enabled when it is available. For example, the user interface element may appear disabled when network conditions do not support the second type of call.

The user interface element 535 may contain a description, text, logo, graphic or other information indicating that the application or type of call (eg, of the second call) is involved. For example, for transitions to a type of video called, a video camera or similar icon may be displayed.

In the example, the user interface element 535 appears as part of a user interface with a call in progress (e.g., call in progress, call entry or in the middle of the call) while the first call The user interface includes a photograph 520 of the other party and several other elements of the user interface to control a current call (e.g. e.g., speaker button 531, mute button 532, button to add another call 533, standby button 534, Bluetooth button 539). In practice, other elements of the user interface can be displayed.

In cases where fluid call transitions are not available, since the applicable communication application is not installed, the user interface element could still be presented. Thus, it can be determined that an application that supports calls of the second type is not installed in the communication device, and an option can be presented, as part of the user interface with call in progress, to initiate a process of installing the application in the communication device.

This element in the user interface can draw attention to the fact that an application that supports smooth call transitions (e.g., through a cone, graphics, text, color, or the like) could be installed. Activating the user interface element can lead to a list of supported communication applications. Activation of an application in the list may result in navigation to a market page where the application can be purchased. Or, the activation of the user interface element may result in direct navigation to an application market, or market page, where the appropriate communication application can be purchased.

Although the user interface element 535 can be enabled by determining that a call transition is possible, the determination does not have to be completely correct. For example, it could be that the other party is no longer subscribed to the corresponding service, or that the network conditions have deteriorated.

An implementation can support multiple elements of user interface 535 to make the transition. For example, different elements may be presented for different types of calls, different services or different characteristics of the call (eg, video, shared call or the like). Or, a single element 535 can support multiple types of calls (e.g., by means of a point and hold, knowledge of user behavior or the like).

If desired, a preference can be set for transitions to take place automatically when they are available.

Example 12 - Illustrative activation

In any of the examples shown here, a user interface element may take the form of a deployed, or implied, user interface element that a user can activate. These elements may take the form of tabs, icons, graphic buttons, areas, items in a list, shapes, slider control, or the like, presented as part of the graphical user interface. The user interface element may include text, graphics or colors to indicate functionality.

An activation (e.g., of a user interface element that can be activated) can take the form of user input indicating a selection (e.g., of the user interface element that can be activated). For example, in systems that support contact, a small blow, a swing or other touch action can be received. Other systems can support click, oscillation, voice activation, flickering, winking and the like.

Example 13 - Illustrative contact points

In any of the examples mentioned here, several telephone numbers or address types may be admitted (eg, home, mobile, work and the like). A contact point can take the form of a number or address associated with a contact. For example, a contact point can be a telephone number, the user's address for a contact, such as the work number for a contact, a mobile number for a contact, or a house number for a contact.

When determining the identity of the third party using the other communication device, the telephone number of the other communication device can be used to search for a contact that matches the contact point. The contact entry can then be used to find a number or user address for the communication application that is initiating the second call. For example, a telephone number can be used to determine the user address for a VolP call.

Example 14 - Illustrative consent

In any of the examples in this document, the opportunity can be given to consent to the call transition on the other communication device before the second call is activated, or initiated. For example, when transiting a type of call that supports video, the other party may not want your device to send video.

A user interface can be deployed to obtain the consent of a user. Information about the requesting party and the type of call can be displayed (eg, "Ellen is requesting that the call now includes video. OK?"). In response to receiving consent, the transition can continue.

To obtain the user's attention to request their consent, an audio tone or indicator can be produced.

If desired, the consent can be implemented so that the transition of the call is maintained respecting the intention of the user. For example, the call can be improved to VolP, but without including the video on the side without consent. Or, additional options may be presented to the user. For example, an independent consent can be implemented for the improvement and inclusion of the video.

In some cases, consent is not supported, and the experience on the recipient's side of the call cannot be that of a smooth transition from your side (e.g., the incoming call appears as an incoming call).

Example 15 - Illustrative method of call transition

Figure 6 is a flowchart of illustrative method of call transition 600 and which can be implemented, for example, in the system shown in Figure 1. A system implementing the method may also include a unique identifier of the first call and the logic to remove the audio as described in this document.

At 620, a second call of a second type of call (eg different from the first type of call) is initiated from the local communication device to the other communication device. The call may occur in the background (e.g., it is not presented to the user as a separate call). Meanwhile, the first call (e.g., the current one) remains active. For example, if a second call typically results in the first call that is on hold, such functionality can be inhibited. As described in this document, the audio of the second call can be deleted.

Although the second call may remain in the background, some indication of progress can be displayed without giving the impression that a second call is made. For example, while waiting for the connection, a frame, animation or other mechanism indicating the preparation for the transition can be displayed. Also, the user interface element that initiates the transition can be disabled.

In 630, the connectivity of the second call is confirmed. For example, it can be determined if the second call was successfully established with the other communication device. In this way, the second call is established (eg, on a second channel) while the first call is maintained. If for some reason the connectivity is not successful (eg, after n seconds), the process may fail and the first call still continues.

In 640, in response to the confirmation of connectivity of the second call, it can be made fully active. In some implementations, the first call may be put on hold, terminated, abandoned or another way to make it inactive. To facilitate the deactivation of the first call, a unique identifier that identifies the first call can be used. To avoid unwanted deactivation, or without authorization of the first call, a very simple unique identifier can be avoided. Instead, a complex identifier generation scheme (eg, GUID or similar) can be used to identify the call.

As part of the transition, audio resources can be changed to better facilitate the second type of call. For example, if the second type of call is video, the audio can be changed from a headset to a speaker to facilitate the use of the camera. If Bluetooth audio is being used, then audio resources do not need to be changed.

As described, the method 600 can be performed in application changes (e.g., switching between a call supported by one type of application to a call supported by a different type of application) while giving the impression that a single call is involved

When transitioning to call types that include video, a local video can be displayed on the device (e.g., to give the user the opportunity to verify the appearance) during an interstitial period, before the local video goes to Be visible on another communication device. The audio of the first call can continue during the interstitial period.

The smooth transition can be implemented in the same way on the recipient's device. However, the incoming call can be denoted as a special call that will be treated as part of the smooth transition. That way, instead of showing the incoming call as an incoming call, it can be handled in the background and the transition of the incoming call can then be done smoothly. Consent can be obtained as described in this document.

In some cases, network conditions may deteriorate, requesting a transition back to the type of call of the first call. Such a transition can be performed smoothly as described in this document. The other party's consent may not be possible or required (eg, when the video of a call is deleted).

Example 16 - Illustrative audio removal

In any of the examples in this document, the audio of the second call can be removed before it is activated. This technique can prevent the audio from duplicating, echoing and the like. The deletion of the call can be controlled by the call controller or another component.

Example 17 - Illustrative sequence of user interface

In any of the examples in this document, the user interface can sequence between the original user interface (e.g., the user interface with the call in progress) and the user interface of the communication application that supports the second call Upon completion of the transition, it seems that the first call becomes the second call. The functionality of the second type of call is then presented for use in the communication device.

On the other device, a request for consent can be displayed, after which the transitions of the user interface on which the second call is supported.

Example 18 - Illustrative state of call transition

In any of the examples in this document, a call transition state can be stored to help initiate the transition process. This state can be implemented together, or as part, of the state of a call. For example, the status may indicate "not implemented", "inactive", "initiating the second call", "completed" or the like.

Similarly, as described in this document, a network status indicator can be stored.

Example 19 - Illustrative method to register a communication application

Figure 7 is an illustrative method flow chart 700 for registering a communication application that performs transitions of fluid calls and that can be implemented, for example, in any of the communication devices described in this document.

In 720, a communication application is registered with a communication device. For example, an operating system, or other control software, may receive a notification that a communication application is being installed, that supports one or more types of calls and that supports smooth call transitions.

In 730, in response to the registration, the configuration of the communication device is updated. For example, you can update a list of communication applications that support a particular type of call, adding the communication application to the list. A preferred communication application can also be stored for a particular type of call.

In 740, as a result of the registration, an option is presented to make the smooth transition to a second call, of a type supported by the communication application in the user interface of the communication device. As described in this document, this option can be presented conditionally or enabled conditionally (eg, depending on the capabilities of the other communication device, network conditions and the like).

Thus, during the installation of the application that supports a second type of calls, the application can be registered to be used when fluid transitions are carried out by means of the second type of call. Subsequently, a user interface element may be presented in response to the registration indicating the second type of call or application.

Example 20 - Registered communication applications

Figure 8 is a block diagram of table 800 that stores a preferred communication application and that can be stored as part of the configuration data (eg, configuration data of transitions 130). Table 800 can store 830 entries indicating an application 830A and if the application is preferred 830B. The table can be constructed and updated when the communication applications are registered. The table can then be consulted when determining whether or which application should be displayed when an option is presented in the user interface for smooth call transitions. For example, if Application 3 is a preferred application, it can be indicated as the application that is invoked when the option is activated in the user interface (eg, by text, graphics, logo or the like).

Other information (e.g., text, icon, logo or other graphic) can also be stored or referenced in the table and displayed as part of the user interface element (e.g., as part of the user interface with the call in progress). The table can explicitly indicate, if an application supports fluid transitions, or the table can be limited to such communication applications. A separate preference can be set for fluid transition purposes. Thus, if there are multiple applications that support a particular type of call, a subset of them can support smooth transitions. If there are multiple applications in the subset, a particular communication application may be designated as preferred.

Although the example shows communication applications for a single type of call, multiple types of calls can be supported. Different applications may be indicated as preferred for different types of calls.

Example 21 - Illustrative configuration of communication applications

Figure 9 is an illustrative user interface configuration scheme 900 for choosing a preferred application for a type of call. In the example, a user interface is shown to choose a preferred communication application for a particular type of call. User interfaces for other types of calls, or additional ones, can be supported.

The preferred application can be shown in box 930. If more than one communication application is available, box 930 can be a drop-down box that allows you to choose a different application. Preferences as described in this document can then be updated accordingly.

Explanatory text 940 may be displayed to describe the result of choosing a particular application (eg, which will show the chosen application in the user interface with the call in progress). If applications are not installed, the interface can display text 940 indicating the results of obtaining a supported communication application. For example, text can describe the benefits of having video, the availability of smooth call transitions, etc. (p. eg, "do you know that you can improve a call to a video call with a better application?").

The user interface 900 can display an element of the user interface 950 that allows navigation to an application market where the supported application can be obtained as described herein.

An alternative technique may allow an application to configure itself as the preferred application for a particular type of call. Applications do not need to have direct access to the settings. For example, during registration, an application can access an API (eg, specifying the type of call, an application identifier or the like) to be configured as the preferred application. To prevent hidden configuration changes, a dialog box can be displayed to confirm the change (eg, "Do you want Application x to be your preferred video application? Yes / No"). An application can check the API to see if it is still preferred. If so, no changes are required.

Example 22 - Illustrative advantages

As described in this document, users can easily take advantage of their device's capabilities without having to learn new processes or even be aware, initially, that such capabilities exist.

Example 23 - Illustrative computer systems

Figure 10 shows a generalized example of a generalized computing system or environment (1000) where several innovations described can be implemented. The computer system 1000 is not intended to suggest any limitations in terms of scope of use or functionality, since innovations can be implemented in various general purpose or special purpose computer systems. A communication device as described in this document can take the form of the computer system 1000 described.

With reference to Figure 10, the computer system 1000 includes one or more processing units 1010, 1015 and memory 1020, 1025. In Figure 10, this basic configuration 1030 is included within a dotted line. The processing units 1010, 1015 execute computer executable instructions. A processing unit can be a general purpose central processing unit (CPU), processor in an application-specific integrated circuit (ASIC) or any other type of processor. In a multiple processing system, multiple processing units execute computer-executable instructions to increase processing power. For example, Figure 10 shows a central processing unit 1010 as well as a graphics processing unit or co-processing unit 1015. The tangible memory 1020, 1025 may be volatile memory (eg, registers, cache memory, RAM) , non-volatile memory (eg ROM, EEPROM, flash memory, etc.), or some combination of the two, accessible by the processing unit (s). Memory 1020, 1025 stores 1080 software that implements one or more innovations described herein , in the form of computer executable instructions suitable for execution by the processing unit (s).

A computer system may have additional features. For example, the computer system 1000 includes storage 1040, one or more input devices 1050, one or more output devices 1060, and one or more communication connections 1070. An interconnection mechanism (not shown) such as a common conductor , controller, or network interconnects the components of the 1000 computer system. Typically, the operating system software (not shown) provides an operating environment for other software running on the computing system 1000, and coordinates activities of the components of the computing system 1000.

Tangible storage 1040 may be removable or non-removable, and includes magnetic discs, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other means that can be used to store information in a non-transient manner and that can be accessed within the system. 1000 count. The 1040 storage stores instructions for the 1080 software implementing one or more innovations described herein.

The input device (s) 1050 may be a touch input device such as a keyboard, mouse, pen, or follow-up, a voice input device, a scanning device, or other device that provides input to the computing system 1000. To encode video, the input device (s) 1050 may be a camera, video card, TV tuner card, or similar device that accepts video input in analog or digital form, or a CD-ROM or CD-RW which reads video samples in the 1000 computer system. The output device (s) 1060 may be a screen, printer, horn, CD writer, or other device that provides output from the 1000 computer system.

Communication connection (s) 1070 allows communication through a means of communication to another computing entity. The communication medium carries information such as instructions executable by computer, 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 way that it encodes information in the signal. By way of example, and not limitation, the communication means may use an electrical, optical, RF, or other carrier.

Innovations can be described in the general context of computer readable media. Computer readable media are any tangible media that can be accessed within a computing environment. By way of example, and not limitation, with computer system 1000, computer readable media includes memory 1020, 1025, storage 1040, and combinations of any of the foregoing.

Innovations can be described in the general context of computer-executable instructions, such as those included in program modules, which are executed in a computer system in a real or virtual target processor (for example, which is ultimately executed in hardware ). Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The functionality of the program modules can be combined or divided between program modules as desired in various modalities. Computer executable instructions can be executed for program modules within a local or distributed computer system.

The terms system and device are used interchangeably here. Unless the context clearly indicates otherwise, no term implies any limitation on a type of computing system or computing device. In general, a computer system or computing device may be local or distributed, and may include any combination of special purpose hardware and / or general purpose hardware with software that implements the functionality described herein.

For the presentation search, the detailed description uses terms such as determining and using to describe computer operations in a computer system. These terms are high level abstractions for operations performed by a computer, and should not be confused with acts performed by a human being. Actual computer operations corresponding to these terms vary depending on implementation.

Example 24 - Illusive mobile devices

In any of the examples in this document, a computing device may take the form of a mobile device. Figure 11 is a system diagram illustrating an illustrative mobile device 1100 that includes a variety of optional hardware and software components, generally shown at 1102. Any of the components 1102 of the mobile device can communicate with any other component, although it is not show all connections, for ease of illustration. The mobile device can be any of a variety of computing devices (e.g., cell phone, smartphone, laptop, personal digital assistant (PDA), etc.) and can allow wireless two-way communications with one or more mobile communication networks 1104, such as a cellular, satellite, or other network. Voice scenarios can also be supported over the Internet protocol (eg, over Wi-FI or other network). The communication devices described in this document can take the form of the mobile device 1100 described.

The illustrated mobile device 1100 may include a controller or processor 1110 (eg, signal processor, microprocessor, ASIC, or other control and processing logic circuit) to perform such tasks as signal coding, data processing, data processing input / output, power control, and / or other functions. An operating system 1112 can control the distribution and use of components 1102 and support one or more application programs 1114. Application programs 1114 may include common mobile computing applications (eg, email applications, calendars, contact administrators, web browsers, messaging applications), or any other computing application. You can also use 1113 functionality to access an application storage to acquire and update 1114 applications.

The illustrated mobile device 1100 may include memory 1120. Memory 1120 may include non-removable memory 1122 and / or removable memory 1124. Non-removable memory 1122 may include RAM, ROM, flash memory, a hard disk or other storage technologies. Well-known memory. Removable memory 1124 may include flash memory or a Subscriber Identity Module (SIM) card, which is well known in systems of ',. »GSM communication or other well-known memory storage technologies, such as smart cards. Memory 1120 can be used to store data and / or encode to run operating system 1112 and applications 1114. Illustrative data may include web pages, text, images, sound files, video data, or other groups of data to be sent to and / or received from one or more network servers or other devices through one or more wired or wireless networks. Memory 1120 can be used to store a subscriber identifier, such as an International Mobile Subscriber Identity (IMSI), and a device identifier, such as International Mobile Equipment Identifier (IMEI). Such identifiers can be transmitted to a network server to identify users and equipment.

The mobile device 1100 can support one or more input devices 1130, such as a touch screen 1132, microphone 1134, camera 1136, physical keyboard 1138 and / or audio tag 1140 and one or more output devices 1150, such as a speaker or speaker 1152 and a screen 1154. Other possible output devices (not shown) may include piezoelectric or other haptic output devices. Some devices can serve more than one input / output function. For example, the touch screen 1132 and the screen 1154 can be combined into an individual input / output device.

A wireless modem 1160 can be coupled to an antenna (not shown) and can support bi-directional communications between the processor 1110 and external devices, as is well understood in the art. The 1160 modem is shown generically and may include a cellular modem for communicating with the mobile communication network 1104 and / or other radio-based modems (for example, Bluetooth 1164 or Wi-Fi 1162). The 1160 wireless modem is typically configured for communication with one or more cellular networks, such as a GSM or CDMA network for data and voice communications within an individual cellular network, between cellular networks, or between the mobile device and a switched telephone network public (PSTN).

The mobile device 1100 may also include at least one input / output port 1180, a power supply 1182, a satellite navigation system receiver 1184, such as a Global Positioning System (GPS) receiver, an accelerometer 1186, and / or a physical connector 1190, which can be a USB port, IEEE 1394 port (FireWire), and / or RS-232 port. The illustrated components 1102 are not required or are all included, since any of the components can be removed and other components can be added.

Example 25 - Illustrative cloud-supported environment

In the example environment 1200 of Figure 12, cloud 1210 provides services for connected devices 1230, 1240, 1250 with a variety of display capabilities. The connected device 1230 represents a device with a 1235 computer screen (for example, a medium size screen). For example, the connected device 1230 could be a personal computer such as desktop computer, laptop, notebook, netbook, or the like. The connected device 1240 represents a device with a mobile device screen 1245 (for example, a small size screen). For example, the connected device 1240 could be a mobile phone, smart phone, personal digital assistant, tablet computer, and the like. The connected device 1250 represents a device with a large screen 1255. For example, the connected device 1250 could be a television screen (for example, a smart television) or another device connected to a television (for example, a cable TV box or game console) or the like. One or more of the connected devices 1230, 1240, 1250 may include touch screen capabilities. Touch screens can accept input in different ways. For example, capacitive touch screens detect tactile input when an object (for example, a fingerprint or stylus) distorts or interrupts an electric current that runs through the surface. As another example, touch screens can use optical sensors to detect touch input when lightning is interrupted from the optical sensors. Physical contact with the screen surface is not necessary for the entry to be detected by some touch screens. Devices without display capabilities can also be used in the illustrative environment 1200. For example, cloud 1210 can provide services for one or more computers (eg, server computers) without screens.

The services can be provided by cloud 1210 through 1220 service providers, or through other online service providers (not illustrated). For example, cloud services can be adapted to the screen size, screen capacity, and / or touch screen capacity of a particular connected device (for example, connected devices 1230, 1240, 1250).

In the illustrative environment 1200, the cloud 1210 provides the technologies and solutions described herein to the various connected devices 1230, 1240, 1250 using, at least in part, the service providers 1220. For example, the service providers 1220 can provide a Centralized solution for several cloud-based services. 1220 service providers can handle service subscriptions for users and / or devices (for example, for connected devices 1230, 1240, 1250 and / or their respective users).

Example 26 - Illustrative implementations

Although the operations of some of the methods described in a particular order are described, sequence! For convenient presentation, it should be understood that this form of description encompasses redistribution, unless a particular order is required by specific language described below. For example, operations described sequentially in some cases can be redistributed or performed concurrently. In addition, for simplicity research, the attached figures may not show the various ways in which the methods described in conjunction with other methods may be used.

Any of the methods described can be implemented as computer executable instructions stored in one or more computer-readable storage media (e.g., non-transient computer-readable media, such as one or more optical media disks, memory components volatile (such as DRAM or SRAM) or non-volatile memory components (such as hard drives)) and run on a computer (e.g. eg, any commercially available computer, including smartphones or other mobile devices that include computer hardware). Any of the instructions executable on the computer to implement the described techniques, as well as any of the data created and used when implementing the described modalities, can be stored in one or more computer-readable media (e.g., media readable to the non-transient computer). The instructions executable to the computer can be part, for example, of a specialized software application or a software application accessed or downloaded by a browser or other software application (such as a remote computing application). Such software can be run, for example, on an individual local computer (for example, any suitable commercially available computer) or in a network environment (for example, over the Internet, a wide area network, a local area network , a client-server network (such as a cloud computing network), or another network) using one or more network computers.

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

In addition, any of the software-based modalities (comprising, for example, computer-executable instructions to make a computer perform any of the described methods) can be uploaded, downloaded, or accessed remotely through the appropriate means of communication. Each suitable means of communication includes, for example, the Internet, the global network, an Intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, infrared communications), electronic communications or Other different means of communication.

The methods, devices, and systems described should not be construed as limiting in any way. Instead, the present description is directed towards all the novel and non-obvious characteristics and aspects of the various modalities described, alone and in various combinations and sub-combinations with each other. The methods, devices, and systems described are not limited to any specific aspect or characteristic or combination thereof, nor are the methods described required that any of the specific advantages be present or problems are resolved.

Non-transient computer readable media

Any computer-readable medium described in this document may be non-transient (e.g., memory, magnetic storage, optical storage or the like). Storage in computer readable media

Any of the storage actions described in this document can be implemented by storing in one or more computer-readable media (e.g., computer-readable storage media or other tangible media).

Any of the things described as stored may be stored on one or more computer-readable media (e.g., computer-readable storage media or other tangible media).

Methods in computer readable media

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

Methods in computer readable storage devices

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

Illustrative combinations

Several combinations can be supported. For example, the user interface of the incoming call can be combined with the user interface of the call in progress (eg, after the incoming call is accepted). The user interface of the call in progress can be combined with the user interface of the call in progress in the background (eg, if the call goes to the bottom).

The user interface of the call in progress can be combined with the home user interface (eg, if navigation occurs in the home user interface during a call). In this case, the user interface of the call in background progress can also be deployed.

The user interface to initiate communications too

Hear- and can be combined with any of the other user interfaces. Alternatives

The technologies of any example can be combined with the technologies described in any or more of the other examples. Where the word "example" is used, an attempt is made to indicate an example and not an ideal modality. In view of the many possible modalities to which the described technology principles can be applied, it should be recognized that the illustrated modalities are examples of the described technology and should not be taken as a limitation on the scope of the described technology. Rather, the scope of the described technology includes what is covered by the following claims. Therefore, everything that comes within the scope and spirit of the claims is claimed as an invention.