Metadata I 45:? Module Me gelry Source I

Metadata I 45:? Module Me gelry Source I
US 20070244924Al
(19) United States
(12) Patent Application Publication (10) Pub. No.: US 2007/0244924 A1
(43) Pub. Date:
Sadovsky et al.
(54) REGISTERING, TRANSFERING, AND
(52)
US. Cl.
Oct. 18, 2007
........................................................ .. 707/104.1
ACTING ON EVENT METADATA
(75) Inventors: Vladimir Sadovsky, Bellevue, WA
(57)
(US); Mysore Y. J aisimha, Redmond,
WA (US); Oren Rosenbloom,
Redmond, WA (US)
A technique and associated mechanism is described for
registering event metadata at a ?rst site, transferring the
event metadata to a second site using a portable module, and
Correspondence Address:
LEE & HAYES PLLC
421 W RIVERSIDE AVENUE SUITE 500
processing the event metadata at the second site. A user can
register the event metadata at the ?rst site in the course of
SPOKANE, WA 99201
consuming broadcast content. Namely, When the user
encounters an interesting portion of the broadcast content,
the user activates an input mechanism, resulting in the
storage of event metadata associated With the interesting s
portion on the portable module. The second site can upload
the event metadata from the portable module and, in
response, provide content associated With the event meta
data, including recommended content associated With the
event metadata.
(73) Assignee: Microsoft Corporation, Redmond, WA
(21) Appl. No.:
11/379,031
(22) Filed:
Apr. 17, 2006
Publication Classi?cation
(51)
Int_ CL
G06F 17/00
ABSTRACT
(2006.01)
100 x
l ______________________________________ _ _I
I
Site A
_ Stage 1:
I
Q
Register
I
Portabka
I
1%
Metadata
I
C
1.1g‘!
:
DUI,1 6"
I 45:? Module
at Site A
t t
Me gelry
I
1m
I
Source I
‘130g 6
l
Content
—
|
I
K
|
:
:
l
l
i --------------------------------------- - -|
l
Stage 2:
|
I
Site B
I
Upload
I
Metadata
l
Portable
Metadata
Remote
|
at Site B
and Receive
I
I
Module
106
Receiving
Module
Service
Module
I
I
—
m
m
|
Content
I
In Response
I
115
|
l
k
m
I
I
|
l
L
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
r ———————————— — _|
Optional
/ I
I
Stage 3:
l
l
Transport
I
'
on en
I
De'ivery
Portable <
I
Portablé
Module
'
1
Module
1 06
to Other Site
I
—
(such as
I
Site A)
E
k
——'—>
r
I
I
| _ _ _ _ _ _ _ _ _ _ _ _ _ _|
C
t
t
Modme
m
_
_
_
_
_
_
_
_
_
_
_
_
_
_
J
Patent Application Publication Oct. 18, 2007 Sheet 1 0f 11
US 2007/0244924 A1
100 w
/
i
_
_
_
_
_
_
_
_
“
'
'
"
_
F
_
_
_
_
_
_
—
_
R
_
*
‘
_
'
_
_
_
_
“
“
_
_
_
_
_
_
_|
|
I
{
Site A
_ Stage 1:
i
u
Register
I
Portable
at Site A
116.
I
i
m
:
C
t t
i
D0? en
Metadata < : Q Module
Me glelry
Content
:
11_0
I
I
Source :
‘130: e
—
I
|
|
|
\
r
l
l
l
l
________________________________________ _ _
r ------------------------------------ - _i
l
i
Stage 2:
:
Site B
:
Upload
:
M
:
Metadata
|
Portable
Metadata
at Site B
:
M d I
Receiving
and Receive
1
210g 9
Content
|
—
In Response
:
113.
Remote
‘
Module
|
Service
:
' Module
:
m
m
|
l
'l
I|
I
K
_
|
h
_
_
_
d
n
-
_
_
—
_
_
_
_
—
_
:
Stage 3:
i
|
Transport
'
'
_
_
—
~
_
_
_
_
_
:
Portable
:
Portable
:
Module
i
Modu'e
' r‘
to Other Site
‘I
m
(such as
:
.12_0
_
r —————————— _ _I
Opt|onal
Site A)
—
i
:
| _ _ _ _ _ _ _ _ _ _ _ _ _ _J
C
t
t
on en
De|ivery
’
Module
m
_
_
—
_
—
_
_
_
_
_
_
_
_
_
_
Patent Application Publication Oct. 18, 2007 Sheet 2 0f 11
US 2007/0244924 A1
200 N
Stage 1:
Log Metadata <
at Site A
m
20
songzh-letariala}
song'iueiauaia _
Event Data for Songt
- Preference Data
- Intent Data and/or
' Context Data
F
|
song‘imatauala
SOHQZMMH
>
_
d
—
d
d
_
_
_
_
SW91 Metsdala
SDngZMetadata
I
I
I
Stage 2:
Upload
Remote
Metadata
at Site B
and Receive
Content
Web :
Service I‘
In Response
ZZQ
Optional
Stage 3:
Transport
Portable
Module
to Other Site
(such as
Site A)
Q
I
I
So "9100mm
so nggcumem
Song1Cunlent
songzcnrtent
Module
I
11a
I
l
l
I
I
Patent Application Publication Oct. 18, 2007 Sheet 3 0f 11
US 2007/0244924 A1
Content Deiivery Module
E
Content
Delivery
Content
Source
1 10
Module
3Q
<
"'
T
User
‘
,
Interaction
Mod ule
E
V
Record ation
Mod ule
51E
Portabie
Module
Portabie
Module
Metadata
4
1‘—
106
Interface
—
308
Patent Application Publication Oct. 18, 2007 Sheet 4 0f 11
US 2007/0244924 A1
Portable Module
E
Site A Content
Interface
Module
a
Delivery Modl?e
@
-
_
_, Ste B Metadata
Receiving Module
1_1_2
Store
515.
Patent Application Publication Oct. 18, 2007 Sheet 5 0f 11
US 2007/0244924 A1
Metadata Receiving Module
m
Remote
_
>
Service
Interface
608
—
Rem'f’te
4
Service
Meta_
Metadata
data
<_
m
Module
Supple‘
w
mentation
User
Module
610
m
>
Interaction
Module
@Q
c
1
Store
V
w
Portable
Mod uie
Interface
§_0_2_
II—
Content
I’
Portabie
Module
m
H
Review Your Selections
Song Title
M51
Where
m
Action
True Love
Malibu Surf
Tail Spin
John Doe
Jane Roe
Bob Jones
Frank Ives
Car Radio
Car Radio
Car Radio
Car Radio
513/2006
5/3/2006
514/2006
514/2006
Purchase
Archive
Purchase
Add to Favorites
Patent Application Publication Oct. 18, 2007 Sheet 6 0f 11
US 2007/0244924 A1
Remote Service Module
Content Delivery
Module
Content
12$
E6
V
Interface for
Interacting with
Site B 4
M
>
Site B
>
m
Recommendation
Module
E
Optional
Metadata
Supplementation
Metadata
‘“"'"">
Service Module
m
Fig. 7
Master Store
m
Patent Application Publication Oct. 18, 2007 Sheet 7 0f 11
US 2007/0244924 A1
Processing Functionality
&
Processor
Media Device(s)
£9.53.
m
z ‘a.
H0
812 ’<:
A
Inter
m
V
RAM
804
> face(s)
E
V
ROM
806
Patent Application Publication Oct. 18, 2007 Sheet 8 0f 11
900 “X
US 2007/0244924 Al
User Couples Portable
Module to Content Delivery
Processing from
User’s Standpoint
Module at Site A
9L2
User Receives Broadcast
Media Content
%
K
\
User Registers Preferences
While Consuming Content,
Resulting in Storage of
Metadata in Portable
Module
M
\
J
r’
\
User Transports Portable
Module to Site 8
w
\
J
\
User Couples Portable
Module to Metadata
Receiving Module of Site B,
Resulting in Transfer of
Metadata to Remote
Service Module
m
J
it
User Receives Content (09
other Data) Based on
Uploaded Metadata
&
Fig. 9
Patent Application Publication Oct. 18, 2007 Sheet 9 0f 11
US 2007/0244924 A1
1000 w
Processing from
Site A standpoint
_
_
Dellvery Module of Site A
Provides Content to User
1002
V
Delivery Module Receives
User Selections
1004
Delivery Module
Determines Metadata
Associated with User's
Selection
1006
V
Delivery Module Provides
Metadata to Portable
Module
L8.
Fig. 10
Patent Application Publication Oct. 18, 2007 Sheet 10 0f 11
US 2007/0244924 A1
“HOD-N
Receiving
Receives Module
Metadata
of From
Site B :
Processing from
Site B Standpoint
Portable Module
m
l
Receiving Module Forwards
Metadata to Remote
Service Module
11%
l
Receiving Module Receives
Content From Remote
Service Module
m
1
Receiving Module
Optionally Transfers
Received Content to the
Portable Module
11%
Fig. 11
Patent Application Publication Oct. 18, 2007 Sheet 11 0f 11
US 2007/0244924 A1
1200 W
Remote Service Module
Receives Metadata From
Processing from
Site B
Remote Service Module
1202
Standpoint
V
Remote Service Module
Accesses Content (and
Optionally Accesses
Recommendations) Based
on Metadata
12%
Remote Service Module
Provides Content to
Receiving Module
£13.
Fig. 12
Oct. 18, 2007
US 2007/0244924 A1
REGISTERING, TRANSFERING, AND ACTING ON
of the user’s consumption of broadcast content or other
EVENT METADATA
media consumption experience. This provision alloWs the
BACKGROUND
user to easily register their preferences and other instructions
While consuming broadcast content, that is, Without per
[0001] Advances in media-related technologies have
given users the opportunity to select from a great number of
media items, such as songs, games, video programs, and so
forth. HoWever, improvements in these technologies have
also introduced neW challenges. A user may ?nd it time
consuming and cumbersome to search through a large col
forming the potentially burdensome task of manually sifting
through a large collection of content items.
[0006] The subject matter set forth in this Summary sec
tion refers to exemplary manifestations of the invention, and
hence does not limit the scope of the invention set forth in
the Claims section.
lection of media items to ?nd one or more media items of
interest. For instance, even if the user knoWs the identity of
a desirable item, the user may have di?iculty sifting through
the large collection to ?nd this item.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] FIG. 1 shoWs an exemplary overvieW of a system
for registering event metadata at a ?rst site, storing the event
In other instances, the user may be consuming a
metadata on a portable module, transferring the portable
broadcast of media items and to encounter one or more items
module to a second site, and uploading and acting on the
that interest the user. As appreciated by the present inven
tors, the user may Wish to purchase the interesting media
event metadata at the second site.
[0002]
items or otherWise discover more about the interesting
media items. HoWever, conventional broadcast technology
does not incorporate a mechanism that alloWs a user to
interact With a source of broadcast content and therefore
does not include provisions for alloWing the user to purchase
or otherWise discover more about the interesting media
items. For instance, a conventional radio includes no mecha
nism that alloWs a user to purchase songs that are broadcast
to the user via the radio.
[0003]
There is therefore a need in the art for more
[0008] FIG. 2 shoWs an exemplary speci?c implementa
tion of the system of FIG. 1.
[0009] FIG. 3 shoWs exemplary additional details regard
ing a delivery module that is used by the ?rst site in the
system of FIG. 1.
[0010]
FIG. 4 shoWs an exemplary integration of the
delivery module of FIG. 3 into a vehicle media system.
[0011] FIG. 5 shoWs exemplary additional details regard
ing the portable module that is used in the system of FIG. 1.
effective strategies for accessing media items and other
[0012] FIG. 6 shoWs exemplary additional details regard
content.
ing a receiving module that is used by the second site in the
system of FIG. 1.
SUMMARY
[0004] The folloWing description sets forth a technique
and associated mechanism for registering event metadata at
a ?rst site, transferring the event metadata to a second site
using a portable module, and processing the event metadata
at the second site. A user can register the event metadata in
the course of consuming broadcast content. Namely, When
the user encounters an interesting portion of the broadcast
content, the user activates an input mechanism, resulting in
the storage of event metadata associated With the interesting
portion on the portable module. More generally, the event
metadata can include one or more of the folloWing data
items: (a) preference data that re?ects the user’s interest in
content; (b) intent data that re?ects an action that the user
[0013] FIG. 7 shoWs exemplary additional details regard
ing a remote service module that is used in the system of
FIG. 1.
[0014] FIG. 8 shoWs exemplary details regarding process
ing functionality that can be used to implement any aspect
of the system of FIG. 1.
[0015]
FIG. 9 shoWs an exemplary operation of the system
of FIG. 1 from the standpoint of a user Who interacts With
the system.
[0016] FIG. 10 shoWs an exemplary operation of the
system of FIG. 1 from the standpoint of the delivery module
of FIG. 3.
Wishes to take With respect to identi?ed content; and (c)
context data that re?ects the circumstances surrounding the
[0017] FIG. 11 shoWs an exemplary operation of the
system of FIG. 1 from the standpoint of the receiving
user’s selection of content, and so on. The second site can
module of FIG. 6.
upload the event metadata from the portable module and
forWard the event metadata to a remote service module. The
remote service module can provide content that corresponds
to the event metadata. Optionally, the remote service module
can also provide recommended content that is selected based
on the event metadata (but does not otherWise have a
one-to-one correspondence to the event metadata). The
portable module can comprise a portable media device, a
personal digital assistant, a memory card, or other kind of
portable device that includes memory for retaining event
metadata.
[0005] The above technique confers a number of bene?ts.
According to one exemplary bene?t, the technique unobtru
sively integrates an event registration mechanism “on top”
[0018] FIG. 12 shoWs an exemplary operation of the
system of FIG. 1 from the standpoint of the remote service
module.
[0019] The same numbers are used throughout the disclo
sure and ?gures to reference like components and features.
Series 100 numbers refer to features originally found in FIG.
1, series 200 numbers refer to features originally found in
FIG. 2, series 300 numbers refer to features originally found
in FIG. 3, and so on.
DETAILED DESCRIPTION
[0020] The folloWing description sets forth a technique
and associated mechanism for registering user event meta
Oct. 18, 2007
US 2007/0244924 A1
data at a ?rst site (site A), transferring the event metadata to
a second site (site B), and then acting on the event metadata
at site B. The event metadata can be registered by the user
also encompasses transitory forms for representing informa
tion, including various hardWired and/or Wireless links for
transmitting the information from one point to another.
in the course of the user’s consumption of a broadcast at site
A, or in the course of some other activity of the user at site
A.
[0028] Al. OvervieW of the System (FIG. 1)
[0021] The term “event metadata” has broad connotation.
It refers to any data that is in any Way associated With
content. For instance, the event data can include one or more
of the following data items: (a) preference data that re?ects
the user’s interest in content is (such as the user’s indication
that he or she is interested in a particular song that is being
broadcast over a radio); (b) intent data that re?ects an action
that the user Wishes to take With respect to identi?ed content
(such as the user’s instruction to purchase the broadcast
song); and (c) context data that re?ects the circumstances
surrounding the user’s selection of content (such as infor
mation that re?ects a location at Which the user consumed
the broadcast song, a device through Which the user con
sumed the broadcast song, and so on). The event data can
[0029]
FIG. 1 shoWs an overvieW of a system 100 for
registering, transferring, and processing event metadata. The
system 100 encompasses at least tWo sites, site A 102 and
site B 104. Broadly stated, site A 102 comprises a site at
Which the user registers event metadata, and site B 104 is a
site at Which the user later performs some processing on the
event metadata. The sites (102, 104) may refer to separate
geographic locations and associated functionality provided
at those separate locations. In an alternative implementation,
site A 102 and site B 104 can refer to the same geographic
location, and optionally, these sites can even rely on the
same functionality or overlapping functionality. The system
100 also includes a portable module 106. The portable
module 106 is used to transfer event metadata from site A
102 to site B 104.
include yet other information associated With the content.
[0030] The exemplary components shoWn in FIG. 1 Will
[0022] The term “content” refers to any target of the user’s
interest, including, but not limited to, media content that is
broadcast to the user for the user’s consumption at site A,
be discussed on a general level in further detail beloW. The
including music information, static pictorial information,
next subsection discusses different applications of the sys
tem 100 shoWn in FIG. 1.
[0031] Starting With site A 102, this site includes any kind
of equipment for delivering content to the user. This equip
video information, game information, and so on. Content
can also refer to physical objects or places that the user
expresses an interest in (or is presumed to have expressed an
ment is represented in FIG. 1 as a content delivery module
interest in).
In one implementation, the delivery module 108 can receive
108 (referred to for brevity beloW as “delivery module”108).
[0023] This disclosure includes the folloWing sections.
content from one or more content sources 110 and provide
Section A sets forth an exemplary system for registering,
transferring, and later acting on event metadata. Section B
the content to the user. The delivery module 108 also
sets forth exemplary procedures that explain the operation of
provides an interface (not shoWn) that alloWs the portable
module 106 to be communicatively coupled to delivery
the system of Section A.
module 108.
[0024] A. Exemplary System
[0025] Generally, any of the functions described With
reference to the ?gures can be implemented using softWare,
hardWare (e.g., ?xed logic circuitry), manual processing, or
a combination of these implementations. The term “logic,
“module” or “functionality” as used herein generally repre
sents softWare, hardWare, or a combination of softWare and
hardWare. For instance, in the case of a softWare implemen
tation, the term “logic,”“module,” or “functionality” repre
sents program code (and/or declarative-type instructions)
that performs speci?ed tasks When executed on a processing
device or devices (e.g., CPU or CPUs). The program code
can be stored in one or more computer readable memory
devices.
[0026] More generally, the illustrated separation of logic,
modules and functionality into distinct units may re?ect an
actual physical grouping and allocation of such softWare
and/or hardWare, or can correspond to a conceptual alloca
tion of different tasks performed by a single softWare pro
gram and/or hardWare unit. The illustrated logic, modules
and functionality can be located at a single site (e.g., as
implemented by a processing device), or can be distributed
over plural locations.
[0027] The terms “machine-readable media” or the like
refers to any kind of medium for retaining information in
any form, including various kinds of storage devices (mag
netic, optical, static, etc.). The term machine-readable media
[0032]
In operation, the user consumes the content that is
delivered by the delivery module 108. In a ?rst scenario,
When the user is interested in a particular part of the content
being delivered by the delivery module 108, such as a
particular song, the user can actuate an input mechanism
(not shoWn) provided by the delivery module 108. In
response to this actuation, the delivery module 108 provides
preference data that identi?es the part of the content that Was
being presented When the user activated the input mecha
nism. This data is referred to as “preference data” because it
registers the user’s interest in (or preference for) particular
content. The delivery module 108 stores this preference data
on the portable module 106.
[0033] In a second scenario, the delivery module 108 can
also receive intent data from the user. The intent data re?ects
the user’s instructions to perform some action on is particu
lar content. For example, in addition to registering a pref
erence for a particular song that is being broadcast, the user
can also register an instruction to later purchase the identi
?ed song, or perform some other action With respect to the
identi?ed song (such as add the song to a list of favorite
songs maintained by the user, and so on.) In one case, the
preference and intent data can comprise tWo distinct items of
information input by the user. In another case, the intent data
can also serve the role of preference data, because, in
addition to setting forth instructions regarding particular
content, the intent data also implicitly registers the user’s
interest in the particular content.
Oct. 18, 2007
US 2007/0244924 A1
[0034] In a third scenario, the delivery module 108 can
also receive context data associated With the user’s selection
of content. For example, the delivery module 108 can record
salient information regarding the circumstances of the user’ s
selection of a particular song, such as the location and/or
time at Which the user selected the song, the type of delivery
module 108 through Which the user received the song (e.g.,
a car radio, etc.), and so on. The location information can be
gauged by various knoWn technologies, such as vehicle
bome GPS technology.
[0035]
In a variant of the third scenario, the delivery
stage 3 (120), the user can transport the portable module 106
to any site at Which the transferred content can be consumed,
such as site A 102.
[0040] In an alternative implementation, the system 100
does not require the physical transport of the portable
module 106 from site A 102 to site B 104. Rather, the
delivery module 108 can record the event metadata on the
portable module 106 at site A 102 and thereafter electroni
cally transfer the event metadata to the receiving module
112 at site B 104. Such transfer can be performed using any
kind of physical conduit of information (such as one or more
module 108 can receive context data Without receiving
preference data and/or intent data, and even Without neces
hardWired netWork links and/or one or more Wireless net
sarily receiving broadcast content. One example of this
Work links), governed by any protocol or combination of
event metadata. In the folloWing discussion, the term event
protocols, such as, but not limited to, Media Transfer Pro
tocol (MTP) over TCP/IP. Thus, in this implementation, the
potable module 106 can optionally be implemented as a
storage module Which remains ?xed Within the delivery
module 108. For example, the portable module 106 can
comprise a hard disk or like storage device Which is physi
metadata Will be used Without alWays expressly identifying
cally incorporated into a vehicle-borne delivery module 108.
the components of this data (e. g., Whether this data includes
preference data, intent data, and/or context data); it is to be
[0041] AZ. Exemplary Applications of the System
understood that the event metadata can include any combi
nation of such enumerated data types, as Well as other data
[0042]
scenario is set forth in the next subsection.
[0036] In general, all of the above-described data (prefer
ence data, intent data, and context data) comprises so-called
types.
[0037] Site B 104 includes any kind of equipment for
uploading the event metadata from the portable module 106
and performing some processing on the event metadata.
FIG. 1 labels this equipment as metadata receiving module
112 (referred to for brevity beloW as “receiving mod
ule”112). The receiving module 112 provides an interface
(not shoWn) that alloWs the portable module 106 to be
communicatively coupled to the receiving module 112. The
receiving module 112 also can be communicatively coupled
to a remote service module 114.
[0038] In operation, the receiving module 112 uploads the
event metadata from the portable module 106 and performs
processing on the event metadata. In one application, the
processing can involve sending the event metadata to the
remote service module 114, Upon receipt, the remote service
module 114 can provide content to the user that is associated
With the event metadata. In one implementation, the receiv
ing module 112 can forWard such content to the user for
consumption by the user via the receiving module 112 at site
B 104. In another implementation, the receiving module 112
can transfer the forWarded content to the portable module
106, Where the content can later be consumed by the user at
another site, such as at the delivery module 108 of site A.
[0039] To summariZe, the operations performed by the
system 100 can be regarded as a three stage process. In a
stage 1 (116), the user couples the portable module 106 to
delivery module 108 of site A 102. The delivery module 108
delivers content to the user (or otherWise exposes the user to
content) and also registers event metadata that re?ects the
user’ s presumed interest in portions of the delivered content.
The delivery module 108 stores the event metadata on the
portable module 106. In a stage 2 (118), the user transports
the portable module 106 to the receiving module 112 of site
B 104. The delivery module 108 uploads the event metadata
and performs some processing on the event metadata, Which
may involve transferring content associated With the event
metadata back to the portable module 106. In an optional
FIG. 2 shoWs a system 200 that represents one
application of the system 100 of FIG. 1. The system 200
includes counterpart components to those shoWn in FIG. 1,
including a site A 202, a site B 204, and a portable module
206 for transferring event metadata from site A 202 to site
B 204.
[0043]
In system 200, site A 202 pertains to a mobile
environment in Which the user consumes broadcast content
through broadcast equipment in a vehicle, such as an auto
mobile. In this environment, the site A 202 includes a
delivery module 208 Within the vehicle. For instance, the
delivery module 208 can comprise a radio that is accessible
via the dash console of the vehicle. The radio delivery
module 208 includes a Wireless interface for receiving
broadcast content (such as broadcast music and other pro
grams) from a broadcast source 210. The broadcast source
210 can comprise any kind of broadcast provider, such as
provider that uses a terrestrial antenna system, a provider
that uses a satellite delivery system, and so forth.
[0044] The delivery module 208 also includes an interface
(not shoWn) for receiving the portable module 206. In one
implementation, the portable module can comprise a por
table media player, a personal digital assistant, a memory
card, or any other kind of transportable device that includes
memory for retaining event metadata. The delivery module
can couple to the portable module 208 in a variety of Ways.
For example, the delivery module 208 can include a slot or
other physical interface Which can receive the portable
module 206. Or the delivery module 208 can couple to the
portable module 206 via a communication line. Once physi
cally coupled together, the portable module 206 and the
delivery module 208 can exchange data. Any kind of mecha
nism can be used to perform this transfer, such as, but not
limited to, a universal serial bus (USB) mechanism. The
exchange of data can be governed by any protocol, such as,
but not limited to, the Media Transfer Protocol (MTP).
[0045]
In operation, the user can use the delivery module
208 in the vehicle to listen to broadcast content in a
conventional manner, that is, by tuning the delivery module
208 to one or more radio stations to listen to music While
Oct. 18, 2007
US 2007/0244924 A1
driving. When the user hears content (such a song) that
module 212. Also, this communication channel can be used
interests him or her, the user can activate an input mecha
instance, the input mechanism can comprise a button that is
to forWard data (such as content) from the receiving module
212 to the portable module 206. Any kind of mechanism can
be used to exchange data betWeen the portable module 206
readily accessible by the user While driving the vehicle, such
and the receiving module 212, such as a USB mechanism.
nism (not shown) provided by the delivery module 208. For
as a button located on the steering Wheel of the vehicle. In
response to this actuation, the delivery module 208 can
access event metadata associated With the content (e.g., the
song) that happens to be playing at the time that the user
activates the input mechanism. The metadata can identify
the name of the song, the track of the song on an album in
Which the song appears, the artist(s) of the song, one or more
codes associated With the song, and any other descriptive
information associated With the song. This type of event
metadata constitutes the above-mentioned preference data
because it identi?es the content that is preferred by the user.
[0046]
In addition, or alternatively, the event metadata can
include intent data and/ or context data. Intent data can
include supplemental data that re?ects some action that the
user Wishes to perform on the identi?ed content, such as an
instruction to purchase the content, archive the content, add
the content to a favorite list, transfer the content to a friend,
and so forth. Context data can comprise any data Which
re?ects the circumstances in Which the user selected the
content, such as the location and/or time at Which the user
selected the content, the mechanism through Which the user
received the selected content (e.g., a car radio, etc.), and so
forth.
[0047]
Event metadata can be provided in different Ways.
As to preference data, in one case, the content source 210
can embed descriptive metadata along With the media con
tent that is transmitted to the delivery module 208. The
delivery module 208 can be con?gured to extract the
descriptive metadata from the transmitted media content. In
another case, the delivery module 208 can send the media
content in a ?rst channel and the descriptive metadata in a
second, separate, channel. Intent data and context data can
be received by various means, such by one or more user
interface mechanisms that can be manipulated by the user
(e. g., comprising, but not limited to, buttons, touch sensitive
panels, voice recognition mechanisms, etc.). Intent data and
context data can also be received through various automatic
data-providing mechanisms, such as position determination
mechanisms (e.g., GPS technology), time-keeping mecha
nisms, and so forth. In any event, the delivery module 208
can store all such collected event metadata in the memory of
the portable module 206.
[0048] At site B 204, a receiving module 212 can be
provided Which comprises a personal computer, game con
sole, set-top box or any other kind of data processing device.
As described With reference to FIG. 1, the receiving module
212 can include an interface (not shoWn) that alloWs the
portable module 206 to be communicatively coupled to the
receiving module 212. In one case, the portable module 206
can be connected to the receiving module 212 by a com
munication line, such as a Wire or cable. In another case, the
portable module 204 can be connected to the receiving
module 212 through a docking receptacle or cradle (not
shoWn) incorporated into the receiving module 212. Still
other
interconnection
implementations
are
possible.
Through this communication channel, the receiving module
212 can upload the event metadata stored on the portable
module 206 into a memory (not shoWn) of the receiving
[0049] In an alternative implementation, as described
above, the portable module 206 can remain coupled to the
delivery module 208. At time of transfer, the delivery
module 208 can transfer the event metadata to the receiving
module 212 via any combination of hardWired and/or Wire
less links, governed by any combination of protocols.
[0050] Once the receiving module 212 receives the event
metadata, it can perform various processing on the event
metadata, Where the nature of such processing depends on
the application. In one application, this processing can
involve displaying the event metadata for inspection by the
user, and/or transferring the event metadata to a remote
service module 214. The remote service module 214 can
comprise a Web site that includes one or more server
computers, storage, and/or other processing equipment. In
this scenario, the remote service module 214 can interact
With the receiving module 212 through a Wide area netWork
216, such as the Internet. Alternatively, or in addition, the
netWork 216 can comprise an intranet, an Ethernet netWork,
a point-to-point coupling mechanism, and so on, or some
combination thereof.
[0051]
The remote service module 214 can use the event
metadata as a lookup key to retrieve the actual content
associated With the event metadata. The remote service
module 214 can then forWard the actual content back to the
receiving module 212. For instance, in one case, the event
metadata identi?es one or more songs, e.g., by providing the
titles of the songs, codes assigned to the songs, and so forth.
The remote service module 214 can use this event metadata
as a lookup key to retrieve the digital data corresponding to
the song content, and can then forWard the song content to
the portable module 206. This operation can be performed
by accessing a lookup table Which maps the metadata
identi?ed in the event metadata to the actual song content.
In an alternative implementation, the remote service module
214 need not immediately transfer the actual song content to
the receiving module 212. Instead, the remote service mod
ule 214 can change the status the identi?ed songs to indicate
that the receiving module 212 or other entity is authoriZed to
doWnload these songs. The receiving module 212 or other
entity can then later doWnload the song content.
[0052] In one case, the processing Which is performed on
the event metadata is governed by intent data Which may
form part of the event metadata. For example, in one
instance, the intent data may indicate that the identi?ed
songs are to be purchased, Whereupon the remote service
module 214 carries out the purchase and delivery of the
songs.
[0053]
In the above example, the remote service module
214 provides content that has a one-to-one relationship With
the event metadata. In other Words, if the user indicates that
she is interested in song X While listening to the radio in the
vehicle, then the delivery module 208 stores metadata asso
ciated With song X on the portable module 206. The receiv
ing module 212 later uses the metadata for song X to retrieve
the content of song X from the remote service module 214
(or to perform some other action on song X). Additionally,
Oct. 18, 2007
US 2007/0244924 A1
or alternatively, the remote service module 214 can use the
event metadata to send recommended content to the user or
to perform some other action With respect to the recom
mended content. For instance, assume that the event meta
data again identi?es song X. In addition to providing the
content of song X, the remote service module 214 can also
provide the content for songs Y and Z. For example, the
remote service module 214 may determine that songs Y and
Z are related to song X (e.g., because these songs all share
one or more characteristics in common). This recommen
dation function cm also be used for cross-selling, up-selling,
and so forth. In another case, the remote service module 214
does not actually forWard the content corresponding to
recommended songs, but merely sends a message to the user
that invites the user to purchase the recommended songs.
[0054]
The content sent to the receiving module 212 from
the remote service module 214 can be forWarded to the user
in any form. In one case, the user can consume (e.g., play)
the forWarded content using the receiving module 212 itself
In another case, the receiving module 212 can transfer the
content to another device. For instance, the receiving mod
ule 212 can transfer the doWnloaded content to the portable
module 206. The user can then transport the portable module
206 back to the vehicle and couple it once again to the
delivery module 208. The delivery module 208 can play the
song content stored on the portable module 206 While the
user drives the vehicle. Thus, in this case, the portable
module 208 and delivery module 208 have a dual purpose:
the ?rst purpose is to record event metadata as the user
consumes broadcast content provided by the content source
210; the second purpose is to play back the content that has
been received from the remote service module 214 in
response to previously uploaded event metadata.
[0055] To summarize, in a ?rst stage (218), the user uses
the portable module 206 and delivery module 208 to receive
event metadata at site A 202. In a second stage (220), the
user uploads the event metadata at site 13204 to the receiv
ing module 212 and receives content corresponding to the
uploaded event metadata from the remote service module
214. In a third stage (222), the user optionally transports the
received content back to site A via the portable module 206
module 106 to the receiving module 112 (such as a personal
computer or other processing device) at site B 104, Where
upon some prescribed processing is performed based on the
event metadata.
[0058] Consider, for example, the case in Which the user
is Watching a commercial for a product that is being offered
for sale. The user can activate the input mechanism during
the commercial, producing event metadata that is stored on
the portable module 106. The event metadata identi?es the
product, e.g., by including a code associated With the
product, or by including data that identi?es the commercial
that features the product, and so on. The portable module
106 can then be transferred to the user’s personal computer
(Which acts as the receiving module 112), Whereupon the
personal computer can upload the event metadata from the
portable module 106. The personal computer can then
interact With a remote merchandising service (Which acts as
the remote service module 114) to consummate a transaction
based on the event metadata. For instance, the merchandis
ing service can alloW the user to purchase or otherWise
acquire the product identi?ed by the event metadata.
[0059] Note that in the above example, the delivery mod
ule 108 can be conceptualiZed as the television in conjunc
tion With the remote control device (not shoWn). In this case,
the device Which actually registers the event metadata (i.e.,
the remote control device) is not physically coupled to the
device that delivers the televised content (i.e., the televi
sion).
[0060]
In another application, site A 102 can comprise any
environment in Which a user can physically move about,
such as a store, a tourist site (such as a historic site), a ZOO,
a museum, and so on. In this scenario, site A 102 can include
a mechanism that tracks the location of the user throughout
the site, such as by using GPS technology, local transponder
technology, etc. In addition, site A 102 can provide a
portable (e.g., hand-held) delivery module 108 to each user
Who visits the site. The delivery module 108 can have an
input mechanism that alloWs the user to register his or her
interest in various items that he or she encounters While
Walking throughout the site. The delivery module 108 is
con?gured to correlate the user’s actuation of the input
and plays the content using the delivery module 208.
mechanism With event metadata; namely, the event metadata
is associated With items physically nearby the user When he
[0056] The scenario shoWn in FIG. 2 is merely one of
many scenarios that can utiliZe the general principles set
forth in FIG. 1. The folloWing discussion sets forth addi
or she activates the input mechanism. Such a correlation can
be performed based on the position of the user as determined
tional exemplary applications of the system 100 shoWn in
FIG. 1.
[0057]
by the tracking mechanism, and predetermined knoWledge
of Where different items are located Within the site. The
thus-produced event metadata can be transferred to a por
In another application, site A 102 can comprise any
location at Which the user consumes video programs. For
example, the delivery module 108 can comprise a television
table module 106 (such as a memory card) and later used to
access further information associated With the items that the
user has expressed an on-site interest in.
or other video output device that alloWs the user to Watch
[0061] Consider, for example, the application of this func
television, movies, and so forth. A remote control device
(not shoWn) can be used to interact With the video output
tionality to a historic battleground site or a museum. The
user can activate a “tell me more” button each time the user
device. The remote control device can include one or more
comes across a site that interests him or her While Walking
buttons that alloW the user to register interest in the video
content that is being provided. In the manner described With
respect to FIG. 1, the delivery module 108 can correlate the
user’s actuation of the input mechanism With metadata that
describes the content that happens to be playing When the
user actuates the input mechanism. The delivery module 108
throughout the site. When the user later returns to a receiving
module 112 (Which can be provided at a central tourist center
or may comprise a personal computer located in the user’s
can store this event metadata on a portable module 106 (such
as a memory card). The user can then carry the portable
oWn home), the user can upload the event metadata to a
remote service module 114 associated With the site, and, in
return, receive literature and other information that further
explains to the parts of the site that the user expressed an
on-site interest in.
Oct. 18, 2007
US 2007/0244924 A1
[0062] In another variant of the above-described example,
GPS technology or other location determination technology
[0068] In another application, a single delivery module
can interface With a delivery module 108 located in the
user’s vehicle. The location determination technology can
For example, in the vehicle-borne scenario, plural individu
be used to determine patterns in the user’s travel. This type
broadcast content. That is, for example, the driver can be
listening to ?rst content being broadcast over a ?rst station,
While a passenger can be listening (via headphones) to
of contextual event metadata can be registered on the
portable module 106, and later, at the receiving module 112,
correlated With commercial establishments that the user
passes on a frequent basis, such as restaurants, stores, etc.
This correlation can be performed by accessing a database
that identi?es the locations of commercial establishments,
and then culling out a subset of these establishments Which
are located in proximity to the user’s typical route. The
receiving module 112, in possible conjunction With the
remote service module 114, can then be used to deliver
advertising material to the user Which is associated With the
identi?ed commercial establishments. The advertising mate
108 can record event metadata associated With plural users.
als in a car can be simultaneously consuming different
second content being broadcast over a second station. In the
manner described above, the delivery module 108 can
receive event metadata that re?ects the preferences of both
of these users. To implement this feature, each entry in the
collection of event metadata can include user data Which
identi?es the user to Which the entry pertains, or the portable
module 106 can include separate ?les for storing event
metadata associated With different users, and so on. The
delivery module 108 can determine the user-based affiliation
of event metadata in different Ways, such as by alloWing
each user to operate a different input mechanism, Where
rials can include literature, coupons, and so forth. These
materials may induce the user to patroniZe the identi?ed
event metadata registered though the different input mecha
establishments.
nisms is associated With different respective users.
[0063] Note that, in the above example, the “content” that
accompanies the registration of context data is actually
associated With the physical environment through Which the
[0069]
user passes, rather than broadcast media content (as in the
[0071] FIG. 3 shoWs additional details regarding site A’s
delivery module 108 according to one exemplary implemen
tation. The delivery module 108 includes a content delivery
module 302 for receiving broadcast content (or other kinds
of content, such as unicast on-demand content, etc.). For
instance, in the case in Which site A 102 is a vehicle, the
example of FIG. 2). Further, in this example, the delivery
module 108 does not actually deliver content, but rather
selves the sole purpose of registering event metadata on the
portable module 106.
[0064] In another application, the system 100 can register
event metadata in an automatic fashion, that is, Without
necessarily receiving input selections from the user. For
Still further applications are possible.
[0070] A.3. Delivery Module
content delivery module 302 can comprise a radio that is
incorporated into or otherWise attached to the dash of the
instance, the user can pre-register user pro?le criteria Which
de?ne the type of content that the user prefers to consume.
For example, the user can indicate that she likes music by a
vehicle’s operating panel. The content delivery module 302
particular artist. In this scenario, the delivery module 108
station.
can be con?gured to investigate the songs that are being
[0072] The delivery module 108 also includes a user
interaction module 304. The user interaction module 304
broadcast over one or more channels to detect the transmis
sion of songs that feature the desired artist. This detection
operation can be performed in various Ways, such as by
comparing the user pro?le criteria With attribute data that
may accompany the broadcast songs. When the delivery
module 108 detects the occurrence of such songs, it can
record associated event metadata on the portable module
106. Event metadata that is recorded in an automatic fashion
can be associated With attribute data that identi?es the fact
that it has been automatically recorded (as opposed to
manually recorded in response to the user’s manual actua
tion); this attribute data can be later displayed to the user
(e. g., at the receiving module 112) to help the user determine
the context in Which the event metadata Was recorded.
[0065] In a variation of the above-described automatic
registration of event data, the delivery module 108 can
automatically infer the preferences of the user based on
trends exhibited by the user’s prior selection of songs.
[0066] In another variation of the above-described auto
matic registration of event data, the delivery module 108 can
delivers media content to the user in a conventional fashion,
e.g., in response to the user tuning to a particular radio
includes an input mechanism (not shoWn) that alloWs the
user to register his or her interest in a particular portion of
the content that is delivered by the content delivery module
302. In the vehicle scenario shoWn in FIG. 2, for instance,
the user interaction module 304 can include a button 402
(shoWn in FIG. 4) that is located on a steering Wheel 404 or
at another convenient location Within the vehicle. Or the
button 402 can be located on the portable module 106 itself
(not shoWn in FIG. 4). The user can s activate this button 402
When the user hears interesting content. In a television
vieWing scenario, the user interaction module 304 can
include a button (not shoWn) that is located on a remote
control device. The button alloWs the user to register interest
in a particular part of a video program being played on the
user’s television set. In any scenario, instead of a physical
button, the user interaction module 304 can incorporate a
voice recognition mechanism for registering the user’s inter
automatically record event metadata based on other consid
est in content. For example, in the vehicle scenario, the user
can speak the Words, “I like it!” or “Record!” to prompt the
delivery module 108 to record event metadata.
erations, such as commercial considerations (e.g., market
[0073] The above actuation mechanisms generally indi
based considerations). For example, an advertiser can pay a
fee to ensure that event metadata associated With advertising
content is stored on the portable module 106.
In other cases, the user interaction module 304 can include
[0067] Still other automated metadata recordation sce
narios are possible.
cate the user’s preference for a particular piece of content.
a ?rst selection mechanism for registering the user’s general
interest in a particular piece of content and a second selec
tion mechanism for registering the user’s instructions as to
Oct. 18, 2007
US 2007/0244924 A1
What action should be performed on the content. In still other
cases, the user interaction module 304 can include plural
can be incorporated into the delivery module 108, and
thereby can be relatively ?xed With respect to the delivery
action buttons (or the like) Which alloW the user to register
module 108.
different respective actions on the content (such as “Pur
[0077]
chase It,”“Send it to a Friend,”“Add it to My Favorite List,”
etc.); in this case, the user interface module 304 can dispense
With a separate preference-indicating mechanism, as the
user’s actuation of an action button implicitly suggests that
the user is interested in a particular piece of content. Other
input mechanism permutations are possible.
[0074] The delivery module 108 can also include a meta
data recordation module 306. The metadata recordation
module 306 identi?es metadata for recordation in response
to the actuation of the input mechanism provided by the user
In one scenario, the portable module interface 308
is used to store event metadata received from the metadata
recordation module 306 into a memory of the portable
module 106. In another scenario, the portable module inter
face 308 is used to upload content from the memory of the
portable module 106. For instance, this content may repre
sent songs that the user has doWnloaded into the portable
module 106 via the receiving module 112 (as Will be
described beloW in greater detail).
[0078] The delivery module 108 can include many other
functions and modules; to facilitate explanation, FIG. 3
interaction module 304. In one case, the metadata recorda
focuses on the modules described above Which serve a role
tion module 306 can perform this task by stripping descrip
in the exchange of event metadata and content.
tive metadata from broadcast media content When the user
[0079] A.4. Portable Module
actuates the input mechanism. For example, the content
source 110 can combine descriptive metadata With media
content that it sends to the delivery module 108, such as by
[0080] FIG. 5 shoWs further details of the portable module
106. As stated above, the portable module 106 can comprise
including descriptive metadata in the headers of packets
containing media payloads, or by multiplexing metadata
any kind of transportable device that includes a memory for
packets With media packets. In these cases, the metadata
recordation module 306 picks out the descriptive metadata
ci?cally, the portable module 106 can include an interface
Within a stream of media content. In another implementa
tion, the content source 110 can dedicate entirely separate
channels for delivering descriptive metadata and media
content, respectively. In this case, the metadata recordation
module 306 listens to both channels simultaneously and
extracts the descriptive metadata from the metadata channel
When the user actuates the input mechanism. In another
scenario, the metadata recordation module 306 can infer the
descriptive metadata based on the content being delivered,
such as by automatically extracting keyWords from a song,
by extracting a digital signature based on a portion of the
song, and so forth. In still another scenario, the content
storing event metadata and, optionally, content. More spe
module 502 for exchanging data With the delivery module
108 When coupled to the delivery module 108, and for
exchanging data With the receiving module 112 When
coupled to the receiving module 112. In one case, the
interface module 502 can include tWo different mechanisms
for interacting With the delivery module 108 and the receiv
ing module 112, respectively. In another case, the interface
module 502 can includes the same mechanism for interact
ing With the delivery module 108 and the receiving module
112. The interface module 502 can include any kind of
physical connectivity mechanism for coupling to the deliv
ery module 108 and the receiving module 112, such one or
more input sockets or plugs for receiving a communication
source 110 sends descriptive metadata on an on-demand
line, any structure for physically docking the portable mod
basis, e.g., in response to the delivery module 108’s request
for such data corresponding to a particular piece of broad
ule 106 into a receiving cradle, Wireless communication
mechanisms, and so forth.
cast content.
[0075] The above-described data collected by the meta
data recordation module 306 pertains to preference data.
This preference data serves primarily to identify the content
that the user is interested in. The metadata recordation
module 306, in conjunction With the user interaction module
304, can also record intent data. The metadata recordation
module 306, in conjunction With various other data-provid
ing mechanisms (not shoWn), such as GPS technology, a
time-keeping mechanism, and so forth, can also record
contextual data.
[0081]
The portable module 106 also includes a store 504.
The purpose of the store 504 is to store event metadata
received from the delivery module 108 and to optionally
receive content received from the receiving module 112. The
store 504 can be implemented by any kind of mechanism for
retaining information; in one case, for instance, the store 504
comprises static solid-state memory.
[0082] It Will be appreciated that the portable module 106
can include many other functions and modules; to facilitate
explanation, FIG. 5 focuses on the modules described above
Which serve a role in the exchange of event metadata and
[0076] Finally, the delivery module 108 includes a por
table module interface 308. The purpose of the portable
module interface 308 is to exchange data With the portable
content.
module 106. In one case, the portable module interface 308
can comprise a socket, cradle, or other docking arrangement
that can physically receive the portable module 106. In
another case, the portable module interface 308 can com
municate With the portable module 106 via a communication
line or Wireless channel. The portable module interface 308
can use any protocol to exchange information With the
portable module 106, such as the Media Transfer Protocol
[0084] FIG. 6 shoWs further details regarding the receiv
ing module 112 provided at site B 104. The receiving
interface 602 is used to upload event metadata from the
portable module 106 and to doWnload content to the portable
module 106. The portable module interface 602 can be
implemented in the same manner described above, e.g.,
(MTP). In another implementation, the portable module 106
using a variety of physical coupling mechanisms, a variety
[0083] A.5. Receiving Module
module 112 includes a portable module interface 602 for
receiving the portable module 106. The portable module
Oct. 18, 2007
US 2007/0244924 A1
of protocols, and so on. In one case, for instance, the
by the receiving module 112 or some other entity. For
portable module interface 602 can comprise a USB coupling
example, the receiving module 112 can use the event meta
mechanism for exchanging information With the portable
data as a guide to organiZe songs archived by the receiving
module, such as by moving songs identi?ed by the event
metadata to a favorite folder (for easy access by the user).
module 106 via a communication line. In other cases, the
portable module interface 602 can incorporate a docking
mechanism for physically receiving the portable module
106. In still another case, the portable module interface 602
can electronically receive event metadata from the portable
module 106 (e.g., via one or more netWork links) While the
portable module 106 is coupled to the delivery module 108.
[0085]
The receiving module 112 can also include a store
604 for retaining event metadata, content, and other data in
course of performing its functions.
[0086] The receiving module 112 can also include a user
interaction module 606 Which alloWs the user to interact
With the receiving module 112. For instance, various func
tions performed by the receiving module 112 can be con
trolled by input received by the user. For instance, the user
can instruct the receiving module 112 through suitable
interface mechanisms to upload event metadata from the
portable module 106, to doWnload content to the portable
[0090] Finally, the receiving module 112 can include a
metadata supplementation module 610. The purpose of this
module 610 is to supplement the event metadata extracted
from the portable module 106 by the portable module
interface 602. Namely, the delivery module 108 may not
have had access to all of the event metadata needed to fully
identify a piece of content. In this case, the metadata
supplementation
can supply the
supplementation
ferent Ways. In
module 610 at the receiving module 112
missing event metadata. The metadata
module 610 can perform this role in dif
one case, the metadata supplementation
module 610 can contact a remote online service. The remote
online service can use the incomplete event metadata that is
supplied to it as a lookup key to determine the missing event
metadata. The remote online service can then supply the
missing event metadata to the receiving module 112.
module 106, and so forth. In one implementation, the user
[0091] It Will be appreciated that the receiving module 112
interaction module 606 can include a user interface compo
can include many other functions and modules; to facilitate
explanation, FIG. 6 focuses on the modules described above
Which serve a role in the exchange of event metadata and
nent 606', a voice recognition component (not shoWn),
and/ or any other kind of interaction mechanism.
[0087]
In one case, the user interaction module 606 can be
used to display the event metadata upon uploading this data
from the portable module 106. The bottom portion of FIG.
6 illustrates one such exemplary kind of presentation that the
user interaction module 606 can use to display the event
metadata. As shoWn there, the presentation can identify
songs that have been registered at the ?rst site 102. The
content.
[0092] A.6 Remote Service Module
[0093]
FIG. 7 shoWs exemplary details of a remote service
module 114. In one case, the remote service module 114 can
be implemented as one or more server computers and
associated databases that are accessible via a Wide area
presentation can also shoW contextual data associated With
the registration (“Where” or “hoW” the songs Were regis
tered, “When” the songs Were registered, Whether the songs
Were registered in response to manual actuation of an input
netWork, such as the internet.
mechanism or in response to automatic selection, and so on).
The presentation can also shoW intent data associated With
infrastructure that communicates With the receiving module
the registration (“What” actions the user originally intended
to perform With respect to the identi?ed content, and so on).
The user can use this presentation to initiate various actions
pertaining to the event metadata.
[0088] The receiving module 112 can include a remote
service interface module 608. As the name suggestion, the
purpose of this module 112 is to interact With a remote
service module 114, such as by providing event metadata to
the remote service module 114 and by receiving content and
other data from the remote service module 114 in response
[0094]
The remote service module 114 includes an inter
face 702 for interacting With the receiving module 112. This
interface 702 can include front-end server communication
112 over a Wide area netWork.
[0095] The remote service module 114 also includes a
content delivery module 704. The purpose of the content
delivery module 704 is to perform any kind of processing of
the event metadata received from the receiving module 112
(Wherein such processing may be identi?ed by intent data
associated With the event metadata). In one case, this pro
cessing comprises identifying and accessing content that
corresponds to the event metadata. For example, consider
the vehicle scenario in Which the event metadata corre
thereto. In the case Where the remote service module 114
sponds to songs that the user has expressed interest in While
driving the vehicle. In this case, the content delivery module
comprises a Web-accessible service, the remote service
interface module 608 can comprise a high-speed broadband
704 correlates the event metadata With the songs associated
With the event metadata, and then accesses the song content
coupling mechanism, a dial-up type coupling mechanism, a
for delivery to the receiving module 112. The content
DSL type coupling mechanism, and so on. The exchange of
data With the remote service module 114 can be performed
delivery module 704 can access the content from one or
via any kind of digital netWork, such as a Wide area netWork
(e.g., the Internet).
more content stores 706. The content delivery module 704
and the content stores 706 can be maintained and adminis
tered by the same commercial entity or by different respec
tive commercial entities.
[0089] HoWever, use of the event metadata to retrieve
associated content is only one possible use of this data. In
another scenario, the receiving module 112 can archive the
event metadata to derive a pro?le of the user’s preferences.
In another case, the receiving module 112 can use the event
[0096] The remote service module 114 can also include a
recommendation module 708. The purpose of the recom
mendation module is to recommend content to the user
based on the user’s event metadata. For instance, as
metadata to organiZe content or other resources maintained
explained above, the content delivery module 704 may fetch
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement