U.S. patent application number 14/201547 was filed with the patent office on 2015-02-19 for seamless call transitions.
The applicant listed for this patent is Peter Bergler, Casey Dvorak, Tony He, Syed Mansoor Jafry, Karthik Nagarajan, Omobayonle Olatunji, Joseph A. Pommier, III, Kerry D. Woolsey. Invention is credited to Peter Bergler, Casey Dvorak, Tony He, Syed Mansoor Jafry, Karthik Nagarajan, Omobayonle Olatunji, Joseph A. Pommier, III, Kerry D. Woolsey.
Application Number | 20150049158 14/201547 |
Document ID | / |
Family ID | 51492444 |
Filed Date | 2015-02-19 |
United States Patent
Application |
20150049158 |
Kind Code |
A1 |
Olatunji; Omobayonle ; et
al. |
February 19, 2015 |
SEAMLESS CALL TRANSITIONS
Abstract
Various user interfaces and other technologies for seamlessly
transitioning between calls of different types can be implemented.
The technologies can be implemented to give the impression of a
single call that is upgraded from one call type to another. A new
application can register so that an appropriate user interface
control appears for activation when seamless call transition is
possible. Transitioning for third-party applications can thus be
supported. Cross-platform implementations can be supported.
Inventors: |
Olatunji; Omobayonle;
(Seattle, WA) ; Jafry; Syed Mansoor; (Kirkland,
WA) ; Nagarajan; Karthik; (Bothell, WA) ;
Pommier, III; Joseph A.; (Sammamish, WA) ; Dvorak;
Casey; (Seattle, WA) ; Woolsey; Kerry D.;
(Duvall, WA) ; He; Tony; (Kirkland, WA) ;
Bergler; Peter; (Duvall, WA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Olatunji; Omobayonle
Jafry; Syed Mansoor
Nagarajan; Karthik
Pommier, III; Joseph A.
Dvorak; Casey
Woolsey; Kerry D.
He; Tony
Bergler; Peter |
Seattle
Kirkland
Bothell
Sammamish
Seattle
Duvall
Kirkland
Duvall |
WA
WA
WA
WA
WA
WA
WA
WA |
US
US
US
US
US
US
US
US |
|
|
Family ID: |
51492444 |
Appl. No.: |
14/201547 |
Filed: |
March 7, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13970504 |
Aug 19, 2013 |
|
|
|
14201547 |
|
|
|
|
Current U.S.
Class: |
348/14.02 ;
370/331 |
Current CPC
Class: |
H04M 3/42161 20130101;
H04W 36/365 20130101; H04L 65/1083 20130101; H04W 4/16 20130101;
H04W 4/50 20180201; H04N 7/147 20130101 |
Class at
Publication: |
348/14.02 ;
370/331 |
International
Class: |
H04W 36/36 20060101
H04W036/36; H04N 7/14 20060101 H04N007/14 |
Claims
1. A method comprising: while conducting a cellular phone call
between a first communication device and a second communication
device, determining, by the first communication device, that the
second communication device supports a Voice-over-Internet-Protocol
(VoIP) call; determining that a network connectivity condition
indicator indicates that the VoIP call is possible; providing a
user interface option for initiating a seamless transition to the
VoIP call in a call progress user interface; responsive to
activation of the user interface option, initiating the VoIP call
between the first communication device and the second communication
device; and after the VoIP call is initiated, switching to the VoIP
call and ending the cellular phone call.
2. The method of claim 1, wherein determining that the second
communication device supports the VoIP call comprises querying an
application service to determine that a contact associated with the
second communication device is recognized.
3. The method of claim 1, wherein the determining that the second
communication device supports the VoIP call comprises using
information associated with a contacts database of the first
communication device.
4. The method of claim 1, wherein the initiating the VoIP call
comprises using a communication application supporting the VoIP
call.
5. The method of claim 1, further comprising: choosing a preferred
communication application for a VoIP call type; and wherein the
user interface option for initiating the seamless transition to the
VoIP call in the call progress user interface is associated with
the preferred communication application for the VoIP call type.
6. The method of claim 1, further comprising: during a registration
process for a third-party communication application, updating a
list of communication applications that support a particular call
type, wherein the updating comprises adding the third-party
communication application to the list.
7. The method of claim 1, further comprising: responsive to
determining that the first communication device and the second
communication device have an application that supports seamless
call transitions in common, designating the application as to be
used for call transition.
8. The method of claim 1, further comprising: updating a status of
the second communication device, wherein the status indicates
whether the second communication device is active.
9. The method of claim 1, further comprising: responsive to a
determination that a call transition is possible, enabling a user
interface element for switching to the VoIP call.
10. The method of claim 1, further comprising: allowing a
communication application to set itself as a preferred application
for a particular call type.
11. The method of claim 10, further comprising: before allowing the
communication application to set itself as the preferred
application for a particular call type, presenting a confirmation
user interface.
12. The method of claim 10, wherein: the particular call type
comprises a video call.
13. The method of claim 1, wherein: switching to the VoIP call
comprises upgrading a voice call to a video call.
14. The method of claim 13, wherein: upgrading the voice call to
the video call comprises switching audio to speaker.
15. The method of claim 13, further comprising: presenting language
and icons indicative of video in the call progress user interface;
wherein the language and icons indicate that the voice call can be
upgraded to the video call.
16. The method of claim 1, further comprising: storing a call
transition state.
17. A mobile device comprising: a phone call application supporting
standard audio phone calls; a communication application supporting
VoIP calls; and a call controller comprising configuration to
seamlessly transition a call from the phone call application to the
communication application supporting VoIP calls upon activation of
a user interface option to initiate a seamless transition to the
VoIP call.
18. The mobile device of claim 17 wherein: the user interface
option is presented as part of a call progress user interface.
19. The method of claim 17, wherein: seamlessly transitioning to
the VoIP call comprises upgrading a voice call to a video call.
20. One or more computer-readable storage media having encoded
therein computer-executable instructions causing a computing system
to perform a method comprising: while conducting a cellular phone
call with no video between a first communication device and a
second communication device, determining, by the first
communication device, that the second communication device supports
a Voice-over-Internet-Protocol (VoIP) call with video; determining
that a network connectivity condition indicator indicates that the
VoIP call with video is possible; providing a user interface option
for initiating a seamless transition to the VoIP call with video in
a call progress user interface; responsive to activation of the
user interface option, initiating the VoIP call with video between
the first communication device and the second communication device;
after the VoIP call with video is initiated, switching to the VoIP
call with video and ending the cellular phone call.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] This application is a continuation of U.S. patent
application Ser. No. 13/970,504, filed on Aug. 19, 2013, which is
hereby incorporated by reference herein.
BACKGROUND
[0002] Mobile phones now have functionality and applications that
provide a wide variety of communication modes. For example, a
single device can now support conventional phone calls,
Voice-over-Internet-Protocol (VoIP) calls, video calls, and the
like. However, such functionality has not been particularly well
integrated, and new users may not even be aware that such
functionality is available to them.
[0003] Because users can face hurdles when attempting to take
advantage of different communication modes, there remains room for
improvement.
SUMMARY
[0004] The Summary is provided to introduce a selection of concepts
in a simplified form that are further described below in the
Detailed Description. The Summary is not intended to identify key
features or essential features of the claimed subject matter, nor
is it intended to be used to limit the scope of the claimed subject
matter.
[0005] The technologies can include a method comprising: while
conducting a cellular phone call between a first communication
device and a second communication device, determining, by the first
communication device, that the second communication device supports
a Voice-over-Internet-Protocol (VoIP) call; determining that a
network connectivity condition indicator indicates that the VoIP
call is possible; providing a user interface option for initiating
a seamless transition to the VoIP call in a call progress user
interface; responsive to activation of the user interface option,
initiating the VoIP call between the first communication device and
the second communication device; and after the VoIP call is
initiated, switching to the VoIP call and ending the cellular phone
call.
[0006] The technologies can include a mobile device comprising: a
phone call application supporting standard audio phone calls; a
communication application supporting VoIP calls; and a call
controller comprising configuration to seamlessly transition a call
from the phone call application to the communication application
supporting VoIP calls upon activation of a user interface option to
initiate a seamless transition to the VoIP call.
[0007] The technologies can include one or more computer-readable
storage media having encoded therein computer-executable
instructions causing a computing system to perform a method
comprising: while conducting a cellular phone call with no video
between a first communication device and a second communication
device, determining, by the first communication device, that the
second communication device supports a Voice-over-Internet-Protocol
(VoIP) call with video; determining that a network connectivity
condition indicator indicates that the VoIP call with video is
possible; providing a user interface option for initiating a
seamless transition to the VoIP call with video in a call progress
user interface; responsive to activation of the user interface
option, initiating the VoIP call with video between the first
communication device and the second communication device; after the
VoIP call with video is initiated, switching to the VoIP call with
video and ending the cellular phone call.
[0008] As described herein, a variety of other features and
advantages can be incorporated into the technologies as
desired.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] FIG. 1. is a block diagram of an exemplary system
implementing seamless call transitions.
[0010] FIG. 2. is a flowchart of an exemplary method of
implementing seamless call transitions.
[0011] FIG. 3. is a block diagram of an exemplary system configured
to determine whether seamless call transitions are possible.
[0012] FIG. 4. is a flowchart of an exemplary method of determining
whether seamless call transitions are possible.
[0013] FIG. 5. is a wire frame of an exemplary call progress user
interface implementing a seamless call transition.
[0014] FIG. 6. is a flowchart of an exemplary method of
transitioning a call.
[0015] FIG. 7. is a flowchart of an exemplary method of registering
a communication application to accomplish seamless call
transitions.
[0016] FIG. 8. is a block diagram of a table storing a preferred
communication application.
[0017] FIG. 9. is a wire frame of an exemplary settings user
interface for choosing a preferred application for a call type.
[0018] FIG. 10. is a diagram of an exemplary computing system in
which some described embodiments can be implemented.
[0019] FIG. 11. is an exemplary mobile device that can be used for
the technologies described herein.
[0020] FIG. 12. is an exemplary cloud-support environment that can
be used in conjunction with the technologies described herein.
DETAILED DESCRIPTION
Example 1
Exemplary Overview
[0021] The technologies described herein can be used for a variety
of seamless call transition scenarios, and adoption of the
technologies can provide improved techniques for communicating via
different call types. The user interfaces can better facilitate
seamless call transitions. Other features described herein can be
implemented to customize the call experience to user preferences.
An overall superior user experience with smoother transitions
between call types can result.
[0022] Further, the technologies can support a variety of
communication applications and implement cross-platform seamless
call transitions.
[0023] Various other features can be implemented and combined as
described herein.
Example 2
Exemplary System Implementing Seamless Call Transitions
[0024] FIG. 1 is a block diagram of an exemplary system 100
implementing seamless call transitions as described herein.
[0025] For purposes of context, FIG. 1 shows that the communication
device 110 is engaged in communication with another (e.g., remote)
communication device 190 via one or more networks 180.
[0026] In the example, a communication device 110 includes a call
controller 120 and a contact database 125. Transitions
configuration data 130 can include a preferred application for use
with a particular call type. A call transition state 137 can track
the state of call transition as described herein.
[0027] 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 hosted by two different
applications, a phone call application 140A in communication with
its counterpart 140B and another (e.g., non-phone call)
communication application 145A in communication with its
counterpart 145B. The different applications 140A, 145B can be of
different application types. As described herein, cross-platform
operation can be supported. The calls can pass through one or more
networks 180. For example, the calls 172, 174 can be made over the
same or different networks 180. The calls can pass through
different physical or logical communication channels.
[0028] As described herein, a transition between the two calls 172,
174 can be performed seamlessly to give the impression that a
single call is involved (e.g., the call or communication are not
interrupted). Various techniques, such as initiating the second
call in the background, maintaining the first call, suppressing
audio of the second call, inhibiting portraying the second call as
a second call, and ultimately transitioning to the second call can
be applied to implement seamless call transitions.
[0029] Although various components are shown in separate boxes, in
practice, component boundaries may vary. For example, the
components can be provided as part of a phone operating system,
call controller, or the like. Other arrangements are possible while
still implementing the technologies.
[0030] In practice, the systems shown herein, such as system 100,
can be more complicated, with additional functionality, more
communication apps, and the like.
[0031] The system 100 and any of the other systems described herein
can be implemented in conjunction with any of the hardware
components described herein, such as the computing systems or
mobile devices described below (e.g., comprising one or more
processors, memory, and the like). In any of the examples herein,
the inputs, outputs, preferences, and applications can be stored in
one or more computer-readable storage media or computer-readable
storage devices. The technologies described herein can be generic
to the specifics of operating systems or hardware and can be
applied in any variety of environments to take advantage of the
described features.
Example 3
Exemplary Method Implementing Seamless Call Transitions
[0032] FIG. 2 is a flowchart of an exemplary method 200 of
implementing seamless call transitions and can be implemented, for
example, in the system shown in FIG. 1.
[0033] The method 200 is typically performed after a first call
(e.g., with a phone call application) has already been established.
In practice, a call progress user interface is displayed while
conducting the first call.
[0034] At 210, it is determined whether seamless call transition to
a second call of a second call type (e.g., different from the first
call) is possible. Such a determination can be made while
conducting the first call of the first call type. As described
herein, such a determination can be based on capabilities of the
other communication device, network conditions, and the like. At
this point, the second call need not be established.
[0035] At 220, responsive to determining that seamless call
transition is possible, an option is presented in a user interface
of the communication device to initiate seamless call transition.
As described herein, such an option can take the form of a
graphical button that is enabled upon determination that seamless
call transition is possible. The option can be presented as part of
a call progress user interface (e.g., while conducting the first
call).
[0036] Although not shown, the method can include obtaining consent
from the other communication device as described herein.
[0037] At 230, responsive to activation of the user interface
option, the first call of the first call type is seamlessly
transitioned to a second call of the second call type. The second
call can be established (e.g., as part of the transition process or
beforehand) while maintaining the first call. Thus, to a user of
the communication device, the two calls appear to be as one (e.g.,
uninterrupted) call. A typical scenario is transitioning a phone
call to a VoIP call (e.g., with or without video), but other
transitions are possible as described herein.
[0038] During seamless transitioning, two calls can be
simultaneously maintained with the same (e.g., other) communication
device.
[0039] A variety of techniques can be used during seamless
transitioning. For example, the second call can be initiated, the
audio suppressed, and connectivity confirmed. Subsequently, the
audio can be unsuppressed, and the first call can be dropped.
[0040] Upon transition to the second call, any features available
to a call of the second type can be made available. As described
herein, such features can include video, screen sharing, or other
functionality provided by the communication application
orchestrating the second call. Accordingly, the user interface can
be upgraded to provide or indicate such features.
[0041] A typical use case for the method 200 is to transition a
call from a phone call over a conventional (e.g., circuit switched,
cellular, or the like) phone call to a Voice-over-Internet-Protocol
(VoIP) call. VoIP calls can support video and other features as
desired. However, the technologies can support transitions between
other call types, or transitions in the other direction.
[0042] The method 200 and any of the other methods described herein
can be performed by computer-executable instructions (e.g., causing
a computing 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
Exemplary Communication Device Implementing Seamless Call
Transitions
[0043] FIG. 3 is a block diagram showing an exemplary system 300
configured to determine whether seamless call transitions are
possible. In the example, a communication device 305 (e.g.,
communication device 110 of FIG. 1) comprises a phone call app
340A, one or more communication applications 345A-349A, a contacts
data base 325, and network state indicator 355.
[0044] A variety of techniques can be used to determine whether a
seamless call transition is possible. In some cases, a variety of
different call types may be supported, and the determination can be
made individually for the different call types (e.g., a seamless
transition to a video call may not be possible, but a seamless
transition to VoIP without video may be possible).
[0045] As described herein, a determination of whether a seamless
call transition to a particular call type is possible can depend on
the network state indicator 355, which indicates whether conditions
on the network 380 will support the call type. A check against the
application registration information 360 can also be performed to
determine whether an application that supports seamless transitions
is registered. Different apps can be registered for different call
types as described herein. The information 360 can indicate whether
a particular application supports seamless transitions (e.g., by
call type).
[0046] The determination can also depend on the capabilities of the
other communication device 390. One technique for determining the
capabilities of the other communication device 390 is to store
information locally (e.g., associated with the contacts database
325). For example, if a device is known to have video capabilities,
an entry in the database (e.g., based on phone number or other
address) can be annotated to indicate that the device has video
capabilities. The communication device 305 can periodically update
the local store by communicating with the application service 385
(e.g., to determine if contacts in the contacts database 387 match
those in the local database 325).
[0047] However, a user may have multiple devices that use the same
address or username for a particular communication service.
Accordingly, capabilities can be determined by communicating with a
counterpart communication application 345B on the other
communication device 390. Or, an application service 385 may
actively update the status of tracked devices (e.g., whether they
are connected, what version of software they have, etc.).
[0048] In some cases, no communication applications 345A-349A are
present. Or, no communication applications of a particular type may
be present. In such a case, although a seamless call transition is
not immediately possible, an option in the current user interface
can be presented by which an appropriate communication application
can be obtained as described herein. Consequently, seamless
transition may then be possible. Thus, users can be helpfully
informed that transition functionality is a possibility on their
device.
[0049] Similarly, if an application is present but not configured
or activated, an option in the current user interface can be
presented by which the communication application can be configured
or activated. Again, users can be helpfully informed that
transition functionality is a possibility on their device.
Example 5
Exemplary Method Implementing Seamless Call Transitions
[0050] FIG. 4 is a flowchart of an exemplary method 400 of
determining whether seamless call transitions are possible and can
be implemented, for example, in the system shown in FIG. 3.
Although other arrangements are possible, in practice, the method
400 is typically invoked during communications with another device
via a call of a first call type. The method can be implemented to
preserve the seamless nature of the call transition. For example, a
simple user interface option can be presented during a call when a
seamless transition is possible instead of requiring navigation to
a special or separate user interface.
[0051] In any of the examples herein, (e.g., before the method 400
commences, during the method 400, or the like) it can be determined
whether a communication application of the second call type is
available (e.g., installed, registered, configured to be active, or
the like) at the local communication device. As described herein,
if multiple communication applications supporting a particular call
type are available, a favorite or preferred application can be
stored for the call type. The preferred application can then be
used throughout the seamless transition process. The determination
can also include determining whether the application supports
seamless transitions (e.g., to a particular call type).
[0052] If a communication application of the second call type is
not available, an option can be displayed in the current user
interface as described herein to obtain the application, activate
it, configure it, or the like. Otherwise, responsive to determining
that a communication application of the second call type is
available, the method can continue. Thus, it is confirmed whether a
communication application of the second call type is available at
the local communication device.
[0053] At 410, it is determined whether the other communication
device supports a second call of the second call type. As described
herein, such a determination can be made in a variety of ways.
[0054] Determining whether the other device supports calls can be
accomplished by querying local information about the other
communication device. For example, a local contacts database (e.g.,
address book) can be checked to see if the other communication
device (e.g., the number of which can be found via caller id or was
dialed) or a user associated with the other communication device
(e.g., the user is stored in local contacts as associated with the
number of the current call) has an account with a service provider
supporting calls of the second call type. If so, it can be assumed
that the other device supports such calls. The address book can be
enhanced or supplemented to indicate whether seamless transitions
are possible. Information such as a platform type, platform
version, application type, application version, and the like can be
stored, consulted, or both to determine whether the other device
can implement seamless transitions.
[0055] Other techniques include checking directly with (e.g.,
querying) the other communication device. Such a check can be made
by handshaking between a local app and the remote app (e.g., or
background versions of the app) that supports calls of the second
call type. For example, if a preferred app is indicated for a
particular call type, a query can be made to see if the other
device has an instance or background listener in place of the app.
Or, the call controller or other software can store such
information to avoid having to invoke the applications.
[0056] Another technique is to query an application service (e.g.,
a server associated with the communication application supporting
the second call type) to see if a number or contact (e.g.,
associated with the other device) is recognized. Recognition can
include whether the number or contact is registered, active, or
both.
[0057] To facilitate the determination, an application programming
interface call can be defined for communication applications by
which a local communication application can be queried to provide
an answer concerning whether the other device has appropriate
capabilities. Inputs can include a call type, a user identifier
(e.g., number, address, or the like), or both.
[0058] At 420, it is determined whether a current network is able
to support a call of the second call type. For example, if
connectivity to certain types of networks is unavailable or
unstable, the call type may not be possible. The communication
device can store one or more network state indicators or network
connectivity condition indicators to indicate the status of
respective networks. Such networks can 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 it is possible to seamlessly transition can
comprise determining whether a network connectivity condition
indicator indicates that the second call type is possible.
[0059] If both of the determinations indicate that a seamless
transition to a call of the second call type is possible (e.g., the
other device has the capability and the network will support the
second call type), then an option for initiating the transition can
be provided as described herein. Other conditions can be
incorporated into the determination.
Example 6
Exemplary Call Types
[0060] In any of the examples herein, the technologies can support
a plurality of different call types. One call type that is nearly
ubiquitous in contemporary communication devices is the standard
(mobile) phone call (e.g., switched or managed via a mobile
operator infrastructure), that is sometimes called a "cellular
call," even though the underlying technology may not be cellular.
Other call types include VoIP calls, which in some implementations
can be further divided into voice-only VoIP calls, video VoIP
calls, and the like. RCS or RCS-e call types can also be
supported.
[0061] The technologies can support a variety of ways of
designating call types. For example, calls orchestrated by
different communication applications that share certain
characteristics can be considered to be the same call type (e.g.,
Skype calls and Viber calls are considered to be of the video call
type). Or, such calls can be implemented as different call types
(e.g., one call type for a Skype call and another call type for a
Viber call).
[0062] In practice, different call types can be accomplished
through different channels or over different networks. However,
some or all legs can share the same network infrastructure.
Example 7
Exemplary Communication Application Types
[0063] In addition to a communication application ("app") that
supports standard phone calls, in any of the examples herein, a
wide variety of other communication application types (e.g.,
non-phone call apps) can be supported on a single device. In
practice, such communication applications can be provided by
different (e.g., third-) parties (e.g., provided and maintained by
an entity other than the entity that provides and maintains the
software for the phone operating system, call controller, the phone
call app, or the like). Exemplary application types that can be
supported include video applications, VoIP application (e.g., that
can support video), and the like.
[0064] In practice, such application types can be associated with
service providers who originate the software for achieving
communications and maintain servers that facilitate connections or
other functionality. For example, the Skype.TM. application
provided by Microsoft Corporation, the Viber application provided
by Viber Media Inc., the Tango.TM. application provided by TangoME,
Inc., and others are available applications that can be supported.
Various RCS and RCS-e applications provided by mobile operators can
also be supported.
[0065] Further, within a particular service, there may be different
actual applications for different platforms or versions of
hardware. For example, a Skype.TM. application may be implemented
on a variety of operating systems. Thus, a single service provider
can originate communication applications to be implemented across
different platforms (e.g., operating systems). For example, a
Skype.TM. communication application can be provided on the various
Windows.RTM. operating systems originating from Microsoft
Corporation, the iOS and Mac OS operating systems originating from
Apple Inc., the Android.TM. operating system originating from
Google Inc., and the like. For purposes of convenience, such a
collection of applications is sometimes called an "application
family" associated with a communication service.
[0066] Thus, a counterpart application on another device need not
be the same actual application. A counterpart application for a
different platform can be used to establish communications. The
technologies herein can distinguish the different versions and
platforms to determine whether seamless call transitions are
possible and then implement them accordingly.
[0067] The applications can serve as endpoints for the calls. Thus,
a seamless transition can transition from one set of endpoints
(e.g., phone call applications) to another set of endpoints (e.g.,
applications in an application family associated with a
communication service).
Example 8
Exemplary Auto-Detection of Capabilities
[0068] Auto-detection of the other communication device's installed
communication applications that support seamless call transitions
can be implemented to determine if there is any intersection with
applications at the local device. So, if both devices have an
application in common that supports seamless call transitions to a
call of the second call type, 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, whether
an application supports seamless transitions may depend on the
platforms or version of the application.
[0069] It can thus be determined that the parties engaged in the
first call both subscribe to the same service. An seamless upgrade
to a call type supported by the service can then be
accomplished.
Example 9
Exemplary Implementation: Upgrade to Video Call
[0070] The technologies described herein can be implemented to
upgrade a voice phone call to a video call. In such a case, the
first call type is a phone call (e.g., audio with no video), and
the second call type is a video call (e.g., typically video and
audio via VoIP). Language and icons indicative of video can be used
throughout the user interface to indicate that a call can be
upgraded to video using the seamless call transition technologies
described herein. Thus, the seamless transition upgrades from an
audio call to a video call.
[0071] So, for example, when two parties are talking as part of a
cellular call, they can upgrade the cellular call to a video call
by seamlessly transitioning the call to a video call type.
[0072] Such an implementation can be accomplished with a system
comprising an executable audio calling application and an
executable video calling application. The call controller can be
configured to seamlessly transition a call from the audio calling
application to the video calling application.
Example 10
Exemplary Implementation: Upgrade to VoIP
[0073] The technologies described herein can be implemented to
upgrade a cellular phone call to a VoIP call. In such a case, the
first call type is a cellular call (e.g., audio with no video), and
the second call type is a VoIP call. Language and icons indicative
of VoIP can be used throughout the user interface to indicate that
a call can be upgraded to VoIP using the seamless call transition
technologies described herein. Thus, the seamless transition
upgrades from a cellular call to a VoIP call.
[0074] So, for example, when two parties are talking as part of a
cellular call, they can upgrade the VoIP call to a video call by
seamlessly transitioning the call to a VoIP call type.
[0075] Such an implementation can be accomplished with a system
comprising an executable phone calling application and an
executable VoIP calling application. The call controller can be
configured to seamlessly transition a call from the phone calling
application to the VoIP calling application.
Example 11
Exemplary User Interface Option to Invoke Seamless Call
Transition
[0076] In any of the examples herein, a user interface option can
be presented by which seamless call transition can be invoked. As
described herein, such an option can be presented conditionally,
based on whether such a call transition is possible.
[0077] FIG. 5 is a wire frame of an exemplary call progress user
interface 500 and includes an activatable user interface element
535 for initiating the transition. In practice, the user interface
element 535 can be depicted as disabled (e.g., greyed out, faded,
or the like) when not available and enabled when available. For
example, the user interface element can be depicted as disabled
when network conditions do not support the second call type.
[0078] The user interface element 535 can incorporate a
description, text, logo, graphic, or other information that
indicates which application or call type (e.g. of the second call)
is involved. For example, for transitions to a video call type, a
video camera or similar icon can be shown.
[0079] In the example, the user interface element 535 is depicted
as part of a call progress (e.g., ongoing call, in-call, or
mid-call) user interface while conducting the first call. The user
interface includes a photograph 520 of the other party, and various
other user interface elements for controlling a current call (e.g.,
speaker button 531, mute button 532, add call button 533, hold
button 534, and Bluetooth button 539). In practice, other or
additional user interface elements can be shown.
[0080] In cases where seamless call transitions are not available
because no applicable communication application is installed, a
user interface element can still be presented. Thus, it can be
determined that an application for supporting calls of the second
type is not installed on the communication device, and an option as
part of a call progress user interface can be presented to initiate
an installation process for the application on the communication
device.
[0081] Such a user interface element can call attention to the fact
that an application supporting seamless call transitions could be
installed (e.g., via an icon, graphics, text, color, or the like).
Activation of the user interface element can lead to displaying a
list of supported communication applications. Activation of an
application in the list can result in navigation to a marketplace
page where the application can be acquired. Or, activation of the
user interface element can result in direct navigation to an app
marketplace or marketplace page where an appropriate communication
app can be purchased.
[0082] Although the user interface element 535 can be enabled upon
determination that a call transition is possible, the determination
need not be completely accurate. For example, it may be that the
other party no longer subscribes to the relevant service, or that
network conditions have since deteriorated.
[0083] An implementation can support multiple user interface
elements 535 for transitioning. For example, different elements can
be presented for different call types, different services, or
different call features (e.g., video, screen sharing, or the like).
Or, a single element 535 can support multiple call types (e.g., via
tap and hold, learning user behavior, or the like).
[0084] If desired, a preference can be set so that transitions
automatically take place when available.
Example 12
Exemplary Activation
[0085] In any of the examples herein, a user interface element can
take the form of a displayed or implied user interface element that
can be activated by a user. Such elements can take the form of
tiles, icons, graphical buttons, areas, items in a list, shapes,
sliders, or the like, presented as part of a graphical user
interface. The user interface element can include text, graphics,
or color to indicate functionality.
[0086] An activation (e.g., of an activatable user interface
element) can take the form of user input indicative of selection
(e.g., of the activatable user interface element). For example, in
systems supporting touch, a tap, hover, or other touch gesture can
be received. Other systems can support clicking, hovering, voice
activation, blinking, winking, and the like.
Example 13
Exemplary Contact Points
[0087] In any of the examples herein, various number or address
types can be supported (e.g., home, mobile, work, or 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 phone number
or user address for a contact, such as a work number for a contact,
a mobile number for a contact, or a home number for a contact.
[0088] When determining the identity of a party using the other
communication device, the phone number of the other communication
device can be used to search for a contact that has a matching
contact point. The contact entry may then be used to find a number
or user address for the communication application that is
orchestrating the second call. For example, a phone number can be
used to determine a user address for a VoIP call.
Example 14
Exemplary Consent
[0089] In any of the examples herein, an opportunity can be given
to consent to the call transition at the other communication device
before the second call is activated or initiated. For example, when
transitioning to a call type that supports video, the other party
may not wish their device to send video.
[0090] A user interface can be displayed that obtains consent from
a user. Information about the requesting party and type of call can
be shown (e.g., "Ellen is requesting that the call now include
video. OK?"). Responsive to receipt of consent, the transition can
continue.
[0091] To obtain the attention of the user, a tone or other audio
indication can be played when asking for consent.
[0092] If desired, consent can be implemented so that the call
transition still takes place while respecting the user's intent.
For example, the call can be upgraded to VoIP, but video from the
non-consenting side is not included. Or, additional options can be
presented to the user. For example, independent consent for upgrade
and inclusion of video can be implemented.
[0093] In some cases, consent may not be supported, and the
experience from the callee's side may not be that of a seamless
transition on the callee's side (e.g., the incoming call appears as
an incoming call).
Example 15
Exemplary Method of Transitioning a Call
[0094] FIG. 6 is a flowchart of an exemplary method 600 of
transitioning a call and can be implemented, for example, in the
system shown in FIG. 1. A system implementing the method can also
include a unique identifier of the first call and audio suppression
logic as described herein.
[0095] At 620, a second call of a second (e.g., different from the
first) call type is initiated from the local communication device
to the other communication device. The call can be placed in the
background (e.g., is not presented to the user as a separate call).
Meanwhile, the first (e.g., current) call is kept active. For
example, if a second call typically results in the first call being
placed on hold, such functionality can be inhibited. As described
herein, the audio of the second call can be suppressed.
[0096] Although the second call can be placed in the background,
some indication of progress can be provided without giving the
impression that a second call has been made. For example, while
waiting for connection, a marquee, animation, or other mechanism
indicative of preparing for the transition can be shown. Also, the
user interface element that initiated the transition can be
disabled.
[0097] At 630, connectivity of the second call is confirmed. For
example, it can be determined whether the second call was
successfully established with the other communication device. Thus,
the second call is established (e.g., over a second channel) while
maintaining the first call. If for some reason connectivity is not
successful (e.g., after n seconds), the process can fail, and the
first call still continues.
[0098] At 640, responsive to confirming connectivity of the second
call, the second call can be made fully active. In some
implementations, the first call can then be placed on hold,
terminated, dropped, or otherwise become inactive. To facilitate
deactivation of the first call, a unique identifier can be used to
identify the first call. To avoid undesirable or unauthorized
deactivation of the first call, a simplistic unique identifier can
be avoided. Instead, a more complex (e.g., GUID or the like)
identifier generation scheme can be used to identify the call.
[0099] As part of the transition, audio resources can be switched
to better facilitate the second call type. For example, if the
second call type is video, the audio can be switched from device
earpiece to speaker to facilitate use of the camera. If Bluetooth
audio is being used, then the audio resources need not be
switched.
[0100] As described, the method 600 can accomplish switching
applications (e.g., switching between a call supported by one
application type to a call supported by a different application
type) while maintaining the impression that a single call is
involved.
[0101] When transitioning to call types that include video, local
video can be shown on the device (e.g., to give the user an
opportunity to check appearance) during an interstitial period
before the local video becomes visible to the other communication
device. Audio from the first call can continue during the
interstitial period.
[0102] On the callee's device, the seamless transition can be
implemented in a similar manner. However, the incoming call can be
denoted as a special call that is to be treated as part of seamless
transition. So, instead of showing the incoming call as an incoming
call, it can be handled in the background, and transition to the
incoming call can then be accomplished seamlessly. Consent can be
obtained as described herein.
[0103] In some cases, network conditions may deteriorate, prompting
a transition back to the call type of the first call. Such a
transition can be performed seamlessly as described herein. Consent
of the other party may not be possible or required (e.g., when
removing video from a call).
Example 16
Exemplary Suppression of Audio
[0104] In any of the examples herein, audio for a second call can
be suppressed before it is made active. Such a technique can avoid
doubling of audio, echoing, and the like. Call suppression can be
controlled by the call controller or other component.
Example 17
Exemplary User Interface Sequence
[0105] In any of the examples herein, the user interface can
sequence between the original user interface (e.g., a call progress
UI) and the user interface of the communication application
supporting the second call. Upon completion of the transition, it
appears that the first call transformed into the second call. The
functionality of the second call type is then presented for use at
the communication device.
[0106] At the other device, a request for consent can be shown,
after which the user interface transitions into that supporting the
second call.
Example 18
Exemplary Call Transition State
[0107] In any of the examples herein, a call transition state can
be stored to help orchestrate the transition process. Such a state
can be implemented in conjunction or as part of a call state. For
example, the state can indicate "not implemented," "inactive,"
"initiating second call," "completed," or the like.
[0108] Similarly, as described herein, a network state indicator
can be stored.
Example 19
Exemplary Method of Registering a Communication Application
[0109] FIG. 7 is a flowchart of an exemplary method 700 of
registering a communication application to accomplish seamless call
transitions and can be implemented, for example, in any of the
communication devices described herein.
[0110] At 720, a communication application is registered with a
communication device. For example, an operating system or other
controlling software can receive a notification that a
communication application is being installed, that it supports one
or more call types, and that it supports seamless call
transitions.
[0111] At 730, responsive to the registration, the configuration of
the communication device is updated. For example, a list of
communication applications that support a particular call type can
be updated by adding the communication application to the list. A
preferred communication application for a particular call type can
also be stored.
[0112] At 740, as a result of the registration, an option for
seamlessly transitioning to a second call of a type supported by
the communication application is presented in a user interface of
the communication device. As described herein, such an option can
be presented conditionally or conditionally enabled (e.g.,
depending on capabilities of the other communication device,
network conditions, and the like).
[0113] Thus, during installation of an application supporting a
second call type, the application can be registered as to be used
when conducting seamless transitions via the second call type.
Subsequently, a user interface element indicating the second call
type or the application can be presented responsive to the
registering.
Example 20
Registered Communication Applications
[0114] FIG. 8 is a block diagram of a table 800 storing a preferred
communication application and can be stored as part of
configuration data (e.g., transitions configuration data 130). The
table 800 can store entries 830 that indicate an application 830A
and whether the application is preferred 830B. The table can be
built and updated when communication applications register. Then,
the table can be consulted when determining whether or which
application to show when presenting a user interface option for
seamless call transitions. For example, if Application 3 is the
preferred application, it can be indicated as the application
invoked when the user interface option is activated (e.g., by text,
graphics, logo, or the like).
[0115] 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 a call progress
UI). The table can explicitly indicate whether an application
supports seamless transitions, or the table can be limited to such
communications applications. A separate preference can be set for
purposes of seamless transitions. So, if there are multiple
applications that support a particular call type, a subset may
support seamless transitions. If there are multiple applications in
the subset, a particular one of the communication applications can
be designated as preferred.
[0116] Although the example shows communication applications for a
single call type, multiple call types can be supported. Different
applications can be indicated as preferred for different call
types.
Example 21
Exemplary Configuration of Communication Applications
[0117] FIG. 9 is a wire frame of an exemplary settings user
interface 900 for choosing a preferred application for a call type.
In the example, a user interface for selecting a preferred
communication application for a particular type of call (e.g.,
video) is shown. User interfaces for other or additional call types
can be supported.
[0118] The preferred application can be shown in box 930. If more
than one communication application is available, the box 930 can be
a drop down box that allows selection of a different application.
Preferences as described herein can then be updated
accordingly.
[0119] Explanatory text 940 can be shown to describe the result of
choosing a particular application (e.g., that the selected
application will be shown in the call progress UI). If no
applications are installed, the interface can display text 940
indicating the results of obtaining a supporting communication
application. For example, the text can describe the benefits of
having video, the availability of seamless call transitions, etc.
(e.g., "Did you know that you can upgrade a call to a video call
with an upgrade app?").
[0120] The user interface 900 can display a user interface element
950 that allows navigation to an application marketplace where a
supporting application can be obtained as described herein.
[0121] An alternative technique can allow an application to set
itself as the preferred application for a particular call type.
Applications need not have direct access to the settings. For
example, during registration, an application can access an API
(e.g., specifying the call type, an application identifier, or the
like) to set itself as the preferred application. To prevent
surreptitious changes to configuration, a dialog box can be
displayed to confirm the change (e.g., "Make Application x your
preferred video application? Yes/No"). An application can query the
API to see if it is already preferred. If so, no change is
required.
Example 22
Exemplary Advantages
[0122] As described herein, users can easily take advantage of
their device's capabilities without having to learn new processes
or even initially be aware that such capabilities exist.
Example 23
Exemplary Computing Systems
[0123] FIG. 10 illustrates a generalized example of a suitable
computing system or environment 1000 in which several of the
described innovations may be implemented. The computing system 1000
is not intended to suggest any limitation as to scope of use or
functionality, as the innovations may be implemented in diverse
general-purpose or special-purpose computing systems. A
communication device as described herein can take the form of the
described computing system 1000.
[0124] With reference to FIG. 10, the computing system 1000
includes one or more processing units 1010, 1015 and memory 1020,
1025. In FIG. 10, this basic configuration 1030 is included within
a dashed 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 multi-processing system, multiple processing units
execute computer-executable instructions to increase processing
power. For example, FIG. 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 (e.g., registers,
cache, RAM), nonvolatile memory (e.g., ROM, EEPROM, flash memory,
etc.), or some combination of the two, accessible by the processing
unit(s). The memory 1020, 1025 stores software 1080 implementing
one or more innovations described herein, in the form of
computer-executable instructions suitable for execution by the
processing unit(s).
[0125] A computing system may have additional features. For
example, the computing 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 bus, controller, or network
interconnects the components of the computing system 1000.
Typically, operating system software (not shown) provides an
operating environment for other software executing in the computing
system 1000, and coordinates activities of the components of the
computing system 1000.
[0126] The tangible storage 1040 may be removable or non-removable,
and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs,
DVDs, or any other medium which can be used to store information in
a non-transitory way and which can be accessed within the computing
system 1000. The storage 1040 stores instructions for the software
1080 implementing one or more innovations described herein.
[0127] The input device(s) 1050 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 1000. For video encoding, 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
that reads video samples into the computing system 1000. The output
device(s) 1060 may be a display, printer, speaker, CD-writer, or
another device that provides output from the computing system
1000.
[0128] The communication connection(s) 1070 enable communication
over a communication medium to another computing entity. 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, communication media can use an
electrical, optical, RF, or other carrier.
[0129] The innovations can be described in the general context of
computer-readable media. Computer-readable media are any available
tangible media that can be accessed within a computing environment.
By way of example, and not limitation, with the computing system
1000, computer-readable media include memory 1020, 1025, storage
1040, and combinations of any of the above.
[0130] The innovations can be described in the general context of
computer-executable instructions, such as those included in program
modules, being executed in a computing system on a target real or
virtual processor (e.g., 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 may be combined or split
between program modules as desired in various embodiments.
Computer-executable instructions for program modules may be
executed within a local or distributed computing system.
[0131] The terms "system" and "device" are used interchangeably
herein. Unless the context clearly indicates otherwise, neither
term implies any limitation on a 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 implementing the functionality described herein.
[0132] For the sake of presentation, the detailed description uses
terms like "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
acts performed by a human being. The actual computer operations
corresponding to these terms vary depending on implementation.
Example 24
Exemplary Mobile Device
[0133] In any of the examples herein, a communication device can
take the form of a mobile device. FIG. 11 is a system diagram
depicting an exemplary mobile device 1100 including a variety of
optional hardware and software components, shown generally at 1102.
Any components 1102 in the mobile device can communicate with any
other component, although not all connections are shown, for ease
of illustration. The mobile device can be any of a variety of
computing devices (e.g., cell phone, smartphone, handheld computer,
Personal Digital Assistant (PDA), etc.) and can allow wireless
two-way communications with one or more mobile communications
networks 1104, such as a cellular, satellite, or other network.
Voice over IP scenarios (e.g., over WiFi or other network) can also
be supported. The communication devices described herein can take
the form of the described mobile device 1100.
[0134] The illustrated mobile device 1100 can include a controller
or processor 1110 (e.g., signal processor, microprocessor, ASIC, or
other control and processing logic circuitry) for performing such
tasks as signal coding, data processing, input/output processing,
power control, and/or other functions. An operating system 1112 can
control the allocation and usage of the components 1102 and support
for one or more application programs 1114. The application programs
1114 can include common mobile computing applications (e.g., email
applications, calendars, contact managers, web browsers, messaging
applications), or any other computing application. Functionality
1113 for accessing an application store can also be used for
acquiring and updating applications 1114.
[0135] The illustrated mobile device 1100 can include memory 1120.
Memory 1120 can include non-removable memory 1122 and/or removable
memory 1124. The non-removable memory 1122 can include RAM, ROM,
flash memory, a hard disk, or other well-known memory storage
technologies. The removable memory 1124 can 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." The memory 1120 can be used
for storing data and/or code for running the operating system 1112
and the applications 1114. Example data can include web pages,
text, images, sound files, video data, or other data sets to be
sent to and/or received from one or more network servers or other
devices via one or more wired or wireless networks. The memory 1120
can be used to store a subscriber identifier, such as an
International Mobile Subscriber Identity (IMSI), and an equipment
identifier, such as an International Mobile Equipment Identifier
(IMEI). Such identifiers can be transmitted to a network server to
identify users and equipment.
[0136] 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 trackball 1140 and one or more output
devices 1150, such as a speaker 1152 and a display 1154. Other
possible output devices (not shown) can include piezoelectric or
other haptic output devices. Some devices can serve more than one
input/output function. For example, touchscreen 1132 and display
1154 can be combined in a single input/output device.
[0137] A wireless modem 1160 can be coupled to an antenna (not
shown) and can support two-way communications between the processor
1110 and external devices, as is well understood in the art. The
modem 1160 is shown generically and can include a cellular modem
for communicating with the mobile communication network 1104 and/or
other radio-based modems (e.g., Bluetooth 1164 or Wi-Fi 1162). The
wireless modem 1160 is typically configured for communication with
one or more cellular networks, such as a GSM or CDMA network for
data and voice communications within a single cellular network,
between cellular networks, or between the mobile device and a
public switched telephone network (PSTN).
[0138] The mobile device 1100 can further 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 (FireWire) port, and/or RS-232
port. The illustrated components 1102 are not required or
all-inclusive, as any components can be deleted and other
components can be added.
Example 25
Exemplary Cloud-Supported Environment
[0139] In example environment 1200 of FIG. 12, the cloud 1210
provides services for connected devices 1230, 1240, 1250 with a
variety of screen capabilities. Connected device 1230 represents a
device with a computer screen 1235 (e.g., a mid-size screen). For
example, connected device 1230 could be a personal computer such as
desktop computer, laptop, notebook, netbook, or the like. Connected
device 1240 represents a device with a mobile device screen 1245
(e.g., a small size screen). For example, connected device 1240
could be a mobile phone, smart phone, personal digital assistant,
tablet computer, and the like. Connected device 1250 represents a
device with a large screen 1255. For example, connected device 1250
could be a television screen (e.g., a smart television) or another
device connected to a television (e.g., a set-top box or gaming
console) or the like. One or more of the connected devices 1230,
1240, 1250 can include touch screen capabilities. Touchscreens can
accept input in different ways. For example, capacitive
touchscreens detect touch input when an object (e.g., a fingertip
or stylus) distorts or interrupts an electrical current running
across the surface. As another example, touchscreens can use
optical sensors to detect touch input when beams from the optical
sensors are interrupted. Physical contact with the surface of the
screen is not necessary for input to be detected by some
touchscreens. Devices without screen capabilities also can be used
in example environment 1200. For example, the cloud 1210 can
provide services for one or more computers (e.g., server computers)
without displays.
[0140] Services can be provided by the cloud 1210 through service
providers 1220, or through other providers of online services (not
depicted). For example, cloud services can be customized to the
screen size, display capability, and/or touch screen capability of
a particular connected device (e.g., connected devices 1230, 1240,
1250).
[0141] In example 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 various cloud-based services.
The service providers 1220 can manage service subscriptions for
users and/or devices (e.g., for the connected devices 1230, 1240,
1250 and/or their respective users).
Example 26
Exemplary Implementations
[0142] Although the operations of some of the disclosed methods are
described in a particular, sequential order for convenient
presentation, it should be understood that this manner of
description encompasses rearrangement, unless a particular ordering
is required by specific language set forth below. For example,
operations described sequentially may in some cases be rearranged
or performed concurrently. Moreover, for the sake of simplicity,
the attached figures may not show the various ways in which the
disclosed methods can be used in conjunction with other
methods.
[0143] Any of the disclosed methods can be implemented as
computer-executable instructions stored on one or more
computer-readable storage media (e.g., non-transitory
computer-readable media, such as one or more optical media discs,
volatile memory components (such as DRAM or SRAM), or nonvolatile
memory components (such as hard drives)) and executed on a computer
(e.g., any commercially available computer, including smart phones
or other mobile devices that include computing hardware). Any of
the computer-executable instructions for implementing the disclosed
techniques as well as any data created and used during
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 part of, for example, a dedicated software application or 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 (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) using
one or more network computers.
[0144] For clarity, only certain selected aspects of the
software-based implementations are described. Other details that
are well known in the art are omitted. For example, it should be
understood that the disclosed technology is not limited to any
specific computer language or program. For instance, the disclosed
technology can be implemented by software written in C++, Java,
Perl, JavaScript, Adobe Flash, or any other suitable programming
language. Likewise, the disclosed 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 set
forth in detail in this disclosure.
[0145] Furthermore, any of the software-based embodiments
(comprising, for example, computer-executable instructions for
causing a computer to perform any of the disclosed methods) can be
uploaded, downloaded, or remotely accessed through a suitable
communication means. Such suitable communication means include, for
example, the Internet, the World Wide Web, an intranet, software
applications, cable (including fiber optic cable), magnetic
communications, electromagnetic communications (including RF,
microwave, and infrared communications), electronic communications,
or other such communication means.
[0146] The disclosed methods, apparatus, and systems should not be
construed as limiting in any way. Instead, the present disclosure
is directed toward all novel and nonobvious features and aspects of
the various disclosed embodiments, alone and in various
combinations and sub-combinations with one another. The disclosed
methods, apparatus, and systems are not limited to any specific
aspect or feature or combination thereof, nor do the disclosed
embodiments require that any one or more specific advantages be
present or problems be solved.
Non-Transitory Computer-Readable Media
[0147] Any of the computer-readable media herein can be
non-transitory (e.g., memory, magnetic storage, optical storage, or
the like).
Storing in Computer-Readable Media
[0148] Any of the storing actions described herein can be
implemented by storing in one or more computer-readable media
(e.g., computer-readable storage media or other tangible
media).
[0149] Any of the things described as stored can be stored in one
or more computer-readable media (e.g., computer-readable storage
media or other tangible media).
Methods in Computer-Readable Media
[0150] 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 technologies described herein can be
implemented in a variety of programming languages.
Methods in Computer-Readable Storage Devices
[0151] Any of the methods described herein can be implemented by
computer-executable instructions stored in one or more
computer-readable storage devices (e.g., memory, magnetic storage,
optical storage, or the like). Such instructions can cause a
computer to perform the method.
Exemplary Combinations
[0152] Various combinations can be supported. For example, the
incoming call user interface can be combined with the
call-in-progress user interface (e.g., after the incoming call is
accepted). The call-in-progress user interface can be combined with
the background call-in-progress user interface (e.g., if the call
moves to the background).
[0153] The call-in-progress user interface can be combined with the
home user interface (e.g., if navigation occurs to the home user
interface during a call). In such a case, the background
call-in-progress user interface can also be displayed.
[0154] The user interface for initiating communications can be
combined with any of the other user interfaces as well.
Alternatives
[0155] The technologies from any example can be combined with the
technologies described in any one or more of the other examples.
Where the word "exemplary" is used, it is intended to indicate an
example and not an ideal embodiment. In view of the many possible
embodiments to which the principles of the disclosed technology may
be applied, it should be recognized that the illustrated
embodiments are examples of the disclosed technology and should not
be taken as a limitation on the scope of the disclosed technology.
Rather, the scope of the disclosed technology includes what is
covered by the following claims. We therefore claim as our
invention all that comes within the scope and spirit of the
claims.
* * * * *