U.S. patent application number 17/372464 was filed with the patent office on 2021-10-28 for telecommunications call augmentation system.
This patent application is currently assigned to Incall Limited. The applicant listed for this patent is Incall Limited. Invention is credited to Chaim Aaron James GREEN, Joshua NYMAN.
Application Number | 20210334856 17/372464 |
Document ID | / |
Family ID | 1000005708731 |
Filed Date | 2021-10-28 |
United States Patent
Application |
20210334856 |
Kind Code |
A1 |
GREEN; Chaim Aaron James ;
et al. |
October 28, 2021 |
TELECOMMUNICATIONS CALL AUGMENTATION SYSTEM
Abstract
A method of augmenting a telecommunications call, the method
comprising: detecting a telecommunications call event at a user
telecommunications device; selecting an item of media content, the
item of media content being associated with the calling party;
augmenting the call with the item of media content; detecting a
user interaction with the device in response to the item of media
content; and transmitting information relating to the user
interaction to the calling party.
Inventors: |
GREEN; Chaim Aaron James;
(London, GB) ; NYMAN; Joshua; (London,
GB) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Incall Limited |
London |
|
GB |
|
|
Assignee: |
Incall Limited
London
GB
|
Family ID: |
1000005708731 |
Appl. No.: |
17/372464 |
Filed: |
July 11, 2021 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15528525 |
May 22, 2017 |
|
|
|
PCT/GB2015/053550 |
Nov 20, 2015 |
|
|
|
17372464 |
|
|
|
|
PCT/GB2014/053455 |
Nov 21, 2014 |
|
|
|
15528525 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04M 3/42042 20130101;
H04M 3/42102 20130101; H04M 7/0036 20130101; G06Q 30/0277 20130101;
H04L 67/22 20130101; H04M 3/42059 20130101; H04M 2203/2011
20130101; H04M 2203/353 20130101; H04M 3/4878 20130101; G06Q
30/0255 20130101; G06Q 30/0267 20130101 |
International
Class: |
G06Q 30/02 20120101
G06Q030/02; H04M 3/42 20060101 H04M003/42; H04L 29/08 20060101
H04L029/08; H04M 3/487 20060101 H04M003/487; H04M 7/00 20060101
H04M007/00 |
Foreign Application Data
Date |
Code |
Application Number |
May 6, 2015 |
GB |
1507768.8 |
May 20, 2015 |
GB |
1508682.0 |
Claims
1. A method of augmenting a telecommunications call, the method
comprising: detecting a telecommunications call event at a user
telecommunications device; selecting an item of media content, the
item of media content being associated with the calling party;
augmenting the call with the item of media content; detecting a
user interaction with the device in response to the item of media
content; and transmitting information relating to the user
interaction to the calling party.
2. A method according to claim 1, further comprising retrieving the
item of media content from a local cache on the device.
3. A method according to claim 2, wherein the item of media content
has previously been provided by the calling party to the local
cache on the device.
4. A method according to any preceding claim, wherein the item of
media content is retrieved or downloaded from a remote server, for
example by an application on the user device.
5. A method according to claim 4, wherein the application is
provided by or otherwise associated with the calling party.
6. A method according to claim 4 or 5, wherein the downloading of
the item of media content is integrated with an update of the
application.
7. A method according to any of claims 4 to 6, wherein the
downloading of the item of media content occurs periodically.
8. A method according to any of claims 4 to 7, wherein the
downloading of the item of media content occurs in response to a
user interaction with the calling party.
9. A method according to any of claims 4 to 8, wherein the
downloading of the item of media content is dependent on the user
granting permission via interacting with an item of media content
present on the device.
10. A method according to any of claims 4 to 9, further comprising
prompting the device to download the item of media content from the
remote server via a signal received from a remote server and/or by
the telecommunications call event.
11. A method according to any preceding claim, wherein the item of
media content is associated with a user profile, preferably the
profile being dependent on one or more of: network operator/tariff,
device model, other applications on device, call/text frequency,
data usage, volume of changes of location, battery size, and number
of contacts.
12. A method according to any preceding claim, wherein the item of
media content is associated with an expiry date and/or time beyond
which it is no longer presented to the user.
13. A method according to any preceding claim, wherein the item of
media content is provided as a payload part of the
telecommunications call.
14. A method according to any of claims 1 to 12, wherein the item
of media content is provided via a different communications channel
than that used for the provision of the telecommunications
call.
15. A method according to claim 14, wherein the telecommunications
call is provided via a voice channel, the media content via a data
channel.
16. A method according to claim 14 or 15, wherein the item of media
content is downloaded via a higher speed channel or network than
that used for the telecommunications call.
17. A method according to any of claims 2 to 16, further comprising
receiving at the user device a signal enquiring about the presence
of items of media content, preferably a specific media content
item, in the local cache.
18. A method according to claim 17, further comprising the device
signalling that items of media content have, preferably that the
specific item of media content has, been downloaded to the device
cache and/or that the items are or item is available for use in
augmenting the telecommunications call.
19. A method according to any of claims 2 to 18, further
comprising, if a specific item of media content is not available,
selecting another, preferably related, item of media content from
the device cache with which to augment the telecommunications
call.
20. A method according to any preceding claim, further comprising
prioritising the presentation of the item of media content to the
user ahead of other media items.
21. A method according to claim 20, wherein the prioritising is
based on a list of qualifying contact details, preferably provided
to and/or stored on the user device.
22. A method according to any preceding claim, further comprising
prioritising the handling of an incoming telecommunications call by
an application on the user device which supports the method of
telecommunications call augmentation.
23. A method according to claim 22, wherein the prioritising
between applications is in dependence on the time of last use of
the applications.
24. A method according to any preceding claim, wherein the item of
media content is presented on the incoming call screen.
25. A method according to any preceding claim, wherein the item of
media content comprises an indicator or identifier allowing the
user to identify the calling party.
26. A method according to claim 25, wherein the indicator is a
trade mark.
27. A method according to any preceding claim, wherein the item of
media content comprises at least one of: audio, preferably in the
form of a ringtone, and/or a visual item, preferably text or an
image.
28. A method according to any preceding claim, wherein the item of
media content indicates a planned call subject, topic or
content.
29. A method according to any preceding claim, wherein the item of
media content indicates information relating to a user account,
order or event, preferably one with the calling party.
30. A method according to any preceding claim, wherein the item of
media content is selected from a plurality of available items
relating to the calling party.
31. A method according to claim 30, wherein the item of media
content is selected based on at least one of: time, user or device
location, user characteristics, previous user interactions.
32. A method according to claim 31, wherein the item of media
content is selected in dependence on a schedule, preferably
downloaded to the user device.
33. A method according to claim 32, wherein the order of items in
the schedule may be changed remotely, preferably by means of a
signal received by the user device.
34. A method according to any preceding claim, wherein the item of
media content indicates a menu of options, preferably comprising at
least two items.
35. A method according to any preceding claim, wherein the user
interaction comprises at least one of: a touch, a press, a swipe,
voice or other body action or movement, optionally the method
further comprising displaying a message to the user in dependence
on the interaction.
36. A method according to any preceding claim, wherein the
information transmitted relating to the user interaction comprises
one or more of: a selection from the menu of options, navigation of
an IVR system, the expression of an interest, mood, a preference, a
vote or an instruction.
37. A method according to claim 36, further comprising in response
to the user interaction presenting a further item of media content
to the user, optionally detecting a further user interaction and
preferably transmitting information relating to the further user
interaction to the calling party.
38. A method according to claim 36 or 37, wherein the instruction
comprises the user scheduling or re-scheduling of an event,
preferably via a selection from a menu of alternative dates and/or
times, interacting with a media content item representation of a
clock and/or calendar, swiping of a slider.
39. A method according to claim 38, wherein the interaction
comprises the user selecting an amount, preferably via one of: a
selecting from a menu of alternative amounts, swiping of a
slider.
40. A method according to any of claims 36 to 39, wherein the
instruction comprises a request for one or more of: a postponement
(for example, specifying a delay for a later call-back), use of or
switch to an alternative means of communication (for example, text
chat rather than voice call), that the calling party desist.
41. A method according to claim 40, wherein the instruction further
comprises scheduling the user device to initiate contact with the
calling party at a future time.
42. A method according to claim 41, further comprising presenting
the user with a related item of media content ahead of the contact
with the calling party being initiated.
43. A method according to any preceding claim, further comprising
exchanging electronic files between the user and the calling
party.
44. A method according to any preceding claim, further comprising
reporting to the calling party whether the telecommunications call
was augmented with the item of media content, preferably
determining and reporting to the calling party whether the user's
behaviour was altered in response to the item of media content.
45. A method according to any preceding claim, wherein the calling
party comprises a second user with a second user device.
46. A method according to claim 45, wherein one or other user may
select from a plurality of options, preferably information
regarding the selection being transmitted to the other user, and/or
edit the items of media content used to augment the
telecommunications call to the other user.
47. A method according to claim 45 or 46, wherein one or other user
may select from a plurality of options and/or edit the actions
resulting from interaction of the other user with the item of media
content used to augment the call.
48. A method according to any preceding claim, further comprising
alternatively or in addition augmenting the telecommunications call
with an item of media content mid-call.
49. A method according to any preceding claim, further comprising
the user receiving a request from the calling party to consider,
and preferably to interact with, an item of media content
augmenting the telecommunications call.
50. A method according to any preceding claim, wherein the item of
media content is one or more of: an image or video for tutorial
purposes, a secure password, a live video or text feed.
51. A method according to any preceding claim, wherein the item of
media content presents the user with the option to share content on
social media, open a chat window, or complete a survey.
52. A method according to any preceding claim, further comprising
alternatively or in addition presenting the item of media content
to the user on a call waiting screen, when the user is already
engaged on a telecommunications call with another party.
53. A method according to any preceding claim, further comprising,
on termination of the call, performing an action in dependence on a
uniform resource identifier or URI associated with the item of
media content.
54. A method according to any preceding claim, further comprising
transmitting information relating to the user interaction also or
alternatively to a party other than the calling party.
55. A method of augmenting a telecommunications call placed to a
user telecommunications device, the method comprising: selecting an
item of media content, the item of media content being associated
with the calling party; augmenting the call with the item of media
content; and determining and reporting to the calling party whether
the user's behaviour was altered in response to the item of media
content.
56. A method of augmenting a telecommunications call received from
a user telecommunications device, the method comprising: selecting
an item of media content, the item of media content being
associated with the calling party and relating to a plurality of
menu items; augmenting the call with the item of media content;
detecting a user interaction with the device in response to the
item of media content, corresponding to the user selection of a
menu item; and transmitting information relating to the user
interaction to the calling party.
57. A method substantially as herein described and/or as
illustrated with reference to the accompanying figures.
58. Apparatus for carrying out the method of any preceding
claim.
59. Apparatus for augmenting a telecommunications call, comprising:
a detecting module for detecting a telecommunications call event at
a user telecommunications device; a selecting module for selecting
an item of media content, the item of media content being
associated with the calling party; an augmenting module for
augmenting the call with the item of media content; a module for
detecting a user interaction with the device in response to the
item of media content; and a module for transmitting information
relating to the user interaction to the calling party.
60. Apparatus substantially as herein described and/or as
illustrated with reference to the accompanying figures.
61. A system for augmenting a telecommunications call, the system
comprising: a media server, for storing items of media content; a
calling device, for placing telecommunications calls to a client or
user device; optionally, a client or user device; wherein the
system is adapted to carry out the method of any of claims 1 to
55.
62. A system substantially as herein described and/or as
illustrated with reference to the accompanying figures.
63. A computer program product comprising software code for
carrying out the method of any of claims 1 to 57.
64. A client or user device in the form of a telecommunications
device or handset such as a smartphone or tablet adapted to execute
the computer program product of claim 63.
Description
RELATED APPLICATIONS
[0001] This application is continuation of U.S. patent application
Ser. No. 15/528,525 filed on May 22, 2017, which is a National
Phase of PCT Patent Application No. PCT/GB2015/053550 having
International Filing Date of Nov. 20, 2015, which claims the
benefit of priority of United Kingdom Patent Applications Nos.
1507768.8 filed on May 6, 2015 and 1508682.0 filed on May 20,
2015.
[0002] PCT Patent Application No. PCT/GB2015/053550 is also a
Continuation in Part (CIP) of PCT/GB2014/053455 filed on Nov. 21,
2014.
[0003] The contents of the above applications are all incorporated
by reference as if fully set forth herein in their entirety.
FIELD AND BACKGROUND OF THE INVENTION
[0004] This invention relates to a telecommunications call
augmentation system and in particular to a method of and apparatus
for augmenting a call with media content. The invention has
particular relevance to providing a user of a telephone, especially
of a mobile telephone or cellphone, such as a smartphone, with
targeted media content in a noticeable yet unobtrusive fashion.
Various embodiments are described wherein an initial item of media
content is used as a trigger or advertisement which when activated
by the user presents further media content.
[0005] Modern telephones have become increasingly sophisticated and
many are able to present or play a wide variety of forms of media
content to their users. This is especially the case with those
mobile telephones or cellphones known as `smartphones`, which are
effectively portable computers with telephone functionality and
often internet connectivity.
[0006] Various attempts have been made to make use of this media
playing ability of smartphones in order to present the user with
pertinent information--for example, service alerts and
advertisements--at times other than those at which the user is
specifically seeking them out. A particular challenge is to make
such alerts noticeable to the user yet not overtly obtrusive. The
present invention aims to address at least some of these
problems.
SUMMARY OF THE INVENTION
[0007] Generally, there is provided a method of augmenting a
telecommunications call with media content, preferably the media
content being dependent on an attribute of the called or calling
party, more preferably the media content enabling the called or
calling party to access further related media content or
services.
[0008] According to an aspect of the invention there is provided a
method of augmenting a telecommunications call, the method
comprising: detecting a telecommunications call event at a user
telecommunications device; selecting an item of media content, the
item of media content being associated with the calling party;
augmenting the call with the item of media content; detecting a
user interaction with the device in response to the item of media
content; and optionally transmitting information relating to the
user interaction to the calling party.
[0009] Preferably, the item of media content may be retrieved from
a local cache on the device. The item of media content may have
previously been provided by the calling party to the local cache on
the device. The media content may have previously been retrieved or
downloaded from a remote server, for example by an application on
the user device. The application may be provided by or otherwise
associated with the calling party. The downloading of the item of
media content may be integrated with an update of the application.
The application may periodically download media content items for
use in augmenting telecommunications calls.
[0010] Alternatively, or in addition, the downloading of the item
of media content may occur in response to a user interaction with
the calling party. The downloading of the item of media content may
be dependent on the user granting permission via interacting with
an item of media content present on the device.
[0011] Alternatively, or in addition, the device may be prompted by
the telecommunications call event to download the item of media
content from the remote server via a signal received from a remote
server and/or by the telecommunications call event.
[0012] Preferably, the item of media content may be associated with
a user profile, where the profile may be dependent on one or more
of: network operator/tariff, device model, other applications on
device, call/text frequency, data usage, volume of changes of
location, battery size, and number of contacts.
[0013] Preferably, the item of media content may be associated with
an expiry date and/or time beyond which it is no longer presented
to the user.
[0014] In some embodiments, the media content is provided as a
payload part of the telecommunications call. Alternatively, or in
addition, the media content may be provided via a different
communications channel than that used for the provision of the
telecommunications call. For example, the telecommunications call
may be provided via a voice channel, the media content via a data
channel. The item of media content may be downloaded via a higher
speed channel or network than that used for the telecommunications
call.
[0015] The method may further comprise receiving at the user device
a signal enquiring about the presence of items of media content,
preferably a specific media content item, in the local cache. The
method may then further comprise the device signalling that items
of media content have, preferably that the specific item of media
content has, been downloaded to the device cache and/or that the
items are or item is available for use in augmenting the
telecommunications call. If a specific item of media content is not
available, another, preferably related, item of media content may
be selected from the device cache with which to augment the
telecommunications call.
[0016] Preferably, the method may further comprise prioritising the
presentation of the item of media content to the user ahead of
other media items. The prioritising may be based on a list of
qualifying contact details, preferably provided to and/or stored on
the user device. The method may further comprise prioritising the
handling of an incoming telecommunications call by an application
on the user device which supports the method of telecommunications
call augmentation. The prioritising between applications may be in
dependence on the time of last use of the applications.
[0017] Preferably, the item of media content may be presented on
the incoming call screen. The item of media content may present the
user with an indicator or identifier allowing the user to identify
the calling party. The indicator may be a trade mark.
[0018] The item of media content may comprise at least one of:
audio, preferably in the form of a ringtone, and/or a visual item,
preferably text or an image.
[0019] The item of media content may indicate planned call subject,
topic or content. Alternatively, or in addition, the item of media
content may indicate information relating to a user account, order
or event, preferably one with the calling party.
[0020] The item of media content may be selected from a plurality
of available items relating to the calling party. The selection may
be based on time, user or device location, user characteristics,
and/or previous user interactions. The item of media content may be
selected in dependence on a schedule, preferably downloaded to the
user device. The order of items in the schedule may be changed
remotely, preferably by means of a signal received by the user
device.
[0021] The item of media content may present the user with a menu
of options; preferably, the menu of options comprises at least two
items.
[0022] The user interaction may comprise a touch, such as a press
or a swipe (for example of a media image, such as a button,
displayed on the screen of the device), by voice or other bodily
movement, optionally the method may further comprise displaying a
message to the user in dependence on the interaction.
[0023] The information transmitted relating to the user interaction
may comprise one or more of: a selection from the menu of options,
navigation of an IVR system, the expression of an interest, mood, a
preference, a vote or an instruction. A further item of media
content may be presented to the user in response to the user
interaction. Optionally, a further user interaction may be detected
and information relating to the further user interaction may be
preferably transmitted to the calling party.
[0024] The instruction may comprise the user scheduling or
re-scheduling an event, for example via a selection from a menu of
alternative dates and/or times, interacting with a media content
item representation of a clock and/or calendar, or swiping of a
slider. The instruction may comprise selecting an amount, for
example via a selecting from a menu of alternative amounts, or
swiping of a slider. The instruction may comprise a request such as
for a postponement (say specifying a delay for a later call-back),
the use of or switch to an alternative means of communication (for
example, text chat rather than voice call), or that the calling
party desist. The instruction may further comprise scheduling the
user device to initiate contact with the calling party at a future
time. The user may, for example, be presented with a related item
of media content ahead of the contact with the calling party being
initiated.
[0025] Electronic files may be transmitted between the user and the
calling party.
[0026] Preferably, the method may further comprise reporting to the
calling party whether the telecommunications call was augmented
with the item of media content, more preferably determining and
reporting to the calling party whether the user's behaviour was
altered in response to the item of media content.
[0027] The calling party may comprise a second user with a second
user device. One or other user may select from a plurality of
options, preferably information regarding the selection or option
selected being transmitted to the other user, and/or edit the items
of media content used to augment the telecommunications call to the
other user.
[0028] Preferably, the calling party may provide information, such
as an indication of the subject of the call, by way of text or an
image (for example an emoticon), ahead of the call. The calling
party may communicate a message, for example as a notification, say
a push notification, in parallel with placing a call, preferably
relating to the reason for calling
[0029] Alternatively, or in addition, one or other user may select
from a plurality of options and/or edit the actions resulting from
interaction of the other user with the item of media content used
to augment the call.
[0030] Alternatively, or in addition, the telecommunications call
may be augmented with an item of media content mid-call.
[0031] The user may receive a request from the calling party to
consider, and preferably to interact with, an item of media content
augmenting the telecommunications call.
[0032] The item of media content may be one or more of: an image or
video for tutorial purposes, a secure password, a live video or
text feed. The item of media content may present the user with the
option to share content on social media, open a chat window, or
complete a survey.
[0033] Alternatively, or in addition, the item of media content may
be presented to the user on a call waiting screen, when the user is
already engaged on a telecommunications call with another
party.
[0034] On termination of the call, an action may be performed in
dependence on a uniform resource identifier or URI associated with
the item of media content.
[0035] Information relating to the user interaction may also or
alternatively be transmitted to a party other than the calling
party.
[0036] According to another aspect of the invention there is
provided a method of augmenting a telecommunications call placed to
a user telecommunications device, the method comprising: selecting
an item of media content, the item of media content being
associated with the calling party; augmenting the call with the
item of media content; and determining and reporting to the calling
party whether the user's behaviour was altered in response to the
item of media content.
[0037] According to another aspect of the invention there is
provided method of augmenting a telecommunications call received
from a user telecommunications device, the method comprising:
selecting an item of media content, the item of media content being
associated with the calling party and relating to a plurality of
menu items; augmenting the call with the item of media content;
detecting a user interaction with the device in response to the
item of media content, corresponding to the user selection of a
menu item; and transmitting information relating to the user
interaction to the calling party.
[0038] According to another aspect of the invention there is
provided apparatus for augmenting a telecommunications call,
comprising: a detecting module for detecting a telecommunications
call event at a user telecommunications device; a selecting module
for selecting an item of media content, the item of media content
being associated with the calling party; an augmenting module for
augmenting the call with the item of media content; a module for
detecting a user interaction with the device in response to the
item of media content; and a module for transmitting information
relating to the user interaction to the calling party.
[0039] According to another aspect of the invention there is
provided a system for augmenting a telecommunications call, the
system comprising: a media server, for storing items of media
content; a calling device, for placing telecommunications calls to
a client or user device; optionally, a client or user device;
wherein the system is adapted to carry out any method as
described.
[0040] According to another aspect of the invention there is
provided a method of augmenting a telecommunications call, the
method comprising: detecting a telecommunications call event at a
user telecommunications device; selecting an item of media content,
the item of media content being associated with the calling party;
augmenting the call with the item of media content; the item of
media content previously having been provided by the calling party
to a local cache on the device. Preferably, the item of media
content is downloaded to the user device via an application on the
user device. The application may be provided by or otherwise
associated with the calling party.
[0041] Generally, the invention provides for a user of a
telecommunications device to be primed for a telecommunications
call via the initial provision of information by--or preferably the
exchange of information with--the calling party before the call is
answered.
[0042] In some embodiments, there is provided (incoming call)
screen communications to allow customers or users to communicate
their preferences to calling parties with the touch of a button,
preferably via or prompted by the media content item. This could be
call back preferences or smartphone preferences.
[0043] With the advent of this technology `Smart Warm Calling` will
change the communication dynamic between service providers and
their customers.
[0044] According to another aspect of the invention, there is
provided a method of augmenting a telecommunications call, the
method comprising: detecting a telecommunications call event at a
user telecommunications device; selecting an item of media content,
the item of media content being associated with a uniform resource
identifier or URI; augmenting the call with the item of media
content; detecting a user interaction with the item of media
content; and on termination of the call, performing an action in
dependence on the resource identified by the URI.
[0045] Augmenting the call in this way may allow for a selected
media content item to be presented to a user of a
telecommunications device in a noticeable yet unobtrusive fashion
(and without distracting the user while the call is in progress).
This may be particularly useful for presenting public notices and
alerts, including advertising.
[0046] Preferably, the selection of the item of media content is in
dependence on an attribute of the call. The selection of the item
of media content may be in dependence on an attribute of the user
device and/or an attribute of the user, such as the user's browsing
history, call history, and text message data, an associated
identity, an associated location and/or an associated date and/or
time.
[0047] Preferably, the selection of the item of media content is in
dependence on an attribute of a party placing the call.
[0048] Preferably, the selection of the item of media content is in
dependence on an attribute of a party receiving the call.
[0049] Preferably, the item of media content comprises an image or
video, and augmenting the call comprises displaying the media
content to the user, preferably overlaid on a call screen of the
device.
[0050] Preferably, the item of media content comprises audio, and
augmenting the call comprises playing the media content to the
user.
[0051] Preferably, the method further comprises receiving the item
of media content from a remote server. Receiving the item of media
content may occur before an incoming call is received or an
outgoing call is made; presentation of the media content to the
user may occur before, during or after the incoming call is
received or the outgoing call is made.
[0052] Thus, in one example, the media content is presented to the
user during call initiation or set up, that is, at the time of an
incoming call alert, or while the user is waiting for a placed
outgoing call to be picked up. In a further example, the media
content is presented to the user after termination of a call
(incoming or outgoing). Furthermore, the media content might be
presented to the user multiple times during the placement or
reception of a call and/or the media content might be split up so
that, for example, part of the media content is presented while a
call is being initiated, and a further portion of the media content
is presented after termination of the call.
[0053] Preferably, the selection of the item of media content is
performed at a remote server.
[0054] Preferably, the method further comprises storing the item of
media content in a local cache on the user device. This may reduce
the time required for the media content to be first displayed by
the device.
[0055] This and other aspects of the invention may also comprise
one or more of the following:
[0056] The item of media content may be stored in the address book
or contacts application or other database on the user device. This
may allow implementation of the invention in restrictive operating
systems, for example where direct control by third parties of the
incoming call screen is not otherwise permitted.
[0057] The item of media content may be a contact profile or image,
potentially applied to an existing contact for which no image is
present. This may be pre-loaded in advance of the call or in some
embodiments the information may be provided and the contacts
updated in real-time.
[0058] The item of media content may comprise an operating system
or app notification, preferably an interactive notification
allowing the user to respond before, during or after--or instead
of--taking the incoming call. The user response may be via a
messaging system, such as SMS.
[0059] The item of media content may be a combination of a
notification, preferably a push notification, and a media item or
contact information stored locally on the device. Preferably, the
notification is synced with the incoming call. Embodiments may make
use of phone or device internal diagnostics and/or the network
signal, preferably to mitigate for signal and/or hardware
delays.
[0060] The app and/or user device may be configured to report to
the calling or third party that it is in a good signal reception
area and has app notifications activated. Alternatively, this
information may be obtained in response to the device being polled
by the calling or third party in advance of a potential call.
[0061] Preferably, a determination is made as to whether the device
user is likely to be poised to receive a call. This determination
may be made according to data obtained from native device hardware
technologies--such as the smartphone accelerator, eyeball trackers
and/or camera(s). Alternatively, or in addition, contextual
information regarding user behaviour may be used.
[0062] Preferably, the user may set preferred times for when they
would be willing to accept a call or excluded times when they would
not be so willing.
[0063] Preferably, a determination is made whether and when to
place a call to the user in dependence on one or more of: signal
strength at the device, configuration of the device, amenability of
the user and user preference.
[0064] Preferably, a determination is made as to whether the user
has seen and their reaction to--and optionally determine whether
they benefited from--the call.
[0065] Preferably, a user incentive scheme is used, such as
detected interaction with the item of media content earning the
user points or prizes.
[0066] The call (event) may be an incoming or an outgoing call.
[0067] Preferably, the user interaction with the item of media
content is reported to a remote server.
[0068] Preferably, items of media content are provided to the
remote server by a media content provider.
[0069] Preferably, a selection of the item of media content is
performed at the user device.
[0070] Preferably, the action performed in dependence on the
resource identified by the URI comprises accessing a network
location, optionally accessing a web page.
[0071] Preferably, the action performed in dependence on the
resource identified by the URI comprises initiating a further
telecommunications call.
[0072] According to another aspect of the invention, there is
provided a computer program product comprising software code
adapted when executed to perform the methods as herein
described.
[0073] According to another aspect of the invention, there is
provided a software development kit, comprising software code for
performing any of the methods as herein described, and adapted to
be bundled together with a further software application, preferably
a "third-party" software application.
[0074] According to another aspect of the invention, there is
provided apparatus for performing any of the methods as herein
described.
[0075] According to a further aspect of the invention, there is
provided an apparatus for augmenting a telecommunications call, the
apparatus comprising: means for detecting a telecommunications call
event at a user telecommunications device; means for selecting an
item of media content, the item of media content being associated
with a uniform resource identifier or URI; means for augmenting the
call with the item of media content; means for detecting a user
interaction with the item of media content; and means for, on
termination of the call, performing an action in dependence on the
resource identified by the URI.
[0076] According to a further aspect of the invention, there is
provided a method of co-ordinating multiple instances of call
augmentation applications, apportioning advertising income
appropriately, preferably according to user interactions with
particular application instances.
[0077] Preferably, the or each call augmentation application is
bundled to, or forms part of, a further application.
[0078] Preferably, the call augmentation application is in the form
of a computer program product as herein described.
[0079] According to a further aspect of the invention, there is
provided a system for augmenting telecommunications calls, the
system comprising: apparatus as herein described at least in part
implemented in software code executable on a client device, the
client device preferably being in the form of a mobile
communications device, more preferably a smart phone; and a remote
server having stored thereon media content for augmenting
communications between the apparatus and at least one further
similar apparatus.
[0080] According to another aspect of the invention, there is
provided apparatus for augmenting a telecommunications call, the
apparatus comprising: a detecting module for detecting a
telecommunications call event at a user telecommunications device;
a selecting module for selecting an item of media content, the item
of media content being associated with a uniform resource
identifier or URI; an augmenting module for augmenting the call
with the item of media content; a module for detecting a user
interaction with the item of media content; and a module for
performing an action in dependence on the resource identified by
the URI.
[0081] Preferably, the apparatus is adapted to be implemented at
least in part in software code executable on a client device, the
client device preferably being in the form of a mobile
communications device, more preferably a smart phone.
[0082] The invention extends to methods, system and apparatus
substantially as herein described and/or as illustrated with
reference to the accompanying figures.
[0083] According to another aspect of the invention there is
provided a software development kit, comprising software code for
performing any of the methods described.
[0084] According to another aspect of the invention there is
provided apparatus for performing any of the methods described.
[0085] According to another aspect of the invention there is
provided a computer program product comprising software code for
performing or carrying out any of the methods described.
[0086] According to another aspect of the invention there is
provided a client or user device in the form of a
telecommunications device or handset such as a smartphone or tablet
adapted to execute the computer program product as described.
[0087] The present invention relates to providing advertising space
on the incoming call screen of a mobile phone.
[0088] Generally, there is provided a method of augmenting a
telecommunications call with media content on an incoming or
outgoing call screen of a mobile phone.
[0089] Embodiments of the present invention may comprise one or
more of the following features: [0090] 1. a method of persuading
mobile phone users to accept call screen advertising, in particular
in the form of a hyperlinked incoming call screen advertisement
[0091] 2. a method of displaying a media content item associated
with a telephone call in a way that does not interrupt the call,
preferably making use of screen "real-estate" which is otherwise
underused [0092] 3. a method for accessing a user's incoming call
screen for displaying media content, for example advertisements
[0093] 4. a method of providing user-friendly call screen
advertisements which can be linked to relevant information [0094]
5. a method of co-ordinating multiple instances of call
augmentation applications, preferably apportioning advertising
income appropriately (for example according to user interactions
with particular application instances) [0095] 6. enabling software
developers to bundle software for providing such call screen
advertising together with their ("free") software applications in
addition to--or instead of--facilitating advertising within their
software applications, and preferably enabling users to select
which form of advertising they would prefer.
[0096] The item of media content may be an advertisement selling at
least one product, promoting or providing information, or
displaying any other type of information for informing the
user.
[0097] Generally, in accordance with one broad aspect of the
invention there is provided a method of providing a media content
item such as an advertisement to a user of a mobile device, the
mobile device comprising at least a phone function and a screen,
the method comprising: providing a call screen display software
application to the phone of a user, wherein said application
comprises means for displaying media content on at least the
incoming call screen of said mobile device; selecting at least one
media content item such as an advertisement to be displayed on said
call screen; providing said media content item such as an
advertisement to said phone; and displaying said media content item
such as an advertisement on said call screen, preferably when a
call occurs between said user and a second party.
[0098] The second party may be the calling party.
[0099] A potential advantage of the present invention is that it
may provide a further opportunity for third parties such as
advertisers; that of the incoming call screen. A further potential
advantage is that it may provide a means of gaining access to the
user's call screen via a second software application. A still
further potential advantage is afforded by a delay feature which
enables hyperlinks within the media content items or advertisements
to be clicked without interrupting a call.
[0100] In this document, the user--or first party--refers to the
user of the smartphone or other communications device.
[0101] The second party is the party involved in the conversation
with the user. This may be a person such as an acquaintance, who
may be the caller or callee, or may be an automated call handling
system, answerphone, or any other party partaking in a call.
[0102] Preferably, the media content item provides information from
a third party other than the second party, that is, the third party
is neither the user nor the second party involved in the call. The
third party may, for example, be a vendor advertising their
products, or an authority providing public information such as news
or weather. The third party may alternatively be the provider of
the communications network used by the smartphone or other
communications device.
[0103] The media content item may be an entire page, a banner, and
may cover all or any part of the mobile device screen. Preferably
the media content item covers most of the screen, but leaves
uncovered the area of the screen in which the operating system of
the mobile device displays the caller ID.
[0104] The media content item may comprise at least one hyperlink
which links to a phone number of the third party. This hyperlink
may delay calling the phone number of the advertiser until the end
of the current phone call, and automatically call the phone number
at the end of the current call, or may display the number to be
dialled along with an option to dial it, when clicked and for the
duration of the original call, or only at the end of the original
call. Alternatively, the hyperlink may connect to a web site or
page.
[0105] References to media content item, image and coding are used
interchangeably.
[0106] The call-screen display software application may be a
software component installed on the mobile device, wherein said
application comprises means for displaying media content on at
least the incoming call screen of said mobile device.
[0107] The media content able to be displayed may be a wide variety
of media content such as pictures, videos, internet data and the
like.
[0108] Generally, the term uniform resource identifier or URI
refers to any means, such as a network or web address (eg. a URL)
or number (eg. an IP address), by which a resource, such as an item
of media content, may be located and/or identified. With reference
to a client device, a URI may direct to a location internal to the
client device (eg. to a local cache) or to an external location,
such as a server accessible over a network.
[0109] Software applications, especially in the context of mobile
phones or smartphones, may also be referred to herein as
"apps".
[0110] Preferably, the method when implemented as a mobile phone
application or `app` conforms to the guidelines or policies of the
network/operating system provider or app distributer, for example,
by conforming to requirements such as: [0111] making clear to the
user the association of the app with the media content [0112] not
impermissibly changing device function without user consent [0113]
if changes are made, making clear to the user which changes are due
to the app [0114] allowing the user to easily reverse any changes
via device and/or app preferences--or by uninstalling the app
[0115] not simulating system notifications or warnings [0116]
allowing the user to dismiss media content presented by the app
[0117] not interfering with third party media content
[0118] The software application may be used to display an item of
media content on the call screen of a mobile device when a call
occurs between the mobile device user and a second party. The call
screen is defined as the image or content displayed on the screen
when a call occurs. This may be for the duration of the call, part
of the call, or only until the call is answered. The call screen
usually displays information about the second party in the call,
such as a phone number or name, along with means for interacting
with the call by answering, rejecting, putting on hold, and the
like. The call is preferably an incoming call although it may
additionally or alternatively be an outgoing call.
[0119] The system also provides for various ways of charging for
the media content, for example on a CPM (cost per mille or
thousand) impressions basis, or CPC (cost per click), or a
combination of both.
[0120] Further features of the invention are characterised by the
appended claims.
[0121] The invention also provides a computer program and a
computer program product for carrying out any of the methods
described herein, and/or for embodying any of the apparatus
features described herein, and a computer readable medium having
stored thereon a program for carrying out any of the methods
described herein and/or for embodying any of the apparatus features
described herein.
[0122] The invention also provides a signal embodying a computer
program for carrying out any of the methods described herein,
and/or for embodying any of the apparatus features described
herein, a method of transmitting such a signal, and a computer
product having an operating system which supports a computer
program for carrying out the methods described herein and/or for
embodying any of the apparatus features described herein.
[0123] The invention extends to methods and/or apparatus
substantially as herein described with reference to the
accompanying drawings.
[0124] Any feature in one aspect of the invention may be applied to
other aspects of the invention, in any appropriate combination. In
particular, method aspects may be applied apparatus aspects, and
vice versa. As used herein, means plus function features may be
expressed alternatively in terms of their corresponding structure,
such as a suitably programmed processor and associated memory.
[0125] Furthermore, features implemented in hardware may generally
be implemented in software, and vice versa. Any reference to
software and hardware features herein should be construed
accordingly.
[0126] Furthermore, any, some and/or all features in one aspect can
be applied to any, some and/or all features in any other aspect, in
any appropriate combination.
[0127] It should also be appreciated that particular combinations
of the various features described and defined in any aspects of the
invention can be implemented and/or supplied and/or used
independently.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
[0128] The invention will now be described, purely by way of
example, with reference to the accompanying drawings, in which:
[0129] FIGS. 1 and 2 show an overview of a telephone call
augmentation system;
[0130] FIGS. 3 and 4 show schematic diagrams of a telephone handset
upon which a call augmentation system/method is implemented;
[0131] FIG. 5 shows an example implementation in flowchart form of
the client application;
[0132] FIGS. 6, 7, 8 and 9 show examples of telephone call
augmentation;
[0133] FIG. 10 shows an example of a media content item selection
algorithm;
[0134] FIG. 11 shows a further example of media content item
selection algorithms;
[0135] FIG. 12 shows an overview of a telephone call augmentation
system for "smart warm calling";
[0136] FIG. 13 shows an example of a telephone call augmentation
related to "smart warm calling";
[0137] FIG. 14 shows an example of a further telephone call
augmentation related to "smart warm calling";
[0138] FIG. 15 shows an example implementation in flowchart form of
a client application used for "smart warm calling"; and
[0139] FIGS. 16, 17, 18 and 19 show example methods of coordinating
the content of the phone call and the item of media content to be
displayed in "smart warm calling";
[0140] FIG. 20 shows another example a telephone call augmentation
related to smart warm-calling;
[0141] FIG. 21 shows call screen user notification by way of a) a
basic (push) notification and b) an interactive notification;
and
[0142] FIG. 22 shows a call screen with an SMS response
facility.
DESCRIPTION OF SPECIFIC EMBODIMENTS OF THE INVENTION
[0143] FIGS. 1 and 2 show an overview of a telephone call
augmentation system 1. A client device 10, comprising for example a
telephone handset--such as a smartphone--is adapted to receive
telephone calls from a second client device, telephone 15, over a
communications network 20.
[0144] Network 20 may be an IP-based network, a 3G (or higher)
telecommunications network or represent a combination of different
types of communications networks.
[0145] Telephone 10 is also in communication via network 20 with a
media server 30, which stores (for example in a database) and
serves media content from local storage 32 and/or remote storage 34
to telephone 10, which may optionally store the received media
content locally at store or cache 112 (which may be internal to
telephone 10) for later display.
[0146] FIGS. 3 and 4 show the telephone handset 10 in more detail,
including the display screen 106 on which callerID information 104
identifying the caller is usually displayed when the telephone 10
receives an incoming call. Also shown are example contents of the
system memory or software architecture 70 of the telephone 10 when
in operation, showing the operating system (OS) 72, the "dialler"
application 114 which handles the making and receiving of telephone
calls, and telephone call augmentation application (commonly
referred to as an "app") 100. Local storage 112 may be shared by
the operating system 72 and software applications installed on the
telephone 10.
[0147] In brief, when the app 100 is active and telephone 10
receives an incoming call, a media content image 101 is shown on
the screen 106 overlaid on top of the default incoming call screen
104 (or, in the case of audio media content, played from the
loudspeaker in place of the ringtone).
[0148] The user can then optionally select the media content image
101 (which will cause it to be shown after the current call has
ended) and can also elect whether to accept or decline the call as
normal.
[0149] The media content is displayed on the incoming call screen
rather than within the app itself, i.e. the display of media
content image 101 is integrated with the usual display of
information on screen 104.
[0150] A software development kit may also be provided to allow
third parties to develop variants of the telephone call
augmentation application "app" 100, which is then optionally
bundled with their own "host" apps.
[0151] In some embodiments, the software system--also referred to
here as "Incall"--in its full form comprises three components:
[0152] A mobile SDK which displays advertisements on the incoming
call screen of mobile devices [0153] An automated brokerage system
which connects developers with advertisers, provides advertising
analytics and handles payment flows and business logic [0154] A
series of algorithms that determine which advertisement(s) should
be displayed on the device.
[0155] A basic commercial embodiment may comprise the following:
[0156] A mobile SDK which bundles the code to display the
advertisements so that it can be bundled into third-party apps
[0157] A web interface front-end which facilitates the manual
administration of the advertising system, and which provides a
basic set of metrics from which financial data can be calculated
[0158] A web back-end and protocol which handles the storage of
adverts, the transmission of adverts to the clients
Detailed Overview
[0159] Generally, the system 1 comprises the following components:
[0160] A client or user device, typically a smartphone 10 [0161] A
server 30 which manages and tracks the media content 108,
determines which items of media content are to be sent to the user
device 10, and delivers the media content 108 to the application
100. [0162] Media content [0163] A client software application 100
to serve media content to a smartphone [0164] A background service
[0165] An algorithm (optionally, two algorithms, one on the server
30 and/or one as part of the client app 100) to select the
appropriate media content 108 with which to augment the call [0166]
Optionally, a SDK (software development kit) for the development of
third-party variants of app 100, particularly for mobile
devices
[0167] The software application may be pre-installed on the mobile
device, or may be available to download for free or for a price
from the internet and/or from a software application platform such
as iTunes.TM. or Android Market/Google Play and/or bundled with or
otherwise coupled with other (potentially free) apps.
[0168] Client Device
[0169] The mobile or client device comprises at least a screen 106
and a phone function in the form of a dialler circuit or
application 114, which handles incoming and outgoing calls and
displays an incoming call screen image including a caller ID on the
screen of the device, among other functions.
[0170] The screen may be an LCD screen, touch screen, or the like.
Preferably the mobile device further comprises internet connection
capability and an internet browser. Such devices are commonly
referred to as `smart phones`.
[0171] Server
[0172] The server may send items of media content to local caches
upon receipt of media content requests, or may push them to the
caches periodically, or when new media content becomes
available.
[0173] The items of media content may alternatively be sent from
the server(s) directly to the application directly using, for
example, a cloud-based service such as Google Cloud Messaging (for
Android) or Push Notifications (for iOS).
[0174] The server 30 applies a proprietary algorithm to determine
the media content 108 to be displayed. The server 30 also
establishes an audit trail and maintains accounts for each app 100
and media content 108 selections in order to distribute revenues to
developers.
[0175] The server may perform any or all of the following back-end
activities: [0176] maintaining a global database of all the items
of media content; [0177] applying an algorithm to determine which
items of media content should be delivered to the client-side app
and/or to the cache on the mobile device of the user; [0178]
maintaining an audit trail comprising records of which items of
media content have been displayed (served) and which hyperlinks
have been selected (clicked); [0179] receiving payments from media
content providers, calculating revenue share, and making payments
to developers, such as second software application developers.
[0180] The server may also perform any or all of the following
front-end services: [0181] secure area for media content providers
to manage their items of media content and make payments; [0182]
secure area for software developers to register their software
application (for example, by means of identifiers) and receive
payment; [0183] secure area for system administrators to monitor
the overall system status and retrieve media content
provider/developer records.
[0184] The server may be implemented for example on the LAMP
(Linux, Apache, MySQL, PHP) stack as a PHP application with a MySQL
database for storing the items of media content. The server may
comprise a REST-based interface (API) for communication with the
software application. SSL may be used for additional security.
Further security measures to counter `click fraud` may also be
implemented, as discussed below.
[0185] The server could be provided centrally for all instances of
software used by the system, or could be incorporated as an
extension of existing architecture in the case where the provider
of the software also provides a server for their specific software
to be used by the system. This is particularly useful for the
"smart warm calling" example implementation of the system, as will
be described later on.
[0186] The server front-end is the part of the server-based system
that the administrators see, from where the system is administered
(adding apps and advertisements) and advertising metrics viewed. It
may have one or more of the following features: [0187] accessible
through the web browser as HTML pages, which are generated with PHP
[0188] provides a secure, password-protected area for
administrators to administrate the system [0189] secured via HTTP
basic authentication [0190] allows app_ids to be generated (in more
advanced implementations, there is also provided means for revoking
app_ids/instance_ids) [0191] allows advertisements to be created
and for the corresponding images to be uploaded in PNG image format
and stored on the server. In more advanced implementation, multiple
images may be supplied for different aspect ratios/pixel densities
[0192] allows a target URL to be specified for each advertisement
[0193] allows existing advertisements to be deleted from the
server. [0194] provides metrics on which advertisements have been
clicked and which host app(s) have been the source of the clicks
(potentially adapted to show impressions if the system tracks
impressions). For example:
TABLE-US-00001 [0194] Virgin Atlantic Coca Cola Nike T-Mobile Angry
Goats 819 219 38 432 Pinstagram 1024 381 564 1003 Temple Dash 7 5
13 8 Cut the String 200 281 543 391
[0195] The server back-end of the server-side system typically
comprises: [0196] A series of PHP scripts which provide the
REST-based API that the client app uses to communicate with the
server [0197] A MySQL database which contains a listing of all the
advertisements in the system, as well as an audit trail of all the
click data
[0198] An example database schema is as follows:
TABLE-US-00002 Data hosts table App ID App name Developer name
Developer email address Timestamp of creation instances table App
ID Instance ID Timestamp of creation advertisements table Advert ID
Client ID Advert target URL - where the advert takes the user when
it's clicked Date uploaded reports table Report ID Instance ID
Report start date Report end date clicks table Report ID Advert ID
Clicks Impressions (if impressions are being tracked)
[0199] Media Content
[0200] The item of media content may comprise one or more of the
following: [0201] a video clip, animation, image, slideshow, text,
hyperlink, web page, URL, audio clip, ringtone, or any combination
of the above. [0202] a combination of the above such as to produce
a display comprising text, at least one image and at least one
hyperlink, similar to a banner advertisement provided on internet
websites. [0203] an animated and hyperlinked image moving across
the screen, such as a hyperlinked image of an aeroplane say moving
from right to left, or a hyperlinked box of cereal pouring flakes
into a bowl. [0204] Speech, music or other audio may be a part of
the media content and may be played while the image or animation is
displayed.
[0205] The item of media content may use .jpg, .gif, or any other
suitable file formats, and may be written in html, php, javascript
or any other suitable programming language.
[0206] The item of media content is stored (for example, in a
database) on a remote server which provides the media content as
required by the mobile device. Alternatively, the item (or items)
of media content may be stored on multiple servers, locally or
remotely, and periodically accessed by mobile devices.
[0207] In order to provide delivery of the media content from the
server to the phone, each item of media content is encoded into a
specific format to be transmitted and stored on the phone.
[0208] In the simplest implementation of a basic banner display
format, each media content "payload" comprises an image, preferably
provided in different sizes and at different DPI for different
screen resolutions and aspect ratios (so that the server can select
the most appropriate format of media content to send for a specific
device to reduce cache/bandwidth wastage).
[0209] The media content item is "clickable" or otherwise is
capable of triggering a further action (most commonly, opening a
webpage).
[0210] Associated metadata is supplied in XML/JSON format which
provides a URL that is launched if the media content is
selected/clicked, along with some other data to by the app in order
to select which item of media content to display.
[0211] In a more complex implementation, each "payload" includes
multiple media types (e.g. image and audio file), or animation
behaviour, along with more comprehensive metadata.
[0212] The more metadata is supplied with the media content, the
more information is available to the server/app to select the most
appropriate app to serve.
[0213] Generally, the media content is presented as an overlay with
one or more of the following properties: [0214] triggered when an
incoming or outgoing phone call event is triggered [0215] is
overlaid onto the incoming call screen [0216] takes up the entire
screen width and the height is set to a fixed height in display
pixels (determined during build) [0217] displays a single PNG image
advertisement (potentially selected at random from the local advert
cache), appropriately sized for the overlay [0218] records an
impression for the advert (if impressions are being tracked) [0219]
the image advertisement is clickable [0220] is hidden once the call
is accepted or rejected [0221] is movable (this may not be possible
in all versions of operating systems and on all handsets) by
pressing and dragging it upwards/downwards, in order to support
different types of diallers on different handsets and operating
systems/versions, and so as not to obscure any caller ID
information from the native dialler [0222] if the advertisement on
the overlay is clicked, then after the call has been accepted,
rejected or completed the corresponding website is launched in the
default browser, and the click data is recorded locally, ready to
be sent to the server indicating that the advert was clicked [0223]
in order to comply with guidelines or policies of the
network/operating system provider or app distributer, the overlay
contains information about the source of the advert and any other
details that may be required for compliance. This information could
be displayed in a pop-up dialog window where necessary [0224] has a
button which can be selected in order to close it. [0225] has
buttons showing ticks and crosses, or other positive and negative
symbols, which can be selected in order to accept or reject a
presented offer. [0226] has buttons (or other interaction means)
through which the user can indicate their preferences, where this
preference may be chosen out of an available options defined by the
buttons.
[0227] Client Application
[0228] The call augmentation client application or app 100 is
typically a stand-alone application which is pre-installed on the
client device as part of the device configuration by a network
provider. Alternatively, the app may be downloaded from an app
distribution platform, library or store such as Apple iTunes or
Google Play.
[0229] The app 100 registers itself to receive updates from the
phone 10 operating system 72 any time when an incoming call event
is triggered.
[0230] Alternatively, the call augmentation client application 100
may be embedded in or form part of a second software application
which has a different primary function. The second application may
be also be preinstalled on the client device or available to
download and install subsequently.
[0231] In this case the call augmentation application 100 may be a
compulsory or optional component of the second application, and if
optional, may be provided as an opt-in or opt-out option during
installation of the second application or at any time during use
thereof.
[0232] Since users do not usually readily volunteer to accept
advertising, an advantage of providing the application as part of a
second application is that users will be persuaded to accept the
advertisement application because of a desire for the features of
the second application.
[0233] In some embodiments, the option is provided to have media
content provided either via the call augmentation client
application 100 or via regular in-app methods, with the further
option provided to switch between the two. This may be an option
which can be activated by the user and/or a configuration option
which can be set in the app. Thus, a user may select whether media
content, such as advertising, is displayed within a "free" app, or
having media content, such as advertising, displayed on an incoming
or outgoing call screen display. Alternatively, the user may choose
to receive "smart warm calls" (as will be detailed later on) from
the provider of the app or from third parties.
[0234] Background Service
[0235] The background service is initialised by the third-party
app, and is configured to run automatically in the background
continually, and to restart itself automatically if the device is
restarted.
[0236] In order to ensure that the media content can be displayed
on-screen immediately without delay, items of media content may be
cached locally on the device.
[0237] There are a number of different ways to implement the
caching system, preferably with a background service to maintain it
so way that it does not grow uncontrollably, but at the same time
ensuring that there is an appropriate amount of media content
available locally on the device.
[0238] The device might not have 3G/Wi-Fi connectivity, or might
not be able to use a data connection simultaneously to the incoming
call, and either way mobile data connections are slow. Therefore,
the background service periodically communicates with the server to
download media content which is then stored locally on the device
in a cache.
[0239] The cache is restricted to a particular maximum size and
must be pruned periodically. In one example this is done is by
checking to see if the cache reaches a particular size (e.g. 20 MB)
and simply deleting older content to make way for the new (i.e.
operating as FIFO queue).
[0240] A more complex version has the server flag each item of
media content with an "expiry date" after which the item of media
content will no longer be displayed and instead will be removed
from the cache.
[0241] Algorithms
[0242] A set of algorithms are used to determine which items of
media content are to be displayed on the phone for a particular
call. In order to provide targeted media content the app selects a
media content item based on a wide range of criteria, optionally
including ones based on real-time information (e.g. current
location, caller information, etc.)
[0243] In cases where the client app can only select media content
from its local cache (not the server), which is a subset of the
total media content library which sits on the server, a two-phase
media content selection algorithm is used, part of which runs on
the server and part on the client, which aims to fulfil the
following two conflicting goals: -- [0244] 1. Minimise cache usage
and data transfer overheads. [0245] 2. Ensure that the best
possible media content item is selected on the device, without
communicating with the server in real-time.
[0246] In order for the media content to be displayed effectively,
the server decides which media content items are sent to the
handset in advance of the call to be cached (this could be several
hours in advance, or even days). The server makes certain
assumptions or predictions about which items of media content are
best-suited to the user. This is based on information which is
periodically sent from the app back to the server, or alternatively
on static information. The server has a wide range of media content
from which to choose, but makes a selection of which items to send
to the client based on fairly limited information.
[0247] Alternatively, the subset of the media content library sent
to the client app is selected randomly.
[0248] The client-side algorithm, on the other hand, has a much
larger set of data upon which to make a decision of which item of
media content to show as it has access to real-time data (e.g.
caller info, date/time/location, etc.) but has a smaller subset of
media content to choose from (i.e. it can only select an item of
media content that already exists in the cache).
[0249] FIG. 10 shows an example of a media content item selection
algorithm.
[0250] The two algorithms complement each other in order to achieve
a balance between the two goals.
[0251] In the first phase, the server chooses which media content
items (of those stored in server database 32) to send to the
client. Then, in the second phase, the client selects the most
appropriate media content item (from those stored in the cache 112)
at the point of the incoming call.
[0252] Generally, the algorithms optimise the media item selection
to maximise rates of user interactions or clicks. This may be based
on prior market research or according to weightings determined from
user interactions.
[0253] In some embodiments, up to four algorithms are used: [0254]
i) Server-side selection algorithm--Used to determine which adverts
should be sent from the server to the client's device to be cached.
[0255] ii) Merge algorithm--Used to merge the new adverts received
from the server with the old adverts stored in the cache. [0256]
iii) Client-side selection algorithm--Used to determine which
advertisement should be selected from the cache and displayed on
the incoming call screen. [0257] iv) Combination algorithm--Used by
both the server-side and client-side selection algorithms in order
to combine multiple sorted lists into a single list. This allows
the adverts to be effectively sorted by multiple factors.
[0258] FIG. 11 shows a further example of media content item
selection algorithms.
[0259] Generally, both the client- and server-side selection
algorithms apply a similar 3-step process whereby the adverts from
the cache are sequentially filtered and/or sorted and then
combined, so with the result that a series of adverts are selected
(on the server) or a single advert is selected (on the client).
[0260] Filter--select those adverts from the cache matching certain
criteria. [0261] Sort--sort them based on how closely they match
the criteria. [0262] Combine--once filters and sorts have been
combined on the data in a single operation, then a "combination"
stage is needed to combine all of the sorted data into a single
list. [0263] Select--select a single advert to display on the
screen.
i) Server-Side Algorithm
[0264] The server uses an algorithm to determine which media
content items to send to the client for local caching, based on
factors such as: [0265] Handset make/model and version of Android
(operating system) [0266] Previous items of media content shown
[0267] User preferences [0268] Nature of the app providing the
media content
[0269] In some embodiments, the media content item is selected at
random.
[0270] Generally, the purpose of this algorithm is to choose those
adverts from the extensive library of advertisements on the server
that match the target device characteristics and factors, thus
maximising the chances that the advertisements available on the
device are relevant (and most likely to be clicked).
[0271] Inputs may include: [0272] Factors received from the handset
(and historic data from the handset) [0273] Adverts from the
advertisers
[0274] Outputs may include a set of one or more advertisements,
which are then transmitted to the client to be cached on the
device.
[0275] The algorithm iterates through the advertisements on the
server and builds a priority list of those that most closely match
the data received from the handset. The top n advertisements (where
n is the maximum cache size) are then collected and sent.
[0276] Filter & Sort [0277] Filter by OS Version/Device Type
[0278] This filter, typically applied first, selects the most
appropriate advert for the device based on the version of OS they
are using and the device type, which consists of information such
as screen resolution, available screen space to show an advert,
screen aspect ratio, etc. [0279] Filter by User Country [0280]
Using the IP address or historic GPS data collected from the phone,
it can be determined which country the user is in, and the adverts
can be filtered accordingly according to their metadata. [0281]
Filter by User Location History [0282] The server can use the
device's location history in order to extrapolate certain patterns
(e.g. commuting patterns), which can then be related back to
advertising metadata. [0283] Filter/Sort by User Advert History
[0284] The advert history consists of adverts that have been
displayed (and frequency) and those that have been clicked (and
frequency) for each user. Based on this information, adverts can
associate (or disassociate) themselves with one another. [0285] In
addition this presents the possibility that the server can try
different combinations of adverts if the current adverts have not
been so successful, or can continue to show the same sort of
adverts if they have been successful.
[0286] Selection [0287] Top N Selection [0288] The server-side
sends the top N results after the sorts have been applied, where n
is a reasonable number of algorithms to be transferred over the
Internet. N could also relate to the frequency of updates (i.e. the
more recent the last transfer, the lower the N value). [0289] In
some embodiments the client itself defines N based on its own
calculations of how many "fresh" adverts are needed, based on the
expiry of algorithms or whether they have already been
selected/displayed, etc. (a side effect of this being that the
merge step can be omitted).
ii) Merge Algorithm
[0290] The purpose of this algorithm is to merge the new adverts
received from the server with the old adverts already stored in the
cache. This algorithm is run every time the client receives an
update from the server.
[0291] Inputs may include: [0292] New adverts received from the
server [0293] Old adverts retrieved from the cache [0294] Local
device factors (possibly--although the server should already be
aware of most of these and would have factored them into the
update).
[0295] Outputs may include a new set of adverts (old and/or new)
which are then stored in the cache.
[0296] The algorithm iterates through each of the new
advertisements received from the server and each of the old
advertisements retrieved from the cache, filters them and sorts
them into a list. Depending on the available cache size, the top n
are selected.
[0297] In an alternative implementation of the system where the
client is able to delete its own adverts when they are deemed to be
no longer relevant, and is able to specifically request a number of
new adverts from the server, the merge algorithm is not actually
required: The client can simply delete N adverts from local
storage, and request a new set of N adverts to replace them,
without needing to merge. This also saves on bandwidth, as only the
required number of adverts actually needs to be transmitted. The
downside of this approach is that the client must perform more
processing initially in order to determine which adverts to delete
and how many slots are open.
iii) Client-Side (Selection) Algorithm
[0298] The client-side algorithm, meanwhile, decides which item of
media content to select from the device local cache. It is able to
do this based on real-time information such as: -- [0299] Location
of the callee (via GPS) [0300] Location (region) of the caller (via
phone number) [0301] Current date and/or time [0302] Specific
incoming and/or outgoing call events
[0303] For example, the app could use caller-based methods to
display location- or situation-based information or to implement
"adversarial" marketing based on sponsorship of particular
factors.
[0304] In some embodiments, the media content item is selected at
random.
[0305] Generally, the purpose of this algorithm is to select a
single advertisement to display on the incoming call screen from
the cache, based on the best available information on the device,
which may include real-time information such as GPS location and
factors to do with the incoming call.
[0306] Filter & Sort [0307] Filter/Sort by Caller Phone Number
[0308] The advert metadata specifies a list of phone numbers (or
phone number regular expressions--up to some level of detail) that
it should be triggered for. When the call comes in, a check is done
to see which adverts should be triggered for this specific number.
[0309] The more specific the list of phone numbers (or the more
concrete the regular expression) the higher position it is given in
the sort. [0310] Filter/Sort by Caller Location [0311] The caller
location can be approximated by examining the caller's area code
(or international country code) and this data can then be matched
with advertising metadata to determine which advert should be
shown. Some adverts may only be relevant to specific countries or
regions. The adverts can be sorted based on the physical proximity
of the advertised content or service to the location of the caller,
and then by how specific they are to a particular region. [0312]
Filter/Sort by User Location [0313] The advert metadata provides a
point and catchment radius in metres, or a 2-dimensional bounding
box specified in latitude & longitude. The current GPS location
data is retrieved and a check is done to see which adverts cover
the current location. [0314] The location data can either be coarse
(i.e. fairly inaccurate using cell triangulation, but faster to
retrieve) or fine (i.e. more accurate via GPS, but slower to
determine). The adverts can be sorted by how far they are from the
current location--or if their location is specified by a bounding
box, then how small the bounding box is. [0315] Sort/Filter by Date
& Time [0316] Certain adverts might be only suitable for
display during specific times or dates, based on the metadata. (For
example, promotions that run for a fixed time, or stores that are
open at specific hours). The date and time in the advert metadata
can be specified as a specific time, or a range. [0317] Sorting is
a combination of (a) the size of the date/time window (the smaller
the date/time window, the higher the sorting priority) and (b) how
close to the target date/time (if there is one) the user is at that
moment (this can also be specified in a forward-looking only mode).
[0318] Sort/Filter by Server Factors
[0319] The client can also optionally apply many of the same
filters that run on the server, such as personal browsing/call
history, etc.
[0320] Selection [0321] Sequential Selection [0322] An ordering is
maintained for each advert, and the adverts are iterated over
sequentially, which prevents the same adverts from being shown
repeatedly (which can happen with Weighted Selection and Top
Selection). [0323] Random Selection [0324] An advert is selected at
random. This usually requires very robust filters to be in place,
because the sorting order is ignored leaving just the filters.
[0325] Top Selection [0326] The top-ranking advertisement is
selected. This is not a good idea unless there are a large number
of adverts available to choose from with a wide variety of factors.
[0327] Weighted Selection [0328] In this algorithm, the
advertisements higher on the sorted list are weighted the most,
with subsequent positions on the sorted list having a probability
of selection that decays exponentially. [0329] The following is an
example of the weighting and subsequent probability of selection
for a list of five adverts:
TABLE-US-00003 [0329] Position on List Weighting Probability of
Selection 1 100 0.52 2 50 0.23 3 25 0.13 4 12.5 0.0625 5 6.25
0.032
iv) Combination Algorithm
[0330] The purpose of this algorithm is to combine multiple
filtered/sorted lists into a single filtered & sorted list from
which a selection can be made.
[0331] Inputs may include: [0332] Filtered/sorted list from each
factor in the algorithm [0333] Weights for each factor (if
applicable) [0334] Hard-coded directives, such as the
position-weight decay function
[0335] Outputs may include a single sorted & filtered list of
adverts from which a selection can be made.
[0336] The filtering, sorting and selection algorithmic components
are specific to each algorithm (and interchangeable), but the
combination algorithm is common both the client-side and
server-side algorithm and consists of combining multiple sorted
lists of adverts into a single sorted list, so that a selection can
be made.
[0337] For example, supposing we have two factors X and Y by which
we want to sort advertisements. X could be, for example, "adverts
sorted by distance from the current user"--the higher on the list
the advert is, the closer it is to the user geographically. Y, on
the other hand, could be "adverts sorted by past history" where the
higher on the list the advert is, the more suitable it is based on
the user's advert history.
[0338] First of all, we can sort them by X:
TABLE-US-00004 Sorted by X Advert 2 Advert 3 Advert 1 Advert 5
Advert 4
[0339] Then, we can independently sort them by Y as well:
TABLE-US-00005 Sorted by Y Advert 4 Advert 1 Advert 2 Advert 3
Advert 5
[0340] The result will be two, completely separate lists, which
makes it difficult to select which advert would be the best one to
show to the user. Even if it were desired simply to select the
"top" advert, the two sorted lists will not agree on which is the
"top" one.
[0341] Therefore, these two lists are combined. A combination
algorithm which shows how this can be achieved is now
described.
[0342] In the above examples, each advert is given a
position-weight where 5 is the top of the list and 1 is the bottom.
The position-weights for X and Y are then added to produce an
overall weight, which then produces a new sorted list as a
combination of the original lists.
TABLE-US-00006 (Weight for X) + Sorted by Y Weight for X Weight for
Y (Weight for Y) Advert 1 3 4 7 Advert 2 5 3 8 Advert 3 4 2 6
Advert 4 1 5 6 Advert 5 2 1 3
[0343] By taking the combined (added) weights, the following
combined list is created, from which a selection can be made
according to the selection algorithms described previously:
TABLE-US-00007 Sorted by X + Y Advert 2 Advert 1 Advert 3 Advert 4
Advert 5
[0344] However, this particular algorithm is heavily simplified and
may not be suitable for real-world implementation. In particular:
[0345] Both X and Y were treated completely equally. In the real
world, one would probably want to weight one factor more than
another. [0346] This algorithm only handled two factors, but it may
be desirable to handle more. [0347] The position-weight of each
advert was calculated by simple linear decay, but this could be
modelled as exponential, etc. to give more weight to higher
results. [0348] There may need to be a "tiebreaker" for handling
cases where after combination, two adverts have the same weight (in
this case, we simply inserted them randomly). [0349] This algorithm
only handles cases of sorting, not filtering (although it can be
assumed that filtering is simply the process of applying an
unsuitable advert with a zero weight).
[0350] According to a further example, a combination algorithm is
also provided, where for an advert a with 3 factors {x, y, z}:
w.sub.a=w.sub.xw.sub.a.sub.x+w.sub.yw.sub.a.sub.y+w.sub.zw.sub.a.sub.z
where: [0351] w.sub.a is the final position-weight of advert a.
[0352] w.sub.x is the pre-defined relative weight of factor x.
[0353] w.sub.ax is the position-weight of advert a on the sorted
list for factor x.
[0354] An example flow of how the advertising selection system
works end-to-end is as follows: [0355] 1. Assuming the client app
has 50 adverts stored locally in the cache, and for simplicity we
assume that all adverts are the same size and that the client
capacity is for 50 adverts. [0356] 2. The client is informed that
it is time for the periodic update with the server, so it requests
an update from the server. [0357] 3. In addition to the request,
the client also sends to the server information about which adverts
have been shown, and which have been clicked since the last update.
It also sends information about their version of Android and
handset type and approximate geographical location over the last 30
days. [0358] 4. The server's advert library is then sorted and
filtered by these factors and then combined into a single list on
which the Top N selection algorithm is used to select the top 50
adverts. [0359] 5. The client receives the 50 new adverts, and uses
the merge algorithm in order to determine which adverts to delete
from the cache, and which to save--and equally which adverts to
"merge in" to the cache from the server update, and which to
ignore. [0360] 6. The merge algorithm completes and the client now
has a set of 50 up-to-date adverts in its cache. [0361] 7. A call
comes in, the client now sorts and filters the adverts from its
cache both by the current user location as well as the date/time
and then applies the combination algorithm to produce a single
sorted list on which a weighted selection is done in order to
select a single advert from the cache to present to the user.
[0362] The above is only one possible example implementation of the
system.
[0363] Software Development Kit
[0364] In some embodiments, a SDK is made available online, which
developers can download to bundle this technology with their own
app. The SDK bundles the client-side components, comprising the
background service and app.
[0365] These components can either be bundled directly inside the
third-party app package, or can be included as a separate package
which is installed by the third-party app (in particular, the
latter approach simplifies dealing with multiple apps on the same
device using the SDK).
[0366] In the case where the software application is provided as
part of a second software application, the software application may
be provided as a software development kit (SDK) made available to
software developers online or elsewhere. The developers of the
second software application would therefore install the software
application as part of their second software application using the
SDK. For example, developers of a game app may use the SDK to
install the software application of the present invention as part
of their game app. An advantage of this arrangement to the
developers is that they gain revenue by enabling advertisements of
a third party to be displayed on the incoming call screens of users
of the game app. An advantage to the third party (the providers of
the advertisement) is that their advertisement is displayed on the
incoming call screens of users who download the game app, and they
may pay for this advantage according to the number of impressions
of their advertisement shown (CPM), or the number of times a user
selects their hyperlink (CPC), or any other means.
[0367] Generally, the SDK may offer one or more of the following
features: [0368] distributed as a downloadable package that can be
incorporated into a third-party app, referred to as the host app
[0369] initialised using a simple API which uses an app_id to
initialise the app with a unique identifier for the host app [0370]
Upon initialisation, the SDK verifies the app_id and requests an
instance_id for this specific installation of the app from the
server which is then stored on the device [0371] Once the SDK has
verified the app_id and received the instance_id, the software
application (Incall) is activated on the app [0372] If the app
cannot validate the app_id because it is rejected as invalid, then
an error message is displayed and Incall is not activated [0373] If
the app cannot validate the app_id because there is no internet
connection available, then no error message is displayed, Incall is
not activated, and Incall will attempt to validate the app_id next
time the initialisation routine is called [0374] If the app cannot
request an instance_id because there is no internet connection
available, then no error message is displayed, Incall is not
activated, and Incall will attempt to request an instance_id next
time the initialisation routine is called.
[0375] Typically, the SDK is bundled with the host app; as such it
is automatically uninstalled with the host app.
[0376] In some configurations (particularity where "smart warm
calling" is used, as will be described later) the SDK may be
integrated into an already installed app via a software update.
This SDK may, optionally, be used by third parties in addition to
the party providing the app, subject to the end user signing a
license agreement. A number of items of media content may be
provided as part of the software update so that the system can work
immediately following the update.
[0377] Security
[0378] Click fraud is a problem encountered by all advertising
networks, that is, how to establish that the "clicks" being
reported to your server are actually genuine clicks, and not
malicious users who have figured out how to game your system in
order to report thousands of fake clicks?
[0379] There are two main ways of gaming the system:
1. developers manually clicking their own ads in order to record
clicks. 2. developers determining the server's API in order to
submit fake click reports.
[0380] There are ways to mitigate click fraud, however as with any
network there is no 100% secure method of ensuring that clicks are
genuine.
[0381] For the present system, the challenge of preventing click
fraud is even greater, as the application code is downloaded and
run locally on the user device (which they can exploit far more
easily) and in a delayed reporting system, this is ideally done in
an offline environment, periodically syncing with the server.
[0382] One way to address this is by establishing a sufficiently
detailed audit trail as so to make any click fraud fairly easily
recognisable.
[0383] Firstly, each click report contains the app_id. This is
generated by the server and is hard-coded into the host app.
[0384] Each click event must contain an app_id which relates to the
host app on the device.
[0385] Therefore, the app_id can be used to establish an audit
trail, to analyse click behaviours coming from a specific app.
[0386] However, the app_id is potentially a weak measure because it
can easily be extracted by specialised tools to extract data (in
particular, strings) from the app binary. A malicious developer
could use the app_id to thousands of fraudulent clicks. Without
further analysis, it may be impossible to determine whether this is
one user sending illegitimately submitting thousands of clicks, or
a thousand users legitimately clicking one advert each.
[0387] To mitigate the shortcomings of using the app_id alone, the
instance_id is introduced as an additional measure in order to
uniquely identify each instance of the app.
[0388] Upon initialisation, the SDK requests a unique instance_id
from the server, and this is stored on the device for the lifetime
of the app. In the event the app is uninstalled and re-installed, a
new instance_id is generated, however the instance_id persists
during an upgrade.
[0389] By using the instance_id, we can now determine whether the
thousand clicks (from the previous example) come from one user
(i.e. one instance) clicking a thousand adverts, or one thousand
users (i.e. one thousand instances) clicking one advert.
[0390] However, there is nothing to stop a malicious user from
generating a single app_id, 1,000 instance_ids and then submitting
click reports of 1 click each. This can be mitigated by: [0391] 1.
Checking the number of clicks per instance_id. If a single
instance_id is generating an abnormally high number of clicks, this
could be indicative of click fraud. [0392] 2. Checking the
timestamps of the instance_id generations. If they were all
generated in a single short burst over a very short timespan (i.e.
matter of minutes), then it is likely that the instance_ids were
generated fraudulently via a script. [0393] 3. Checking the IP
addresses of the instance_id generations. If they were all
generated from the same IP address, then it is extremely likely
that the instance_ids were generated fraudulently by the same user.
[0394] 4. Checking the Android app download figures directly with
Google. In the event of a click fraud investigation, a developer
could be asked to prove their installation figures from their
Google Developer Console. If the number of instance_ids vastly
exceeds the number of downloads & installations, then it is
extremely likely that the instance_ids have been fraudulently
generated.
[0395] Therefore, by combining the app_id with the instance_id, and
also looking at the IP address of the click report (which cannot be
spoofed), there is enough data to mitigate the risks associated
with most common forms of click fraud.
[0396] A further example incorporates the following features:
[0397] Using the device's IMEI number to further validate click
information. [0398] Using triggers on the advertiser's website to
validate click-throughs as being genuine. [0399] Using a one-time
code based on the instance_id (or a server-based nonce).
[0400] Therefore, the SDK simply reports the app_id and instance_id
for each click/impression, and the server stores an audit trail of
app_ids, instance_ids, timestamps and IP addresses in its database
in order to facilitate manual investigations and to support a
possible future implementation of an automated detection
algorithm.
[0401] In addition, all communication between the app and the
server is secured via SSL to prevent eavesdropping and
man-in-the-middle attacks.
[0402] In some embodiments, clicks are accompanied by the IP
address of the source of the click, in order to make it easier to
monitor for click fraud.
[0403] Privacy
[0404] It is important that the various approaches discussed for
collecting and uploading potentially sensitive user data to the
server, which may include personal information, are legal and
in-line with appropriate guidelines, and also that such information
is properly communicated to the end-users to allow them to make an
informed decision as to whether or not they wish to share their
personal information.
Operation
[0405] FIG. 5 shows an example implementation in flowchart form of
the client application. [0406] S1. When a call occurs from a second
party to the user of the mobile device, an incoming call event is
triggered by the operating system and the dialler sends
notification 110 of the incoming call event to launch the
application 100. [0407] S2. The augmentation application 100 is
launched. [0408] S3. Algorithm determines which media content item
to display [0409] This may involve the application sending a media
content request 102 to a cache 112. The cache 112 is a local store
of media content on the mobile device. Upon receipt of the media
content request the cache sends the media content item 108 to the
application 100. [0410] As described above, in some embodiments,
the mobile device periodically accesses the remote server and
downloads updated media content for downloading updatable
information. [0411] S4. Media item overlay is displayed, i.e. a
view is attached to the phone's window manager and is overlaid onto
the incoming call screen. [0412] Since a call is occurring, the
screen will usually be displaying an incoming call screen image or
callerID 104. The application interacts with the windows manager
(or other appropriate component of the operating system) of the
mobile device to enable the media content to be prioritized over
the incoming call screen and therefore the media content image 101
to be overlaid on the incoming call screen image 104 such that the
screen 106 displays the media content image. This change in
priority may be conducted by changing the respective display
z-orders of the item of media content image 101 with respect to
that of the incoming call screen image 104. [0413] S5. Is the call
accepted/rejected/timed out? i.e. the app waits until the call is
answered or rejected, at which point . . . [0414] S6. The view is
removed from the phone's window manager. [0415] S7. The app remains
in the background for the duration of the call. [0416] S8. Was the
media content item clicked? [0417] S9. If yes, the user clicked on
the media content item prior to accepting the call, then a browser
window is opened after the call which takes the user onto a
specific website. (Alternatively, this could be a different action
other than opening the browser, such as dialling a number, etc.)
[0418] S10. Otherwise, the app terminates itself (and optionally
reactivates itself after the call).
[0419] FIGS. 6, 7, 8 and 9 show examples of telephone call
augmentation.
[0420] FIG. 6 shows an Overlay Example 1: Movable banner. In this
example, the media content item is shown as a traditional banner ad
which can be moved upwards and downwards by the user (or set
programmatically) so that it does not occlude the caller
information and call accept/reject buttons. It could also be
horizontally/vertically resizeable.
[0421] FIG. 7 shows an Overlay Example 2: Custom animation. In this
example, the overlay does not necessarily need to be a rectangular
shape, and indeed in many cases it would be more desirable to have
the objects more fluid in order not to obscure the call screen. In
this example, the media content item is shown as an aircraft which
zooms across the screen right-to-left upon the incoming call.
[0422] Many different shapes or types of media (image/video/3D
animation, etc.) that can be displayed on the screen, e.g. a cereal
box which appears from the bottom of the screen, propelling
cornflakes all over the screen.
[0423] FIG. 8 shows a further example, showing the overlay/media
content item with "host" app origin, further information and
`close` buttons. User clicks on the media item in the immediate
vicinity of the close button may in some embodiments be interpreted
as `near-miss` attempts to close the overlay.
[0424] FIG. 9 shows an overlay example for a limited offer, showing
the overlay/media content item with tick and cross buttons 201,
202, an indication of location 203 and "Stop Ads?"/`close` button
204. This example is particularly useful for offers which are
specific to a particular location or time. The user may take up the
offer by pressing the tick button 201, or reject it by pressing the
cross button 202. Pressing the "Stop Ads?" button 204 may redirect
the user to a page where they can purchase a premium version of the
developers' application which does not include the bundled SDK.
[0425] Delay Feature
[0426] In a preferred embodiment, the media content item comprises
at least one hyperlink with a delay feature, such that when a user
selects (or "clicks") the hyperlink before answering a call, or
during a call, the call is not interrupted and the user's viewing
of the destination website, webpage or URL defined by the hyperlink
is delayed until the end of the call. Upon ending the call, the
mobile device screen displays the website at the destination
specified by the hyperlink.
[0427] In some embodiments, the destination page may be
"pre-loaded" by being navigated to in the background during the
call by the browser of the mobile device.
[0428] Alternative implementations of the delay feature include:
[0429] immediate navigation to and display of the destination, but
the incoming call screen, or the displayed part of the incoming
call screen, may still be accessible and usable [0430] only the
portion of the screen displaying the media content item immediately
displays the destination website; the rest of the screen may
display the destination website only at the end of the call [0431]
selecting or clicking the hyperlink may both cause the browser to
navigate to and display the destination website, and answer the
call. In this case, navigation to and/or display of the destination
website may be immediate or delayed until after the call. An
advantage of this is that the user can, with one selection, answer
the call, and navigate to the desired destination website. The
destination website will either stay on the screen until the end of
the call or be displayed at the end of the call, at which time the
user can view it.
Android Implementation
[0432] Depending on the specific operating system in question, the
components, implementation and terminology may differ slightly from
platform to platform. The description used in this document is
based loosely on the Android paradigm. A basic prototype which
provides an incoming call screen overlay on the Android platform
will now be described. [0433] 1. The app registers a
BroadcastReceiver to receive the android.intent.action.PHONE_STATE
intent with maximum priority. [0434] 2. When the intent is received
by the BroadcastReceiver, the TelephonyManager.EXTRA_STATE
information is retrieved from the intent's extras. [0435] 3. If the
state is equal to TelephonyManager.EXTRA_STATE_RINGING, the app
starts a new Service. [0436] 4. Upon starting, the Service gets the
WINDOW_SERVICE system service and adds a new View with the relevant
content. It also registers itself as with a new IntentFilter to
receive a custom IDLE_STATE action. [0437] 5. The Service also
handles updating the view with the relevant media content, along
with any user interaction (e.g. clicking). [0438] 6. When the
BroadcastReceiver receives a further intent with the
TelephonyManager.EXTRA_STATE intent equal to
TelephonyManager.EXTRA_STATE_IDLE (i.e. the call has been accepted
or rejected) then a new intent is sent with the IDLE_STATE action.
[0439] 7. The Service receives the IDLE_STATE action and terminates
itself.
[0440] In order to capture the post-call event (in order to display
the media content, if it was clicked), the prototype can be
extended to maintaining a boolean on the Service of whether the
media content item was activated or `clicked`.
[0441] It is also possible to retrieve not just the current state
from the intent on the BroadcastReceiver, but also to compare it to
the previous state (which was earlier stored, as the
BroadcastReceiver is triggered independently each time the
android.intent.action.PHONE_STATE intent is received) in order to
determine when the call has ended.
[0442] A more complete implementation uses a background service and
caching system for the media content, along with the relevant
algorithm to select the most appropriate item of media content.
[0443] Different versions of Android place the call accept/reject
buttons differently, and OEMs have the ability to replace the
incoming call screen with their own alternatives (e.g. HTC's Sense
& Samsung's TouchWiz). Therefore, the media content item screen
overlay is placed and sized differently according to each handset
and version of Android in order to ensure that the caller ID and
accept/reject buttons are accessible. The app is therefore
customised for compatibility with each version of Android and each
handset.
Support for Multiple Parties
[0444] The SDK may also facilitate deployment from multiple
third-party apps.
[0445] The challenges this poses are as follows: -- [0446] 1. The
call screen is generally only capable of displaying one item of
media content per call, therefore the deploying apps must cooperate
(or indeed compete) to ensure that only one item of media content
is shown at a time. [0447] 2. There needs to be a fair way of
distributing the revenue between the multiple third-parties.
[0448] In other words, each time a call comes in, there is one
media display slot on offer, and therefore the client-side app must
introduce an additional selection stage in order to decide which
media content item is selected for display.
[0449] A number of example approaches that are used to handle
multiple apps deploying the call-handling facility on the same
device are described below (those models which only work in a CPM
scenario are labelled accordingly):
[0450] (As previously, CPM or cost-per-mille refers to the number
of times the media item is shown; CPC or cost-per-click refers to
or the number of times a user selects the associated
hyperlink).
[0451] Monopoly Model (CPC/CPM)
[0452] The monopoly model is both the simplest and least fair: the
first app which uses the SDK is granted all media display slots on
the device, to the exclusion of any other apps that may be
installed at a later date.
[0453] If an app tries to activate the media content display and
another app using the SDK is already installed, the app will be
informed that the activation failed, and instead would be forced to
provide some other means of media display (or forgo media display
entirely).
[0454] Sequential Model (CPM)
[0455] In the sequential model, the SDK maintains a list of all
third-party apps which use the SDK. When a call comes in, the SDK
cycles through each app displaying an item of media content
pertaining to a specific app, one per call giving each app one slot
in turn.
[0456] Probabilistic Model (CPM)
[0457] In the probabilistic model, the SDK maintains a list of all
third-party apps which use the SDK. When a call comes in, the SDK
selects one at random from the list and displays it.
[0458] Financial Distribution Model (CPC/CPM)
[0459] In the financial distribution model, all of the CPC/CPM
proceeds are put into a central pot which is then divided between
the apps installed.
[0460] Bid Model (CPC/CPM)
[0461] In the bid model, each media content provider (or app
developer) "bids" for the media display slot through an automated
auction system.
[0462] Generally, Incall is provided as a SDK (Software Development
Kit) in the form of a source code component that is bundled with
third party apps in order to provide pre- and post-call
advertising.
[0463] Each Incall-enabled app is packaged with the SDK before
distribution within, in the example of an Android OS, an APK
(Android Package) file, therefore each enabled app has its own
separate copy of the SDK (which is referred to as a separate
"instance" of Incall).
[0464] The SDK has three key functions: [0465] 1. To intercept the
incoming call screen to add advertising and to detect when the call
has been ended to display the post-call advertisement. [0466] 2. To
periodically sync with a central server to retrieve a fresh set of
advertisements to display to the user. [0467] 3. To report back to
the server the number of clicks and impressions for each
advert.
[0468] The syncing function of the SDK may allow a media content
provider to bid for media display slots and quickly supply their
media content to users.
[0469] Although there may be multiple instances of Incall on a
single (Android) device (due to the presence of multiple enabled
apps), only one instance of Incall should be responsible for the
above three functions. If each instance were to act independently
with no co-ordination between them, then the result would be:
[0470] 1. Multiple instances would conflict with each other when
trying to add adverts to the call screen. The likely outcome would
be that multiple adverts would be shown on top of one another.
[0471] 2. Multiple sync events would take place, which would
consume data allowance and battery. [0472] 3. Clicks and
impressions would be reported inaccurately: due to conflicting
instances of the SDK, they might be recorded multiple times, or not
at all.
[0473] An algorithm is accordingly provided to allow multiple
instances of Incall to coordinate with one another so that a single
("master") instance of Incall is responsible for displaying the
adverts, syncing with the server and reporting the clicks and
impressions.
[0474] The algorithm incorporates also the following features:
[0475] Allow inter-instance communication so that the other
("slave") instances are able to contribute app metrics to the
master instance for transmission to the server [0476] Be
decentralised so that there is no reliance on any third-party
components (which could be uninstalled) or shared log files (which
could be removed or tampered with) [0477] Give precedence to
instances of Incall that are a more recent version. [0478] Switch
instantaneously (or at least minimise any delay) in switching
between instances so that Incall is continuously active on the
device. [0479] Be invulnerable to outside apps interfering with the
master/slave coordination process.
[0480] The following three different example algorithms for
master/slave coordination are described below (in overview and
using pseudo-code): [0481] i) intent-driven algorithm [0482] ii)
log-driven algorithm [0483] iii) server-driven algorithm
[0484] A further option iv) is also described.
[0485] Once multiple instances are able to coexist, coordinate and
cooperate on a single device, business logic is used to divide the
revenue from clicks and impressions between the multiple
instances.
i) Intent-Driven Algorithm
[0486] The intent-driven algorithm uses Android intents to provide
a decentralised method of coordinating between multiple Incall
instances.
[0487] The Android documentation describes an Intent as "an
abstract description of an operation to be performed." Intents are
commonly used either locally to trigger events between different
components of an app, or system-wide to communicate between
multiple apps. Put simply, an intent can be thought of as a sort of
message which can be sent from an app to all other apps on the
device. For example, the intent [0488]
android.intent.action.VOICE_COMMAND is sent when an app wants to
start accepting voice commands. Android has built-in support for
voice commands, but by registering and responding to this intent,
other third-party apps can receive them too and offer to provide
voice command services.
[0489] In the intent-driven algorithm, system-wide broadcasted
intents are used in order to facilitate communication between slave
instances and their master. An intent is in effect an "event
broadcast". One app (strictly speaking, a component of an app),
sends out the intent, and any other apps (strictly speaking,
components of those apps) which are registered to receive that
intent will pick it up and can take action accordingly.
Advantages:
[0490] Technologically elegant. [0491] Decentralised. [0492] Using
intent "extras" it's possible to attach an additional payload to
the intent which makes it easy to collect metrics from other
Incall-enabled apps by passing the metrics as intent extras. [0493]
Intents are event-driven, so no need for polling.
Disadvantages:
[0493] [0494] Using system-wide intents, there is no way to prevent
a malicious third-party developer from triggering their own intents
and disrupting the natural application flow. [0495] Void period
when transitioning instances caused by waiting for intent
interval.
[0496] In terms of implementation, upon installation, each instance
of Incall by default starts in slave mode (unless it has previously
recorded itself as being a master instance in preferences), and
registers a BroadcastReceiver to receive a com.getincall.HEARTBEAT
intent, sent by a master instance to inform the slave instances
that it is active.
[0497] It then also defines a variable sleepTime which is a random
number in the range heartbeatInterval+1 to maxSleepTime.
heartbeatInterval and maxSleepTime are constants defined as
follows: [0498] heartInterval is the constant, pre-defined time
between "heartbeats". The com.getincall.HEARTBEAT intent must be
activated once every heartbeatInterval by the master Incall
instance to tell the slaves that it is still active on the device.
[0499] maxSleepTime is the constant, pre-defined maximum time that
should be allowed to elapse without any master Incall instance
asserting itself.
[0500] It is desirable that maxSleepTime-heartbeatInterval>10000
to ensure a sufficient number of random variations for the sleep
timer, thus staggering when each instance wakes up to ensure that
two instances don't wake up at the same time and both try to become
masters simultaneously.
[0501] If (and each time) the com.getincall.HEARTBEAT intent is
received, sleepTime is reinitialised to a random number in the
range heartbeatInterval+1 to maxSleepTime and the instance stays in
slave mode. This is because if a heartbeat is detected, then there
must still be an active master instance on the device.
[0502] If the heartbeat is not received, or if the app starts and
reads from preferences that it is the master, then it takes over
all the Incall responsibilities on the devices, such as displaying
ads, syncing and reporting. It also registers a BroadcastReceiver
to receive the com.getincall.RESIGN_MASTER intent, which can be
broadcast by any slave instance in order to force the resignation
of the master instance (for example, to enforce version precedence)
at which point it returns to a slaved state.
[0503] An example implementation is as follows: [0504] 1. An Incall
instance is installed on the device. It begins in slave mode,
listening for a heatbeat over a random interval. [0505] 2. No
heartbeat is received in that interval, so it now becomes the host
and starts broadcasting a heartbeat every heartbeatInterval. [0506]
3. Incall instance B is now downloaded and installed on the device,
and it too begins in slave mode. [0507] 4. Because B keeps
receiving the heartbeat from A within its sleepTime interval, it
stays in slave mode. [0508] 5. Incall instance C is now also
downloaded and installed on the device, also beginning in slave
mode. [0509] 6. Because C also receives A's heartbeat within its
(random) sleepTime interval, it too will stay in slave mode. [0510]
7. At some point, A is now uninstalled from the device, causing its
heartbeat to stop. [0511] 8. Because
sleepTime.sub.B.noteq.sleepTime.sub.C (since they were both chosen
randomly), either B or C will "time-out" before the other. [0512]
9. In this example since sleepTime.sub.B<sleepTime.sub.C, B's
timer ends first, so it now becomes the master and broadcasts the
heartbeat, which is received by C which then continues to run in
slave mode.
[0513] As pseudo-code:
TABLE-US-00008 const HEARTBEAT_INTERVAL = 1800000 // 30 minutes
const MAX_SLEEP_TIME = 2400000 // 40 minutes heartbeatReceived =
false isMaster = false function onFirstRun( ) { on Boot( ) }
function onBoot( ) { isMaster = preferences.read("isMaster") if
(!isMaster) { becomeSlave( ) } else { becomeMaster( ) } } function
onIntentReceived(intent) { if (intent = = "com.incall.HEARTBEAT") {
heartbeatReceived = true } else if (intent = =
"com.incall.RESIGN_MASTER") { becomeSlave( ) } } function
becomeSlave( ) { isMaster = false preferences.write("isMaster",
false) register_to_receive("com.incall.HEARTBEAT") do {
heartbeatReceived = false var sleepTime =
rand(HEARTBEAT_INTERVAL+1, MAX_SLEEP_TIME) sleep(sleepTime) } while
(!heartbeatReceived) becomeMaster( ) } function becomeMaster( ) {
is Master = true preferences.write("isMaster", true)
register_to_receive("com.incall.RESIGN_MASTER") do {
sleep(HEARTBEAT_INTERVAL) broadcast_intent("com.incall.HEARTBEAT")
} while (isMaster) }
ii) Log-Driven Algorithm
[0514] The log-driven algorithm is similar to the intent-driven
algorithm, but instead of using a decentralised algorithm and
waiting for real-time intents, it instead polls shared log file to
coordinate between the multiple Incall instances.
Advantages:
[0515] Simple--just a single shared file text file needed. [0516]
Traceable--can be used to store a record of
installations/uninstallations.
Disadvantages:
[0516] [0517] Log files must be stored outside of the app directly
(i.e. not in Internal Storage), leaving them open to user/other app
tampering or deletion. [0518] If log file is stored on SD card and
the card is ejected, the log is lost. [0519] Must poll log file on
disk which is inefficient (wastes CPU and battery). [0520] Void
period when transitioning between master instances caused by
polling interval.
[0521] Regarding implementation, upon installation, the Incall
instance checks for the presence of the log file and begins reading
it from top to bottom. If there is no log file, one is created and
the current instance records itself as the master and writes to the
log.
[0522] Each instance still uses a randomised sleepTime variable
like in the intent-driven algorithm, but the range is from
minPollingInterval+1 to maxPollingInterval where
maxPollingInterval-minPollingInterval>10000 to ensure a wide
number of values to ensure staggered polling between each
instance.
[0523] The master app is responsible for writing an entry into the
log file every minPollingInterval. Therefore, if after
minPollingInterval+1, no update has been made to the log file, then
similar to the heartbeat in the intent-driven algorithm, this would
be evidence that the master instance is no longer running on the
device, and clears the current instance to upgrade itself to master
status.
[0524] An example implementation is as follows: [0525] 1. At time
18877180, Incall-enabled app A (package name com.alpha.A) is
installed on the device and writes to the log file every
minPollingInterval=100000. [0526] 2. Another Incall-enabled app B
(com.alpha.B) is installed on the device and starts polling the log
file at randomised intervals within the above specified range.
[0527] 3. At time 19189243, A is uninstalled from the device, which
means that its last log entry is at 19177180. The log file looks
like this:
TABLE-US-00009 [0527] Time Master instance package name 18877180
com.alpha.A 18977180 com.alpha.A 19077180 com.alpha.A 19177180
com.alpha.A
[0528] 4. When B finishes sleeping and next polls the log file
(which happens to be at time 19178465), there has been no update
from A, and so B is able to upgrade itself to master mode. [0529]
5. B then updates the log file every minPollingInterval=100000,
which means that continuing directly from above, the next entries
in the log file appear as follows:
TABLE-US-00010 [0529] 19178465 com.beta.B 19278465 com.beta.B
19378465 com.beta.B
[0530] At some point it is necessary to prune the log to avoid it
becoming excessively long (this can be done after just a single
entry, as it is not necessarily required to maintain a long and
detailed history).
[0531] The above does not take into consideration: (a) contribution
of any metrics or extra information from the slaves to master
instance, and (b) decisions based on version numbers, etc. For this
reason, the intent-driven algorithm may be a more flexible and
decentralised alternative to the log files algorithm.
[0532] The pseudo-code is similar to that for the intent-driven
algorithm, only writing to the log file instead of a heartbeat, and
polling at random intervals instead of waiting random intervals for
intent broadcasts.
iii) Server-Driven Algorithm
[0533] The Server-Driven Algorithm involves each instance
interrogating the Android OS for the installed apps and monitors
for installations, uninstallations and upgrades and then
communicates that information to a server (via an API) and the
server then informs each instance whether it should be a master or
slave.
[0534] Unfortunately, Android does not allow an app to detect when
it is about to be uninstalled by the user, or take any actions when
the uninstall itself takes place. However, all apps can retrieve a
list of the package names of currently installed on the device, and
all apps other than the one being installed/uninstalled/upgraded
can listen for the following intents: [0535]
android.intent.action.PACKAGE_ADDED [0536]
android.intent.action.PACKAGE_REPLACED [0537]
android.intent.action.PACKAGE_REMOVED
[0538] Each Incall instance sends these package names to the server
(which maintains a list of package names which are enabled, ordered
by precedence) and the server then responds to each instance
whether it should be a master or slave.
Advantages:
[0539] Instant switching between instances, because this approach
is event-driven by monitoring for the actual package
install/upgrade/remove operations (and therefore more efficient),
there is no need for polling. [0540] Because decisions are made by
the server rather than on the device itself, it would be very
difficult for a malicious third-party app to interfere with this
process.
Disadvantages:
[0540] [0541] Entire app package list must be sent to the server,
which could be a privacy concern (could send package hashes
instead, but this would still be a privacy issue). [0542] Server
must maintain list of package names, versions, precedence, etc.
which requires extra server-side logic. [0543] Internet connection
is required to determine mode each time a package operation takes
place.
[0544] In terms of implementation, the app registers to receive the
intents [0545] android.intent.action.PACKAGE_ADDED [0546]
android.intent.action.PACKAGE_REPLACED [0547]
android.intent.action.PACKAGE_REMOVED in order to check when the
package list changes, and also immediately sends the package list
to the server along with the name of the current instance's package
name.
[0548] The server then cross-references this information against
its stored package list, ignores any packages which are not
Incall-enabled and uses a priority list to report back to each
instance whether they should be the host or not.
[0549] Since each Incall instance on the device carries out these
identical steps, it is not necessary for the server to actually
maintain any state for each Incall instance, only to maintain an
ordered package list of all Incall-enabled apps.
[0550] An example implementation is as follows: [0551] 1. A
(com.alpha.A) is installed on the device (which is an
Incall-enabled app). It registers to receive the package
add/replace/remove intents, and then sends its package list to the
server, which consists of [com.magnum.Fighter,
com.facebook.Facebook, com.alpha.A] along with its own package name
(com.alpha.A). [0552] 2. The server receives the instance package
name and full package list and cross-references it against its own
package list. [0553] 3. In this case, com.alpha.A is the only
installed app which is an Incall instance, so the server API
responds telling the app to become the master. [0554] 4. At some
point in the future, a second Incall-enabled app B (com.beta.B) is
downloaded and installed on the device. [0555] 5. At this point,
the android.intent.action.PACKAGE_ADDED intent is received by A,
which fires off a server request with the new package list
[com.magnum.Fighter, com.facebook.Facebook, com.alpha.A,
com.beta.B] to the server. [0556] 6. At the same time, B is
initializing, so it also sends its package name and the same
package list to the server. [0557] 7. B incorporates a newer
version of Incall (we can assume that the app version is sent along
with the package name), so com.beta.B is higher on the server's
priority list than com.alpha.A.
[0558] 8. Therefore, the server responds to A telling it to become
a slave, and to B telling it to become the master.
[0559] In Pseudo-Code:
TABLE-US-00011 isMaster = false function onFirstRun( ) {
register_to_receive("android.intent.action.PACKAGE_ADDED")
register_to_receive("android.intent.action.PACKAGE_REPLACED")
register_to_receive("android.intent.action.PACKAGE_REMOVED")
determineMode( ) } function onBoot( ) { // Do nothing } function
onIntentReceived(intent) { determineMode( ) } function
determineMode( ) { packages = Device.getPackages( ) response =
API.call("packages", [App.packageName( ), packages]) if (response =
= "master") isMaster = true isMaster = false }
iv) On-Boot Intent
[0560] In this alternative, when the device boots up (or when a new
instance is installed), all apps broadcast intents and the system
then automatically gives precedence to the latest version of Incall
(or some other rule to ensure a consistent precedence between all
instances).
[0561] Allocation of Revenues
[0562] In order to resolve the problem of how to allocate
advertising revenues per impression/click-through at each incoming
or outgoing call event between n developers when n incall/outcall
SDKs are installed on a given handset, the following algorithm is
provided.
[0563] Incall uses an algorithm which takes as inputs handset and
SDK Application (this is an application on a given handset which
contains the incall/outcall SDK) end user metrics. Parameters are
also defined which assign a weighting to each metric. This
weighting and the input metrics are then used to calculate a score
for each SDK application on a given handset and then allocate
advertising revenue.
[0564] The algorithm is continuously optimised to ensure an
efficient, fair, and commercially viable distribution of funds
across SDK Applications.
[0565] An example list of inputs to the algorithm--specifically to
allocate revenue--is as follows (assuming that all of the required
user/phone identification metadata is available and accounted for):
[0566] Date/time when host app was first installed [0567] Date/time
when host app was last run [0568] Total duration of host app
running [0569] Frequency of host app launches [0570] App category
[0571] History of ad impressions (and factors associated with those
historic ads, if you choose to store them) [0572] History of ad
clicks (and factors associated with those historic ads, if you
choose to store them [0573] App rating [0574] App download numbers
(very approximate)
[0575] An example weighting output is as follows:
[0576] For two Host Apps on a single device, .English Pound.100
pounds of revenue to allocate
[0577] Total Duration of App run time=75% weighting
[0578] Total of launches=25% weighting
[0579] App A: 10 hours 100 launches
[0580] App B: 2 hours 500 launches
[0581] Calculation:
TABLE-US-00012 App Weight App A B A+ B Duration 0.75 10 2 12
Launches 0.25 100 500 600 B % A % of of A B Weight A + B A + B
weighted weighted Duration 0.75 0.83 0.17 0.63 0.13 Launches 0.25
0.17 0.83 0.04 0.21 A B Total Total Duration 62.50 12.50 Launches
4.17 20.83 TOTAL 66.67 33.33
Alternatives & Modifications
[0582] App Tokens
[0583] In some embodiments, "app tokens" are used instead of "API
keys" to allow the association of clicks with (host) apps (of which
a developer may have many), rather than clicks for each
developer.
[0584] Input Metrics
[0585] Broadly speaking there are three types of algorithmic inputs
(or metrics): [0586] 1. Point-in-time metrics--these are acquired
at the time an incoming call event occurs, and involve the app
being brought to the foreground capturing various data, primarily
the incoming call number, but also other data such as GPS
information. [0587] 2. Long-period metrics--this is collected over
longer time periods. The app may, for example, install a background
service to, say, periodically check GPS coordinates. Alternatively,
the app may use the call log to determine what numbers have been
called or from what numbers calls have been received. [0588] 3.
Personal metrics--this comprises information which is collected
from personal data in the phone itself, such as the phone
directory, or text messages.
[0589] The metrics acquired are those which may be used to better
select the media content item(s) to present to the user. Some
embodiments may however also collect and make use of more esoteric
information, such as that acquired from accelerometers.
Examples of Metrics Include:
[0590] General [0591] Current date/time [0592] Current phone number
on the device (if verified--ideally there should be an SMS
verification process to prove the number is valid as getting it
from the device programmatically may be unreliable) [0593] Device
operating system and version [0594] Device model and manufacturer
[0595] IP address(es)
[0596] Location Services [0597] GPS location (current) [0598] GPS
location traces/history (this may be collected in background,
preferably infrequently so as not to drain the device battery)
[0599] Incoming Call [0600] Phone number (this can also be
cross-referenced against the call log) [0601] Country/region/area
of caller (derived from phone number) [0602] Whether the number is
in the user's contact list or not.
[0603] Call Log [0604] Numbers of callers and callees historically
[0605] Date, time and duration of calls (also frequency)
[0606] Host App Information (the app which is "hosting" the
augmentation app) [0607] Date/time when host app was first
installed [0608] Date/time when host app was last run [0609] Total
duration of host app running [0610] Frequency of host app launches
[0611] Any other developer-defined metrics fed out from the host
app (can leave up to developer to decide, for example this could
include app category, etc.)
[0612] SDK Information [0613] History of ad impressions (and
potentially factors associated with those historic ads) [0614]
History of ad clicks (and potentially factors associated with those
historic ads) [0615] Other metrics defined by the system (for
example, advertisers could pay more for a higher "priority"
metric)
[0616] App distribution system metrics (can be retrieved by
scraping the site) [0617] App rating [0618] App download numbers
[0619] App category
[0620] Display Options
[0621] When the item of media content is overlaid onto the dialler
when an incoming call is received, there are many possible options
for how the media content is displayed, including for example one
or more combinations of the following: [0622] only part of the
incoming call screen image is overlaid such that the caller ID can
still be viewed and the call can still be answered and interacted
with in the usual manner [0623] the entire incoming call screen
image is overlaid and call interaction and ID functions may be
provided within the media content image [0624] the item of media
content replaces, rather than overlays, the incoming call screen
image [0625] the item of media content modifies the incoming call
screen image to enable display of the media content alongside,
embedded in, or in any other way along with the incoming call
screen [0626] the media content item may be partially transparent,
allowing an animated shape to move across the screen while the rest
of the incoming call screen, the space outside of the animated
shape, remains visible to the user [0627] the media content item
may be implemented as an overlay as a floating, resizeable (within
limits) view that can be customised to the user [0628] a customised
caller ID system is implement as part of the media content overlay,
potentially leaving only the call accept/reject buttons
unchanged
[0629] Where it is not possible to have the overlay cover the
entire screen (for example, because APIs are prevented from
overriding the default call accept/reject actions) the media
content item display is implemented as a floating overlay which
covers only part of the screen and leaves the call accept/reject
buttons exposed.
[0630] Media Item Ordering
[0631] The items of media content may be sent from the application
to be displayed on the screen one by one--in a specified order, or
selected at random, or in a combination of random and specific or
prioritized order using any algorithms--or multiple items may be
sent and displayed on the screen at once.
[0632] Audio Media
[0633] It is also possible to add a custom ringtone or sound
effects to the overlay, which can either supplement the device's
ringtone, or replace it entirely. That is, where the item of media
content comprises an audio clip such as music, speech or any audio
file, which may or may not be accompanied by an image or video
clip, the audio clip is played by the loudspeaker in place of the
usual ringtone played by the mobile device upon receipt of a call.
The ringtone may be intercepted, replaced, overlaid, delayed until
after the audio file, or otherwise interrupted.
[0634] Cache-Less Devices
[0635] In some embodiments there may be no local cache and the
phone may remotely download at least one item of media content from
the server upon each media content request. It will be appreciated
that it may take longer to first download and display an item of
media content than it would to display one stored locally.
[0636] Outgoing Calls
[0637] In another embodiment, media content is displayed when the
device user makes an outgoing call to a second party. In this case,
the operation is as described above with the exception that the
notification sent by the dialler to the application is sent upon
occurrence of an outgoing call event rather than an incoming call
event, and the image overlaid by the advertisement is the outgoing
call screen image and/or presented when the outgoing call is
completed, say for a present amount of time.
[0638] This functionality may be provided within the same SDK as
described in relation to the system for processing incoming calls.
In some embodiments, the outgoing call feature may be linked to the
incoming call feature; hence the incoming and outgoing call screen
images may also be related.
[0639] Syncing
[0640] The system maintains two separates databases--the main
database on the server side, and a smaller database on the phone
(cache) which stores a subset of adverts to display to the
user.
[0641] Periodically, the two caches are "synced" whereby the client
purges its cache and acquires fresh media content items from the
server.
[0642] In some embodiments, the sync time is kept short. This may
not be an ideal solution in all circumstances as sync events are
not guaranteed e.g. a user may be roaming and have their data
connection turned off etc.
[0643] Furthermore, because the server-side database can be edited
in real-time and the client-side database only fetches those
updates periodically, there are cases where the two databases can
end up out of sync. For example, if the server has items {A, B, C,
D, E, F, G}, the client downloads adverts {B, D, G} into its cache,
but then the owner of B logs into the online system and deletes
advert B from the system. This is handled in the following possible
ways: [0644] 1. B is not fully deleted from the server-side (no
items are ever fully deleted), instead the item is just flagged as
"inactive". Until the next sync, item B is still shown as usual,
and even clicking on B will take the user to B's website, but the
click is not actually recorded in the database and therefore the
owner of B is not charged, although has free advertising--while the
developer makes no money. [0645] 2. When B is deleted from the
server-side, as before it is flagged as inactive. When the user
clicks the advert, the system checks if the advert is active. If it
is flagged as inactive, the advert is not loaded and no click is
recorded. This also provides B with free advertising (even though
the ad cannot be clicked, it still appears on the handset). [0646]
3. As a variant of 2), if an advert is clicked which is found to be
inactive, it is deleted from the cache and not shown again. This
gives B one free click per user, and even though the target URL is
not loaded, B is still getting free impressions.
[0647] The situation where an advertiser edits their advert (rather
than deleting) is less problematic, but they will need to wait for
their edits to propagate through the entire Incall user-base, as
there is no way of pushing updates to the users--rather, the update
will only take place once the periodic sync takes place.
[0648] In some embodiments, rather than have a feature to delete
ads from the system, instead each advert just has an expiry time
which is part of the advert. Therefore, when the client sync with
the server it gets the expiry time of each ad, which means that
adverts can expire locally without needing to wait for the next
sync (because the phone can always check the advert expiry time
against the phone's current time).
[0649] Therefore, once an advertiser sets an expiry time for their
item, that expiry time is locked and cannot be changed. The clients
will then start downloading the ad and the ad will expire at that
time. Of course, the expiry time can then be extended (and on the
next sync, the expiry will be extended on the client too), but the
expiry time cannot be shortened (because we cannot guarantee that
there will be a sync event between now and whenever the earlier
expiry date is.)
[0650] The only vulnerability in this is that technically speaking
the user can adjust the time/date on their phone which may result
in some anomalous outcomes.
[0651] Reporting/Feedback
[0652] In some embodiments, the user interaction with the displayed
item of media content is reported to a remote server, either in
real-time or stored and reported periodically. This feedback may
assist in distributing revenue to advertisers and developers.
[0653] The system can either be used to track clicks only, or to
track clicks and impressions, depending on whether a delayed
reporting model, or live reporting is used. The difficulty with
tracking impressions is that this data must be stored locally and
then transmitted at a later date. Variants track impression data or
only clicks.
[0654] As shown in FIG. 9, the media content may include two or
more buttons, one of which can be used to take up a presented offer
and one of which can be used to reject this offer. In this case,
the clicks on each button are tracked separately. This feedback may
assist in providing user response to offers.
i) Delayed Reporting
[0655] In the delayed reporting model (which works well for
impressions, and also removes the need for a redirect page), all of
the tracking is done locally on the device, and an aggregated
report is periodically pushed to the server.
[0656] The problem with this approach is that it makes the system
more vulnerable to click fraud, and is also more technically
challenging to implement. [0657] The SDK locally stores information
about which advertisements have been served (impressions) and which
have been clicked [0658] The SDK periodically pushes to the server
a JSON-encoded click report which contains the following
information: [0659] Authentication information & meta-data
about the app and report (necessary to establish an audit trail)
[0660] Detailed click report [0661] The report is JSON-encoded and
pushed to the server API via a SSL secured connection [0662] The
authentication information includes the "app ID" (in order to trace
clicks back to their host apps for payment purposes), along with
the "instance ID" (which tracks the clicks for that specific user)
[0663] The detailed click report shall consist of the date range
for the current report, and also include a list of each
advertisement and how many times it has been clicked:
TABLE-US-00013 [0663] Impressions Clicks 10012 4 2 Virgin Atlantic
10048 3 0 Coca Cola 10078 2 0 Nike 10102 8 1 T-Mobile
[0664] An example of a JSON-encoded click report is as follows:
TABLE-US-00014 [0664] { "app_id":"jMnwWXmmaOqp",
"instance_id":"yUXnswIqw", "report_id":7 "report_from":1355213918,
"report_to":1355925596, "metrics":{ 10012:[4,2], 10048:[3,0],
10078:[2,0], 10102:[8,1] } }
[0665] The click report is sent from the SDK to the server at
periodic intervals, when an internet connection is available [0666]
Once the click report has been successfully delivered from the SDK
to the server, the local click data is purged and the local click
data store is reset.
ii) Live Reporting
[0667] In a live reporting system, when an advert is clicked the
user is not sent directly to the advertiser's site, but is first
sent to an Incall-controlled redirect page (along with the
instance_id to prevent click fraud--or preferable, a one-time code
based on the instance_id), where the click is recorded in
real-time, and the user is then seamlessly redirected straight on
to the advertiser's page. [0668] 1. User clicks advert [0669] 2.
User is taken to redirect page and click is recorded. [0670] 3.
Redirect complete, user is now on advertiser's page
[0671] This is a more tried-and-tested approach, and the main
advantages of this approach are that it is more difficult (and less
effective) to try and commit click fraud on this type of system and
also that all click information is available in real-time. It also
means that the advertisers can adjust which page their advert links
to by editing the redirect on the server rather than having to push
out a new set of adverts.
[0672] To prevent replay attacks (which could result in click
fraud) a one_time_instance_id is preferably used which is generated
from the instance_id. [0673] When an advert is clicked, the SDK
shall direct a user to the appropriate hardcoded redirect site,
along with the ad_id and one_time_instance_id. [0674] The redirect
page shall then validate the one_time_instance_id and log the
relevant click. [0675] The redirect page shall then redirect the
user on to the advertiser's target web page based on the ad_id.
[0676] Third-Party App Integration
[0677] In some embodiments, the app (and/or SDK) is configured to
allow (permitted by contract) third parties to integrate the
call-augmentation features within their own app as installed on
user devices. Hence, when a call is received by the user device
from the company, the app on the user device presents
company-specific media content to the user. This may be in the form
of a company logo, banner, advertisement and/or ringtone--and
presented at the outset, during and/or conclusion of the call.
[0678] Post-Call Events
[0679] In some embodiments, the app may be adapted to perform
certain actions or events after a specific call concludes. For
example, after a call from a specific company, a screen may be
displayed requesting the user complete a survey based on their
experience of the preceding call. This may be provided via another
application or via a link to a website hosting the survey.
[0680] Use of Temporary Internal Numbers
[0681] In an example, companies may assign a new (internally owned)
telephone number to a customer for a specific amount of time, this
number will, if called or texted, automatically forward all calls
or messages to actual customer number. This is useful as it limits
the digits that need screening.
[0682] Outbound or Augmented IVR
[0683] Whereas in a normal IVR system the caller is required to
navigate a sometime labyrinthine audio menu system, in some
embodiments the app works in tandem with the IVR to augment the
caller experience.
[0684] The augmented IVR service is triggered when calling a
predefined number. This may be done, for example, via the SDK
bundled with a third party app installed on the user handset
monitoring outbound calls and activating the augmented IVR
experience for calls placed to a predefined number or numbers.
[0685] An audio menu is activated which explains to the user that
there is content on the end users screen Preferably, the app
detects whether the device is operating in hands-free mode so as to
play the audio via the device loudspeaker(s).
[0686] As the caller listens to the audio menu the app presents
related options on-screen. These options may be the same as or
different to the audio menu options. The caller may for example
select from yes/no options eg. "New customer?" or make more
specific selections eg. "Sales or technical support?" thereby
navigating the IVR menu via the device, for example via a
touchscreen.
[0687] For a roadside vehicle assistance/recovery embodiment the
call may proceed as follows (bold CAPITALS indicate user choice):
[0688] i) New Member or EXISTING MEMBER? [0689] ii) Are you calling
because you've BROKEN DOWN or is it something else? [0690] iii)
Kindly enter you membership number or number plate or are you a
PREMIUM BANK CUSTOMER? [0691] iv) Please enter you sort code
account number dob and post code . . . thanks [0692] v) Are you in
a hazardous place (ie. motorway/main road) or are you in a SAFE
PLACE? [0693] vi) are there any children with you Yes or NO? [0694]
vii) Kindly confirm make and model of car. [0695] viii) You are now
being connected to the appropriate member of staff. Your
loudspeaker will automatically turn off. Please hold you handset to
your ear.
[0696] Other options may for example trigger a call back when an
operator is available, allow the caller to request a call back, or
to start an online chat.
[0697] For the roadside vehicle assistance/recovery embodiment
other options may include: arranging a specific time on the call
screen for a call back or for handset to automatically self-call to
a newly loaded direct-dial number for the appropriate member of
staff. In some embodiments the calling or third party could
communicate back via online chat on the display or display an
on-screen wizard with instructions for the user to perform certain
simple vehicle checks.
[0698] One advantage of this augmented IVR is that it integrates
seamlessly with the user experience via the app, ie. it does not
need to be launched separately, say via a company website support
forum or during a call from within a website or app. Another
advantage is that the IVR menu may be immediately tailored to the
specific caller. This may be particularly beneficial to large
companies with high volume subscription of the company app.
[0699] This IVR functionality may be provided as a stand-alone
feature or optionally in combination with any of the example
embodiments described herein.
[0700] Smart Warm Calling
[0701] In some embodiments, the media content item provides
information from or relating to the second party in the call to the
user. This may allow a second party to identify themselves or
provide other relevant information to the user when the second
party calls the user, or when the user calls the second party. The
second party in this case may, for example, be a bank providing
information about customer support services or advising how to
contact such services. Alternatively, the second party may be a
vendor providing information about their products. Embodiments may
be used in conjunction with a telephone conversation about
products, providing a way for vendors to "warm call" potential
customers, as opposed to traditional cold calling. Preferably, this
example may be provided in the case where a user has previously
installed an app associated with the vendor on their handset. In
this case, the vendor's app may serve as the "host" app for the
call augmentation system/software, which may periodically download
new information as previously described.
[0702] In certain embodiments, the user may interact with the
second party in the call via the media content item, or otherwise
provide feedback via the media content item. In the case where the
call is an incoming call, this is referred to generally as "smart
warm calling".
[0703] FIG. 12 shows an overview of a telephone call augmentation
system 1000 for "smart warm calling". This differs from the similar
system shown in FIG. 1 in that the media server 30 is in
communication with both the client device 10 (to serve media
content to device 10) and the second device 150. The media server
30 may be in communication with a plurality of client devices 10,
as shown. The second device 150 may be a call-placing device, a
telephone or a wider telecoms system, which may be configured to
place a large number of calls to a plurality of client devices 10
over a communications network 20. For example, the second device
150 may form part of a call centre.
[0704] Along with serving items of media content, the server 30 is
also used to supply feedback from the user's interaction with the
supplied media content at the client 10 to the second device 150,
and also may be used to coordinate the supplied media content with
the calls made by the second device 150 to the client device
10.
[0705] The hardware used by the client device 10 in the "smart warm
calling" system 1000 may be understood by reference to FIGS. 3 and
4, with the difference that the callerID may be supplied via the
app 100 rather than the dialler 114, as will be described later
on.
[0706] FIG. 13 shows an example of "smart warm calling" telephone
call augmentation. As shown in FIG. 13, the media content item 101
provided on the incoming call screen is provided with a number of
buttons 301 providing hyperlinks to allow the user to indicate that
they are unwilling or unable to take an incoming call and to
specify a time at which they would like to be called back.
[0707] As shown in the figure, the item of media content 101 may
further comprise an indicator 302 as to what subject, topic or
content the second party plans to talk about during the call. This
may comprise text, images, or video, for example, and may
additionally comprise audio. Optionally, this audio may replace the
device's conventional ringtone. The user, upon receiving a call, is
therefore made aware of the subject of the call and thus is more
likely to answer it than if he or she receives an unsolicited call,
even if they know who is calling. The indicator 302 may also
comprise account details in the case where the user is a customer
of the calling party, such as account balance, remaining
minutes/text/data, delivery time, or date/time of a planned visit
(for e.g. meter testing or broadband installation).
[0708] In this regard the callerID/name 303 of the second party is
preferably presented to the user alongside the item of media
content 101, where the callerID/name 303 replaces or appears in
addition to the telephone number as would occur normally for
contacts in a user's address book. In the case where the second
party's name is not listed as a contact in the user's address book,
the second party's name may be added to the user's address book.
Alternatively, a different indicator of the identity of the second
party may be provided in place of their name 303, such as a
trademarked logo or sound.
[0709] Although the user will be far more likely to answer a "warm
call" (when they know who the call is from and what it is about)
rather than a "cold call," they may be unable to pick up the call
due to them being busy, or it being an inconvenient time for other
reasons. The buttons 301 are provided on the item of media content
to enable the user to indicate when they would prefer to be called
back. As shown in FIG. 13, a variety of options for different times
may be provided. The options defined by the buttons 301 are defined
by the provider of the media content. Alternatively, a single
button 301 may be provided for the user to indicate that they would
like the call to be deferred (for example, showing a message
similar to "call me back in 10 minutes"). In some situations, users
may be more likely to interact with the item of media content 101
when a single button is provided rather than a plurality of
buttons. Optionally, a press of a button 301 may also cause the
device to hang up on the incoming call, or may present the user
with an option to hang up the call.
[0710] Other messages to the second party which may, optionally, be
provided by the buttons 303 include: [0711] Never call me again
[0712] I prefer to be contacted via text/email [0713] I never want
to be called at this time [0714] Call me back in the
morning/evening [0715] I am not interested in talking to you about
[this specified subject] [0716] I would be interested if you are
calling about/will call back about [another subject]. (i.e. a `menu
of options`, as will be described in more detail later on.)
[0717] The buttons 301 may also provide a number of `quick
responses` to the subject of the call, as indicated by the
indicator 302, so that the user can quickly reply to the calling
party if they are unwilling or unable to discuss the subject in a
phone call. For example, if the user has made an appointment with a
doctor (or other specialist) via a centralised app, the doctor may
call the user if they need to reschedule the appointment. This is
indicated to the user by the indicator 302, and the user may be
provided with a number of alternative appointment times (which
could be informed by the content of the user's calendar app,
provided that the user has previously indicated that the app may
access the native calendar app on the device) via the buttons 301.
If the user does not want to take any of the suggested appointments
or wishes to discuss the matter in detail, they can simply answer
the phone and rearrange the appointment during the call.
[0718] The second party may then call the user back at the
specified time, contact the user via another communication channel
(such as email), or simply log the data in order to build up a
model of when all users or the specific user prefers to be called
and/or the topics of specific interest to them. Alternatively or
additionally, when a button 301 is pressed, calls from the second
party may be blocked for the specified time period, ensuring that
the user does not receive a call from the second party during this
time period. Alternatively, the system 1000 may be arranged to
cause the user's device to place a call to the second party at the
specified time. In this case, the user may be alerted that this
call will imminently take place by a tone or other notification,
and may be provided with a further item of media content 101 on the
outgoing call screen with which they may interact to further defer
the call, select an exact time at which they wish to be called
back, or select another option.
[0719] This system 1000 is particularly useful for companies
offering special offers via telephone, as in the example shown in
FIG. 13.
[0720] This system 1000 could also be applied to personal calls, or
any other type of telephone call where the calling party is known
to the user, for example, but not exclusively, when the calling
party is not listed as a contact in the user's address book. In
some embodiments, the calling party may provide information, such
as an indication of the subject of the call, by way of text or an
image (for example an emoticon), ahead of the call thereby allowing
the callee an opportunity to decide whether or not to take the
call--or indeed to have a moment to prepare for the call.
[0721] FIG. 14 shows another example of "smart warm calling"
telephone call augmentation, in which the user is provided with a
survey 304 or other list of options.
[0722] In this example, the media content item 101 provides a means
to engage with users, which may make them more likely to accept the
call. The option chosen is reported to the second party as
previously described, and may feed into the content of the
subsequent call--for example, the survey 304 may ask the user which
model of phone they would like in their upgrade, which might then
be discussed in the call with a sales representative. This survey
304 might also be used for market research, allowing the user to
provide feedback about the level of service they receive, for
example. The survey 304 may be presented alongside the indicator
302 of the subject of the call or without this indicator 302,
depending on use. Where no indicator 302 is provided, this function
may be used to provide the user with a menu of options of what is
to be discussed during the call, in which case the option selected
may be used to assist with connecting the user to an appropriate
sales representative or branch of an IVR (interactive voice
response), for example. This menu of options may alternatively be
provided by a third party. The survey 304 may alternatively be part
of an ongoing advertising campaign, or similar, and is provided to
raise awareness.
[0723] An alternative function of this telephone call augmentation
may be used to generate inbound calls to relevant sections of a
call centre, where a button press causes the current call to end
and a new call to be placed from the user's device to the call
centre. In this case, the sole purpose of the incoming "smart warm
call" is to encourage the user to press a button and thereby make
an inbound call back to the call centre.
[0724] User interaction with a button 301 on an item of media
content 101 may cause a second item of media content 101 to be
shown, which may provide a further menu of options. This may be
useful for allowing a user to provide further detail about their
instructions or preference. For example, if the user indicates
their favourite model of phone in response to a survey 304 provided
as an item of media content 101, the second item of media content
101 may be used to allow the user to pick a reason why they prefer
that model of phone.
[0725] The item of media content 101 may also provide a button 301
giving the user the option to `live chat` rather than take the
call. User selection of this button may cause the incoming call to
be cancelled or hung up and trigger the launch of a realtime online
chat window or program, allowing the user to converse with the
caller or a representative of the caller. The chat window or
program may be accessed via an external application or may be built
in to the application providing the "smart warm calling"
functionality. The chat window or program may provide the ability
to add new users into the conversation and allows files to be
transmitted bi-directionally.
[0726] The item of media content 101 may also provide a button 301
giving the user the option to convert the call into a Voice over IP
(VoIP) call. User selection of this button may cause the call to be
cancelled or hung up and may automatically trigger a call-back via
a VoIP service, such as Skype or Viber. Alternatively, the user's
device may place the call out to the original second party, where
the second party's VoIP contact details are provided with or
associated with the item of media content 101.
[0727] It will be appreciated that the features of the system 1000
shown in FIGS. 13 and 14 may be combined, and that further features
according to other examples as shown in FIGS. 6-9 or as described
above may be incorporated into the "smart warm calling" interface
shown in FIGS. 13 and 14. It will also be appreciated that the
features of the system 1000 shown in FIGS. 13 and 14 may be used in
the previously described example of the system 1 as shown in FIGS.
6-9, with the user being able to provide feedback to the third
party providing the media content (or initiate a chat session or
convert the call to a VoIP call, as described).
[0728] It will be appreciated that the buttons 301 provided on the
item of media content 101 as input means may be replaced or used
alongside a variety of alternative input means, which may include
the detected orientation of the device (where turning the device
face-down means `call me back in an hour`, for example), a detected
gesture made by the user, an audio command, shaking the device, a
drawn pattern or swipe on the screen, or a signal from an auxiliary
device configured to communicate with the device. In particular,
the user may manipulate a dial or clock hands displayed on the
device or on an auxiliary device to specify the time at which they
would like to be called back. The item of media content 101 may
also comprise a slider allowing the user to quickly and precisely
communicate a quantity, rather than picking from a number of
discrete options provided by buttons. This may be particularly
useful where the user is asked to specify a call-back time or is
asked how much they would be willing to pay for an item as part of
a survey, for example. The slider may extend from a minimum of 5
minutes to a maximum of 24 hours, for example, when the relevant
quantity is time.
[0729] The `clicks` or user selections of each button 301 are
tracked and reported separately as previously described. `Clicks`
may be recorded and subsequently sent to the second party. The item
of media content 101 may indicate to a user that a button has been
pressed, such as by highlighting the button. An interaction with a
button may also prompt the user to be shown a message, which may be
a simple confirmation that their engagement has been noted or may
encourage them to answer the call, for example.
[0730] When a button 301 is pressed, the second party may be
alerted as to the option chosen by a number of possible means, such
as a text message, an email, or by sending a signal over a data
connection to a server operated by the second party and identified
by a URI associated with the button 301. Preferably, live reporting
(as described above) is used, so that user feedback can be
integrated into the subsequent phone call (for the case when a user
provides feedback and then answers the call).
[0731] Preferably, the display of an item of media content 101
causes an indication to be produced, which is then reported to the
second party at a later date, such as when new items of media
content 101 are downloaded. Alternatively, this may be reported
live, as previously described. This indication may be associated
with the item of media content 101 and stored in the cache, for
example, until such time that it is reported. The purpose of this
indication is to prove to the second party that the desired item of
media content 100 was indeed shown to the user on the call screen
for the relevant call.
[0732] As previously mentioned, the user may also choose to receive
"smart warm calls" rather than accept advertising within an app.
These calls may be from third parties with some access to the
user's data, either via the app or via alternative means.
Implementation
[0733] For "smart warm calling", the app used as part of the system
1000 is configured to recognise `qualifying phone numbers` that are
saved onto the device's memory. An index of these `qualifying phone
numbers` may be downloaded to the device when new items of media
content 101 are downloaded to the device 10. Alternatively, this
index may be downloaded to the device periodically or in response
to a forthcoming call event. Optionally, these qualifying phone
numbers may be provided via a separately downloaded piece of
software. Media content items 101 are downloaded to the device
prior to the call. The items of media content 101 according to the
examples shown in FIGS. 13 and 14 may be stored in a cache, as
previously described, and displayed when an incoming call from a
qualifying number is detected by the app (which may run as a
background service, as previously described).
[0734] The second party may be able to control when new media and
rules for display are pushed to user devices 10 and when they are
removed. The app on the device 10 is configured to check the server
30 to see if any new items of media content 101 should be
downloaded and to see if any should be removed every time the
server is accessed. This may occur every time a user accesses
and/or logs in to the app used as part of the system 1000. For
example, for a banking app, new items of media content 101 may be
downloaded every time the user checks their balance. As described
above, in some embodiments, the mobile device 10 may also
periodically access the remote server 30 and download updated media
content. The frequency of accesses the sever 30 by the device 10
can be changed by the provider of the app, and may also change
subject to other actions.
[0735] Each item of media content 101 may be flagged with an
"expiry date" as previously mentioned. This is especially relevant
to items of media content associated with a limited-time promotion,
which are then removed when the promotion expires.
[0736] FIG. 15 shows an example implementation in flowchart form of
an application according to the present invention used for "smart
warm calling". [0737] S1. When an incoming call is detected, an
incoming call event is triggered by the operating system and the
dialler sends notification of the incoming call event to the
application 100. [0738] S2. The phone number is checked against the
list of qualifying phone numbers--if it matches, the application
100 seeks to display an item of media content 100. If not, the
application 100 takes no further action. Another instance of Incall
may take over at this point. [0739] S3. The application 100 looks
up the item of media content 101 to be displayed. This is
preferably predetermined, as will be described later on. [0740]
This may involve the application sending a media content request
102 to the cache. Upon receipt of the media content request the
cache sends the media content item 101 to the application 100.
[0741] S4. The item of media content 101 is displayed on the call
screen. [0742] S5. The user may interact with the item of media
content 101 as described above. [0743] S6. If an interaction is
detected, information related to this interaction is recorded and
is transmitted to the second party. [0744] S7. The user may
interact with the item of media content 101 while the phone is
ringing, that is, up until such time that the call is accepted,
rejected, or times out [0745] S8. The item of media content is
hidden at this point. [0746] S9. The app may then terminate itself.
Alternatively, the app may remain in the background for the
duration of the call and then perform an action (such as reporting
feedback or opening a hyperlink) following the termination to the
call, as previously described with reference to FIG. 5.
[0747] The media content items 101 downloaded by the device from
the server 30 may be based on a profile of the user, which may be
informed by prior feedback provided by the user interacting with
the media content items 101. The information included in his
profile may also comprise network operator/tariff, device model,
other apps on device, call frequency/text frequency/data usage,
volume of changes of location, battery size, and number of
contacts, among many other options.
[0748] Where a cache 112 is used, the media content items 101 in
the cache 112 may be updated as described above. However, for large
download file sizes, such as where many complex media content items
101 are downloaded, the download of the media content items 101 may
be integrated into an update of the app used as part of the system
1000. Where the user's permission is required to update the app,
this could be requested via a button provided on an item of media
content 101 in a "smart warm call".
Multiple Instances
[0749] In an example, where an app providing the "smart warm
calling" functionality is provided this app will always take
precedence such that the item of media content associated with the
"smart warm call" will always be displayed on the call screen in
place of an item of media content supplied by another app. This can
be implemented in a number of ways, such as by putting the phone
number(s) associated with a smart warm call on a whitelist
associated with the other apps, checking to see if the app
providing "smart warm calling" responds to a call before launching
other apps, or by making the app providing "smart warm calling" the
`master` according to any of the models listed above with reference
to providing support for multiple parties.
[0750] Where multiple instances of "smart warm calling" are present
on a device, the incoming phone number will be checked against all
open instances of client applications using smart warm calling in
order of `last time application used`, before then reverting to
Incall applications without "smart warm calling" functionality, if
provided. As soon as a phone number is recognised by a client
application using "smart warm calling," a media content item 101 is
displayed and the number is not searched against additional
instances of the software used as part of the system 1000 provided
on different apps.
External Sync
[0751] The item of media content displayed when an incoming call is
detected may be chosen according to the algorithms described above,
but in many situations it is advantageous that the item of media
content 101 to be displayed is coordinated with the planned content
of the incoming call, so as to maximise the relevance and
usefulness of the item of media content 101 and to provide a more
integrated user experience.
[0752] FIG. 16 shows an example method of coordinating the content
of the phone call and the item of media content to be displayed. In
this method, the media content items are downloaded into the cache
with an associated identifier (S1), the identifier being a property
of the call. This property is preferably the suffix to a qualifying
phone number. This association may be made at an optional `priming`
stage (not shown) or may be provided together with the media
content item as part of the index of qualifying phone numbers. When
a call is detected (S2), the app compares the relevant property of
the call against the media content item identifiers (S3) and
identifies the appropriate media content item (S4). This media
content item is then shown on the call screen (S5). This method is
preferred because it allows the item of media content to be
effectively and simply coordinated with the planned content of the
phone call, but requires a relatively high level of telecoms
infrastructure.
[0753] Optionally, an exchange of information takes place prior to
a "warm call" being placed. This `priming` stage occurs before S1
shown in the flowchart of FIG. 15, and provides an alternative
means of specifying the item of media content to be shown, so that
the item of media content 101 matches the planned content of the
phone call. This priming information may be delivered to the device
10 from the second party in a variety of media, although it is
advantageous that the user is not made aware of this priming stage
taking place. The information may be delivered via a GSM mobile
network or via a data connection, for example, and may comprise a
signal indicating the item of media content 101 to be shown next
out of a plurality of items of media content 101 available for
selection from the cache or a schedule of items of media content
101 to be shown alongside the next specified number of phone calls.
This schedule may be updated or revised in response to data
gathered about the user and/or user feedback, indicated via the
user's (or a number of users') interactions with items of media
content 101. Optionally, this signal may further comprise
instructions related to which item of media content 101 should next
be downloaded to the cache, or may comprise an item of media
content 101 which is downloaded into the cache.
[0754] FIG. 17 shows another example method of coordinating the
content of the phone call and the item of media content 101 to be
displayed. In this example, media content items 101 are downloaded
with an associated place in a schedule (S1). A `priming` signal may
be sent from the second party to change this order by providing a
new schedule (S2). When a call is made (S3), the first item of
media content 101 in the schedule is displayed (S4).
[0755] FIG. 18 shows another example method of coordinating the
content of the phone call and the item of media content 101 to be
displayed. After media content items have been downloaded into the
cache at an earlier time (S1), the app used as part of the system
1000 of the present invention may send a signal (S3) indicating
what (if any) items of media content 101 are available in the cache
in response to a request signal from the second party or the server
(S2). This request signal may be provided as part of the priming
stage, or may take place subsequently. The signal from the second
party requesting information about cache content may relate to a
specific item of media content 101, thereby functioning as a
`check` that the smart warm call will be successful, in that the
correct item of media content 101 will appear. Optionally, a
further `priming` signal may be sent from the second party to the
app (S4) to specify the media content item to be shown, as
described above. Following these steps, the call is made (S5), the
app looks up the media content item 101 to be displayed (S6) (based
on the priming signal, a schedule, or an identifier) and the media
content item is displayed (S7).
[0756] Alternatively or additionally, the second party may keep a
record (for example, in a database) of what items of media content
101 are available in the cache from records of previous downloads.
Alternatively, the item of media content 101 may be chosen at
random from a plurality of media content items in the cache, or
only one item of media content 101 is available in the cache at any
given time. In this case, the use of a priming stage is not
necessary. As previously described, the section of the item of
media content 101 to be displayed may be informed by the time of
day or user location, among other factors.
[0757] FIG. 19 shows another example method of coordinating the
content of the phone call and the item of media content to be
displayed. This method provides a method for a new item of media
content to be sent to the device immediately prior to the call. In
this example implementation, the calling party may send a `priming`
signal indicating that a call will shortly take place and that the
relevant item of media content should be downloaded (S1). The
device may then test to see if it is connected to Wi-Fi (S2). If
the device is connected to Wi-Fi, it will connect with the server
and download the relevant item of media content (S4). The
completion of the download is signalled to the server (S5),
indicating that the device is ready to receive a call and display
the correct item of media content. Where the device is not
connected to Wi-Fi, the device may wait for a predetermined time
period and then test again (S3). This may result in a long delay
between the `priming` signal and the download of the media content
item, so an additional step is included in which the server tests
to see if this is likely to be a suitable time by referring to
factors including the time of day, the device location, and data of
the user's previous interactions with the system (S6). If the
server determines that the user is likely to not take the call, the
call may be deferred and the system may wait for a defined time
period before testing again (S7). Alternatively, a call may be
scheduled for a time when the user is likely to be free and willing
to take the call. When the call is made (S8), the newly downloaded
item of media content is shown on the call screen (S9).
[0758] Alternatively, a mobile data network may be used to download
the media content item. Optionally, where no Wi-Fi connection is
available, a media content item 101 from the cache may be displayed
instead--in this implementation, it may be beneficial for the media
content items 101 in the cache to be applicable to a wide variety
of situations, while those downloaded immediately prior to a call
(if possible) are specifically related to the subsequent call.
[0759] As an alternative, the item of media content 101 may be sent
at the same time as the phone call. In this case, the same
communication channel is preferably used for both purposes. This is
most useful for voice-over-IP calls, where there is more likely to
be sufficient bandwidth available, and provides the advantage of
added flexibility about which item of media content 101 is
shown.
[0760] It will be appreciated by the skilled person that there are
many potential ways in which the planned content of the call and
the item of media content 101 could be coordinated, and elements of
the examples listed above may be combined.
Other Implementations
[0761] The skilled person will appreciate that aspects of the
invention may be implemented in alternative ways in accordance with
the specific hardware and software capabilities and
restrictions.
[0762] FIG. 20 shows another example a telephone call augmentation
related to smart warm-calling, in this example on an iPhone running
iOS.
[0763] As with the Android implementation described previously, the
user downloads the SDK as part of--or in addition to--the
third-party app. However, whereas Android permits greater control
by third parties of the incoming call screen (as mentioned
previously, in the case of OEMs allowing its replacement entirely),
this facility is restricted in iOS. Consequently, for iOS devices
the corresponding SDK makes use of the native `contacts` facility,
loading suitable third-party contact information including one or
more telephone numbers and a display profile into the contacts or
address book database, so that when the calling or third party
calls the user from a recognised number the caller display screen
displays the calling or third party information, much as it would
for a regular contact.
[0764] The third-party contacts information may be pre-loaded in
advance of the call or in some embodiments the information is
provided and the contacts updated in real-time. FIG. 21 shows call
screen user notification by way of a) a basic (push) notification
and b) an interactive notification.
[0765] A back end system is configured to send the user or callee a
personal (sniped) `interactive push notification`, preferably timed
to appear on the call screen at the same time as the incoming call.
This may be a basic (push) notification or an interactive
notification allowing the user to respond directly without taking
the call.
[0766] The item of media content displayed to the user may
therefore effectively comprise contact information in combination
with a (push) notification.
[0767] Timing the push notification to sync or coincide with the
incoming call is done by making use of the phone internal
diagnostics and/or the network signal so as to mitigate for signal
and/or hardware delays. This may be done by having the app on the
user device report to the calling or third party that it is in a
good signal reception area and has app notifications activated.
Alternatively, this information may be obtained in response to the
device being polled by the calling or third party in advance of a
potential smart-warm call.
[0768] In some embodiments, the app also determines whether the
user is likely to be poised to receive a call--which is discussed
in more detail below.
[0769] FIG. 22 shows a call screen with an SMS response
facility.
[0770] In some embodiments, the user response may be prompted via
SMS rather than via interaction with an interactive
notification.
[0771] The implementation described above may also be applied to
embodiments such as: [0772] Call screen display/advertising (as
previously described with reference to FIG. 5, suitably
adapted)--wherein content is synced in real-time to existing
contacts for which no profile picture is stored for display when an
incoming call is received from one of said contacts. Such facility
may be used by network operators and/or mobile virtual network
operators (MVNOs)--or indeed for any app. In some embodiments, each
interaction with the displayed content eg. a `clickthrough` or
social media `share` would earn the user points or prizes. [0773]
`Perfonality` of the person-person app interaction, allowing a user
to communicate a message, for example as a notification, say a push
notification, in parallel with placing a call, preferably relating
to the reason for calling eg. as `2 mins . . . it's about sunday`.
Person-to-person smart warm calling is also discussed in more
detail below.
[0774] Alternatives
[0775] As mentioned above, the "smart warm calling system" may,
optionally, be extended to apply to personal calls, as in
`person-to-person smart warm calling`, in which case both the
devices used by the caller and the callee must have the same app
installed, or alternatively two separate apps which are arranged to
communicate. In this example of the system 1000, the app used as
part of the system 1000 (or a separate app) may be provided with
the functionality for a caller to select the options that they wish
to present to the callee via buttons or alternative input means, as
previously described. These options may be selected from a list, or
there may be an option for the caller to write or customise their
own buttons. Alternatively, a default set of options and/or item of
media content may be provided. The option selected by the callee
may be presented to the caller using the caller's app. The
functionality may also extend to allowing the caller to change the
way their picture, contact details, or even phone number appears on
the callee's call screen by replacing (or hiding) these elements
with an item of media content. The font used and positioning of
elements may also be specified. The item of media content 101 shown
to the user on the call screen is therefore preferably totally
customisable by the caller. In addition, the ringtone heard by the
callee when the caller calls may be specified by the caller.
[0776] The caller may customise the item of media content 101 to be
shown (and the ringtone to be heard) by editing a `caller profile`
via the app on their device. The caller may specify a plurality of
caller profiles to be used for different callees, so as to provide
items of media content and ringtones that are appropriate to
different callees. The callee may be able to preview the item of
media content to be shown for certain or all contacts via the app,
and block items of media content or certain elements of items of
media content. As such, users of the app may be notified when
contacts update their caller profiles, so that they are provided
with the opportunity to preview the item of media content.
[0777] Buttons 301 providing the callee with the option to open a
chat window, share content on a social network, or convert the call
to a VoIP call may be particularly useful in combination with this
example implementation of the system.
[0778] The use of the system with personal calls is particularly
useful with the advent of `personal branding` as a product of
social/professional online networks, and provides for users to
brand their contacts' call screens.
[0779] Optionally, an item of media content 101 as described in
relation to "smart warm calling" may be presented to the user on a
call screen of an outgoing call. This call may be to the party
providing the items of media content and/or the app, for example,
or may be to an unrelated party. This functionality is particularly
useful where inbound calls are generated via a previous interaction
with an item of media content 101, as described above.
[0780] Optionally, a further item of media content 101 may be
presented to the user as described following the termination of any
accepted call from the second party. This item of media content 101
may, for example, request that the user provide feedback about the
customer service they received during the call via a list of
options, as described. Optionally, the app may therefore remain in
the background as the call takes place, and only terminate itself
following the display of the described further item of media
content 101.
[0781] Optionally, an item of media content 101 may be presented to
the user mid-call to provide additional functionality to a phone
call. For example, the calling party may ask the user to turn on
speakerphone and look at the call screen, where an item of media
content 101 may be displayed providing buttons allowing the user to
interact with the item of media content 101. Alternatively, the
item of media content 101 may show an image or video for tutorial
purposes, a secure password, or a live video or text feed, for
example. The item of media content may also present the user with
the option to share content on social media, open a chat window, or
complete a survey as previously described.
[0782] Optionally, an item of media content 101 may be presented to
the user on a call waiting screen, which may appear when the user
receives a call from the party providing the app when already
engaged in a phone call. This is particularly advantageous as the
user can indicate their call-back preferences rather discontinuing
their existing call, which they may be unwilling to do.
[0783] Optionally, the app may access the native device hardware
technologies--such as the smartphone accelerator, eyeball trackers
and/or camera(s)--to determine device and/or user data.
[0784] This data may be used to notify a calling or third party (in
response to a query made of the device) that the end user is
amenable or poised to receive a phone call. For example, eye
tracking and/or accelerator data may be used to determine whether a
user is using their phone for games or browsing.
[0785] In some embodiments even without accelerator and/or
eye-tracking data it is possible to determine whether the end user
is poised for call, for example by noting contextual information
such as they have just finished texting someone.
[0786] In some embodiments, the user may set preferred times for
when they would be willing to accept a call or excluded times when
they would not be so willing.
[0787] In some embodiments therefore a determination is made
whether and when to place a smart-warm call to a user in dependence
on one or more of: signal strength at the device, configuration of
the device, amenability of the user and user preference.
[0788] Device and/or user data may be used to track whether the
customer/user has seen and their reaction to--and optionally
determine whether they benefited from--smart warm calling. This
will have implications on conversion data and also on the fees
charged to calling or third parties.
[0789] In some embodiments, calling or third parties may be offered
the option to `piggy back` and provide smart warm-calling via the
app of another (calling or other) party. This relies on some call
screens being stored natively and some numbers being added for the
SDK to screen.
[0790] It will be appreciated that these alternatives and
modifications, while being complementary to the "smart warm
calling" example of the system 1000, may also be used together with
the previously described examples of the system 1 to provide
additional functionality.
SUMMARY
[0791] In summary, a method of and apparatus and system for
augmenting an incoming or outgoing (telephone) call with media
content has been described.
[0792] It will be understood that the invention has been described
above purely by way of example, and modifications of detail can be
mad e within the scope of the invention.
[0793] Each feature disclosed in the description, and (where
appropriate) the claims and drawings may be provided independently
or in any appropriate combination.
[0794] Reference numerals appearing in the claims are by way of
illustration only and shall have no limiting effect on the scope of
the claims. [0795] It is the intent of the applicant(s) that all
publications, patents and patent applications referred to in this
specification are to be incorporated in their entirety by reference
into the specification, as if each individual publication, patent
or patent application was specifically and individually noted when
referenced that it is to be incorporated herein by reference. In
addition, citation or identification of any reference in this
application shall not be construed as an admission that such
reference is available as prior art to the present invention. To
the extent that section headings are used, they should not be
construed as necessarily limiting. In addition, any priority
document(s) of this application is/are hereby incorporated herein
by reference in its/their entirety.
* * * * *