JP4026668B2 - Network AV system - Google Patents

Description

  The present invention relates to a network AV (Audio / Video) system capable of reproducing audio and / or video, and more particularly to a network AV system including a plurality of servers and clients.

Recently, a network AV system using a client server system has been provided. WO 03/102919 ( prior application 1 ) discloses a network AV system including a server storing a large number of contents and an audio client connected via a LAN (Local Area Network). The audio client requests a desired content from the server, and in response, the server delivers the requested content to the audio client. The audio client reproduces the content distributed from the server.

  In the network AV system, if there are a plurality of servers, the accumulated content can be increased. However, if the content stored in each server is different, the audio client has to search in which server the desired content is stored. It is cumbersome to connect to each server until the audio client finds the desired content.

  Also, if the server stops operating while delivering content to the audio client, the playback operation of the audio client is interrupted.

  In addition, if the audio client wants to reproduce another content after receiving and reproducing the content from the server, it is necessary to reconnect to the other server that stores the content to be reproduced.

  One object of the present invention is to provide a network AV system in which a client can easily find a desired content even if a plurality of servers accumulate a plurality of contents.

  Another object of the present invention is to provide a network AV system that allows a client to play back the content to the end even if the server that is delivering the content stops its operation.

  Another object of the present invention is to provide a network AV system in which a client does not need to reconnect a server.

Means for Solving the Problems and Effects of the Invention

Network AV system according to the present invention is a network AV system comprising a plurality of servers comprising a center server and multiple sub servers, and a client,
Each of the center server and the sub server includes a storage unit for storing a plurality of contents, and a local list that lists a plurality of contents stored in the other server from the other server started after the server starts. A local list acquisition means for acquiring the content, a local storage list for storing the local list of contents stored in the local list, and a local list for each of the other servers. The center server further includes global list transmission means for transmitting a global list in which a plurality of local lists are collected to the client in response to a request from the client . The client includes a global list acquisition unit that requests and acquires the global list from the center server. The center server further includes a transmission means for transmitting a takeover command to a server connected to itself first among the other servers started after the center server is started when the center server leaves the network AV system. Prepare. Further, the sub server operates as the center server when receiving the takeover command.

In the network AV system according to the present invention, the center server transmits a global list listing a plurality of contents stored in the center server and the sub server to the client. Therefore, the client does not need to request a list of contents for each server (center server and sub server) in which contents are accumulated, and can easily find desired contents based on the global list.
Further, the center server selects a takeover server that takes over the operation of the center server from among the sub servers, and instructs the takeover server to take over the operation of the center server. As a result, even if the center server ends its operation, another server (sub server) functions as the center server.

Preferably, the client includes content requesting means. Content request means for requesting a selected from a global list sent content Sentasa server. Sentasa server further includes a content reply means. The content reply means returns the content selected in response to the request from the client to the client. The client further includes playback means. Reproducing means for reproducing the content that has been Sentasa bus or we reply.

In this case, the client can easily select a desired content from a plurality of contents stored in a plurality of servers (center server and sub server). The selected content is transmitted from the center server to the client, and the client can reproduce audio or video based on the content.

  Preferably, the content requesting unit requests the selected content from the center server, the center server includes a content return unit, and the center server further includes a server specifying unit and a content acquisition unit. The server specifying unit specifies a server that stores the content selected based on the global list in response to a request from the client. The content acquisition means acquires the content selected from its own storage means when the specified server is a center server, and when the specified server is a sub server, the content acquisition means acquires the content selected from the storage means of the sub server. get. The content reply unit returns the content acquired by the content acquisition unit to the client.

  In this case, the client requests the selected content from the center server. The center server specifies the server (center server and sub server) that stores the content selected in response to the request from the client based on the global list, acquires the content from the specified server, and returns the acquired content to the client To do. That is, the center server has a relay function between the client and the sub server. As a result, if the client connects to the center server, the global list and contents can be acquired.

  Preferably, the global list includes addresses of a plurality of servers storing a plurality of contents corresponding to the plurality of contents, and the server specifying unit specifies the addresses of servers storing the contents requested by the content requesting unit. .

  In this case, the center server can easily specify the server (center server and sub server) that accumulates the content from the address of the server included in the global list.

Preferably, the global list includes specific information of a plurality of servers in which content stored in correspondence with a plurality of contents. The client further includes content requesting means for requesting the content selected from the transmitted global list to the center server or the sub server that stores the selected content based on the specific information . The center server and the sub server further include content return means for returning the selected content to the client in response to a request from the client. The client further includes playback means for playing back the returned content .

  In this case, the client can easily specify the server (center server and sub server) that stores the selected content from the global list. As a result, the client can directly request the content from the server that stores the selected content.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals, and the description thereof is incorporated.

[table of contents]
1. Global list server system 1.1. Outline 1.2. Configuration 1.2.1. Server configuration 1.2.2. Configuration of audio client 1.3. System operation 1.3.1. Server startup processing 1.3.2. Server operation after startup processing 1.3.2.1. Connection operation with other servers 1.3.2.2. Connection operation with audio client 1.3.2.3. Distribution operation 1.3.2.4. List update operation 1.3.2.4.1. When its own local list is updated 1.3.2.4.2. When the local list of another server is updated 1.3.2.4.3. When another server leaves 1.3.2.5. Ending operation 1.4. Global server system including controller 1.4.1. Outline 1.4.2. Configuration 1.4.3. System operation 1.4.3.1. Handle acquisition operation 1.4.3.2. Global list acquisition operation and update operation 1.4.3.3. Monitoring operation 1.4.3.4. Control action Center server system 2.1. Outline 2.2. System operation 2.2.1. Server startup processing 2.2.2. Center server operation after startup processing 2.2.2.1. Distribution operation 2.2.2.2. List update operation 2.2.2.2.2.1 When own local list is updated 2.2.2.3. Ending operation 2.2.3. Sub-server operation after startup processing 2.2.3.1. Connection operation 2.2.3.2. List update operation 2.2.3.2.1. When own local list is updated 2.2.3.2.2. When the local list of another server is updated 2.2.3.2.3. When another server leaves 2.2.2.3. Ending operation 2.3. Center server system including controller 2.3.1. 2. System operation Other Embodiments 3.1. File sharing server system 3.2. Local list transmission system Global list server system 1.1. Referring to FIG. 1, a global list server system 10 includes a plurality of servers SV1 to SV3 for accumulating a large number of song data, and a plurality of songs for reproducing music based on song data from the servers SV1 to SV3. Audio clients CL1 to CL3.

  Here, the servers SV1 to SV3 store music data, but instead of or together with this, video data may be stored, and various other digital contents may be stored. In the following, description will be given using music data as an example. Although the audio clients CL1 to CL3 are displayed in FIG. 1, it is sufficient that at least one audio client CL exists.

  These are connected to each other by a LAN (local area network) 50. However, the present invention is not limited to this, and any suitable device such as USB or IEEE 1394 may be adopted. When adopting a LAN, it is preferable to adopt a standard TCP / IP protocol in a PC (personal computer), but a UDP protocol or the like may be adopted, and the protocol is not particularly limited. Further, in this figure, the server SV and the audio client CL are connected so as to branch off from the basic wiring of the LAN 50. For example, in the case of 10BASE-T or 100BASE-TX, they are connected in a star shape with the hub as the center. .

  The HDD (hard disk drive) 14 of the server SV1 includes a plurality of pieces of music data M11 to M1n (n is a natural number). The HDD 14 of the server SV2 includes a plurality of song data M21 to M2n, and the HDD 14 of the server SV3 includes a plurality of song data M31 to M3n.

  Furthermore, a global list GL is stored in the HDD 14 of each of the servers SV1 to SV3. The global list GL is a list of song names, artists, genres, etc. of each song data. The global list GL includes a list of music piece data M11 to M1n, M21 to M2n, M31 to M3n stored in a plurality of servers SV1 to SV3 belonging to the LAN 50. When the list of song data M11 to M1n is a local list LL1, the list of song data M21 to M2n is a local list LL2, and the list of song data M31 to M3n is a local list LL3, a global list stored in the HDD 14 of the servers SV1 to SV3. The GL includes local lists LL1 to LL3.

  When each server SV updates the music data stored by itself, it sends the updated local lists LL1 to LL3 to the other server SV. Specifically, when new song data is registered in the server SV1, the server SV1 updates the local list LL1. At this time, the server SV1 transmits the updated local list LL1 to the servers SV2 and SV3 ((1) in the figure). The servers SV2 and SV3 receive the updated local list LL1, and replace it with the local list LL1 before update in the global list GL. Similarly, when new song data is registered in the server SV2, the server SV2 updates the local list LL2, and transmits the updated local list LL2 to the servers SV1 and SV3 ((2) in the figure). When new song data is registered in the server SV3, the server SV3 transmits the updated local list LL3 to the servers SV1 and SV2 ((3) in the figure). Through the above operation, the global list GL in each server SV always includes the latest local lists LL1 to LL3.

  Next, an outline of the operation of the global list server system 10 when a music piece is reproduced by the audio client CL will be described. With reference to FIG. 2A, when the music data M31 is reproduced by the audio client CL2, the audio client CL2 requests the global list GL from an arbitrary server SV. In FIG. 2A, the audio client CL2 requests the server SV2 for the global list GL ((4) in the figure), but it may request the server SV1 or the server SV3. Based on the request from the audio client CL2, the server SV2 transmits the global list GL ((5) in the figure). The user of the audio client CL2 refers to the transmitted global list GL and selects a music piece M31 to be reproduced. After the selection, as shown in FIG. 2B, the audio client CL2 requests the music data M31 from the server SV3 ((6) in the figure). The server SV3 receives the request from the audio client CL2, and distributes the music piece data M31 to the audio client CL2 ((7) in the figure).

  With the above operation, in the global list server system 10, once the audio client CL acquires the global list GL from any server SV on the LAN 50, any music stored in the plurality of servers SV can be selected. Therefore, the audio client CL does not need to request the local list LL for each server SV in order to select the music data M stored in the plurality of servers SV on the LAN.

1.2. Configuration 1.2.1. Server Configuration Referring to FIG. 3, the server SV1 includes an HDD (Hard Disk Drive) 14 for storing compressed digital music data, a CPU processing unit 20 including a database management unit 16 and a network protocol processing unit 18, A LAN controller 22 that transmits and receives signals between the server SV1 and the LAN 50; The HDD 14 stores music data M11 to M1n. The server SV2 and the server SV3 have the same structure as the server SV1. Servers SV1 to SV3 are connected to each other.

表１を参照して、サーバリストはサーバＩＤとサーバ情報とを含む。サーバＩＤはサーバＳＶ１と接続した他のサーバＳＶ２又はＳＶ３の識別子である。サーバＩＤはサーバＳＶ１の接続要求に応答した順番に登録される。サーバＳＶ１の接続要求に初めに応答したのがサーバＳＶ２であり、次に応答したのがサーバＳＶ３である場合、表１に示すように、サーバＩＤ＝１にはサーバＳＶ２のサーバ情報が登録され、サーバＩＤ＝２には、サーバＳＶ３のサーバ情報が登録される。 The HDD 14 stores a server list shown in Table 1.

Referring to Table 1, the server list includes a server ID and server information. The server ID is an identifier of another server SV2 or SV3 connected to the server SV1. Server IDs are registered in the order in which they responded to the connection request of the server SV1. When the server SV2 first responds to the connection request of the server SV1 and the server SV3 responds next, the server information of the server SV2 is registered in the server ID = 1 as shown in Table 1. In the server ID = 2, server information of the server SV3 is registered.

表２を参照して、サーバ情報はサーバ特定情報とサーバ名とローカルリストＬＬ２とを含む。サーバ特定情報は、サーバＳＶ２の場所を特定するためのサーバアドレスやポート番号等を含む。サーバアドレスとは、そのサーバＳＶのＩＰ（Internet Protocol）アドレスやＭＡＣアドレス等である。ローカルリストＬＬ２は、サーバＳＶ２に格納されている曲データＭ２１〜Ｍ２ｎのリストである。表３にローカルリストＬＬ２を示す。

表３を参照して、ローカルリストＬＬ２は、サーバＳＶ２がそのＨＤＤ１４内に蓄積する複数の曲データＭ２１〜Ｍ２ｎに関する曲情報Ｉ２１〜Ｉ２ｎを含む。表４に曲情報Ｉ２ｎの詳細を示す。

表４を参照して、曲情報Ｉ２ｎはファイル名と、曲名と、アーティスト名と、アルバム名と、ジャンル名と、曲の長さ（時間）と、ファイルフォーマットと、曲ＩＤと、サーバ特定情報とを含む。ファイル名には、当該曲データＭが格納されているＨＤＤ１４のフルパス名が記録される。

クライアントリストは、サーバＳＶ１にクライアントとして接続された機器に関する情報（クライアント情報）を含む。サーバＳＶ１にクライアントとして接続される機器は、オーディオクライアントＣＬやサーバＳＶである。クライアント情報はクライアントインデックスに対応して登録される。クライアントインデックスは、サーバＳＶ１に接続された機器ごとに付与される識別子である。
クライアント情報を表６に示す。

表６を参照して、クライアント情報中の「flag」はサーバＳＶ１との接続の有無を示す。接続がある場合、「flag」はセットされ、接続がない場合「flag」はリセットされる。 「type」はサーバＳＶ１に接続された機器のクライアントタイプを示す。サーバＳＶ１に接続された機器がオーディオクライアントＣＬであれば、クライアントタイプは「オーディオクライアント」である。接続された機器がサーバＳＶであれば、クライアントタイプは「サーバ」である。 Subsequently, server information of the server SV2 is shown as an example of server information.

Referring to Table 2, the server information includes server specifying information, a server name, and a local list LL2. The server specifying information includes a server address and a port number for specifying the location of the server SV2. The server address is an IP (Internet Protocol) address or a MAC address of the server SV. The local list LL2 is a list of song data M21 to M2n stored in the server SV2. Table 3 shows the local list LL2.

Referring to Table 3, local list LL2 includes song information I21-I2n related to a plurality of song data M21-M2n stored in HDD 14 by server SV2. Table 4 shows details of the music information I2n.

Referring to Table 4, song information I2n includes file name, song name, artist name, album name, genre name, song length (time), file format, song ID, and server identification information. Including. In the file name, the full path name of the HDD 14 in which the song data M is stored is recorded.

The client list includes information (client information) related to devices connected to the server SV1 as clients. A device connected as a client to the server SV1 is an audio client CL or a server SV. Client information is registered corresponding to the client index. The client index is an identifier assigned to each device connected to the server SV1.
Table 6 shows the client information.

Referring to Table 6, “flag” in the client information indicates the presence / absence of connection with server SV1. If there is a connection, “flag” is set, and if there is no connection, “flag” is reset. “Type” indicates the client type of the device connected to the server SV1. If the device connected to the server SV1 is an audio client CL, the client type is “audio client”. If the connected device is a server SV, the client type is “server”.

  Information after “status” is recorded when the client type is “audio client”. “Status” is a current status (state) such as playback, stop, completion, pause, fast forward, and rewind. “Volume” indicates the current volume value (volume). “ProductID” is a product ID (model information) assigned to each client type. “FirmwareID” is a firmware ID indicating the version of the firmware installed in the audio client CL. “Hostname” is a client name assigned to the client device. “SongID” is a song ID for identifying a song being reproduced. “CurKey” is a list construction key necessary for creating a list of songs being reproduced.

  The list construction key includes a filter type and a keyword. Filter types include title name, genre name, artist name, album name, and file name. For example, when the type of filter is an artist name, the name of the desired artist is recorded as the keyword. A desired song list can be created by searching the global list GL with the list construction key. Details are disclosed in the aforementioned prior application 1.

表７を参照して、プレゼンテーションコンテンツリストＰＬは各ローカルリストＬＬ１〜ＬＬ３内の複数の曲データ（Ｍ１１〜Ｍ１ｎ，Ｍ２１〜Ｍ２ｎ，Ｍ３１〜Ｍ３ｎ）の曲情報Ｉ１１〜Ｉ１ｎ，Ｉ２１〜Ｉ２ｎ，Ｉ３１〜Ｉ３ｎの格納場所、すなわち、ＨＤＤ１４内のどの場所に格納されているかを記録する。サーバＳＶ１がオーディオクライアントＣＬからグローバルリストＧＬの要求を受けたとき、サーバＳＶ１はプレゼンテーションコンテンツリストＰＬに基づいて、表８に示すグローバルリストＧＬを更新（作成）し、オーディオクライアントＣＬに送信する。

表８を参照して、グローバルリストＧＬはローカルリストＬＬ１〜ＬＬ３の曲情報Ｉ１１〜Ｉ１ｎ，Ｉ２１〜Ｉ２ｎ，Ｉ３１〜Ｉ３ｎを含む。 The HDD 14 of the server SV further includes a presentation content list PL shown in Table 7.

Referring to Table 7, the presentation content list PL includes song information I11 to I1n, I21 to I2n, I311 to a plurality of song data (M11 to M1n, M21 to M2n, M31 to M3n) in the local lists LL1 to LL3. The storage location of I3n, that is, the storage location in the HDD 14 is recorded. When the server SV1 receives a request for the global list GL from the audio client CL, the server SV1 updates (creates) the global list GL shown in Table 8 based on the presentation content list PL, and transmits it to the audio client CL.

Referring to Table 8, global list GL includes music information I11-I1n, I21-I2n, I31-I3n of local lists LL1-LL3.

1.2.2. Configuration of Audio Client Referring to FIG. 4, the audio client CL temporarily stores a microcomputer processing unit 28 including a network protocol processing unit 24 and a system operation unit 26, a flash memory 30, and sequentially input compressed digital music data. A memory 32 for storing and outputting sequentially, an audio processing unit 34 for decoding compressed digital music data to generate uncompressed digital music data, and a D / A converter for converting digital music data into analog music data ( DAC) 36, and a LAN controller 38 that transmits and receives signals between the audio client CL and the LAN 50. Unlike the server SV, the audio client CL does not include an HDD for storing the song data M.

1.3. System operation 1.3.1. Server Activation Processing Server SV activation processing in the global list server system 10 will be described. When the servers SV2 and SV3 in FIG. 1 are operating and the server SV1 is activated, referring to FIG. 5, the server SV1 searches for other servers SV (SV2 and SV3) on the LAN 50, After the search, the local lists LL2 and LL3 are acquired from the active servers SV2 and SV3. Details will be described below. In this section, the startup process of the server SV1 in FIG. 1 will be described as an example, but the startup processes of the other servers SV (SV2, SV3) are the same.

  Referring to FIG. 5, the server SV1 clears the server list in the HDD 14 before searching for another server SV operating on the LAN 50 (S1). Subsequently, the server SV1 searches for another server SV operating on the LAN 50. Specifically, the server SV1 broadcasts a magic word predetermined at the command port to the LAN 50 by, for example, the UDP protocol (S2). Since the server SV2 and the server SV3 are operating in the LAN 50, the server SV2 and the server SV3 receive the magic word broadcast in step S2 at the search port, and return the same magic word to the broadcast server SV1. At this time, the servers SV2 and SV3 transmit server specifying information (IP address) for specifying themselves to the server SV1.

  Subsequently, the server SV1 resets a timer for measuring the elapsed time after sending the magic word (S3), and then determines whether a magic word reply has been received (S4). When a magic word reply is received (when another server SV is found), the server SV1 records server specifying information of the server SV in the server list (S5). At this time, the server SV1 assigns server IDs in the order of the server SVs to which the magic words are returned, and registers server specifying information. For example, when the magic words are returned in the order of the servers SV2 and SV3, the server SV1 registers the server identification information of the server SV2 in the server ID = 1 of the server list and the server identification information of the server SV3 in the server ID = 2.

  After registering the server specifying information, it is determined whether or not the timer has exceeded a predetermined time, for example, 2 seconds (S6). That is, the server SV1 waits for a response from another server SV for 2 seconds.

  If no magic word reply is received in step S4 (when no other server SV is found), the server SV1 determines whether or not it has exceeded 2 seconds since the magic word was broadcast (S6), and is still If not, the process returns to step S4.

  If it has exceeded 2 seconds after the broadcast, the server SV1 determines whether or not server specifying information is registered in the server list (S7). When the server list is empty, that is, when no server identification information is recorded in the server list, the server SV1 ends the activation process. On the other hand, when the server list is not empty, that is, when the server identification information of at least one server SV is recorded in the server list, the server SV1 performs a connection process to the server SV recorded in the server list (S8 to S8). S12).

  First, the count value n is set to 1 (S8), and it is determined whether or not the number of servers registered in the server list is n or more (S9). As a result of the determination, if the number of servers registered in the server list is n or more, the server SV1 acquires the local list LL of the server SV with the server ID = 1 (S10). This local list acquisition process will be described later. After executing the local list acquisition process, the count value n is counted up (S12), and the process returns to step S9 to continue the local list acquisition process. That is, the local list acquisition process is continued until the local lists LL (LL2, LL3) of all the servers SV (SV2, SV3) registered in the server list are acquired. Here, the local list acquisition process in step S10 will be described.

  When the server SV1 acquires the local list LL2 of the server SV2, referring to FIG. 6, the server SV1 first establishes a connection with the server SV2 (connection process: S1000), and then acquires the local list LL2 (list) Acquisition process: S1010).

  When the server SV1 executes the connection process (S1000), the server SV2 executes the connection response process (S1020). Specifically, the server SV1 generates a socket based on the IP address and command port of the server SV2 registered in the server list in accordance with TCP (Transmission Control Protocol), and requests connection to the server SV2 using this socket ( S1001). The command port is a port for receiving a command from the server SV1 to the server SV2 and transmitting a response from the server SV2 to the server SV1. The server SV2 accepts a connection at the command port (S1021), whereby the server SV1 establishes a connection to the command port of the server SV2.

  Subsequently, the server SV1 transmits a client index request command to the command port (S1002). In response to the client index request command, the server SV2 returns the client index from the command port to the server SV1 (S1022), and the server SV1 receives this (S1003). The client index request command is a command in which the server SV1 requests a client index from the server SV2.

  Subsequently, the server SV1 generates a socket with the IP address and push port of the server SV2 in accordance with TCP, and requests connection to the server SV2 using this socket (S1004). The push port is a port for transmitting a request from the server SV2 to the server SV1. The server SV2 accepts a connection at the push port (S1023), whereby the server SV1 establishes a connection to the push port of the server SV2. However, at this time, the server SV2 has not yet identified which server SV or which audio client CL is connected to the push port. Therefore, the server SV1 transmits the client index received in step S1003 to the push port of the server SV2 (S1005). The server SV2 receives the client index, and thereby identifies that the server SV1 is connected to the push port (S1024). After establishing the push port connection, the server SV1 transmits its client information to the server SV2 (S1006). The server SV2 receives the transmitted client information and registers it in the client list shown in Table 5.

  As a result of the server SV1 executing the connection process (S1000) and the server SV2 executing the connection response process (S1020), when the server SV1 is connected to the server SV2, the server SV1 acquires the local list LL2 of the server SV2 ( List acquisition processing: S1010). At this time, the server SV2 transmits the local list LL2 (list transmission processing: S1030). Specifically, the server SV1 transmits a request command for the local list LL2 to the server SV2 using the command port (S1011). The server SV2 receives the request command from the server SV1, and transmits the local list LL2 of the server SV2 to the server SV1 (S1031). The server SV1 receives the local list LL2 from the server SV2, and registers the local list LL2 in the HDD 14 (S1012). At this time, all server information of the server SV2 is registered in the server list in the server SV1. The server SV1 performs the same operation on the server SV3, and registers the server information of the server SV3 including the local list LL3 in the server list.

  With the above operation, the server SV1 establishes connections with all the servers SV2 and SV3 registered in the server list, and acquires all the local lists LL2 and LL3.

  Returning to FIG. 5, since the count value n exceeds the number of servers in the server list after acquiring the local list LL of all servers SV operating on the LAN 50 (S9), the server SV1 is another server SV on the LAN 50. The local list LL1 owned by itself is transmitted to (local list transmission processing: S11). Details of the local list transmission process in step S11 will be described below.

  Referring to FIG. 7, server SV1 obtains local lists LL of all servers SV in step S10, and then broadcasts a preparation OK command (S1101). After receiving the preparation OK command broadcast from the server SV1, the servers SV2 and SV3 on the LAN 50 execute connection processing (S1000) on the server SV1. At this time, the server SV1 executes connection response processing (S1020). The servers SV2 and SV3 execute list acquisition processing (S1010) after establishing a connection with the server SV1. In response to this, the server SV1 executes list transmission processing (S1030), and transmits the local list LL1 of the server SV1 to the servers SV2 and SV3.

  Through the above operation, the servers SV2 and SV3 can acquire the local list LL1 of the server SV1. Therefore, each server SV accumulates all local lists LL possessed by a plurality of servers SV on the LAN 50.

  In FIG. 7, the server SV1 receives a command port connection request from another server SV or the audio client CL even before the preparation OK command is broadcast. In this case, the server SV1 receives the command port connection request. Absent. This is because the accurate global list GL cannot be transmitted to the audio client unless all the local lists LL of the other servers SV are acquired.

1.3.2. Server Operation After Startup Processing Referring to FIG. 8, server SV after startup executes connection operation (S100), distribution operation (S200), and list update operation (S300). In the connection operation (S100), the local list LL is exchanged by connecting to the server SV newly activated on the LAN 50, or the global list GL is transmitted by connecting to the audio client CL on the LAN 50. In the distribution operation (S200), music data is distributed in response to a request from the audio client CL. In the list update operation (S300), when the own local list LL or the local list LL of another server SV is updated, the updated local list LL is exchanged. After executing each operation, the server SV determines whether or not the operation end for ending its own operation has been selected (S15). The selection of whether or not to end the operation is performed by a user who manages the server SV, for example. If the operation end is not selected, the server SV returns to step S100 and repeats each operation (S100 to S300). On the other hand, when the operation end is selected in step S15, the server SV executes the end operation (S400). Details of each operation will be described below.

1.3.2.1. Connection Operation with Other Servers When a new server SV (hereinafter referred to as an activation server SV) is activated on the LAN 50 while the server SV1 is in operation, the activation server SV broadcasts a server search magic word. Referring to FIG. 9, server SV1 determines whether or not a magic word broadcast by activation server SV has been received (S101). When receiving the magic word, the server SV1 executes a connection response process (S1020) for the broadcasted start server SV to establish a connection with the start server SV. At this time, the server SV1 registers the client information of the activation server SV in the client list.

  After establishing the connection, the server SV1 executes list transmission processing to the activation server SV (S1030), and transmits the local list LL1. After transmitting the local list LL1, the server SV1 determines whether the device connected in step S1020 is the server SV or the client CL (S102). At this time, the server SV1 makes a determination with reference to “type” (client type) in the client information registered in the client list. As a result of the determination, since the connected device is the activation server SV, the server SV1 acquires the local list LL from the activation server SV and registers server information in the server list. This is for updating the global list GL. Therefore, the server SV1 executes connection processing (S1000) with respect to the activation server SV. After executing the connection process, the server SV determines whether or not the connection is successful (S103). Before the activation server SV broadcasts the preparation OK command (that is, after the activation server SV establishes a connection with the server SV1 and acquires the local list LL1, acquisition processing of the local list LLn of another server SV is being executed) When the server SV1 executes the connection process (S1000) to the activation server SV, the connection fails. In this case, after receiving the preparation OK command from the activation server SV (S104), the server SV1 executes the connection process again (S1000). If the connection is successful, the server SV1 executes list acquisition processing to acquire the local list LL from the activation server SV (S1010). After acquiring the local list LL of the activation server SV, the server SV ends the connection operation.

  Through the above operation, the server SV1 can also acquire the local list LL of the newly started server SV.

1.3.2.2. Connection Operation with Audio Client The audio client CL2 on the LAN 50 may request connection to the server SV1 in order to acquire the global list GL. In response to the connection request processing (S120) from the audio client CL, the server SV1 executes a connection operation (S110). Referring to FIG. 10, when audio client CL2 executes a connection process for server SV1 (S1000), server SV1 executes a connection response process (S1020). At this time, the server SV1 registers the client information of the audio client CL2 in the client list.

  After the server SV1 executes the connection response process (S1020), the audio client CL2 transmits a request command for the global list GL to the server SV1 using the command port (S105). The server SV1 receives the global list request command from the audio client CL2, and creates the global list GL based on the presentation content list PL (S106). Specifically, the music information I is acquired from the storage locations of the plurality of music information I registered in the presentation content list PL, and all the music information I is listed to create the global list GL. After creating the global list GL, the server SV1 transmits the global list GL to the audio client CL2 (S107). The audio client CL2 receives the global list GL and registers it in the memory 32 (S108).

  The audio client CL2 can acquire the global list GL from a server SV (SV2, SV3) other than the server SV1. Similarly, the other audio clients CL can acquire the global list GL.

  With the above operation, the client CL can acquire the global list GL including all the music information I on the LAN 50 by connecting to any server SV on the LAN 50.

1.3.2.3. Distribution Operation The user of the audio client CL2 refers to the global list GL acquired from the server SV1 and selects a song to be listened to. When the user selects the song data M31 after referring to the global list GL, referring to FIG. 11, the audio client CL2 requests the server SV3 that stores the selected song data M31 to request the song data M31. The process is executed (S240). The server SV3 that stores the music data M31 requested by the audio client CL3 executes the distribution operation (S200).

  Referring to FIG. 11, the audio client CL2 executes a connection process for the server SV3 (S1000). In the global list GL, server specifying information (IP address and port number) for specifying a server SV in which song data is stored is recorded. The audio client CL2 executes a connection process with respect to the server SV3 based on the server specifying information registered in the music information I31 of the selected music data M31. The server SV3 executes connection response processing (S1020) for the audio client CL2. Thereby, the connection for distributing the music data M31 is established. At this time, the server SV1 maintains the connection with the audio client CL2 established in the connection operation (S100). That is, the audio client CL2 has established a connection with the server SV1 and the server SV3. If the audio client CL2 disconnects from the server SV1 and then attempts to connect to the server SV3 as a result of the connection failure, the audio client CL2 leaves the LAN 50. In order to prevent such a situation, the server SV1 maintains a connection with the audio client CL2.

この曲データ転送要求コマンドは、転送すべき曲データＭ３１の取得開始アドレス及び取得データ長を含む。サーバＳＶ３は曲データＭ３１の転送要求コマンドに応答して、取得開始アドレスにより指定された先頭アドレスからその取得データ長分だけ曲データＭ３１のデータをオーディオクライアントＣＬ２に配信する（Ｓ２０１）。オーディオクライアントＣＬ２は配信された曲データＭ３１のデータをメモリ３２に格納する。メモリ３２は図１２に示すように複数（図１２では８つ）のバッファを含む。図１３に示すように、オーディオクライアントＣＬ２は曲データ転送要求コマンドで曲の先頭から１バッファ分（＝取得データ長）の曲データを取得して格納する（Ｓ２２２）。格納後、オーディオクライアントＣＬ２はメモリ３２のバッファが全て曲データで埋まったか判断し（Ｓ２２３）、図１４に示すようにバッファが全て埋まるまで曲データを取得して格納する。 After the connection between the server SV3 and the audio client CL2 is established, the audio client CL2 transmits a song data transfer request command shown in Table 9 via the command port (S221).

This song data transfer request command includes the acquisition start address and the acquisition data length of the song data M31 to be transferred. In response to the transfer request command of the music data M31, the server SV3 distributes the data of the music data M31 from the head address specified by the acquisition start address for the acquired data length to the audio client CL2 (S201). The audio client CL2 stores the distributed music data M31 in the memory 32. As shown in FIG. 12, the memory 32 includes a plurality of (eight in FIG. 12) buffers. As shown in FIG. 13, the audio client CL2 acquires and stores music data for one buffer (= acquired data length) from the head of the music by a music data transfer request command (S222). After the storage, the audio client CL2 determines whether all the buffers in the memory 32 are filled with music data (S223), and acquires and stores the music data until all the buffers are filled as shown in FIG.

  Steps S221 to S223 are repeated, and when the buffer is completely filled with music data, the audio client CL2 starts reproduction (S224). Specifically, as shown in FIG. 15, music data starts to be output from the head buffer to the audio processing unit 34. When music data is output and played back, there will eventually be an empty space for one buffer as shown in FIG. When the memory 32 becomes empty (S225), the audio client CL2 transmits a music piece data transfer request to the server SV3 again (S226), and the server SV3 distributes the music data for the request (S202). The audio client CL2 stores the distributed music piece data in an empty buffer in the memory 32 (S227). After the storage, the audio client CL2 confirms whether or not all the music data M31 has been received (S228). When all the music data M31 has not been received, that is, when the server SV3 has not yet transmitted all the data of the music data M31 to the audio client CL2, the audio client CL2 and the server SV3 are freed up in the memory 32 due to reproduction. Steps S226, S202, and S227 are repeated. In the above description, the reproduction is started after the buffer is completely filled with music data. However, the reproduction may be started before the buffer is completely filled.

  When the audio client CL2 receives all the music piece data M31 from the server SV3 (S228), the audio client CL2 continues the reproduction operation until all the music piece data M31 is reproduced (S229).

  As described above, the client CL can specify the server SV for storing the selected song data from the global list GL and request the transfer of the song data. In addition, the music data is divided and intermittently distributed from the server SV to the audio client CL, so that music can be appropriately reproduced even if the buffer capacity is small.

1.3.2.4. List update operation The server SV (1) When its own local list LL is updated, (2) When the local list LL of another server SV is updated, (3) The other server ends its operation, and the LAN 50 When the user leaves the list, a list update operation, which is an operation of updating the global list GL, is performed. In such a case, since the number of song data held by the plurality of servers SV on the LAN 50 changes, the audio client CL needs to acquire the latest global list GL after the change. Hereinafter, the list update operations (1) to (3) will be described.

1.3.2.4.1. When its own local list is updated Referring to FIG. 17, when new song data M12 is stored in the HDD 14 of the server SV1, the server SV1 updates the local list LL1 (S301). Further, the server SV1 deletes the presentation content list PL before the local list LL1 is updated (S302). Thereafter, a new presentation content list PL corresponding to the local list LL1 updated in step S301 is created (S303).

  After creating a new presentation content list PL, a list update notification is sent to all servers SV and audio clients CL that have established connections to the server SV1 (S304 to S307). Specifically, the server SV1 sets the count value n = 1 (S304), and determines whether n is larger than the number of clients registered in the client list (S305). As a result of the determination, if the number of clients is n or more, the server SV1 transmits a list update notification to the server SV or the audio client CL with the client index = n (S306). After the notification, the server SV1 counts up n (S307) and returns to step S305.

  By repeating the above operation, the list update notification can be transmitted to all the servers SV and audio clients CL that have established connections with the server SV1. When n is larger than the number of clients in step S305, the server SV1 notifies all the servers SV and audio clients CL in the client list, and thus ends its operation.

[Operation of audio client that received list update notification from server]
Referring to FIG. 18, the audio client CL that has received the list update notification (S306) from the server SV1 first deletes the global list GL registered in the memory 32 (S351). Subsequently, the audio client CL transmits a global list request command to the server SV1 (S352). The server SV1 receives the global list request command, and transmits the updated global list GL to the audio client CL2 (S308). The audio client CL registers the transmitted global list GL in the memory 32 (S353).

  Next, the operation of another server SV that has received the list update notification transmitted in step S306 will be described.

1.3.2.4.2. When Local List LL of Other Server is Updated Referring to FIG. 19, when server SV2 receives the list update notification transmitted from server SV1 in step S306 (S311), server SV2 has an existing presentation content list. The PL is deleted (S312). After the deletion, the server SV2 deletes the local list LL1 registered in the HDD 14 (S313). After deleting the local list LL1, the server SV2 requests the updated local list LL1 from the server SV1 (S314). The server SV1 receives the request from the server SV2 (S331), and transmits the updated local list LL1 (S332). The server SV2 receives the transmitted local list LL1 and registers it in the HDD 14 (S315). After registration, the server SV2 creates a presentation content list PL (S316). Thereby, the global list GL is updated.

  After creating the presentation content list PL, the server SV2 performs list update notification processing (S320) in order to transmit the updated global list GL to the plurality of audio clients CL connected to the server SV2. Specifically, after setting the count value n = 1 (S321), the server SV2 determines whether the number of clients registered in the client list is n or more (S322). As a result of the determination, if the number of clients is n or more, the server SV2 determines whether or not the device with the client index = n is the audio client CL (S323). The determination is made based on “type” (client type) in the client information registered in the client list. As a result of the determination, if “type” of the client index = n is “audio client”, the server SV2 transmits a list update notification to the audio client CL (S324). After transmission, the count value n is counted up (S325), and the process returns to S325. On the other hand, as a result of the determination in step S323, if “type” of the client index = n is “server”, the process proceeds to step S325 without transmitting the list update notification. This is because the list update notification is transmitted from the server SV1 to the other server SV, so that the server SV2 only needs to send the list update notification to the audio client CL.

  By repeating the above operation, a list update notification is transmitted to all audio clients CL connected to the server SV2. The operation of the audio client CL that has received the list update notification is the same as in FIG.

1.3.2.4.3. When another server leaves the server Referring to FIG. 20, when the server SV2 operating on the LAN 50 stops its operation and leaves the LAN 50, the server SV2 is transferred to another server SV (SV1, SV3) on the LAN 50. On the other hand, a notification of departure is broadcasted (S335). The server SV1 receives the withdrawal notification from the server SV2 (S311), and deletes the existing presentation content list PL (S312). Further, the server SV1 deletes the local list LL2 registered in the HDD 14 (S313). After deleting the local list LL2, the server SV1 creates a presentation content list PL (S316). Accordingly, the global list GL created based on the presentation content list PL does not include the local list LL2. After creating the presentation content list PL, the server SV1 executes list update notification processing (S320). The server SV3 performs the same operation as the server SV1.

  Through the above list update operation, the audio client CL can always acquire the latest global list GL.

1.3.2.5. Ending Operation When the server SV1 connected to the audio client CL ends the operation and leaves the LAN 50, it is preferable to change the connection destination of the audio client CL to another server SV on the LAN 50. Further, when the server SV1 leaves during the distribution of music data to the audio client CL, it is preferable to deal with such that the client CL can continue to receive the music data.

  Referring to FIG. 21, when server SV1 ends its operation, first, count value n = 0 is set (S401), and it is determined whether or not the number of audio clients CL connected to server SV1 is larger than n. (S402). The determination in step S402 is made based on the client list. As a result of the determination, if the number of audio clients CL is n or less, the audio client CL is not connected to the server SV1. Accordingly, the server SV1 transmits a leave notification to another server SV (S335). End the operation.

  On the other hand, if the number of audio clients CL is larger than n in step S402 (that is, if there is an audio client CL connected to the server SV1), it is determined whether or not the audio client CL with client index = n is currently being reproduced. Judgment is made (S403).

  As a result of the determination, if the audio client CL with the client index = n is not being reproduced (hereinafter, this audio client CL is referred to as CL2), the server SV1 instructs the audio client CL2 to switch the connection to the takeover server SV. Is transmitted (S404). Here, the takeover server SV is a server SV that takes over the connection with the audio client CL2. The server SV1 determines the takeover server SV based on the server list. Specifically, the server SV having the server ID = 1 in the server list is determined as the takeover server SV. For example, when the server identification information of the server SV2 is registered in the server ID = 1, the server SV1 determines the takeover server SV as the server SV2. After transmitting the server switching instruction, the server SV1 counts up the count value n (S407) and returns to step S402 again.

  After receiving the server switching instruction from the server SV1 (S431), the audio client CL2 disconnects from the server SV1 (S432). After the disconnection, the audio client CL2 executes a connection process for the server SV2 in accordance with the switching instruction (S1000). At this time, the server SV2 executes a connection response process (S1020). After establishing connection with the server SV2, the audio client CL2 executes list acquisition processing (S1010). At this time, the server SV2 executes list transmission processing (S1030). With the above operation, even when the server SV1 ends the operation, the audio client CL2 can acquire the latest global list GL from the server SV2 by switching the connection destination to the server SV2.

  On the other hand, as a result of the determination in step S403, if the audio client CL with the client index = n is reproducing the song data M11 (hereinafter, this audio client CL is referred to as CL1), even after the server SV1 finishes the operation. The audio client CL1 needs to receive the continuation of the distribution of the music data M11. This is because if the distribution of the music data M11 is interrupted, the audio client CL1 must end the reproduction of the music data M11 in the middle. Therefore, the server SV1 finishes the operation after dealing with the takeover server SV to continue the distribution of the music data M11. Specifically, the server SV1 executes the music data takeover process of the music data M11 with respect to the server SV2 (S404). At this time, the server SV2 executes music data acceptance processing (S414). Hereinafter, the music data takeover process and the music data takeover process will be described.

  Referring to FIG. 22, the server SV1 requests the server SV2 to register the music data M11 being distributed to the audio client CL1 (S4041). The server SV2 receives the request from the server SV1 (S4111), and registers a new song ID in the HDD 14 to store the song data M11 (S4112). The server SV2 transmits the new song ID to the server SV1 (S4113). The server SV1 receives the new song ID, and transmits the song data M11 to which the received new song ID is assigned to the server SV2 (step S4043). The server SV2 receives the music data M11 and stores it in the area of the new music ID in the HDD 14 (S4114). With the above operation, the music data M11 is taken over from the server SV1 to the server SV2.

  Returning to FIG. 21, after the server SV2, which is the takeover server SV, takes over the song data M11 from the server SV1, the audio client CL1 determines from which position in the song data M11 the data distribution server SV2 should be requested. There is a need. This is because the audio client CL1 receives the distribution of the music data M11 from the server SV1 and does not need to receive the music data M11 from the server SV2. Therefore, the server SV1 calculates the acquisition start address of the music data M11 that the audio client CL1 receives from the server SV2 (S405). Specifically, the server SV1 determines a value obtained by adding the data length of the music data M11 distributed so far to the audio client CL2 to the head address of the music data M11 as an acquisition start address. After calculating the acquisition start address, the server SV1 transmits a playback command to the audio client CL2 (S406). The reproduction command includes the server identification information of the server SV2 and the acquisition start address calculated in step S405 as parameters.

  After transmitting the reproduction command, the server SV1 increments the count value n (S407), returns to step S402 again, and repeats the operation. As a result, the end operation can be executed for all the audio clients CL connected to the server SV1. After executing the termination operation for all audio clients CL, that is, when the count value n exceeds the number of client connections (S402), the server SV1 transmits a leave notification to the other server SV (S335), End the operation.

  After receiving the reproduction command from the server SV1 (S421), the audio client CL1 disconnects from the server SV1 (S422). After the disconnection, the client connection request process (S120) is executed for the server SV2, and the server SV2 executes the connection operation (S110), so that the audio client CL1 establishes a connection to the server SV2. Thereafter, the audio client CL1 executes a distribution request process (S240). At this time, the audio client CL2 makes a music piece data transfer request using the acquisition start address received in step S421 as a parameter. The server SV2 executes a distribution operation based on the acquisition start address in the song data transfer request (S200). With the above operation, the audio client CL2 can acquire the continuation of the music piece data M11 from the server SV2, and can continue the reproduction of the music piece data M11.

  As described above, when the server SV finishes its operation, even if there is an audio client CL to which music data is distributed (that is, being reproduced) from the server SV, the music data is sent to the takeover server SV. Take over. Therefore, the audio client CL can continue reproduction.

1.4. Global server system including controller 1.4.1. Outline The global server system 10 may include a controller CN as shown in FIG. The controller CN is connected to the servers SV1 to SV3 and controls the audio clients CL1 to CL3 via the servers SV1 to SV3. For example, the controller CN causes the desired audio client CL to play a desired song or stop the song being played. Although one controller CN is shown in FIG. 23, there may be a plurality of controllers CN.

  FIG. 24 shows a connection relationship among the servers SV1 to SV3, audio clients CL1 to CL3, and the controller CN shown in FIG. As shown in FIG. 24, the controller CN is connected to all the servers SV1 to SV3. The audio clients CL1 to CL3 are connected to any of the servers SV1 to SV3. In FIG. 24, the audio client CL1 is connected to the server SV1, and the audio clients CL2 and CL3 are connected to the server SV2. That is, the audio client CL1 acquires the global list GL from the server SV1, and the audio clients CL2 and CL3 acquire the global list GL from the server SV2.

  Returning to FIG. 23, when the controller CN causes the audio client CL2 to play a song based on the song data M31, the controller CN transmits a playback command to the audio client CL2. Specifically, after confirming that the audio client CL2 is connected to the server SV2, the controller CN transmits a playback command to the audio client CL2 via the server SV2 ((1) in the figure) (in the figure). (2)). The operation of the audio client CL2 that has received the playback command is the same as (B) in FIG.

1.4.2. Configuration The controller CN functions as a client for the servers SV1 to SV3. Referring to FIG. 25, the controller CN includes a LAN controller 38, a microcomputer processing unit 28, a flash memory 30, a memory 32, a display device 37 such as a CRT or LCD, and an input device 39 such as a keyboard or a mouse. . The controller CN is different from the audio client CL in that the audio client CL has a reproduction function, whereas the controller CN does not have to have a reproduction function, and mainly has a monitoring function and a control function of the audio client CL. is there.

表１０を参照して、コントローラ用サーバ情報は、表２と比較して、ローカルリストＬＬの代わりにクライアントリスト（「clientlist」）が登録される。クライアントリストには、サーバＳＶ１〜ＳＶ３が持つ全てのクライアント情報が登録される。要するに、コントローラＣＮはサーバＳＶ１〜ＳＶ３が持つ全てのクライアント情報を持つ。そのため、コントローラＣＮはグローバルサーバシステム１０で稼働するオーディオクライアントＣＬ１〜ＣＬ３の存在を把握し、かつ、各オーディオクライアントＣＬがどのサーバＳＶと接続しているかを把握する。 A controller server list having the same configuration as in Table 1 is registered in the memory 32 of the controller CN. Table 10 shows server information (controller server information) registered in the controller server list.

Referring to Table 10, in the controller server information, a client list (“clientlist”) is registered instead of the local list LL as compared with Table 2. All client information possessed by the servers SV1 to SV3 is registered in the client list. In short, the controller CN has all client information possessed by the servers SV1 to SV3. Therefore, the controller CN grasps the existence of the audio clients CL1 to CL3 operating in the global server system 10, and grasps which server SV each audio client CL is connected to.

  Furthermore, a global list GL is also registered in the memory 32.

1.4.3. System operation 1.4.3.1. Handle acquisition operation The controller CN is connected to all the servers SV of the global server system 10, and acquires a monitoring handle and a control handle for monitoring and controlling the audio clients CL1 to CL3 connected to each server SV.

  Referring to FIG. 26, the operations in steps S1 to S7 are the same as those in FIG. In short, the controller CN searches for the servers SV1 to SV3 operating on the LAN 50, and registers the server specifying information of the servers SV1 to SV3 in the server list.

  If it is determined in step S7 that the server identification information is registered in the server list, a handle acquisition process is executed for each server registered in the server list (S71 to S74). First, the count value n is set to 1 (S71), and it is determined whether or not the number of servers registered in the server list is n or more (S72). When the number of servers is n or more, the server SV1 executes a handle acquisition process for the server SV with the server ID = 1 (S73). After executing the handle acquisition process, the count value n is counted up (S74), and the process returns to step S72. In short, the controller CN executes a handle acquisition process for all servers registered in the server list. As an example, a handle acquisition process for the server SV2 will be described.

  Referring to FIG. 27, controller CN executes a connection process for server SV2 (S1000). At this time, the server SV2 executes a connection response process (S1020). The controller CN establishes a connection with the server SV2 by the connection process and the connection response process. In the connection process, the controller CN transmits its own client information to the server SV2. At this time, the controller CN notifies that the client type is “controller”.

  After establishing the connection, the controller CN transmits a client list request command to the server SV2 (S7301). The server SV2 receives the client list request command and transmits the client list in the HDD 14 to the controller CN (S7302). Since the audio clients CL2 and CL3 and the controller CN are connected to the server SV2, the client list transmitted in step S7302 includes the client information of the audio clients CL2 and CL3 and the client information of the controller CN. . After receiving the client list, the controller CN registers it in the controller server list in the memory 32 (S7303). More specifically, the acquired client list is registered in “clientlist” of the controller server information of the server SV2 in the controller server list.

  After registering the client list, the controller CN requests and acquires the monitoring handle and control handle of the audio clients CL2 and CL3 connected to the server SV2 from the server SV2 based on the client list (S7305 to S7311). The monitoring handle is an authority to monitor the audio client CL given from the server SV to the controller CN. The control handle is an authority to control the audio client CL given from the server SV to the controller CN.

  The controller CN sets the count value n = 1 (S7304), and determines whether the number of clients in the client list is n or more (S7305). When the number of clients is n or more, the controller CN determines whether or not the client information with the client index = 1 is its own information (S7306). If it is not its own client information, the client index (= 1) is transmitted to the server SV2, and its monitoring handle and control handle are requested (S7307).

  The server SV2 records the client index (= 1) transmitted from the controller in association with the client index of the controller CN (S7308), and issues a monitoring handle and a control handle to the controller CN (S7309). As a result, the controller CN acquires the monitoring handle and control handle of the audio client CL corresponding to the client index = 1 (S7310).

  Subsequently, the controller CN increments the count value n (S7311), and returns to the operation of step S7305. In short, the controller CN obtains a monitoring handle and a control handle for all audio clients CL (here CL2 and CL3) registered in the client list. If it is determined in step S7306 that the client information with the client index = n is its own client information, the process advances to step S7311. This is because the controller does not need to obtain a monitoring handle and a control handle for itself.

  The handle acquisition process is executed for all the servers SV1 to SV3. Therefore, the controller CN acquires the monitoring handles and control handles of all the audio clients CL1 to CL3 operating in the global server system 10.

1.4.3.2. Global List Acquisition Operation and Update Operation The operation in which the controller CN acquires the global list GL from the server SV is the same as the operation of the audio client CL2 in FIG. The controller CN acquires the global list GL from an arbitrary server SV. If connections have already been established with all the servers SV1 to SV3 by the handle acquisition operation, the controller CN requests a global list from any server SV without executing the connection process (S1000) in FIG. (Step S105 in FIG. 5). The arbitrary server SV is, for example, a server SV with a server ID = 1 in the controller server list.

  Similarly to the audio client CL, the controller CN receives a list update notification from the server SV and updates the global list GL. The operation for updating the global list is the same as in FIG.

  With the above operation, the controller CN can always acquire the latest global list.

1.4.3.3. Monitoring Operation The controller CN can monitor the audio client CL by acquiring a monitoring handle. Referring to FIG. 28, when the volume value of the audio client CL2 is changed, the audio client CL2 transmits a volume value change notification to the server SV2 (S7501). The volume value change notification includes information on the changed volume value.

  After receiving the volume value change notification, the server SV2 updates the client information of the audio client CL2 (S7502). Specifically, the data of “volume” in the client information is updated. The server SV2 further transmits the updated client information to the controller CN that has acquired the monitoring handle of the audio client CL2 (S7503).

  The controller CN receives the updated client information and updates the client information of the audio client CL2 in the controller server list (S7504). The updated client information is displayed on the display device 37 (S7505).

  The above process is repeated each time client information of all the audio clients CL1 to CL3 from which the controller CN has acquired the monitoring handle is updated.

  As described above, when the server SV receives client information from the audio client CL, the controller CN can always monitor the audio client CL by transmitting the client information to the controller CN.

1.4.3.4. Control operation The controller CN can control the audio client CL by obtaining a control handle. As an example of the control operation, a process in which the controller CN instructs the audio client CL2 to play a song based on the song data M31 will be described. The song data is selected based on the global list GL held by the controller CN.

  Referring to FIG. 29, controller CN selects song data M31 based on global list GL (S7601). After the selection, the controller CN identifies the server connected to the audio client CL2 based on the controller server list (S7602). Specifically, the controller CN refers to the controller server list and determines that the server information having the client information of the audio client CL2 is the server information of the server SV2. In other words, the controller CN determines that the server connected to the audio client CL2 is the server SV2. Therefore, the controller CN transmits a reproduction command to the server SV2 (S7601). The reproduction command includes information (for example, song ID) for specifying the song data M31.

  The server SV2 transmits the reproduction command transmitted from the controller CN to the audio client CL2 (S7602). In short, the controller CN transmits a reproduction command to the audio client CL2 via the server SV2.

  Upon receiving the playback command, the audio client CL2 executes a distribution request process in order to acquire and play the music data M31 (S240). At this time, the server SV3 executes a distribution operation (S200).

  FIG. 29 shows the operation in the case of instructing the reproduction of the music, but the same applies to the case of stopping the music reproduction. When the controller CN transmits a music playback stop command to the audio client CL2 via the server SV2, the audio client CL2 stops music playback. The same applies to control such as volume adjustment.

  With the above operation, the controller CN can control the audio client CL that has acquired the control handle.

  If the global server system 10 includes a plurality of controllers CN, a plurality of control handles for each audio client CL are not issued. In other words, only one controller CN can control each audio client CL. On the other hand, the monitoring handle of each audio client CL is issued redundantly, and a plurality of controllers CN can monitor one audio client CL.

2. Center server system 2.1. Outline FIG. 30 is a diagram showing an overall configuration of a center server system. Referring to FIG. 30, the center server system 70 includes a center server CSV, a plurality of sub servers SSV1, SSV2, and a plurality of audio clients CL1 to CL3. These are connected to each other via a LAN 60. The configurations of the center server CSV and the sub server SSV are the same as those in FIG. In FIG. 30, the number of subservers SSV is two (SSV1, SSV2). However, one or more subservers SSV are sufficient. Further, it is sufficient if there are one or more clients CL.

  In the global list server system 10, all the servers SV1 to SV3 on the LAN 50 have the global list GL, whereas in the center server system 70, only the center server CSV has the global list GL. The center server CSV further includes song data M31 to M3n and a local list LL3. On the other hand, the sub server SSV1 includes music data M11 to M1n and a local list LL1, and the sub server SSV2 includes music data M21 to M2n and a local list LL2.

  When the music data stored therein are updated, the sub-servers SSV1 and SSV2 transmit the updated local lists LL1 and LL2 to the center server CSV ((1) in the figure). The center server CSV receives the local lists LL1 and LL2, and updates the global list GL together with the local list LL3. The local list LL3 is not transmitted from the center server CSV to the sub servers SSV1 and SSV2. In addition, the local lists LL1 and LL2 are not transmitted and received between the sub server SSV1 and the sub server SSV2.

  Referring to FIG. 31A, the plurality of audio clients CL1 to CL3 transmit a transfer request for the global list GL to the center server CSV ((2) in the figure). The center server CSV receives the request for the global list GL and transmits the global list GL to each of the audio clients CL1 to CL3 ((3) in the figure).

  When the audio client CL2 reproduces the song data M21 after receiving the global list GL, the audio client CL2 transmits a song data transfer request for the song data M21 to the center server CSV with reference to FIG. Medium (4)). The center server CSV receives the music data transfer request and requests the sub server SSV2 storing the music data M21 to distribute the music data M21 to the center server CSV ((5) in the figure). Referring to FIG. 31C, the sub server SSV2 receives the request from the center server CSV and distributes the music piece data M21 to the center server CSV ((6) in the figure). The center server CSV distributes the music data M21 distributed from the sub server SSV2 to the audio client CL2 ((7) in the figure).

  As described above, in the center server system 70, all requests from the audio client CL such as a transfer request for the global list GL and a music data transfer request are transmitted to the center server CSV. The music data M is distributed from the sub server SSV to the audio client CL via the center server CSV. The center server CSV relays between the sub server SSV and the audio client CL, and also includes the music data M, and distributes the music data M stored therein directly to the audio client CL. The audio client CL can play back all music data M on the LAN 60 if requested to the center server CSV.

  When the music data M is requested from the audio client CL, a music data transfer request may be made to the sub server SSV that stores desired music data M without going through the center server CSV server.

2.2. System operation 2.2.1. Server Activation Process In the center server system 70, the server SV activated first on the LAN 60 operates as the center server CSV, and the server SV activated second and later operates as the sub server SSV.

  Referring to FIG. 32, the operation from step S1 to S6 of the server SV at the time of activation (hereinafter referred to as activation server SV) is the same as in FIG. The activation server SV broadcasts a magic word to determine whether another server SV on the LAN 60 is already operating. After two seconds have passed since the broadcast, if there is no server specific information in the server list (S7), the other server SV does not exist on the LAN 60, so the activation server SV operates as the center server CSV (S50). Regarding the operation of the center server CSV, 2.2.2. I will explain it.

  On the other hand, if the server specifying information is included in the server list in step S7, the center server CSV is already operating, so the activation server SV operates as the sub server SSV. At this time, the sub server SSV executes connection processing to the center server CSV (S1000). The connection process at this time is the same as the operation in step S1000 in FIG. When the sub server SSV executes the connection process (S1000), the center server CSV performs a connection response process (the same process as S1020 in FIG. 6).

  After the connection process to the center server CSV (S1000), the sub server SSV executes a local list transmission process for the center server CSV (S11), and transmits its local list LL to the center server CSV. Details of the local list transmission processing are the same as those in FIG. The server SV in the global list server system 10 broadcasts a preparation OK command after executing connection processing to all other servers SV, but the sub server SSV performs connection processing to the center server CSV. Broadcast a preparation OK command.

  As a result of the above operation, when the activation server SV becomes the sub server SSV, after connecting to the center server CSV and transmitting its own local list LL to the center server CSV, the operation of the sub server SSV is executed (S65). Regarding the operation of the sub server SSV, see 2.2.3. I will explain it.

2.2.2. Center Server Operation after Startup Processing Referring to FIG. 33, the center server CSV executes a connection operation (S100, S110), a distribution operation (S500), and a list update operation (S600), and ends (S15). The operation (S700) is executed. The connection operation (S100, S110) is the same as the server connection processing operation (1.3.2.1 and 1.3.2.2) in the global list server system 10. The distribution operation (S500), list update operation (S600), and end operation (S700) will be described below.

2.2.2.1. Distribution operation When the audio client CL2 that has acquired the global list GL from the center server CSV selects the music data M21 of the sub server SSV2 from the global list GL, the audio client CL2 transmits a music data transfer request to the center server CSV. The music data M21 is received from the server SSV2 via the center server CSV and played. Details will be described below.

  Referring to FIG. 34, first, the audio client CL2 executes a connection process with respect to the center server CSV (S1000). On the other hand, the center server CSV executes a connection response process (S1020). By this connection process, a connection for distributing the music data M21 is established between the center server CSV and the audio client CL2. At this time, the center server CSV also maintains the connection with the audio client CL2 established in the previous connection operation (S110). Therefore, the audio client CL2 has established a connection for receiving the global list and a connection for receiving music data with the center server CSV. Thus, by separating the command port for global list reception and the command port for music data transfer request, traffic congestion can be alleviated.

  The operation of the audio client CL2 after the connection process is the same as the operation of the audio client CL2 in FIG.

  When the audio client CL transmits a song data transfer request for the song data M21 to the center server CSV in step S221, the center server CSV executes song data distribution processing (S501). Hereinafter, the music data distribution process will be described.

  Referring to FIG. 35, center server CSV receives a song data transfer request from audio client CL2 (S5011), and determines whether the requested song data is song data in center server CSV (S5012). If the song data is in the center server CSV, the center server CSV distributes the song data to the audio client CL2 (S5015).

  Since the audio client CL2 now requests the music data M21 (S5012), the center server CSV acquires the music data M21 from the sub server SSV2 that stores the music data M21, and distributes it to the audio client CL2. First, the center server CSV executes connection processing for the sub server SSV2 (S1000). On the other hand, the sub server SSV2 executes a connection response process (S1020), and establishes a connection for music data transfer request between the servers. In order to alleviate traffic congestion, a connection for music list data transfer is established together with a connection for obtaining a local list. After establishing the connection, the center server CSV executes music piece data relay processing (S502). Specifically, the center server CSV transmits a song data transfer request for the song data M21 to the sub server SSV2 (5013). The sub server SSV2 receives the song data transfer request and distributes the song data M21 to the center server CSV based on the acquisition start address and the data length in the song data transfer request (S5014). The center server CSV distributes the music data M21 distributed from the sub server SSV2 to the audio client CL2 (S5015).

  With the above operation, the center server CSV distributes the music data M21 to the audio client CL2 in S501.

  Note that after the audio client CL2 starts playing the music in step S224, the center server CSV that has received the music data transfer request in step S226 executes the music data relay process (S502), and continues to deliver the music data M21.

  With the above operation, the center server CSV relays between the sub server SSV2 and the audio client CL2, so that the audio client CL2 can reproduce the music piece data M21.

  Since the client CL2 can recognize from the global list GL that the song data M21 is stored in the sub server SSV2, the client CL2 directly executes a distribution request process for the sub server SSV2 (S240), and the sub server SSV2 May execute the distribution operation (S200). The operation in this case is the same as in FIG.

2.2.2.2. List Update Processing In the center server system 70, only the center server CSV creates the global list GL. Therefore, when the center server CSV registers new song data, the center server CSV does not need to send a list update notification to a plurality of sub-servers SSV on the LAN 60, and performs a list update notification only to the audio client CL. . The operation of the center server CSV in response to the list update notification from the sub server SSV is the same as the operation of the server SV2 in FIG. Further, the operation of the center server CSV when the sub server SSV leaves is the same as the operation of the server SV1 in FIG. Hereinafter, the list update operation of the center server CSV when the center server CSV registers new music data M31 will be described.

2.2.2.2.1. When the server updates the list Referring to FIG. 36, when the song data M31 is updated, the center server CSV updates the local list LL3 (S601) and deletes the existing presentation content list PL (S602). ). Thereafter, a new presentation content list PL is created (S603), and list update notification processing is executed (S320). The list update notification process is performed for a plurality of audio clients CL on the LAN 60.

2.2.2.3. End operation [End operation of center server when client CL is not playing]
Referring to FIG. 37, the end operation (S403, S405, S335, S431, S432, S1000, S1020) of the center server CSV when the audio client CL is not playing from step S401 (in the case of client CL2 in FIG. 37). Is the same as FIG.

[End operation of center server that is distributing song data of sub server]
When the audio client CL1 is reproducing music data (S403), the center server CSV determines whether or not the music data being reproduced by the audio client CL1 is music data stored in the center server CSV itself (S701). As a result of the determination, if the music data is not stored in the center server CSV, for example, if the audio client CL1 is reproducing the music data M21, the center server CSV is performing relay processing of the music data M21. At this time, the center server CSV calculates an acquisition start address (S405). The acquisition start address is calculated based on the song data length that the center server CSV has already acquired from the sub server SSV2. The calculated acquisition start address is included in the reproduction request command and transmitted to the audio client CL1 (S406). Note that the reproduction request command includes server specifying information of the takeover server SV of the center server CSV. The center server CSV sets the sub server SSV with the server ID = 1 in the server list stored therein as the takeover server SV. When the server ID = 1 is the sub server SSV1, the sub server SSV1 also receives a takeover command when receiving a withdrawal notification from the center server CSV, and operates as the center server CSV.

  After transmitting the reproduction command, the center server CSV increments the count value n and returns to step S402.

  After receiving the reproduction command from the center server CSV (S421), the audio client CL1 disconnects from the center server CSV (S422). After the disconnection, the client connection request process (S120) is executed for the takeover server SV (sub server SSV1), and the takeover server SV executes the connection operation (S100), so that the audio client CL1 receives the call from the takeover server SV. Establish a connection. Thereafter, the audio client CL1 executes a distribution request operation (S240). At this time, the audio client CL1 makes a music piece data transfer request using the acquisition start address received in step S421 as a parameter. The takeover server SV executes the distribution operation based on the acquisition start address in the music data transfer request (S500). With the above operation, the audio client CL1 can acquire the continuation of the music piece data M21 from the takeover server SV and can continue the reproduction of the music piece data M21.

[End operation of the center server that is distributing its song data]
As a result of the determination in step S701, when the music data M31 is being reproduced by the audio client CL1, the center server CSV needs to transmit the music data M31 stored therein to the takeover server SV. Therefore, the center server CSV executes music piece data takeover processing (S404). In addition, the takeover server SV executes music data acceptance processing (S411). After the music data takeover process, the center server CSV proceeds to step S405.

After transmitting the reproduction command in step S406, the center server CSV increments the count value n (S407), returns to step S402 again, and repeats the operation. As a result, the end operation can be executed for all the audio clients CL connected to the center server CSV. After the end operation is executed for all audio clients CL, that is, when the count value n exceeds the number of client connections (S402), the center server CSV transmits a leave notification to the plurality of subservers SSV (S335). The operation is finished.
The center server CSV also transmits a takeover command to the takeover server when sending the leave notification to the other subserver SSV.

2.2.3. Sub-Server Operation After Startup Processing In the center server system 70, the center server CSV performs all transmissions of the global list GL and the music data M to the audio client CL. Therefore, the center server CSV acquires the updated local list LL from the sub server SSV by performing the connection operation (S100) and the list update operation (S500), and distributes the latest global list GL to the audio client CL. On the other hand, as shown in FIG. 38, the sub server SSV also performs the connection operation (S650) and the list update operation (S550). Although the sub server SSV does not distribute the global list GL to the audio client CL, when the center server CSV executes the operation end (S700), the sub server SSV connected to the center server CSV first is connected from the center server CSV. Receive a takeover order. That is, the sub server SSV may change to the center server CSV. For this reason, the sub server SSV acquires the local list LL of the sub server SSV that has been started after performing the start processing, and prepares to function as a center server when receiving a takeover command from the center server CSV.

  After executing the connection operation in step S650 and the list update process in step S550, the sub server SSV determines whether or not a takeover command has been received from the center server CSV (S21). When receiving the takeover command, the sub server SSV executes the operation of the center server as the center server CSV (S50). On the other hand, even if no takeover command is received, even if there is no server (center server CSV and other subserver SSV) connected to the subserver SSV itself, the subserver SSV operates as a center server CSV. Execute. Whether there is a server SV connected to the sub server SSV itself is determined based on the server list.

  When the sub server SSV finishes the operation (S23), and the sub server SSV does not distribute the music piece data M to the center server CSV (S24), after sending a leave notification (S335), End the operation. On the other hand, when the music data M is distributed to the center server CSV, after the music data M is taken over by the center server CSV (S750), the operation is terminated.

  The connection operation (S650), list update operation (S550), and end operation (S750) will be described below.

2.2.3.1. Connection Operation Referring to FIG. 39, when the active sub-server SSV1 receives a magic word for server search (S651), the sub-server SSV1 does not respond or responds that it is a sub-server SSV. (S652). As a result, the audio client CL cannot be connected to the sub server SSV.

  Next, it is determined whether the magic word is broadcast by the activation server SV or the client CL (S653). Since the sub server SSV separates the port that receives the search magic word from the activation server SV (other sub server SSV) and the port that receives the search magic word from the audio client CL, the determination in step S653 can be made. . Note that the sub-server SSV may be able to make the determination in S653 because the magic words for searching the activation server SV and the audio client CL are different.

  If the result of determination in step S653 is that the audio client CL has broadcast, the sub server SSV1 ends the connection operation. On the other hand, as a result of the determination, if the start server SV (sub server SSV2) broadcasts, the sub server SSV2 has started after the sub server SSV1. At this time, the sub server SSV1 registers the server specifying information of the sub server SSV2 started later than itself in the server list (S654). Server specific information is broadcast along with the magic word.

  Subsequently, the sub server SSV1 executes a connection process (S1000) to the sub server SSV2 in order to acquire the local list LL2. If the sub server SSV2, which is the activation server SV, is executing the connection process with the center server CSV (that is, during the activation process), the connection fails even if the sub server SSV1 executes the connection process (S1000) to the sub server SSV2. To do. In this case, after receiving the preparation OK command from the sub server SSV2 (S656), the sub server SSV1 executes the connection process again (S1000). When the connection is successful (S655), the sub server SSV1 acquires the local list LL2 from the connected sub server SSV2 and stores it in the HDD 14 (S1010).

  With the above operation, the sub server SSV acquires all the local lists LL of the sub server SSV started up after starting up and stores it in the HDD 14. This is because it is necessary to create a global list GL from the acquired local list LL and transmit it to a plurality of audio clients CL when it becomes the center server CSV by receiving a takeover command or the like. Note that the sub server SSV does not acquire the local list LL of the server SV (center server CSV or sub server SSV) that has been started before the sub server SSV is started. In the center server system 70, when the center server CSV is taken over, it is taken over in the order of the activated server SV. Therefore, when a certain sub server SSV becomes the center server CSV, all the server SVs activated before the sub server SSV are disconnected from the LAN 60. Therefore, it is not necessary to acquire the local list LL of the server SV that has already been activated before its own activation.

2.2.3.2. List update operation 2.2.3.2.1. When its own local list is updated When the sub server SSV updates its own song data, the sub server SSV transmits a list update notification to the center server CSV and the sub server SSV started earlier than itself.

Referring to FIG. 40, when the sub server SSV1 updates its song data, the sub server SSV1 updates the local list LL1 (S551). Next, the sub server SSV1 deletes the existing presentation content list PL (S552). In the presentation content list PL of the sub server SSV1, the storage location of the local list LL1 of the sub server SSV1 and the storage location of the local list LL of the other sub server SSV started after the sub server SSV1 is started are recorded. After deleting the presentation content list PL, the sub server SSV1 creates a new presentation content list PL based on the updated local list LL1 (S553). The reason for creating the presentation content list is that it is necessary when it becomes the center server CSV. After creating the presentation content list PL, the sub server SSV1 transmits a list update notification (S554). The list update notification is transmitted to a plurality of servers SV registered in the client list in the sub server SSV1 .

2.2.3.2.2. When the local list of another server is updated The sub server SSV1 receives a list update notification from the sub server SSV activated after itself. Referring to FIG. 41, in the center server system 70 activated in the order of the sub servers SSV1 and SSV2, when the sub server SSV2 registers new song data, the sub server SSV2 starts the center server CSV and sub A list update notification is transmitted to the server SSV1 (S555). After receiving the list update notification (S556), the sub server SSV1 deletes the existing presentation content list PL (S557). Subsequently, the sub server SSV1 deletes the local list LL2 of the sub server SSV2 (S558). After deleting the local list LL2, the sub server SSV1 transmits an updated transfer request command for the local list LL2 to the sub server SSV2 (S559). After receiving the transfer request command (S560), the sub server SSV2 transmits the updated local list LL2 to the sub server SSV1 (S561). After receiving the updated local list LL2 (S562), the sub server SSV1 creates the presentation content list PL (S563).

  With the above operation, the sub server SSV1 receives the takeover command from the center server CSV and can transmit the latest global list GL to the client CL even when the sub server SSV1 operates as the center server CSV.

2.2.3.2.3. When Other Servers Referring to FIG. 42, in the center server system 70 activated in the order of the sub servers SSV1 and SSV2, when the sub server SSV2 finishes its operation and leaves the LAN 60, the sub server SSV2 A leave notification is transmitted to the server SV that has been activated first (S564). The leave notification is transmitted to all the servers SV registered in the client list in the sub server SSV2. After receiving the withdrawal notification (S565), the sub-server SSV1 deletes the existing presentation content list PL (S566). Thereafter, the local list LL2 registered in the HDD 14 is deleted (S567). After deleting the local list LL2, the sub server SSV1 creates the presentation content list PL (S568).

2.2.3.3. Ending operation Referring to FIG. 43, when the sub server SSV1 ends the operation, the sub server SSV1 determines whether or not the music data stored therein is being distributed to the center server CSV (S751). If the song data is not distributed, the sub server SSV1 transmits a disconnection notification to the server SV activated before the sub server SSV1 (S757), and ends the operation. On the other hand, when the music data M11 is being distributed, the sub server SSV1 transmits a registration request command for the music data M11 to the center server CSV (S752). The center server CSV receives the request command and registers a new song ID in the HDD 14 (S753). After registration, the center server CSV transmits the new song ID to the sub server SSV1 (S754). The sub server SSV1 receives the new song ID, assigns the new song ID to the song data M11, and transmits it to the center server CSV (S755). After the transmission, the sub server SSV1 transmits a leave notification (S757) and ends the operation. The center server CSV receives the song data M11, and registers the song data M11 in the HDD 14 in a location where the song data to which the new song ID is assigned is stored (S756).

  With the above operation, even when the sub server SSV1 is distributing its own music data M, it can leave the LAN 60.

2.3. Center Server System Including Controller The center server system 70 described above may include a controller CN as shown in FIG. The controller CN is connected to the center server SV and controls the audio client CL via the server SV. The configuration of the controller CN is the same as that in FIG. The controller CN has a controller server list and a global list. In FIG. 44, one controller CN is shown, but a plurality of controllers CN may be provided.

  When the controller CN causes the audio client CL2 to play a song based on the song data M21, the controller CN transmits a playback command to the audio client CL2. Specifically, the controller CN transmits a playback command to the audio client CL2 via the center server CSV (1). The operation of the audio client CL2 that has received the playback command is the same as (B) and (C) in FIG.

2.3.1. System operation The controller CN is connected to the center server CSV and executes a handle acquisition process. The handle acquisition process is the same as in FIG. The center server CSV executes the operation of the server SV2 in FIG. All the audio clients CL1 to CL3 of the center server system 70 are connected to the center server CSV. Therefore, the controller CN can acquire the monitoring handles and control handles of the audio clients CL1 to CL3 by executing a handle acquisition process for the center server CSV.

  The global list GL acquisition operation and update operation are described in 1.4.3.2. Is the same. However, the server that transmits the global list GL is the center server CSV.

  The controller CN that has acquired the monitoring handle can monitor the audio client CL. The monitoring operation of the controller CN is the same as in FIG. In the center server system 70, the center server CSV executes the operation of the server SV2 in FIG.

  The controller CN that has acquired the control handle can control the audio client CL. Referring to FIG. 45, controller CN transmits a reproduction command to center server CSV (S7603). The server SV2 transmits the reproduction command transmitted from the controller CN to the audio client CL2 (S7604).

  Upon receiving the playback command, the audio client CL2 executes a distribution request process in order to acquire and play the song data (S240). At this time, the center server CSV executes a distribution operation (S500).

  With the above operation, the controller CN can instruct the audio client CL that has acquired the control handle to perform playback or stop playback. That is, the audio client can be controlled.

3. Other Embodiments 3.1. File Sharing Server System The file sharing server system uses a file sharing protocol such as SMB (Server Message Block) or CIFS (Common Internet File System). Referring to FIG. 46A, server SV2 has a list of music data M21 to M2n stored therein and a list of music data M11 to M1n and M31 to M3n stored in server SV1 and server SV3. That is, the server SV2 can share files stored in the server SV1 and the server SV3. The server SV2 provides the list to the client CL2 in response to the list request from the client CL2. The client CL2 requests the desired music piece data M31 based on the list. Referring to FIG. 46B, the server SV2 receives the request, acquires the music data M31 in the server SV3, and distributes it to the client CL2.

  In the file sharing server system, the server SV1 and the server SV3 function as devices that simply store music data. Therefore, for example, even if new song data is registered in the server SV1, the server SV1 does not transmit an update notification to the server SV2.

  Note that the servers SV1 and SV3 may be able to share the files of the other servers SV similarly to the server SV2.

3.2. Local List Transmission System The local list transmission system is a system in which the audio client CL can select all the music data M stored on the LAN by acquiring a plurality of local lists LL from a plurality of servers SV.

  Referring to FIG. 47A, in the local list transmission system 30, each server SV holds only the local list LL of music data stored therein. When the audio client CL2 requests the local list LL ((1) in the figure), as shown in FIG. 47B, each of the servers SV1 to SV3 transmits the local lists LL1 to LL3 to the audio client CL2 (( 2)). After acquiring all the local lists LL1 to LL3, the audio client CL2 selects a song based on those lists. If the selected song is song data M31, as shown in FIG. 47C, the audio client CL2 requests the song data M31 from the server SV3 ((3) in the figure), and the server SV3 responds to the request. The song data M31 is transmitted ((4) in the figure).

  While the embodiments of the present invention have been described above, the above-described embodiments are merely examples for carrying out the present invention. Therefore, the present invention is not limited to the above-described embodiment, and can be implemented by appropriately modifying the above-described embodiment without departing from the spirit thereof.

  For example, when taking over the center server, not only the song being played by the client but also the song that the client is planning to play may be transmitted to the takeover server. Further, in the center server system, the client may directly request a song from the sub server. In this case, the client is immediately notified of the list update from the center server by connecting to the center server via a push port. be able to. Further, in the center server system, the client may be automatically connected to the center server at startup. Further, in the center server system, a plurality of server groups may exist, and a center server may be provided for each group. Further, when the client searches for a server, at least the center server may respond to the client in the center server system. However, if the client does not support the center server, the sub server may respond to the client by determining the magic word attribute (attribute indicating that the center server is not supported). Further, the server stores client information (connection information, status (playing, stopped, etc.), client type, volume, product ID, firmware ID, client name, playback file name, and / or list creation key for creating a list). In the global list server system, each server can have client information that other servers have, and in the center server system, the center server can have client information of all sub-servers. Thereby, in a system having a controller for monitoring the state of the client, the controller can monitor information of all the clients by connecting to one server (center server in the center server system). Note that client information sharing and updating methods can be implemented in the same manner as content list sharing and updating methods. Furthermore, client information may be included in the content list.

It is a functional block diagram which shows the whole structure of a global list server system. It is the schematic for demonstrating the global list server system of FIG. It is a functional block diagram which shows the structure of the server in FIG. It is a block diagram which shows the structure of the audio client in FIG. It is a flowchart which shows operation | movement when a server starts with the multi-server system in FIG. It is a flowchart which shows the detail of operation | movement of step S10 in FIG. It is a flowchart which shows the detail of operation | movement of step S11 in FIG. It is a flowchart which shows operation | movement of the server currently operate | moving with the multi-server system in FIG. It is a flowchart which shows the detail of operation | movement of the server which received the connection request from the other server among operation | movement of step S100 in FIG. It is a flowchart which shows the detail of operation | movement of the server which received the connection request from the audio client among operation | movement of step S100 in FIG. It is a flowchart which shows the detail of operation | movement of step S200 in FIG. It is a figure which shows the structure of the buffer memory for storing music data by step S222 in FIG. FIG. 13 is a diagram showing a state in which music data for one buffer is stored from the beginning of the music in the buffer memory shown in FIG. 12. It is a figure which shows the state which stored the music data for all the buffers following FIG. FIG. 15 is a diagram illustrating a state in which music data is output from the head buffer following FIG. 14. FIG. 16 is a diagram illustrating a state in which an empty space for one buffer has occurred, following FIG. 15. It is a flowchart which shows the update operation | movement when the music data of a server itself are updated among the operation | movement of step S300 in FIG. It is a flowchart which shows operation | movement with the server and audio client after step S306 in FIG. It is a flowchart which shows the update operation | movement when the music data of another server are updated among the operation | movement of step S300 in FIG. It is a flowchart which shows the update operation | movement when another server detaches | leaves from LAN among the operation | movement of step S300 in FIG. It is a flowchart which shows the detail of completion | finish operation | movement of step S400 in FIG. It is a flowchart which shows the detail of operation | movement of step S404 and S411 in FIG. It is a functional block diagram which shows the whole structure of the global server system containing a controller. It is the schematic for demonstrating the connection relation of the server in FIG. 23, an audio client, and a controller. It is a functional block diagram which shows the structure of the controller in FIG. FIG. 24 is a flowchart showing a handle acquisition operation of the global server system shown in FIG. 23. It is a flowchart which shows the detail of operation | movement of step S73 in FIG. It is a flowchart which shows the monitoring operation | movement of the global server system shown in FIG. FIG. 24 is a flowchart showing a control operation of the global server system shown in FIG. 23. It is a functional block diagram which shows the whole structure of a center server system. It is the schematic for demonstrating the center server system of FIG. FIG. 31 is a flowchart showing an operation when a server is activated in the center server system shown in FIG. 30. FIG. 31 is a flowchart showing an operation of a center server operating in the center server system shown in FIG. 30. It is a flowchart which shows the detail of operation | movement of step S500 in FIG. It is a flowchart which shows the detail of operation | movement of step S501 in FIG. FIG. 36 is a flowchart showing details of the update operation when the center server updates its own local list in the update operation of step S600 in FIG. It is a flowchart which shows the detail of completion | finish operation | movement of step S700 in FIG. FIG. 31 is a flowchart showing an operation of a sub-server operating in the center server system shown in FIG. 30. It is a flowchart which shows the detail of operation | movement of step S650 in FIG. It is a flowchart which shows the detail of list update operation | movement when a self local list | wrist is made among list update operation | movement of step S550 in FIG. It is a flowchart which shows the detail of list update operation | movement when the local list | wrist of another subserver is updated among list update operation | movement of step S550 in FIG. It is a flowchart which shows the detail of list update operation | movement when another subserver leaves | leaves LAN among the list update operation | movement of step S550 in FIG. It is a flowchart which shows the detail of completion | finish operation | movement of step S750 in FIG. It is a functional block diagram which shows the whole structure of the center server system containing a controller. FIG. 45 is a flowchart showing a control operation of the center server system shown in FIG. 44. It is the schematic for demonstrating a file sharing server system. It is the schematic for demonstrating a local list transmission server system.

Claims (5)

A plurality of servers comprising a center server and multiple sub servers, a network AV system comprising a client,
Each of the center server and sub-server is
Storage means for storing a plurality of contents ;
A local list acquisition means for acquiring a local list enumerating a plurality of contents stored in the other server from the other server started after the server is started;
Comprises a local list of own listing the content itself accumulates, and a list storage means for storing a local list of each of the said other server,
The center server further includes
In response to a request from the client, a global list transmission unit that transmits a global list in which the plurality of local lists are collected to the client,
The client
A global list acquisition means for requesting and acquiring the global list from the center server;
The center server further includes
When its leaves from the network AV system, one of the the other servers that it has started after starting, a transmission means to transmit the takeover command to the connected very first to their server,
The network AV system, wherein the sub server further operates as the center server when receiving the takeover instruction. The network AV system according to claim 1,
The client
Comprising a content request means for requesting the content selected from among the transmitted global list to the Sentasa server,
The Sentasa bar further,
Content return means for returning the selected content to the client in response to a request from the client;
The client further includes:
Network AV system characterized in that it comprises reproducing means for reproducing a content that is the Sentasa bar or al reply. The network AV system according to claim 2 ,
Before Symbol center server further,
Server specifying means for specifying a server for storing the selected content based on the global list in response to a request from the client;
When the specified server is a center server, the selected content is acquired from its own storage means. When the specified server is a sub server, the selected content is acquired from the storage means of the sub server. Content acquisition means for acquiring,
The network AV system, wherein the content return means returns the content acquired by the content acquisition means to the client. The network AV system according to claim 3, wherein
The global list includes addresses of a plurality of servers in which the plurality of contents are stored corresponding to the plurality of contents,
The network AV system, wherein the server specifying unit specifies an address of the server that stores the content requested by the content requesting unit. The network AV system according to claim 1 ,
The global list may include identification information of a plurality of servers in which the content is accumulated in correspondence with a plurality of contents,
The client further includes:
The content selected from the previous SL transmitted global list, based on the specific information includes a content request means for requesting the center server or the sub-server storing the selected content,
The center server and the sub server further include
In response to a request from the client, a content return means for returning the selected content to the client is provided.
The client further includes:
A network AV system characterized by comprising playback means for playing back the returned content .

Images