WACA Introduction XO 102604.docWACA Introduction XO 102601.doc
`
`Rev. XO
`
`Public Relations and Marketing role, which must be kept in mind so the
`wireless adaptor should be in a fairly robust and mature stage such
`as a "pilot
`series" with final form,
`fit and function.
`
`1.2.3 Production
`
`The production launch is scheduled for the summer of 2005. The wireless
`audio adaptor may be bundled with entertainment phones special "iRadio"
`edition or sold as an accessory through various distribution channels.
`
`1.3
`
`Scope
`
`This document first describes the concept of the wireless audio car adapter,
`summarizes the various technical assumptions then proposes a road map for
`various market segmentations.
`It then highlights milestones deliverables and
`preliminary schedule.
`In appendix, are
`listed
`the specific relationship
`responsibilities and various term sheet details such as ownership, licensing,
`warranties, and technical assistance.
`
`Key products we seek to develop through this collaboration
`
`1- Initially for demonstration Q4 2004: a universal CD adaptor for a majority
`of OEM and aftermarket head-units forwarding on a serial bus at 9.6kbps
`- 19.2kbps (RS232 or TTL) all the" head-unit key events along with
`pushing CD text information back to the head-unit. This should be based
`on similar products developed for iROD interface, different brand CD
`changer or XM / Sirius "direct connect" interface technology.
`
`2- For trials Q2 2005: an integrated core reference design that could be
`licensed to an ODM of Motorola's choice based on an Analog Devices
`BlackFin technology, a similar combo DSP/ARM media processor or
`integrated into Zeevo BlueTooth "system on chip". This reference design
`will integrate audio decoder(s), Motorola's iRadio BlueTooth stack and
`control middleware with the partner universal CD changer adapter
`technology.
`
`3- To be Negotiated:
`a. small series of 100-200 wireless adaptors based on reference
`design to be demonstrated in Q2 2005 for limited trial.
`b. Production agreement
`
`Motorola Confidential
`
`Proprietary
`
`Page 6
`
`2/11/200510/27/200'1 |
`
`Page 334 of 667
`
`Petitioners
`Exhibit 1003, Page 334
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 102604.doc
`
`Rev: XO
`
`14 Glossary
`
`Mobile Client An iRadio enabled mobile device has its own storage and is
`occasionally connected to a home PC/gateway for updating
`stored content and sending back usage data. For the Demo
`and Trial, the only Mobile Client will be Motorola Entertainment
`phones. For later product phases Mobile Clients could also
`include: car decks and high-end wireless adapters, PDA,
`personal music player...
`
`"WACA"
`Wireless
`Audio Car
`Adapter
`
`the car
`A device that forms the gateway between the phone and
`radio head-unit, acting as a universal adaptor for a majority of
`aftermarket and OEM car decks.
`translate them to
`It will receive car radio/CD changer messages,
`appropriate Mobile Client commands and send the translated
`commands over Bluetooth to the Mobile Client.
`It will receive Mobile Client commands over Bluetooth, translate
`them to appropriate car radio/CD changer messages to the car
`radio.
`It will receive compressed audio over Bluetooth from the Mobile
`Client, decode it and output it via a lineout audio output.
`In higher-end inceptions, it could broadcast audio and data over
`T'-.'TV FM or store its own content directy and acts as a stand-alone
`renderer. Road-map allows the Bluetooth wireless link
`to evolve
`towards WiFi type of wireless protocol
`
`A2DP
`
`PAN
`
`SPP
`
`A BlueTooth Advanced Audio Data profile which allows quality
`stereo audio to be streamed over BlueTooth rather than the
`limited speakerphone/or headphone profile.
`It uses as a
`standard a Sul>band perceptual codec (SBC). Alternatively,
`well-known codec decoders could be attached as plugins such
`as MPS, WMA or AAC+
`to avoid codec cascading degradation.
`
`Another BlueTooth serial profile dubbed "Personal Area
`Network" for proximity ad-hoc networking over IP network.
`
`The basic serial profile connection for FTP exchanges over
`BlueTooth for point-to-point files exchange
`
`Motorola Confidential
`
`Proprietary
`
`Page 7
`
`2/11/200510/27/2001 |
`
`Page 335 of 667
`
`Petitioners
`Exhibit 1003, Page 335
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 102601.doc
`
`Rev: XO
`
`1.5 Assumptions
`
`• The wireless adaptor wiD be able to interface a majority of major
`aftermarket brands such as Pioneer, Alpine, Clarion, Kenwood, Sony,
`JVC and Panasonic
`• The wireless adaptor will be able to interface a majority of major OEM
`brands such as GM, Ford, DaimlepChrysler, Toyota, Honda and most
`European makers like BMW and VW.
`• The wireless adaptor will control directly the MUTE line and
`bus.
`• All depressed keys on the head-unit are expected to be reported. At a
`
`minimum, all presets memory keys, previous track /next track,
`fast forward
`and Rewind, source information should be relayed
`to the WACA
`• The wireless adaptor will be able to display text on the car radio deck and
`will manage the timing of the displays and associated warning sounds
`• The alternative use of "proprietary" custom car radio buses is legal
`through either legal reverse engineering and public domain information or
`individual agreement with the car radio makers.
`
`the proprietary
`
`• Others TBD...
`
`Motorola Confidential Proprietary
`
`Page 8
`
`2/11/200510/27/2001 |
`
`Page 336 of 667
`
`Petitioners
`Exhibit 1003, Page 336
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 102604.doc
`
`Rev: XO
`
`2 Wireless Audio Car Adaptor options
`
`The "WACA" concept can branch into a various farrily of products, which may not
`all end up in production, but may address different segments of the market. It
`starts with BlueTooth as the major wireless proximity transport then expands to
`the WiFi family and even branch into a tethered solution to hostthe transmitting
`phone in a recharging USB cradle. Here is a brief description of the major
`topologies:
`
`2.1 Basic WACA Architecture
`
`The WACA is a 2 way wireless gateway interface that translates audio
`files and commands streamed
`from a Motorola phone over BUeTooth into
`an analog or PCM audio feed to the car radio. It also receives car deck
`user interface commands (key push and release events) and status
`information so that the system operates in a closed loop where both the
`phone and the car deck can select which music
`the user wants. Finally,
`the WACA also send text information to the car deck through the limited
`CD text capabilities which are either containing audio program associated
`data or dialog with the user.
`
`TIC
`
`• BlueTooth transport
`• Streamed audio file
`• Text commands
`• car decks inputs and
`status
`
`•PPRat.
`
`BlueTopth^Slack^
`
`hiDAe]
`
`iGodec!
`
`mil
`
`iRadioCar Stack
`icjunctiomeo
`
`CaftdecKBBi
`Bustgont'olfelKa
`
`ipRSMj
`Flash
`
`Sm?
`
`fc
`
`Figure 1: generic WACA Architecture
`
`• Power, ground
`• R+,R-.L+,L-
`• Mute
`• Custom bus:
`/ •car decks inputs and status
`•CD text display
`• SP/DIF
`
`fcftlKS
`illppj
`
`n MSu
`
`--
`
`gp.
`
`-3 PI
`V£...
`
`Motorola Confidential Proprietary
`
`Page 9
`
`Page 337 of 667
`
`Petitioners
`Exhibit 1003, Page 337
`
`

`
`WACA Introduction XO 102604.doc W AC A Introduction X0 102604.doc
`
`Rev: XO
`
`2.2 WACA#1: BlueTooth baseline Ihin client
`
`The baseline will use BlueTooth as a wireless transport and the "WACA" will
`behave essentially as a "slave" device to the phone. The following diagram
`represents this:
`
`Command/Control
`
`Steaming Audio
`
`©f
`'
`iOsMk
`MSf I
`
`r**-
`
`W !
`
`.v/'&J
`
`mm*
`
`"tk
`
`reiduMl
`IMalaSI
`
`1
`
`r _ .
`
`MMiabas^B
`
`• Analog or PCM
`Audio
`• Text display
`• Car deck events
`and status
`
`Bl
`
`lOSjli^rinelLJ
`
`Figure 2: Baseline thin client WACA Architecture
`
`The CD changer interface "adaptors" on the market are using some ATMEL /
`Cirrus 8/16bits microcontrollers which are not powerful enough to handle the
`BlueTooth stack and the associated audio decodng. Two controller solutions are
`envisioned and will dictate the road map based on price targets and flexibility of
`reconfiguration;
`• Use an integrated "System-on-Chip" like Zeevo family of products which
`integrates BlueTooth stack, basic SBC decoder andARM+DSP chips on
`the same die, allowing cost-effective application solutions like iRadio
`to be
`built on.
`• Use a two chip solution: integrated BlueTooth baseband processor from
`Broadcom or CSR and multimedia embedded controller like the Analog
`Devices BlackFin, PowerPC or Intel Xscale
`
`Natural evolution: With improvements in price and power consumption, WiFi
`802.1 Ixx wireless transport may gradually replace BlueTooth in the phones and
`other portable media devices as ubiquitous wireless PAN transport. Insuch a
`case, a next version of the WACA thin client would replace the BlueTooth stack
`with a WiFi stack. WiFi/802.11xx interface may also allow direct transfer and
`
`/
`
`Motorola Confidential Proprietary
`
`Page 10
`
`Page 338 of 667
`
`Petitioners
`Exhibit 1003, Page 338
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XQ 102601.doc
`
`Rev: XO
`
`synchronization from the home gateway without the phone being needed if RF
`propagation allows it.
`
`2.3 WACA #2: "No Install-totally wireless" thin client
`
`For consumer mass adoption, it is likely that however simple the professional
`installation could be, this is still a major hurdle to clear with the consumer. A
`totally wireless solution would include a wireless FM broadcast to convert the
`audio stream and tune to one FM station at a time on the car deck. The sound
`quality will be sacrificed for the ease of installation. SDARS user's high
`percentage request has proven that the FM broadcast solution was a great
`enabler for mass adoption and easy listening in the car or at home.
`
`In the case of iRadio, the two-way interaction could be improved by adding two
`key features:
`• Use RDS to display text for audio program associated data and also
`interactive messages.
`• Use of basic short vocabulary command based speech recognition to
`select channel playlists
`
`Command
`/ Control
`
`Streaming Audio
`
`Bl M-TUPU ,
`
`NSS
`'WV'
`
`D
`
`Micro
`
`IN
`
`•M
`
`* i
`
`<3
`
`.^Esp'^EchSi.lJ
`
`t "JHHTl
`
`1
`
`f-Broadca
`
`11|
`
`'*
`
`: i BmaBcasu
`
`iHsemmands
`
`FM
`
`Car radio
`deck
`
`Figure 3: "Totally wireless" thin client WACA Architecture
`
`2.4 WACA #3: Wired Audio Car Adaptor
`
`In this architecture, the WACA is a "Master" reading content from mass
`storage devices connected through USB. The key advantage from this
`
`Motorola Confidential
`
`Proprietary
`
`Page 11
`
`2/11/200510/27/2001 |
`
`Page 339 of 667
`
`Petitioners
`Exhibit 1003, Page 339
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 10260'l.doc
`
`Rev: XO
`
`topology is to offer a simple mass storage interface mode between phone
`and other MPS media players appearing as media mass storage for the
`USB host, which is reading the audio tracks in sequence. This topology
`does not require any iRadio middleware or cellular phones iRadio enabled
`to work (you could plug any media player with USB and they should
`appear as mass storage to the WACA which wouti work as the master.
`However, adding iRadio USB manager and radio command module will
`bring a fuller user experience with all the advanced services for user
`convenience synonym of iRadio service. The USB link will be equivalent
`to the multiple Bluetooth connections and could multiplex audio stream
`and command & control data...
`
`Command
`/ Control
`
`•;
`Mass storage
`Audio files
`
`;
`
`EH
`HMMg
`......
`
`I SB
`Manager.
`
`Wmm
`mm&m
`
`MtfijJjtd
`Dt'Codk'
`
`^
`X
`
`' Audio files
`
`. v-Ato
`
`I
`
`giaipgmR|||
`BfqJraialil
`
`—i
`
`•'
`
`» " .
`(....
`
`A.
`
`.Char.e'el:
`
`>
`
`Figure 4: Wired USB thin client WACA Architecture
`
`2.5 WACA #4: "Hands-Free" kit audio adaptor - Hybrid BlueTooth + USB cradle
`
`-
`
`This hybrid topology caters to the people who may need the flexibility to
`recharge their phone into the car or use the USB link with other MPS
`players while having possible Hands-free phone conversation through the
`car radio stereo. It is also perfect for the cases where the iser want to
`experience iRadio audio streaming without moving the phone out of his
`pocket.
`
`Motorola Confidential Proprietary
`
`Page 12
`
`2/11/200510/27/2001 |
`
`Page 340 of 667
`
`Petitioners
`Exhibit 1003, Page 340
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 102604.doc
`
`Rev: XO
`
`Hands-Free
`Microphone
`
`D-
`
`Command
`/ Control
`
`Streaming Audio
`-4
`Voice input
`
`»•
`
`•Re-charge
`•Mass storage
`server
`
`{ *"*- Stream
`f-ntodiT
`
`/'
`
`• .
`
` M i
`
`l a d d i d 4 1
`
`.
`
`
`
`UMI
`
`g1«init.tr
`
`/
`
`—•r-:-".?
`•anv
`11 Sidt-r
`
`-y*
`-f- n SB"-^.
`. M mjcer
`
`|RM|O||||
`ftWanaglg
`
`©ifeMi
`
`Mt!
`
`mmzti
`
`!ir
`
`'f.
`
`Figure 5: "Hybrid" hands-Free expandable thin client WACA Architecture
`
`2.6 WACA #5: "Thick Client"
`
`roacknap evolutions
`
`. The WACA could evolve in a more powerful "Thick client" adaptor which would
`be the 'missing Link" for mass adoption of nomadic digital players into the car
`while waiting for BlueTooth, WiFi and hard-drives / memory cards to become
`ubiquitous on the car decks themselves (jonger aftermarket and OEM lifecycle).
`It is considered "Thick" once it hosts its own memory and manages "iRadio"
`business rules for the content without a need for the phone. By providing more
`than one USB port and managing these ports, the WACA could beome a
`successful "low cost alternative" media gateway for all the legacy car decks, that
`
`will not yet provide digital memory and wireless interfaces.
`
`The entire iRadio middleware available in the phone can be ported into the
`WACA so that, in the advent of a WIFI direct link with the Home Gateway, the
`WACA will function as both a server and renderer roles under an UpnP AA/
`paradigm. The phone may not be needed in this picture unless it provides
`some
`value added services like "hot content".
`In such a ca$, the Home gateway or
`WiFI/WiMAx hot spots on the go can transfer directly the media content updates
`into the car
`
`and receive usage tracking from
`the WACA.
`
`Motorola Confidential Proprietary
`
`Page 13
`
`2/11/200510/27/2001 |
`
`Page 341 of 667
`
`Petitioners
`Exhibit 1003, Page 341
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 10260'i.doc
`
`Rev: XO
`
`Command/Control
`
`Streaming Audio
`
`•BTkey ^...
`•WiFi Key
`•Storage key
`
`ii''
`*;«BTpvlana|;er
`
`(Efe'cotiei]
`
`Car radio
`deck Bus
`
`RMJ
`M
`IsMB
`• m
`
`••••
`
`jjSl
`
`[liB!
`
`*J ""'.Lbli
`
`BpueiMieB
`
`iv'-
`
`w%
`
`hS^e'ii
`aaiimwnii
`
`rf"
`
`pi^r :@i
`
`*'$t **'
`Zeevo SoC or
`
`-
`
`Z^\
`
`[wSfKreTOKi
`
`2 ch
`
`^^^P
`ps-bolutionVe!g^feR|'Broaqc:b
`»T
`|in
`..^*B|!^kf
`
`Figure 6: "High-End" expandable
`
`thin client WACA Architecture
`
`This approach would require a more powerful controller structure than the
`BlueTooth Zeevo system on chip may be able to provide. The BlackFin chip
`series from Analog Devices has shown tremendous computing power for very
`cost effective price. The WACA partner wll of course be influential in the
`decision of the core controller.
`
`Motorola Confidential Proprietary
`
`Page 14
`
`2/11/200510/27/2001 |
`
`Page 342 of 667
`
`Petitioners
`Exhibit 1003, Page 342
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 10260'1 .doc
`
`Rev: XO
`
`3 Timeline
`
`3.1
`
`iRadio timeline
`
`• iRadio is
`
`targeted
`
`for
`
`
`
`alpha release on December 31, 2004 for
`
`CES
`
`demo
`
`• iRadio Beta release on February 15, 2005:
`defined as Version 0.9:
`o Locked feature-set
`o All features implemented
`o Functionally complete
`o Operational
`• Public trials of iRadio "beta" starting
`
`on April
`
`
`
`a release in this context is beta
`
`
`
`4,
`
`2005
`
`for
`
`up
`
`• Commercial product release will commence in Q3 2005.
`product
`the
`The Commercial product release of iRadio 1.x will assume that
`undergone and passed rigorous QA
`testing
`for
`
`functionality, stability and data
`integrity.
`
`has
`
`3.2 WACA timeline
`
`
`
`no later than
`
`. •. Car deck to RS232 + Line in adaptor- one manufacturer model:
`11/22/04
`to RS232 + Line in adaptor - multi-manufacturers
`
`Car deck
`later
`than 12/1/04
`model: no
`(alpha):
`• Single board BlueTooth + car adaptor prototype
`• Single board BlueTooth + car adaptor
`(beta):
`2/15/2005
`• Single module BlueTooth + car adaptor
`
`(pilot)- qty 200: 4/15/2005
`• Single module BlueTooth + car adaptor
`
`(production)- qty >1000/ week:
`7/1/2005
`
`programmable
`
`12/15/2004
`
`Motorola Confidential Proprietary
`
`Page 15
`
`2/11/200510/27/2004 |
`
`Page 343 of 667
`
`Petitioners
`Exhibit 1003, Page 343
`
`

`
`WACA Introduction XO 102604.docWACA Introduction XO 102604.doc
`
`Rev: XO
`
`4 Rotes & responsibilities
`
`4.1 Motorola:
`
`Motorola will provide:
`• Program contact
`• System definition leadership
`•
`iRadio middleware interface algorithm
`• Phone interface protocol
`• Integration into
`target phones
`
`4.2 WACA partner
`
`WACA partner will provide
`
`the integrality
`
`or
`
`a
`
`
`
`sub-function of the following list:
`
`(hardware and software)
`interface
`adaptor
`
`Provides car radio
`and USB interfaces (hardware &
`software)
`Provides wireless
`
`core reference design
`Provides hardware
`adaptor
`radio
`car
`Integrates iRadio middleware with wireless and
`Provide WACA kit
`including housing module and adaptation cable sets
`Product validation for
`automotive
`environment
`OMD high volume /Jow cost
`agreed manufacturing
`
`Motorola Confidential Proprietary
`
`Page 16
`
`2/11/200510/27/2001 |
`
`Page 344 of 667
`
`Petitioners
`Exhibit 1003, Page 344
`
`

`
`1
`
`2
`
`3
`
`Introduction
`1.1
`Overview
`1.2
`Phases
`1.2.1
`Demo
`1.2.2
`Trial
`1.2.3
`Product
`1.3
`Scope
`1.4
`Glossary
`System Definition
`2.1
`Structure
`2.2
`Elements
`2.2.1
`Content Provider Interface
`2.2.2
`Home Configuration PC
`2.2.3 Mobile Clients
`2.2.4
`Thin car client
`2.2.5
`Public WiFi Hot spot
`2.2.6
`Cellular data system
`2.2.7
`Internet
`2.2.8
`In-home network
`2.2.9
`Home remote control
`2.2.10 Home renderer
`2.2.11 Updating system
`2.3
`Actors
`2.3.1
`User
`2.3.2
`Friend
`System Functions
`3.1
`Content Provider Interaction
`3.1.1
`Temporary Content Provider Standiri...
`3.2
`Updating
`3.2.1
`Discovery/Authorization....
`3.2.2
`Opportunistic Updating
`3.2.3 Mobile to mobile updates...
`3.2.4
`Content license approaches
`3.2.5
`Data updated
`3.2.6
`Problem situations
`3.2.7
`Cellular data opportunities....
`3.2.8
`Hot-spot opportunities
`3.3 Mobile Communications Medium
`3.3.1
`BlueTooth/WiFi
`Thin car client (streaming from a mobile client)
`3.4
`3.4.1
`A2DP Basic
`3.4.2
`A2Dp Advanced
`3.4.3
`User Interface
`3.4.4
`Short-term approaches..
`3.5
`DRM/codecs
`3.6
`Device to Device Transitions
`
`3
`3
`3
`3
`3
`3
`3
`3
`4
`4
`4
`4
`5
`5
`5
`5
`5
`6
`6
`6
`6
`6
`6
`6
`6
`7
`7
`7
`7
`7
`8
`8
`8
`8
`Error! Bookmark not defined.
`9
`9
`9
`9
`9
`9
`Error! Bookmark not defined.
`10
`10
`10
`10
`
`Page 345 of 667
`
`Petitioners
`Exhibit 1003, Page 345
`
`

`
`Configuration
`3.7
`3.7.1
`Personal MP3 support
`3.7.2
`iRadio Purchased content support.
`3.7.3
`Content not supported
`3.7.4
`At computer user interface
`3.7.5
`Remote configuration
`3.7.6
`Transitions
`3.7.7
`Channels
`3.8
`In-home content consuption
`3.8.1 Mobile unit as an in-home remote control
`3.8.2
`UPnP
`3.8.3
`Pause/Resume
`3.9 Mobile (Personal) operations
`3.9.1
`Content consumption
`3.9.2
`Storage
`3.10 At computer content consumption
`3.10.1 At home
`3.10.2 Remote
`3.11 Home Gateway
`3.12 Usage tracking
`3.13 Alarm clock
`
`10
`10
`10
`10
`11
`11
`Error! Bookmark not defined.
`11
`11
`Error! Bookmark not defined.
`12
`12
`12
`12
`12
`12
`12
`12
`12
`12
`Error! Bookmark not defined.
`
`Page 346 of 667
`
`Petitioners
`Exhibit 1003, Page 346
`
`

`
`1 Introduction
`1.1 Overview
`The core iRadio functionality
`
`1.2 Phases
`
`is well described
`
`in
`
`
`
`the Market Requirements Document. iRadio
`
`
`
`6-
`
`1.2.1 Demo
`9). It
`a suite during the CES show (Jan
`
`This is the CES 2005 demo. It will take place in
`will demonstrate how
`iRadio
`technology will work
`throughout
`a typical
`
`
`to waking up in the morning, driving work, going to the gym and
`
`returning home. The software
`implementing this demo will use Bluetooth
`for mobile
`
`updates client UPnP will be used for
`
`streaming content in
`the home.
`1.2.2 Trial
`second
`the
`course of
`the
`over
`is planned
`A trial with several hundred users
`
`and Ideally the car
`
`home
`the
`The Trial will demonstrate seamless operation between
`
`Trial system will be a natural evolution
`of
`
`system. the Demo This evolution would include the
`implementation of missing
`
`as features as well testing and enhancements
`
`1.2.3 Product
`well
`as
`trial
`the
`suggested by
`The product will incorporate improvements
`
`environments. In order to be on
`the market with a
`uncovered by testing
`in representative user
`to
`
`
`1) phase as will probably have the same
`
`features
`partner in 2005, the initial product (referred
`as the demo system. More advanced features will be deferred
`to
`following
`phases.
`
`user's
`
`quarter
`domains.
`
`as
`
`1.3 Scope
`the the operation of iRadio system for the Demo and Trial.
`
`
`This document focuses on
`Functionality beyond the Demo and Trial may
`be
`identified
`and
`even
`focus of this document.
`
`described,
`
`but
`
`1.4 Glossary
`Mobile Client
`either
`to
`connected
`occasionally
`is
`Any iRadio enabled mobile device which
`providing
`the home network or the Internet
`for updating stored
`content
`and
`usage data. Mobile Client can include: cell phone, car
`device,
`personal
`music
`player
`...
`content
`the
`An ordered set of content. By default a playlist would cause
`played in sequential order. There might also be a way
`to randomize
`the
`
`(or playing of it) so that the original order
`is not apparent. On mobile client, a
`playlist may only be partially resident on
`a
`device.
`
`to be
`playlist
`
`_
`
`Playlist
`
`Page 347 of 667
`
`Petitioners
`Exhibit 1003, Page 347
`
`

`
`Light-weight
`updating
`Bulk Content
`
`
`
`does The exchange of relatively small amounts of data which not include bulk
`
`
`content
`Actual audio or video content which
`
`involves
`
`
`
`large amounts of data.
`
`2 System Definition
`2.1 Structure
`SYSTEM DIAGRAM GOES HERE
`
`2.2 Elements
`2.2.1 Content Provider Interface
`The content provider
`is not part of the iRadio system. This interface encompasses all
`communication with
`the content provider. At its simplest, the content provider will provide
`playlists (genre channels, user custom channels, and
`the bulk
`content associated with
`Playlists). The iRadio Server provides user consumption and
`rating
`
`information. Additionally,
`the content provider interface handles the
`
`user's purchase of individual pieces of content.
`There is nothing in the system which
`
`
`the limits number content providers which could be
`supported.
`2.2.2 iRadio system
`together
`The iRadio Server and the Home Gateway work
`system. The exact division of responsibilities between
`the
`and is often unimportant when trying
`to understand how
`
`core the iRadio
`
`
`implement
`
`elements will be decided later
`
`system works whole.
`
`to
`two
`the
`
`as
`
`those
`
`of
`
`the
`
`a
`
`2.2.2.1 iRadio Server
`This is the central content aggregation point for the iRadio system. It communicates with
`
`
`
`on the content providers and passes the information to the rest of the system. Although the
`
`Home Gateway is typically in the communications path with mobile the iRadio devices,
`
`Server can communicate directly with mobile devices
`
`
`public via WiFi access points or via
`the cellular system.
`
`2.2.2.2 Home Gateway
`user's home PC or on a dedicated in-home media
`
`the
`The Home Gateway software runs on
`
`server (MS 1000). iRadio content is cached on the Home Gateway before played in the it is
`
`
`home via UPnP A/V or preemptively transferred
`to Mobile
`iRadio
`Clients which can
`connect to the Home Gateway via the home network.
`The Home Gateway functionality has
`no need for a user interface and no user
`interface
`is planned.
`
`Page 348 of 667
`
`Petitioners
`Exhibit 1003, Page 348
`
`

`
`2.2.3 Home Configuration PC
`for the Home Gateway as they use for configuring the
`
`Although the user may use the same PC
`iRadio, these are two different roles and are called out separately. The most extreme case for
`
`the Configuration PC being separate from the Home Gateway when the Home gateway is
`
`is
`MS 1000.
`2.2.4 Mobile Clients
`Mobile Clients are any iRadio enabled mobile devices which occasionally connect to either the
`
`home network or the Internet
`for updating stored content
`
`and providing data. For the usage
`
`Demo and Trial phases, cell phones are
`
`the only Mobile In later phases it could be a car Client
`
`device can or personal music player.
`
`a
`
`2.2.4.1 Phone client
`software which controls all iRadio
`
`iRadio
`The phone is running either native or Java
`listening
`just when
`the user
`is
`functions. This software must run continuously, not
`
`content on the phone. Running in the background, the software takes care of updating the
`
`
`so phone and the rest of the iRadio system that content
`is always up-to-date. There are no
`
`specific plans to use cellular data communications for any updating, but
`that
`remains
`possibility.
`
`a
`
`2.2.4.2 Car client (thick)
`interacts with
`support
`An iRadio in-car unit with content storage and WiFi
`
`system the same as any other mobile client. The in-car unit could be integrated
`
`into radio,
`Telematics Control Unit or installed as an after-market
`unit
`
`the via changer interface. CD
`
`
`
`the
`a
`
`iRadio
`
`2.2.5 Thin Car Client
`The Thin Car Client has no memory of its own. If allows content to be streamed to it from
`personal device carried by someone in
`the car
`
`via Bluetooth or WiFi. Additionally the in-car
`audio control actuations are sent
`to
`
`the source of the stream so that the driver can easily control
`the content.
`2.2.6 Public WiFi Hot spot
`mobile to updated
`
`allows
`a public WiFi hot-spot
`Not part of the Demo or Trial system,
`
`content directly from the iRadio Server. In early phases this updating will not
`include
`personal audio files which were not purchased
`through
`the
`
`system. iRadio WiFi access points
`
`which require the user
`
`to enter encryption information will not be supported. Configuration of
`acceptable WiFi access points will be possible
`to
`limit connections.
`
`a
`
`2.2.7 Cellular data system
`Not part of the Demo or Trial system, a mobile client capable of cellular data connections could
`
`use these connections for partial updates at minimal
`
`cost. Full updates would be cost
`prohibitive.
`
`devices
`user's
`
`Page 349 of 667
`
`Petitioners
`Exhibit 1003, Page 349
`
`

`
`2.2.8 Internet
`the Home Gateway
`to
`to connect the iRadio Server
`The Internet is used
`
`directly to mobile clients via a public WiFi access point or via cellular data connection.
`
`and in
`
`the
`
`future,
`
`2.2.9 In-home network
`to are support the streaming of content for in-
`
`
`The two responsibilities of the home network
`home consumption and
`
`to facilitate updating of mobile clients. These two responsibilities could
`be addressed by different in-home networks as
`
`as long they are both supported by the Home
`
`Gateway.
`
`2.2.9.1 UPnP
`UPnP A/V facilitates the streaming of content within a small network. This is the chosen
`
`
`in approach for the consumption of content the home for the Demo and Trial.
`
`
`2.2.9.2 Mobile connection
`or Bluetooth, any
`In the short term, Mobile Clients will be updated over WiFi
`high speed network would also work. For the Demo and Trial, Bluetooth will be the
`
`reasonably
`
`Home remote control
`2.2.10
`device as the user's will
`
`the personal mobile
`For the Demo and Trial
`it
`is assumed that
`
`
`remote control in the home for iRadio content consumption. This will use a Bluetooth link
`
`back to the Home Gateway which will participate in the UPnP network on the
`remote's behalf.
`
`also act
`
`Home renderer
`2.2.11
`analog to is converted for presentation
`
`
`
`the home
`. This is the end point where streamed content in
`to the user. For UPnP there are several commercially available audio rendering devices.
`
`Updating system
`2.2.12
`the differentiating technology of iRadio system which allows the
`
`The updating system
`is
`
`multiple devices/domains
`
`
`to keep in sysnc regarding what the user has listened to, is listening
`to, and is expected to listen
`
`in to the future.
`
`
`2.3 Actors
`2.3.1 User
`This is the person who uses the iRadio system
`
`
`
`in the various domains and for various purposes.
`
`2.3.2 Phone Friend
`For scenarios and which involve receiving
`the user.
`
`a phone call, this would be the person who phones
`
`.
`
`Page 350 of 667
`
`Petitioners
`Exhibit 1003, Page 350
`
`

`
`3 System Functions
`
`Interaction
`3.1 Content Provider
`content
`all
`providing
`for
`providers
`The iRadio relies on content
`celebrity
`playlists,
`genre
`provide
`initially
`own. Content Providers would
`
`purchase. The iRadio system would provide
`content
`
`consumption through this information
`interface also. This interface would be widened
`as
`needed
`to
`cover
`billing
`as needed.
`Server iRadio and the Content Provider would
`
`
`the
`The connection between
`
`a VPN privacy and security. Considering for
`
`the
`private connection or
`be
`crossing
`between
`the
`iRadio
`information which may
`a high capacity connection.
`
`over be dedicated
`
`
`
`large of
`amounts
`server
`and
`
`the
`
`which
`playlists,
`
`a
`
`and
`
`the
`
`on
`
`the
`
`3.1.1 Temporary Content Provider Standin
`faked
`Content The content will either be Provider.
`
`
`For Demo, there will not
`really be
`a
`iRadio server or a
`simple Content
`
`stub Provider could be created. The stub would use HTTP
`
`
`for all communications. Most of the genre playlists, celebrity playlists, and purchase
`interactions could be done via XML
`(or
`
`SOAP). even Bulk content transfers
`
`don't
`XML or SOAP, so those would be
`
`at one transferred time using plain HTTP GET a
`
`
`
`
`benefit from
`requests.
`
`3.2 Updating
`all
`Updating occurs between
`Gateway and Mobile Clients)
`
`elements
`the major
`
`is and the main enabler of
`
`the
`
`of
`iRadio
`
`
`
`iRadio Home
`the
`features.
`
`system
`
`users.
`
`the
`
`
`
`inquiry or response associated with actual
`
`discovery
`
`of
`
`supported
`
`user's
`
`
`
`
`
`to information if there are users
`
`in
`
`see
`
`3.2.1 Discovery/Authorization
`users which A Mobile Client will it supports.
`
`
`
`of
`list
`Each element of
`
`the iRadio system has a
`
`
`likely have only one person
`in the
`user The iRadio server could have millions list.
`of
`The initial handshake between
`to
`iRadio
`
`elements determine whether is
`
`
`used the
`two
`to
`elements have any users
`in
`
`common. If they have users in common,
`then
`the
`interchange
`proceeds to determine what
`information
`needs
`to
`be
`updated.
`
`Discovery occurs amongst Mobile clients and the Home Gateway. Communications with
`iRadio server
`is established
`via known URL rather a
`
`
`than discovery.
`The following stages occur:
`• Discovery: Receive
`initial
`iRadio enabled device
`• Authentication: Exchange
`common.
`• Add to registry: The discovered and
`devices available for updating.
`• Updating: Immediately after
`the
`to
`addition
`occurs as needed
`
`so long as the device remains in the registry.
`• Remove from registry: When
`it
`is
`determined
`
`that the registry can no a
`longer be reached,
`then
`it
`is
`
`removed from the registry.
`discovery
`the
`For devices designed
`
`to to connect the iRadio Server,
`
`in parallel with
`in the immediate proximity,
`
`is there also an effort
`
`
`to form a connection to the iRadio Server.
`
`an
`
`occurs.
`
`authenticated
`
`
`
`device a registry of is
`
`
`
`placed
`
`
`
`registry Updating also updating
`
`
`
`
`
`device
`
`of
`
`Page 351 of 667
`
`Petitioners
`Exhibit 1003, Page 351
`
`

`
`3.2.2 Data updated
`client during updating:
`
`types are sent from of data the mobile
`
`
`
`
`small
`The following relatively
`• Content Status Changes:
`
`Playing,
`Stopped,
`Paused, Resumed, Skipped. Where
`appropriate,
`this
`includes play-point
`information.
`• Rating: This
`the
`user's
`
`
`a of rating the content and contains content identifier, and both
`
`
`the change
`in rating and
`the
`new
`rating
`value.
`• Purchase Request: This
`
`contains a content identifier.
`• Key Press: For diagnostic
`
`purposes and user interaction
`captured.
`timezone
`time is stamped (UTC
`
`
`above
`Each piece of data
`interest
`of
`general
`are
`Changes and Ratings
`Press
`
`information only of interest
`Purchase Request and Key
`other
`elements.
`may be forwarded
`through
`client:
`Updating also
`involves
`sending
`the
`
`following data to the mobile
`• Playlists/Daily Set descriptions:
`
`These are user specific content
`not include the actual bulk
`content.
`• Bulk Content The
`large
`pieces
`of
`• User configuration/Preferences:
`TBD
`
`studies,
`
`each
`
`key
`
`press
`
`is
`
`and
`to
`
`is to