(12) United States Patent
`J awa et al.
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`US 6,728,729 B1
`Apr. 27, 2004
`
`US006728729B1
`
`(54) ACCESSING MEDIA ACROSS NETWORKS
`
`(75) Inventors: Amandeep J aWa, San Francisco, CA
`(US); J e?'rey L. Robbin, Los Altos, CA
`(US); David Heller, San Jose, CA (US)
`(73) Assignee: Apple Computer, Inc., Cupertino, CA
`(Us)
`
`( * ) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(21)
`(22)
`(51)
`(52)
`(58)
`
`(56)
`
`Appl. No.: 10/423,638
`Filed:
`Apr. 25, 2003
`
`Int. Cl.7 .............................................. .. G06F 17/30
`US. Cl. .......................... .. 707/104; 707/3; 707/203
`Field of Search .............................. .. 707/104, 3, 4,
`707/5, 203
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,920,856 A
`5,983,218 A
`6,243,713 B1
`6,523,022 B1
`
`*
`
`*
`
`*
`
`*
`
`7/1999 Syeda-Mahmood .......... .. 707/3
`11/1999 Syeda-Mahmood .......... .. 707/3
`6/2001 Nelson et al. ......... .. 707/104.1
`2/2003 Hobbs ......................... .. 707/3
`
`OTHER PUBLICATIONS
`
`“Apple Introduces iTunes—World’s Best and Easiest To
`Use Jukebox Software,” Macworld Expo, San Francisco,
`Jan. 9, 2001, downloaded from http://www.apple.com/pr/
`library/2001/jan/09itunes.html, on Jul. 10, 2002, 2 pages.
`iTunes, Playlist Related Help Screens, iTunes v1.0, Apple
`Computer, Inc., Jan. 2001.
`“Apple Announces iTunes 2,” Press Release, Apple Com
`puter, Inc., Oct. 23, 2001, downloaded from: http://ww
`w.apple.com/pr/library/2001/oct/23itunes.html, on Jul. 10,
`2002, 2 pages.
`Speci?cation Sheet, iTunes 2, Apple Computer, Inc., Oct.
`31, 2001.
`
`iTunes 2, Playlist Related Help Screens, iTunes v2.0, Apple
`Computer, Inc., Oct. 23, 2001.
`SoundJam MP Plus, Representative Screens, published by
`Casady & Greene, Inc., Salinas, CA, 2000.
`“SoundJam MP Plus Manual, version 2.0”—MP3 Player
`and Encoder for Macintosh by Jeffrey Robbin, bill Kincaid
`and Dave Heller, manual by Tom Negrino, published by
`Casady & Greene, Inc., 2000.
`“WWDC 2002 Keynote Coverage,” MacCentral Staff, May
`6, 2002, downloaded from: http://naccentral.macworld.com/
`news/2002/05/06/wwdckeynote on Nov. 12, 2003, 8 pages.
`“WWDC Keynote Coverage,” MacCentral Staff, May 6,
`2002, downloaded from: http://maccentral.macworld.com/
`news/2002/05/06/wwdckeynote on Nov. 12, 2003, 8 pages.
`“Review: SoundJam MP Plus 2.5.1,” Daniel Chvatik, Oct.
`2000, downloaded from: http://www.atpm.com/6.10/sound
`jam.shtml on Nov. 12, 2003, 8 pages.
`“iHam on iRye: 2.0—VersionTracker,” downloaded from:
`http://www.versiontracker.com/dyn/moreinfo/macosx/
`13021 on Nov. 12, 2003, 3 pages.
`“iCommune—Share your music over a network,” down
`loaded from http://www.icommune.sourceforge.net/ on Nov.
`12, 2003, 1 page.
`
`* cited by examiner
`
`Primary Examiner—Sanjiv Shah
`(74) Attorney, Agent, or Firm—Beyer Weaver & Thomas
`LLP
`
`(57)
`
`ABSTRACT
`
`Method and apparatus for accessing media across networks.
`The present invention generally allows for media to be
`provided across a network. A client requests media infor
`mation from a server so the client can create a local
`representation of the server’s database. The client is then
`able to manage the media information locally. When the
`client selects the desired media, it requests the selection
`from across the network. The server then delivers the
`selected media.
`
`15 Claims, 11 Drawing Sheets
`
`SERVER-SIDE MEDIA MANAGEMENT SYSTEM
`
`j 200
`
`MEDIA MANAGER
`
`5210
`
`205
`
`MUSIC
`DATABASE
`
`215
`
`SONGS L5 220
`
`PLAYLISTS L
`
`Yamaha Corporation of America Exhibit 1018 Page 1
`
`

`

`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 1 0f 11
`
`US 6,728,729 B1
`
`125
`
`120
`
`C)
`
`FIGURE 1
`
`Yamaha Corporation of America Exhibit 1018 Page 2
`
`

`

`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 2 0f 11
`
`US 6,728,729 B1
`
`SERVER-SIDE MEDIA MANAGEMENT SYSTEM
`
`MEDIA MANAGER
`
`215
`
`§ 200
`
`M US I C
`DATABAS E
`
`SONGS
`
`‘
`
`220
`
`PLAYLISTS
`
`FIGURE 2
`
`CLIENT-SIDE MEDIA MANAGEMENT SYSTEM
`
`lg 305
`
`MEDIA
`MANAGER
`
`I 300
`
`7
`
`FIGURE 3
`
`Yamaha Corporation of America Exhibit 1018 Page 3
`
`

`

`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 3 0f 11
`
`US 6,728,729 B1
`
`SERVER
`406$
`
`409
`
`Client Connects to Network g
`
`CLIENT
`f 403
`
`SERVER-INFO Request
`
`412
`
`SERVER-INFO Reply
`
`>
`
`418
`‘f
`
`CONTENT CODE Request (Optional)
`
`421
`
`CONTENT CODE Reply
`
`P
`430 J 427
`
`Client Logs On (If Necessary) %
`
`>
`
`J
`
`415
`
`5
`
`424
`
`<
`
`FIGURE 4A
`
`Yamaha Corporation of America Exhibit 1018 Page 4
`
`

`

`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 4 0f 11
`
`US 6,728,729 B1
`
`SERVER
`
`II
`
`436 I‘
`439 JI’
`
`CLIENT
`
`SERVE R-DATABASE Request
`
`433
`
`SERVER-DATABASE Reply
`
`FIGURE 48
`
`442
`
`rfsee FIG. 5
`
`SERVER
`
`406 f
`
`DATABASE-SONGS Request
`
`CLIENT
`
`403
`
`445
`
`DATABAS E-SONGS Reply
`
`453
`t/S\ee FIG. 6
`
`FIGURE 4C
`
`Yamaha Corporation of America Exhibit 1018 Page 5
`
`

`

`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 5 0f 11
`
`US 6,728,729 B1
`
`SERVER
`
`406 f
`
`457 j
`
`DATABASE-PLAYLIST Request
`
`DATABASE-PLAYLIST Reply
`
`FIGURE 4D
`
`SERVER
`
`CLIENT
`
`PLAYLlST-SONGS Request
`
`463
`
`PLAYLIST-SONGS Reply
`
`466 j
`
`FIGURE 4E
`
`469
`
`U
`
`ee FIG. 7
`
`Yamaha Corporation of America Exhibit 1018 Page 6
`
`

`

`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 6 0f 11
`
`US 6,728,729 B1
`
`CLIENT
`f 403
`472
`
`SERVER
`
`406\/\
`
`475 J
`
`SONG-DATA Request
`
`Stream SONG
`
`FIGURE 4F
`
`Yamaha Corporation of America Exhibit 1018 Page 7
`
`

`

`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 7 0f 11
`
`US 6,728,729 B1
`
`CLIENT-SIDE DATABASE MANAGEMENT SYSTEM
`
`MEDIA MANAGER
`
`f 305
`
`I 300
`
`515
`
`FIGURE 5
`
`Yamaha Corporation of America Exhibit 1018 Page 8
`
`

`

`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 8 0f 11
`
`US 6,728,729 B1
`
`CLIENT-SIDE DATABASE MANAGEMENT SYSTEM
`
`MEDIA MANAGER
`
`f 305
`
`605
`
`5 300
`
`510
`
`TTT_“H
`PLAYLISTS l|
`
`FIGURE 6
`
`Yamaha Corporation of America Exhibit 1018 Page 9
`
`

`

`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 9 0f 11
`
`US 6,728,729 B1
`
`5/ 300
`
`CLIENT-SIDE DATABASE MANAGEMENT SYSTEM
`
`MEDIA MANAGER
`
`f 305
`
`605
`
`SONGS
`
`[
`
`_ __ _ J
`
`510
`
`(J05
`PLAYLISTS Ti
`LI__—_—__—_'IJ
`
`FIGURE 7
`
`Yamaha Corporation of America Exhibit 1018 Page 10
`
`

`

`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 10 0f 11
`
`US 6,728,729 B1
`
`SERVER
`
`810
`f UPDATE Request
`
`4
`
`CLIENT
`
`805
`f 815
`
`820 f‘
`825 5
`
`UPDATE Reply
`
`FIGURE 8
`
`Yamaha Corporation of America Exhibit 1018 Page 11
`
`

`

`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 11 0f 11
`
`US 6,728,729 B1
`
`I 905
`
`Processor(s)
`
`$0
`
`I 910
`
`Interface(s)
`
`f 920
`
`f 915
`
`Memory
`
`BUS
`
`FIGURE 9
`
`Yamaha Corporation of America Exhibit 1018 Page 12
`
`

`

`US 6,728,729 B1
`
`1
`ACCESSING MEDIA ACROSS NETWORKS
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`The present invention relates to digital media and, more
`particularly, to accessing digital media across netWorks.
`2. Description of the Related Art
`The ability of computers to be able to share information
`is of utmost importance in the information age. NetWorks are
`the mechanism by Which computers are able to communi
`cate With one another. Generally, devices that provide
`resources are called servers and devices that utiliZe those
`resources are called clients. Depending upon the type of
`network, a device might be dedicated to one type of task or
`might act as both a client and a server, depending upon
`Whether it is giving or requesting resources.
`Increasingly, the types of resources that people Want to
`share are entertainment-related. Speci?cally, music, movies,
`pictures, and print are all types of entertainment-related
`media that someone might Want to access from across a
`netWork. For eXample, although a music library may reside
`on a family computer in the den, the media oWner may Want
`to listen to the music in the living room.
`HoWever, sharing media data can be a network-intensive
`process. People have devoted signi?cant resources to both
`reducing the load on netWorks and increasing the capability
`of netWorks to handle large data transfers. Due to advances
`in compression technology and netWork bandWidth, the
`throughput of information through netWorks has increased
`dramatically over the years.
`Although the described technologies Work Well in many
`applications, there are continuing efforts to further improve
`the ability to transfer digital media.
`
`SUMMARY OF THE INVENTION
`The present invention provides a method of retrieving
`media across a netWork. First, a client connects to a netWork
`that includes a server. The server includes at least one media
`database that has media and associated media information.
`The client then queries the server for at least a portion of the
`media information and then receives media information
`responsive to the query. The client then uses a client-side
`media management system to manage the received media
`information. Management of the received media information
`includes selecting media. The client then requests the
`selected media from across the netWork and, in response to
`the request, receives the requested media.
`In another aspect, a client queries the server for server
`information and capabilities after connecting to the netWork.
`The client then receives a response that identi?es the server
`and informs the client as to its capabilities. After receiving
`the server information, the client queries the server for
`database enumeration and receives a response that enumer
`ates all databases, hoW much media is available, and hoW
`many media collections are available. After the database
`identi?cation, the client queries the server for an enumera
`tion of media collections in the database and receives a
`response that identi?es media collections. The client then
`queries the server for data associated With an identi?ed
`media collection, the query being capable of requesting a
`different level of detail than Would be given by default. The
`response to the media collection query identi?es data asso
`ciated With the identi?ed media collection in the requested
`level of detail. The client then eXecutes the identi?ed media
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`2
`collection, requesting media from the server When the media
`collection requires the media and receiving the requested
`media.
`In yet another aspect, the invention provides a method of
`ensuring that a media database representation on a client is
`current. The server ?rst provides a media database that
`updates to a current revision indicator Whenever the media
`database is modi?ed. Then, the server receives a request
`from the client, the request pertaining to the database that
`includes a client-provided revision indicator. After receiving
`the request, the server compares the current revision indi
`cator to the client-provided revision indicator. The server
`then responds to the request With a response that includes at
`least an identi?cation of the current revision indicator if the
`client-provided revision indicator did not match the current
`revision indicator.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The invention may best be understood by reference to the
`folloWing description taken in conjunction With the accom
`panying draWings in Which:
`FIG. 1 is a block diagram illustrating an eXemplary
`environment in Which the present invention may be imple
`mented;
`FIG. 2 is a block diagram illustrating an organiZational
`structure of a server-side media management system on the
`server illustrated in FIG. 1;
`FIG. 3 is a block diagram illustrating an organiZational
`structure of a client-side media management system on the
`client illustrated in FIG. 1;
`FIG. 4A is a representational control How diagram illus
`trating one technique that can be used to determine the
`features of the server-side media management system illus
`trated in FIG. 2;
`FIG. 4B is a representational control How diagram illus
`trating one technique that could be used to enumerate
`databases of the server-side media management system
`illustrated in FIG. 2;
`FIG. 4C is a representational control How diagram illus
`trating one technique that could be used to populate a song
`records portion of the client-side media management system
`illustrated in FIG. 5;
`FIG. 4D is a representational control How diagram illus
`trating a technique that could be used to enumerate playlists
`of the server-side media management system illustrated in
`FIG. 2;
`FIG. 4E is a representational control How diagram illus
`trating a technique that could be used to populate a playlist
`records portion of the client-side media management system
`illustrated in FIG. 6;
`FIG. 4F is a representational control How diagram illus
`trating a technique that could be used to retrieve a song from
`a song database once a song is selected from the client-side
`media management system illustrated in FIG. 7;
`FIG. 5 is a block diagram illustrating an organiZational
`structure of the client-side media management system after
`receiving a reply to the SERVER-DATABASE request illus
`trated in FIG. 4B;
`FIG. 6 is a block diagram illustrating an organiZational
`structure of the client-side media management system after
`receiving a reply to the DATABASE-SONGS request illus
`trated in FIG. 4C;
`FIG. 7 is a block diagram illustrating an organiZational
`structure of the client-side media management system after
`
`Yamaha Corporation of America Exhibit 1018 Page 13
`
`

`

`US 6,728,729 B1
`
`3
`receiving a reply to the PLAYLIST-SONGS request illus
`trated in FIG. 4E;
`FIG. 8 is a representational control How diagram illus
`trating one technique that could be used to ensure the client
`and the server illustrated in FIG. 1 are synchronized; and
`FIG. 9 is a diagram illustrating an exemplary computing
`device in Which various embodiments of the invention may
`be implemented.
`It is to be understood that, in the draWings, like reference
`numerals designate like structural elements. Also, it is
`understood that the depictions in the ?gures are not neces
`sarily to scale.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`In the folloWing description, numerous speci?c details are
`set forth to provide a thorough understanding of the present
`invention. HoWever, it Will be obvious to one skilled in the
`art that the present invention may be practiced Without some
`or all of these speci?c details. In other instances, Well knoWn
`process steps have not been described in detail in order to
`avoid unnecessarily obscuring the present invention.
`The present invention generally alloWs for client
`machines to access a media database on a server. Both data
`and metadata on the server describes and organiZes the
`media in various Ways and alloWs the server to manipulate
`the media. Instead of relying on the server to execute the
`media management system, the client requests the data and
`metadata and then uses the information on a local media
`management system, effectively creating a representation of
`the server on the client. Once media is selected on the client
`through the client-side media management system, the client
`can request the media from the server, and the server can
`deliver the media to the client.
`The invention can support both “thick” and “thin” clients.
`Thick clients are typically softWare programs, such as
`iTunesTM softWare available from Apple Computer, Inc. of
`Cupertino, Calif., operating on hardWare devices that sup
`port full user interface abilities and have considerable pro
`cessor and memory resources. Thin clients are softWare
`programs operating on hardWare devices that may have
`limited user interface abilities and have reduced processing
`and memory resources. The invention alloWs for robust
`control features appropriate for thick clients, but can adapt
`to minimal control features for thin clients.
`Generally, a client Will ?rst make a request to determine
`Whether media is available on a server. Then, the client can
`make a series of requests to create a representation of the
`media available on the server on the client. The represen
`tation contains information about the media available on the
`server (“media information”). Thick clients can choose to
`retrieve a complete representation of the server’s available
`media, While thin clients may choose to retrieve a partial
`representation of the server’s available media. After receiv
`ing the media information from the server, the client (as
`instructed by its user) can then search, broWse, sort, or
`otherWise interact With the media information noW resident
`on the client. Further, the client (as instructed by its user)
`Will typically select a media item to be presented (e.g.,
`played). In such a case, the media content for the selected
`media item is streamed from the server to the client.
`In addition, clients can receive noti?cations from the
`server When a media database has been changed. Multiple
`connections can alloW a client to use one connection to
`access media While using another connection to Wait for a
`noti?cation that the database has changed, or to broWse
`media listings.
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`4
`FIG. 1 is a block diagram illustrating an exemplary
`environment in Which the present invention may be imple
`mented. A netWork 105 couples a server 110 to various
`clients 115, 120, 125, and 130. The netWork 105 can
`generally be a data netWork, such as a LAN, WAN or the
`Internet. The server 110 may or may not be a dedicated
`device. In the example shoWn in FIG. 1, the server 110 is a
`general purpose computer. The various clients 115, 120, 125,
`and 130 can be thick or thin clients, With varying levels of
`processing poWer. Clients may include portable computers
`115, desktop computers 120, specialiZed devices such as
`iPodsTM 125 available from Apple Computer, Inc. of
`Cupertino, Calif., or even netWork-aWare audio/video com
`ponents 130 that are designed to Work across a netWork 105.
`The folloWing discussion Will, for simplicity, assume only
`the portable computer client 115 is requesting information
`from the server 110.
`FIG. 2 is a block diagram illustrating an organiZational
`structure of a server-side media management system 200 on
`the server 110. The server-side media management system
`200 includes a media manager 210 and a music database
`205. The media manager 210 controls access to the music
`database 205. More particularly, the media manager 210
`receives requests from the client 115, accesses the music
`database, and returns responses to the client 115.
`The music database 205 has a number of records 215 and
`220 that are used to classify, identify and/or describe media
`(i.e., media items) in the music database 205. For simplicity,
`the folloWing discussion Will assume the digital media
`contained on the server 110 only contains music ?les that
`can be streamed over the netWork 105. It should be appre
`ciated that any reference to “songs” or “music” made in this
`document could be generaliZed to any form of digital media,
`Which can include sound ?les, picture data, movies, text ?les
`or any other types of media that can be digitally stored on a
`computer. Similarly, any reference to “playlists” can be
`generaliZed to media collections, including collections of
`mixed digital media.
`The media manager 210 has or can obtain information
`about the database 205 that may, for example, include the
`name of the server, the version of the database being used,
`the type of security that is required, the number of databases
`available to the server, Whether content codes are supported,
`Whether persistent identi?cation is supported, etc. It should
`be appreciated by those skilled in the art that the information
`about the database 205 may exist in a single record ?le or
`can be either partially or fully generated on demand, iden
`tifying the various pieces of information as needed.
`The song records 215 contain metadata about each media
`item available in the database 205. The metadata might
`include, for example, the names of songs, an identi?cation
`number, a persistent identi?cation number, the artist, the
`album, the siZe of the song, the format of the song, the
`required bit rate, and any other appropriate information. Of
`course, the type of information may depend on the type of
`media. A video ?le might additionally have director and
`producer ?elds, but may not use the album ?eld. Still
`pictures Would have no need for bit rate information. While
`some ?elds may be standard, others may be speci?c to
`certain applications. For example, a video signal may have
`secondary audio program (SAP) information. A mechanism
`for ensuring clients can properly process non-standard con
`tent codes is described in connection With FIG. 4A.
`Both an identi?cation number and a persistent identi?ca
`tion number can be used. If supported, a persistent identi
`?cation could be used to access the same information across
`
`Yamaha Corporation of America Exhibit 1018 Page 14
`
`

`

`US 6,728,729 B1
`
`5
`server restarts. Typically, a server Would assign each record
`a neW identi?cation number every time the media manage
`ment system 200 restarted. However, persistent identi?ca
`tion numbers Would remain the same for as long as the
`record is available.
`The playlist records 220 contain information about each
`playlist available in the music database 205. Further, the
`information for a given playlist can include the identi?cation
`numbers for each of the songs Within the playlist. Playlists
`are collections of media that may or may not be in any
`particular order. Users may choose to combine media by
`genre, mood, artists, audience, or any other meaningful
`arrangement. While the playlists 220 on the server 110 Will
`usually only include media contained in its oWn music
`database 205, there is no reason the playlist records 220
`cannot include media or playlists stored on other servers.
`HoWever, certain non-standard content codes may need to be
`used, depending upon the implementation of the server-side
`media management system 200.
`FIG. 3 is a block diagram illustrating an organiZational
`structure of a client-side media management system 300 on
`one of the clients 115. The client-side media management
`system 300 includes a media manager 305. The media
`manager 305 interacts With the media manager 210 of the
`server-side media management system 200 through the
`netWork 105 so as to replicate at least a portion of the music
`database 205 at the server 110 on the client 115. When the
`client-side media management system 300 ?rst starts, it
`cannot access media on the server 110 because it does not as
`yet have any information about What media is available.
`FIG. 4A is a representational control How diagram illus
`trating one technique that can be used to determine the
`features of the server-side media management system 200.
`Operations performed by the client 115 and the server 110
`are represented by corresponding vertical lines 403 and 406.
`At 409 the client 115 connects to the netWork 105 and ?rst
`becomes aWare of the server 110. The client 115 can use any
`connection mechanism that alloWs it to interact With the
`netWork 105. For example, if the client 115 Were an
`iBookTM, available from Apple Computer, Inc. of Cupertino,
`it might use RendezvousTM netWorking technology, also
`available from Apple Computer, Inc. of Cupertino, Calif., in
`order to automatically con?gure itself With the netWork 105.
`If the client is not aWare of the server 110, other mechanisms
`can be used. For example, a user might manually search for
`the server 110, or the user might directly enter the address
`of the server 110.
`Once the client 115 is aWare of the server 110, it can send
`a SERVER-INFO request to the server 110 at 412. The
`SERVER-INFO request is usually used to obtain informa
`tion from the server prior to attempting any other transac
`tions. If the netWork 105 uses the TCP/IP protocol, the
`request could be formatted as an HTTP GET request. The
`GET request might also alloW for additional extensions to be
`added to the request, enabling, for example, the client 115 to
`include information about the client-side media manage
`ment system 300.
`At 415 the server responds to the SERVER-INFO request
`With information describing a series of features supported by
`or required by the server. The information might, for
`example, include information about the server-side media
`management system 200, the number of available databases,
`Whether and What login procedures are required, Whether
`updates are supported, Whether persistent identi?cation
`numbers are supported, Whether content codes are
`supported, and the protocol version.
`
`10
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6
`The information provided to the client 115 at 415 permits
`the client-side media management system 300 to understand
`the capabilities of the server 110. Although the client 115 is
`able to identify the server 110, the client 115 does not yet
`have any information about the available media.
`If the client 115 determines that the server 110 responded
`to the SERVER-INFO request With an indication that con
`tent codes are supported at 418, the client 115 can optionally
`issue a CONTENT CODE request at 421. The CONTENT
`CODE request is one mechanism by Which the client 115 can
`obtain a list of content codes supported by the server 110 and
`associated string names mapped thereto.
`The inclusion of the string name alloWs multiple devel
`opers to use the same codes for their individualiZed prod
`ucts. For example, one developer may assign the code
`“16000” to a feature that alloWs users to purchase corre
`sponding albums over the netWork; While another developer
`may assign the same code to feature that provides users With
`the lyrics of songs that are being listened to. By alloWing a
`string name to be included, the client 115 can determine
`Whether it can support the content code. Uniqueness of the
`string name can, for example, be ensured by including the
`developer’s URL as part of the string name.
`At 424 the server 110 responds to the CONTENT CODE
`request the codes and their associated string names. At 427,
`the client 115 can simply ignore the code/string pairs that it
`does not recogniZe. OtherWise, for those code/string pairs
`that the client 115 does recogniZe, the client 115 Will
`associate the code With the associated string name.
`At 430 the client 115 logs into the server 110. The login
`procedure might require a user name (or account name) and
`passWord so the user of the client can be authenticated. The
`login procedure is only required if the server 110 requires it.
`Certain security protocols might require that every future
`request made by the client 115 include certain parameters
`such as a session identi?cation number.
`Once logged in, the client 115 is ready to begin populating
`its local representation of the music database 205. FIG. 4B
`is a representational control How diagram illustrating one
`technique that can be used to enumerate databases of the
`server-side media management system 200. Operations per
`formed by the client 115 and the server 110 are represented
`by corresponding vertical lines 403 and 406. At 433 the
`client 115 can issue a SERVER-DATABASE request, Which
`can be used to retrieve the list of all music databases from
`the server 110. The SERVER-DATABASE request may
`additionally include an index range and/or a query. Although
`available to both thick and thin clients, thin clients might use
`index ranges and/or queries to limit the amount of data
`contained in each server response.
`The index range might be used in any request to constrain
`the items returned in the response to a subset of the total set
`of items, based on the position (or index) of the ?rst item and
`the number of items requested. For example, an index range
`could be used to request: the second music database from a
`server, songs 10 through 20 from a music database, the last
`5 playlists from a music database, the ?rst 5 songs from a
`given playlist, or the 42nd song in a music database.
`The query might be used in any request to constrain the
`items returned in the response to a subset of the total set of
`items, based on the speci?ed criteria. For example, a query
`could request: songs in a database after a given year;
`playlists that contain a certain Word in their name; songs in
`a database that do not contain a given Word in their name;
`or some combination thereof.
`After processing the SERVER-DATABASE request at
`436, the server 110 issues a response at 439. If no index
`
`Yamaha Corporation of America Exhibit 1018 Page 15
`
`

`

`US 6,728,729 B1
`
`7
`range and/or query Was given, the response Would contain a
`complete list of the music databases available at the server
`110 together With information about the one or more music
`databases. The information about each database might, for
`example, include the database identi?cation number, the
`persistent database identi?cation number, the name for each
`database, the numbers of songs, and the number of playlists.
`With this information, the client-side media management
`system 300 becomes aWare of the general structure of the
`one or more music databases at the server 110.
`FIG. 5 is a block diagram illustrating the organiZational
`structure of the client-side media management system 300
`shoWn in FIG. 3 after receiving a reply to the SERVER
`DATABASE request. At 442, the client 115 is able to
`identify the music database 510, the number of available
`song records 515, and the number of available playlists 520.
`Once the general structure of the music database 510 is
`knoWn, the client 115 can populate its representation using
`any number of techniques.
`FIG. 4C is a representational control How diagram illus
`trating one technique that could be used to populate the song
`records 515 portion of the client-side media management
`system 300 for a speci?c database 510. Operations per
`formed by the client 115 and the server 110 are represented
`by corresponding vertical lines 403 and 406. At 445 the
`client issues a DATABASE-SONGS request to obtain meta
`data about available songs.
`Athick client may choose to issue a DATABASE-SONGS
`request so that it can front load netWork traf?c. Once
`metadata about a song is received and stored, the client 115
`does not need to request that metadata again. Playlists Would
`only need to correctly identify a song (e.g., using the song
`identi?cation number), and the client-side media manage
`ment system 300 Would be able to associate it With the
`already-received metadata.
`Thin clients may choose to issue an index range, query,
`metadata ?eld speci?er, or skip 445 all together. Ametadata
`?eld speci?er Would indicate that only certain metadata
`?elds are desired. Thick clients that use 445 may also choose
`to use these same index range, query or metadata ?eld
`speci?er techniques. For example, limiting the song meta
`data request to only songs in a certain genre might be a
`technique that is used to provide the user With a different
`user experience.
`The server 10 performs any necessary ?ltering operations
`at 448 and then issues a reply at 451. FIG. 6 is a block
`diagram illustrating the organiZational structure of the
`client-side media management system 300 at 453, after
`receiving a reply to the DATABASE-SONGS request. The
`song records 605 may either be a partial or complete
`representation of the server-side song records 215, having
`metadata that might, for example, include the names of
`songs, an identi?cation number, a persistent identi?cation
`number, the artist, the album, the siZe of the song, the format
`of the song, the required bit rate, and any other appropriate
`information. If the server-side management system 200 had
`multiple databases, a DATABASE-SONGS request (if used)
`Would need to be issued for each database.
`FIG. 4D is a representational control How diagram illus
`trating a technique that could be used to enumerate the
`playlist records 220 portion of the server-side media man
`agement system 200. Operations performed by the client 115
`and the server 110 are represented by corresponding vertical
`lines 403 and 406.
`At 454 the client issues a DATABASE-PLAYLIST
`request to obtain a list of available playlists. Playlists on the
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`8
`server 110 can either be user-identi?ed or generated auto
`matically by the server-side media management system 200.
`For example, a “base playlist” might be automatically cre
`ated as a special playlist that contains all the songs in the
`entire song database 205 While a “John Lennon playlist”
`might be a user-created collection of songs by John Lennon.
`After receiving the DATABASE-PLAYLIST