`Jawa et al.
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`US 6,728,729 B1
`Apr. 27, 2004
`
`US006728729B1
`
`(54) ACCESSING MEDIA ACROSS NETVVORKS
`
`(75)
`
`Inventors: Amandeep J awa, San Francisco, CA
`(US); Jefl'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
`
`Filcd:
`
`Apr. 25, 2003
`
`Int. Cl.7 .............................................. .. G06F 17/30
`U.S. 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
`0,243,713 B1
`6,523,022 B1
`
`**%-)6
`
`7/1999 Sycda—Mahmood .......... .. 707/3
`11/1999 Syeda—Mahm00d .......... .. 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.
`Specification 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.
`“VVWDC 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
`
`MEDIA MANAGER
`
`210
`
`X
`
`215
`
`E 200
`
`205
`
`MUSIC
`DATABASE
`
`
`
`SONGS
`
`220
`
`PLAYLISTS
`
`APPLE 1008
`
`APPLE 1008
`
`
`
`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 1 of 11
`
`US 6,728,729 B1
`
`115
`
`I
`
`110
`
`105
`
`125
`
`I
`
`130
`
`1 i
`
`i
`
`FIGURE 1
`
`2
`
`
`
`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 2 of 11
`
`US 6,728,729 B1
`
`200
`
`300
`
`SERVER-SIDE MEDIA MANAGEMENT SYSTEM
`
`MEDIA MANAGER
`
`M US I C
`DATABAS E
`
`PLAYLISTS
`
`FIGURE 2
`
`MEDIA
`
`CLIENT-SIDE MEDIA MANAGEMENT SYSTEM
`
`MANAGER
`
`FIGURE 3
`
`3
`
`
`
`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 3 of 11
`
`US 6,728,729 B1
`
`SERVER
`
`406f
`
`<
`
`Client Connects to Network
`
`CLIENT
`
`409
`
`403
`
`SERVER—lNFO Request
`
`412
`
`SERVER—lNFO Reply
`
`418
`
`CONTENT CODE Request (Optional)
`
`421
`
`CONTENT CODE Reply
`
`430
`
`427
`
`415
`
`424
`
`Client Logs On (If Necessary)
`
`<
`
`FIGURE 4A
`
`4
`
`
`
`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 4 of 11
`
`US 6,728,729 B1
`
`SERVER
`
`CLIENT
`
`SERVER—DATABASE Request
`
`433
`
`
`
`
`SERVE R—DATABASE Reply
`
`442
`
`See FIG. 5
`
`FIGURE 4B
`
`SERVER
`
`CLIENT
`
`436
`
`439
`
`406
`
`448
`
`4“
`
`
`
`
`403
`
`445
`
`453
`
`S%FB6
`
`DATABASE-SONGS Request
`
`DATABAS E-SONGS Reply
`
`FIGURE 4C
`
`5
`
`
`
`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 5 of 11
`
`US 6,728,729 B1
`
`SERVER
`
`406
`
`CLIENT
`
`403
`
`DATABASE-PLAYLIST Request
`
`454
`
`
`
`
`
`DATABASE—PLAYLIST Reply
`
`457
`
`FIGURE 4D
`
`SERVER
`
`CLIENT
`
`460
`
`463
`
`469
`
`PLAYLIST-SONGS Request
`
`PLAYLIST-SONGS Reply
`
`
`
`
`
`466
`
`See FIG. 7
`
`FIGURE 4E
`
`6
`
`
`
`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 6 of 11
`
`US 6,728,729 B1
`
`SERVER
`
`CLIENT
`
`403
`
`406
`
`
`
`SONG-DATA Request
`
`Stream SONG
`
`472
`
`
`
`475
`
`
`FIGURE 4F
`
`7
`
`
`
`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 7 of 11
`
`US 6,728,729 B1
`
`CLIENT-SIDE DATABASE MANAGEMENT SYSTEM
`
`MEDIA MANAGER
`
`300
`
`""‘7"n
`
`PLAYLISTS
`
`FIGURE 5
`
`8
`
`
`
`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 8 of 11
`
`US 6,728,729 B1
`
`CL|ENT—S|DE DATABASE MANAGEMENT SYSTEM
`
`300
`
`MEDIA MANAGER
`
`"‘“_“H
`PLAYLISTS In
`
`FIGURE 6
`
`9
`
`
`
`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 9 of 11
`
`US 6,728,729 B1
`
`CLIENT-SIDE DATABASE MANAGEMENT SYSTEM
`
`300
`
`MEDIA MANAGER
`
`FIGURE 7
`
`10
`
`10
`
`
`
`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 10 of 11
`
`US 6,728,729 B1
`
`SERVER
`
`CLIENT
`
`805
`
`810
`
`UPDATE Request
`
`815
`
`
`
`820
`
`825
`
`UPDATE Reply
`
`FIGURE 8
`
`11
`
`11
`
`
`
`U.S. Patent
`
`Apr. 27, 2004
`
`Sheet 11 of 11
`
`US 6,728,729 B1
`
`900
`
`Processor(s)
`
`FIGURE 9
`
`12
`
`12
`
`
`
`US 6,728,729 B1
`
`1
`ACCESSING MEDIA ACROSS NETWORKS
`
`BACKGROUND OF TIIE 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. Specifically, 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 significant 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 identifies 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
`identification, the client queries the server for an enumera-
`tion of media collections in the database and receives a
`
`response that identifies media collections. The client then
`queries the server for data associated with an identified
`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 identifies data asso-
`ciated with the identified media collection in the requested
`level of detail. The client then executes the identified media
`
`10
`
`15
`
`'
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`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 first provides a media database that
`updates to a current revision indicator whenever the media
`database is modified. 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 identification 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 flow 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 flow 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 flow 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 [low 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 flow 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 flow 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
`
`13
`
`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 flow diagram illus-
`trating one technique that could be used to ensure the client
`and the server illustrated in FIG. I 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 figures are not neces-
`sarily to scale.
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`10
`
`15
`
`In the following description, numerous specific details are
`set forth to provide a thorough understanding of the present
`invention. IIowever, it will be obvious to one skilled in the
`art that the present invention may be practiced without some
`or all of these specific 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 first 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 notifications 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
`notification that
`the database has changed, or to browse
`media listings.
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`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
`Cupcrtino, Calif., or even network-awarc audio/vidco 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 files 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 files, picture data, movies, text files
`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 identification 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 file 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 identification
`number, a persistent identification 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 file might additionally have director and
`producer fields, but may not use the album field. Still
`pictures would have no need for bit rate information. While
`some fields may be standard, others may be specific to
`certain applications. For example, a video signal may have
`secondary audio program (SAP) information. A niechanisni
`for ensuring clients can properly process non-standard con-
`tent codes is described in connection with FIG. 4A.
`
`Both an identification number and a persistent identifica-
`tion number can be used. If supported, a persistent identi-
`fication could be used to access the same information across
`
`14
`
`14
`
`
`
`US 6,728,729 B1
`
`5
`server restarts. Typically, a server would assign each record
`a new identification number every time the media manage-
`ment system 200 restarted. However, persistent identifica-
`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 identification
`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 managetiietit 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
`
`it
`client-side media management system 300 first starts,
`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 flow 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 first
`
`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 configure 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
`identification
`numbers are supported, whether content codes are
`supported, and the protocol version.
`
`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 identification 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 flow 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 first 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 first 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 specified 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
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`15
`
`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 identification number,
`the
`persistent database identification 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 flow 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 specific 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 traffic. 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
`identification 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 rangc, qucry,
`metadata field specifier, or skip 445 all together. Ametadata
`field specifier would indicate that only certain metadata
`fields are desired. Thick clients that use 445 may also choose
`to use these same index range, query or metadata field
`specifier 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 filtering 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 identification number, a persistent identification
`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 flow 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.
`issues a DATABASE-PLAYLIST
`At 454 the client
`request to obtain a list of available playlists. Playlists on the
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`server 110 can either be user-identified 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 request and
`performing any necessary filtering operations, the server 110
`issues a reply at 457. The reply includes a list of all playlists
`in the music database 205 and information about
`those
`playlists. The information about
`the playlists might, for
`example, include identification numbers and/or persistent
`identification numbers for the playlists, and any other infor-
`mation (e.g., whether the songs in the playlist are in order or
`can be shuffled) that may have been provided. Multiple
`DATABASE-PLAYLIST requests may be required to popu-
`late multiple databases.
`FIG. 4E is a representational control flow diagram illus-
`trating a technique that could be used to populate the playlist
`records 520 portion of the client-side media management
`system 300. Opcrations performed by thc clicnt 115 and the
`server 110 are represented by corresponding vertical lines
`403 and 406. Once a playlist is identified at 460, the client
`115 sends a PLAYLIST—SONGS request for that playlist at
`463. Depending upon whether operations 445 through 451
`were already performed,
`the PLAYLIST—SONGS request
`could additionally request that metadata accompanying each
`song also be delivered in order to populate the song records
`605. Although thick clients that do not have a mechanism for
`informing the server 110 of already-received song records
`605 would run the risk of receiving duplicate song records
`605, thin clients that did not retain song records 605 might
`benefit from requesting song metadata alo