Network type content reproduction system

The present invention relates to a network-type content playback system, and more particularly to a network-type content playback system including a server, a client connected to the server, and a controller connected to the server.

A typical conventional audio system reads music data from a medium and reproduces music based on the music data. Since such an audio system basically has to be installed in each room one by one, it is expensive as a whole. On the other hand, a centralized audio system that can store all music data in one place and play the selected music in each room is also provided.

However, in the centralized audio system, a large number of wirings such as wirings for music signals and wirings for control signals must be laid in each room. Also, although it is possible to play one song in each room at the same time, it is not possible to play the same song from the beginning in another room while playing one song in one room.

Also, if you install an application program for playing music on a general-purpose computer, you can get music data from sites on the Internet and play music, but only the received data is like a music CD. In addition, you cannot play a song in the middle, fast forward, or fast rewind. That is, special reproduction cannot be performed on the data that has not been received yet.

<p> One object of the present invention is to provide a network-type content reproduction system in which a client can freely select and reproduce contents such as audio and video stored in a server.</p><p> Another object of the present invention is to provide a network-type content playback system that allows a user to freely play back data that has not yet been received by the client, such as playing back from the middle.</p><p> Yet another object of the present invention is to provide a network-type content playback system that enables continuous playback of content by a client in a client-server environment.</p><p> Yet another object of the present invention is to provide a network-type content playback system that eliminates the conflict of continuous playback instructions to the client.</p><p> Yet another object of the present invention is to provide a client with an automatic connection recovery function that can quickly recover the connection even if the connection with the server is lost.</p>

Means for Solving Problems and Effects of Invention

The network-type content playback system according to the present invention includes a server and at least one first client connected to the server. The server includes a storage means for storing a plurality of contents (music content, video content, etc.). The first client includes a content requesting means for requesting a server for content selected from a plurality of contents. The server further includes a content reply means for returning the content selected in response to the request from the first client to the first client. The first client further includes a replay means of replaying the content returned from the server.

In this network-type content playback system, desired content is selected from a large number of contents stored in the server according to the request of the client. The selected content is sent from the server to the client and the content is played. Therefore, the client can freely select and play a plurality of contents stored in the server.

When the content is music content, a desired song is selected from a large number of songs stored in the server according to the request of the first client. The data of the selected song is sent from the server to the first client, and the selected song is played based on the data. Therefore, the first client can freely select and play a plurality of songs stored in the server.

Preferably, the first client is mounted in a wall-embedded outlet box.

In this case, the user can listen to music and watch images in the room without installing a first client inside the room.

Preferably, the first client further includes a content list requesting means that requests the server for a content list listing a plurality of contents. The server also includes a content list reply means that returns the content list in response to a request from the first client. The first client further includes a content list receiving means for receiving the content list returned from the server. The content requesting means selects the content to be requested from the content list.

In this case, the first client can acquire the content list from the server, select the desired content from the content list, and play the desired content.

More preferably, the content list requesting means requests the server for a specified amount of the content list, preferably a part of the content list. The content list reply means returns a specified amount of the content list, preferably a part of the content list, in response to a request from the first client.

In this case, since only a part of the content list is sent from the server to the first client, the memory capacity required for storing the content list in the first client can be reduced.

More preferably, the content list requesting means includes an acquisition start index indicating the first content that the first client intends to acquire from the server, and an acquisition number indicating the number of contents that the first client intends to acquire from the server. Send a list request command containing. In response to the list request command, the content list reply means returns a content list including the number of contents acquired from the first content indicated by the acquisition start index.

More preferably, the content list reply means further returns the number of contents included in the content list to be returned and the number of remaining contents after the content list.

In this case, the first client can recognize the number of remaining contents in the content list that has not been acquired yet, so that the remaining content list can be requested from the server.

Preferably, the first client further includes a category list requesting means that requests the server for a category list listing a plurality of categories. The server also includes a means of returning a category list in response to a request from the first client. The first client further includes means of receiving the category list returned from the server. The content list requesting means selects the category to which the content of the content list to be requested belongs from the received category list.

In this case, the first client first gets the category list from the server and selects the desired category from it. Subsequently, the first client acquires the content list from the server and selects the desired content from the content list. Therefore, it is possible to gradually narrow down and select the desired content from a large number of contents.

Preferably, the content list requesting means sends the list building key required to create the content list to the server. The content list reply means creates a content list based on the list construction key.

In this case, the first client can acquire the content list by sending the list construction key to the server when the content list is needed, so it is not necessary to remember the acquired content list.

Preferably, the content requesting means requests a predetermined amount of content from the server. The content reply means returns a predetermined amount of content in response to a request from the first client. The content requesting means repeats the content request until the entire content is acquired.

In this case, since only a part of the content is sent from the server to the first client, the memory capacity required for storing the content in the first client can be reduced.

More preferably, the content requesting means calculates an acquisition start address indicating the initial address of a predetermined amount of content and transmits it to the server. The content reply means returns a predetermined amount of content from the acquisition start address sent from the first client.

More preferably, the content requesting means transmits a content transfer request command including an acquisition start address and an acquisition data length indicating the length of the content that the first client intends to acquire from the server. The content reply means responds to the content transfer request command and returns the content for the length of the acquired data from the acquisition start address.

In this case, by arbitrarily setting the acquisition start address, the client can perform special playback even for the unreceived content.

More preferably, the content requesting means adds the acquisition data length to the previous acquisition start address to calculate the next acquisition start address.

More preferably, the first client further sets the first and second addresses according to the user's operation, and when the calculated acquisition start address exceeds the second address, the acquisition start address is set. Includes means to set to the first address.

In this case, the first client can repeatedly acquire and play the contents from the first address to the second address.

Alternatively, the first client further includes means for setting a desired address according to the operation of the user and means for setting the acquisition start address to the desired address.

In this case, the first client can acquire the content from the desired address and play it from the middle.

Preferably, the first client further includes means for setting a predetermined skip amount according to the operation of the user and means for shifting the acquisition start address by the set skip amount.

In this case, the first client can acquire the content discontinuously from the server, thereby performing fast forward playback and fast rewind playback.

Preferably, the first client further includes means of transmitting identification information of the selected content to the server. The server further includes means of returning the offset of the selected content to the first client in response to the identity sent by the first client. The first client further includes means of detecting the beginning of the selected content based on the offset returned from the server.

In this case, the first client detects the beginning of the content based on the offset of the content sent from the server, so that the content can be played immediately.

Preferably, the first client further includes means of transmitting identification information of the selected content to the server. The server further includes means of returning the size of the selected content to the first client in response to the identity sent by the first client. The first client further includes means of detecting the end of selected content based on the size returned from the server.

In this case, the first client detects the end of the content based on the size of the content sent from the server, so that the playback of the content can be terminated immediately.

Preferably, the content requesting means requests a specified amount of content from the server. The content reply means returns a specified amount of content in response to a request from the first client. The content requesting means changes the specified amount of content requested from the server.

In this case, the first client acquires the content according to the load of the server, such as reducing the specified amount of content when the load on the server is heavy and increasing the specified amount of content when the load on the server is light. The amount can be adjusted appropriately.

Furthermore, since the server returns only "a part of the song data" specified by the client, the client can arbitrarily change the specified "part of the song data" to handle data that the client has not received. Special playback (for example, fast forward, fast rewind, playback from the middle, etc.) can be performed. Furthermore, since the server sends only "a part of the song data", if the client fails to receive the song, it is sufficient to receive only the failed part from the server again, and the processing at the time of the reception failure should be speeded up. Can be done.

Furthermore, if the song format requested by the client is compressed data (MP3, etc.), the load on the server can be reduced by reducing the specified amount of data. This is because the compressed data is decoded at the time of reproduction, so that the amount of data becomes large.

Preferably, the first client further includes means of transmitting the client information to the server each time the client information about itself changes.

In this case, the client information is not always sent from the first client to the server, but only when there is a change. Therefore, the server can manage the latest client information of the first client without increasing the network traffic.

Preferably, the networked content playback system further comprises a second client that is connected to the server through the network and monitors the first client.

In this case, the user can know the operating state of the first client by the second client different from the first client.

More preferably, the first client further includes means of transmitting client information about itself to the server. The server includes means for receiving client information transmitted from the first client and means for transmitting the received client information to the second client. The second client includes means of receiving client information from the server.

In this case, the user can know information about the first client in the second client different from the first client, for example, the connection state with the server, the client type, the current operating state, the current volume, and the like.

Preferably, the server sends client information to the second client through a push port for forcing a request to the second client.

In this case, the server can send the client information to the second client without a request from the second client.

Preferably, the second client further includes means for displaying the received client information and means for changing the display of the received client information when the received client information is changed.

Preferably, the second client further includes a content list requesting means that requests the server for a content list listing a plurality of contents. The server also includes a content list reply means that returns the content list in response to a request from the second client. The second client further includes a content list receiving means for receiving the content list returned from the server.

Preferably, the client information includes a list building key needed to create the content list. When the list construction key included in the received client information is changed, the content list request means sends the list construction key to the server. The content list reply means creates a content list based on the list construction key sent from the second client.

Preferably, the second client receives the client information transmitted from the server when connected to the server.

In this case, the second client is connected to the server when the power is turned on, so that the client information about the first client can be obtained from the server.

More preferably, the client information includes a list building key needed to create the content list. The content list requesting means sends the list construction key included in the received client information to the server. The content list reply means creates a content list based on the list construction key sent from the second client.

In this case, even if the power is turned off after instructing the first client to play the content and the content list being played is lost, the second client acquires the list construction key when the power is turned on again. Therefore, if the second client sends the acquired list construction key to the server, the content list lost from the server can be acquired again.

Preferably, the client information includes the name of the data format of the content that can be played by the first client. The second client includes means of displaying the name of the data format of the content playable by the first client based on the received client information.

In this case, the user can know the data format that can be played by the first client on the second client different from the first client.

More preferably, the second client further displays a means of acquiring a content list listing a plurality of contents from the server, and among the contents included in the acquired content list, the content that can be played by the first client. , Includes means of not displaying non-reproducible content by the first client or displaying in a manner different from reproducible content.

In this case, the content that cannot be played by the first client is not displayed, so that it is possible to prevent the user from selecting the content.

Preferably, the second client includes means of determining whether the client to be monitored is the first client.

In this case, since the client to be monitored by the second client is not the first client, it will not be monitored, so that malfunction can be prevented.

Preferably, the second client includes means for obtaining the watch handle required to monitor the first client and means for monitoring the first client when the watch handle is obtained.

In this case, the second client that has not acquired the monitoring handle does not monitor the first client, so that network traffic can be reduced.

Preferably, the networked content playback system further comprises a second client that is connected to the server through the network and controls the first client.

More preferably, the second client includes a server request means that requests the server to control the first client. The server also includes means of controlling the first client in response to a request from the second client.

In this case, the user can control the first client through the server from a second client different from the first client.

Preferably, the server request means sends information to identify the first client and information to identify the selected content to the server.

In this case, the user can play the desired content on the first client.

Preferably, the second client includes means of determining whether the client to be controlled is the first client.

In this case, since the client to be controlled by the second client is not the first client to control, malfunction can be prevented.

Preferably, the second client is selected if the data format matches the means of determining whether the data format of the selected content matches the data format of the content reproducible by the first client. Includes a means of instructing the first client to play the content based on the data of the content.

In this case, since the second client commands the playback of the content only for the content that can be played by the first client, malfunction can be prevented.

Preferably, the second client includes means for acquiring the control handle required to control the first client and means for controlling the first client when the control handle is acquired.

In this case, the second client that has not acquired the control handle does not control the first client, so that network traffic can be reduced.

Preferably, the first client further sends a completion status to the server when it finishes playing the content commanded by the second client, and when it finishes playing the content of its choice, or the user's operation. Includes a means of sending a stop status different from the completion status to the server when playback ends in the middle of the content according to

In this case, the server distinguishes between the completed status and the stopped status so that the first client has finished playing the content ordered by the second client, or has it finished playing the content of its choice? Alternatively, it is possible to determine whether or not the playback has ended in the middle of the content according to the user's operation.

Preferably, the server includes means of receiving the completion status sent from the first client and sending it to the second client. The second client includes means of instructing the first client to play the next content of the finished content in response to the completion status sent from the server.

In this case, the first client that has finished playing the content sends the completion status to the second client that ordered the playback of the content, so that the second client continuously sends the content to the first client according to the content list. Can be regenerated.

Preferably, the networked content playback system further comprises a plurality of second clients that are connected to the server through the network and control the first client. Each of the second clients includes a replay command means that commands the first client to replay the content. The content reproduction means of the first client reproduces the content according to the instruction from the second client. The first client further includes means of sending a completion status to the server when the content has finished playing. The server receives the completion status sent from the first client, sends the completion status to the second client instructed to the first client among the plurality of second clients, and sends the completion status to the other second client. Includes means of sending outage status to clients. The replay command means of the second client commands the first client to replay the content next to the replayed content in response to the completion status sent from the server.

In this case, the first client that has finished playing the content sends the completion status to the second client that ordered the playback of the content through the server, so that the second client correctly continues to the first client. Order playback. On the other hand, since the server sends the stop status to the other second client, the other second client recognizes that the first client is in the stopped state and erroneously orders the first client to play continuously. There is nothing to do.

Preferably, the first client further includes a broadcast means of broadcasting predetermined information. The server includes means for returning the server identification information for identifying itself to the first client in response to the predetermined information broadcast from the first client. The first client includes means for receiving server-specific information returned from the server and registering it in the server list.

In this network-type content playback system, a client broadcasts predetermined information to the network, and if there is a server connected to the network, the server notifies the client of server specific information (IP address, port number, etc.). Therefore, the client can find the server existing on the network.

Preferably, the first client further includes means for determining whether or not the server specific information is registered in the server list. As a result of the determination, if the server specific information is not registered in the server list, the broadcasting means broadcasts the predetermined information again.

In this case, the first client starts searching for the server again if no server specific information is registered in the server list, so it keeps searching until it finds at least one server.

Preferably, the first client further includes means of accessing a server on the Internet when the number of broadcasts by the broadcast means reaches a predetermined number of times, or when the broadcast time by the broadcast means reaches a predetermined time.

In this case, the first client does not continue to look for the server if there are no servers on the local network, in which case it can find the server on the Internet.

Preferably, the first client is a means of establishing a connection on the command port for sending and receiving commands between the server and the first client, and forcing the server to send a request to the first client. Includes means of establishing a connection with a pushport.

In this network-type content playback system, commands and status are sent and received between the server and client via the command port. Also, commands from the server are forcibly sent to the client through the push port.

Preferably, the first client further includes means of sending a client index request command through the command port requesting the client index needed to identify itself. The server also includes means of returning the client index to the client in response to the client index request command sent by the first client. The first client further includes means of sending the client index returned by the server to the server through the pushport.

Preferably, there are a plurality of first clients. The server includes connection limiting means that limit the number of clients that can be connected.

Preferably, the connection limiting means disconnects the connected client according to a predetermined priority when the unconnected client tries to connect.

Yet another network-type content playback system according to the present invention is a server, a first client connected to the server via a network, an AV device connected to the first client, and an AV connected to the server through the network. It has a second client that controls the device. The second client includes means of sending control commands to the server to control the AV device. The server includes means of sending control commands sent by the second client to the first client. The first client includes means for transmitting the control command transmitted from the server to the AV device. The AV device is further controlled in response to a control command sent from the first client.

In this case, the control command is sent from the second client through the server to the first client. The AV device is controlled according to this control command. Therefore, the second client can control the AV device.

Yet another network-type content playback system according to the present invention is a server, a first client connected to the server, an AV device connected to the first client, and an AV device connected to the server through a network. It has a second client to monitor. AV equipment includes means of transmitting information about itself to a first client. The first client includes an AV device information transmitting means for transmitting information transmitted from the AV device to the server. The server includes means for sending information sent from the first client to the second client.

In this case, the information about the AV device is transmitted to the second client through the first client and the server. Therefore, the second client can monitor the AV device based on this information.

Preferably, the AV device information transmitting means of the first client transmits frequently changing information at predetermined time intervals.

In this case, network traffic can be reduced.

Preferably, the server further includes a firmware update means that updates the firmware of the first client.

In this case, the firmware of the first client is automatically updated by the server.

Preferably, the server is further a means for registering information on a plurality of firmwares suitable for the first client and a means for transmitting a firmware list for transmitting a firmware list listing the information on the plurality of registered firmwares to the first client. And include. The first client further includes means for receiving the firmware list sent from the server and means for requesting the server to send the firmware selected from the received firmware list. The firmware update means returns the selected firmware in response to the request from the first client to the first client.

In this case, the firmware of the first client is not necessarily updated to the latest version, but is updated to the appropriately selected version.

Preferably, the first client further includes means of sending client information about itself to the server. The server also includes means of creating a firmware list based on the client information sent by the first client.

In this case, a firmware list can be created that lists the firmware information corresponding to the first client.

Preferably, the first client requests a specified amount of firmware, preferably a portion of the firmware, from the server. The firmware update means returns a specified amount of firmware, preferably a part of the firmware, in response to a request from the first client.

In this case, since the server sends only the specified amount of firmware, if the client fails to receive, it is sufficient to receive only the failed part from the server again, and the processing at the time of reception failure can be speeded up. .. Further, since only a part of the firmware list is sent from the server to the first client, the memory capacity required for storing the firmware list in the first client can be reduced.

Another network-type content playback system according to the present invention includes a server, a first client connected to the server, and a plurality of second clients connected to the server. The server includes a content storage means for storing a plurality of contents. Each of the second clients is provided with means for designating a content from a plurality of contents and instructing the first client to play the designated content. The first client includes means for playing back the specified content in response to a command from the second client, and means for sending a completion status to the server when the playing of the content is completed. The server further comprises a status transmission means that, when it receives a completion status from the first client, it selects one of the plurality of second clients and sends the completion status to the selected second client. When each of the second clients further receives a completion status from the server, the first client specifies the next content of the content that has completed playback and instructs the first client to play the specified content. Provide means.

Preferably, the server further comprises means of managing the priority of the second client that can control the first client. The status transmission means selects the second client with the highest priority as the second client to which the completion status should be sent. Alternatively, the server further provides means for storing the identification information of the second client that ordered the replay. The status transmission means selects the second client that has ordered playback based on the identification information of the second client stored as the second client to which the completion status should be transmitted.

In this system, when the server receives the completion status from the first client that has completed the playback of the content, it selects one of the second clients and sends the completion status to the second client. Therefore, the only second client will instruct the first client to play continuously. As a result, this system can eliminate the conflict of the continuous playback instruction to the first client and enable the first client to continuously play the content.

Preferably, the status transmission means transmits the stop status to a second client other than the second client with the highest priority.

In this case, the stop status is sent to the second client other than the second client with the highest priority, not the completion status, so that the other second client does not take any active action. You can simply monitor the status of the first client.

Another network-type content playback system according to the present invention includes a server, a first client connected to the server, and a plurality of second clients connected to the server. The server includes a content storage means for storing a plurality of contents. Each of the second clients specifies a control handle acquisition means for acquiring the control handle required to control the first client, and after acquiring the control handle, specifies the content from a plurality of contents and specifies the content. It is provided with a means for instructing the first client to play the content. The first client includes means for playing back the specified content in response to a command from the second client, and means for sending a completion status to the server when the playing of the content is completed. The server also provides a means of forwarding the completion status sent by the first client to each of the second clients. When each of the second clients further receives a completion status from the first client that has acquired the control handle, it specifies the content next to the content that the first client has completed playing, and that designation. Provide a means for instructing the first client to play the content.

In this system, the second client acquires the control handle required to control the client and then instructs the first client to play the content. The first client sends a completion status when it completes playing the content. When the second client receives the completion status from the first client that has acquired the control handle, it instructs the first client to perform continuous playback. As a result, this system can eliminate the conflict of the continuous playback instruction to the first client and enable the first client to continuously play the content.

Preferably, the control handle acquisition means prohibits the other second client from acquiring the control handle when the control handle is acquired.

In this case, since a plurality of second clients cannot acquire the control handle of one first client at the same time, the conflict of the replay instruction to the first client can be completely eliminated.

More preferably, the first client further comprises means of transmitting a stop status to the server when playback of the content is stopped prematurely. The server also provides a means of forwarding the outage status sent by the first client to each of the second clients. Each of the second clients further comprises means for releasing the control handle acquisition prohibition when it receives a stop status from the first client that has acquired the control handle.

In this case, the first client that stopped playing the content in the middle sends the stop status to all the second clients, and the second client that receives the stop status from the first client that has acquired the control handle. Releases the control handle. Therefore, any second client can get the control handle of this first client.

Yet another network-type content playback system according to the present invention includes a server, a first client connected to the server, and a second client connected to the server. The server includes a content storage means for storing a plurality of contents. The second client provides means for designating a content from a plurality of contents and instructing the first client to play the designated content. The first client includes means for playing back the specified content in response to a command from the second client, and means for sending a completion status to the server when the playing of the content is completed. When the server receives the completion status from the first client, the server further specifies the next content of the content that the first client has completed playing, and instructs the first client to play the specified content. Equipped with command means.

In this system, when the first client who has completed the playback of the content sends the completion status to the server, the server itself instructs the first client to play the content continuously. As a result, this system can eliminate the conflict of the continuous playback instruction to the first client and enable the first client to continuously play the content.

Preferably, the server also has a means of storing a list build key required to create a content list enumerating the content to be played by the first client and a means of creating a content list based on the list build key. And. The continuous playback command means commands the first client to play the content according to the content list.

In this case, the server stores the list construction key and creates a content list based on the list construction key, so that the content to be played next can be specified.

Yet another network-type content playback system according to the present invention includes a server, a first client connected to the server, and a second client connected to the server. The server is provided with a content storage means for accumulating a plurality of contents, a second client specifies a content from the plurality of contents, and a means for instructing the first client to play the specified contents, and a first method. It provides a means of sending the list building key required to create a content list to be played by one client to the first client. The first client includes means for playing back the specified content in response to an instruction from the second client and means for sending the list building key sent from the second client to the server. The server also provides a means of creating a content list based on the list building key sent by the first client and sending it to the first client. The first client further provides means for playing the next content of the content that the first client has completed playing according to the content list sent from the server.

In this system, the content list created by the server based on the list construction key is sent to the first client. The first client performs continuous playback by itself according to this content list. As a result, this system can eliminate the conflict of the continuous playback instruction to the first client and enable the first client to continuously play the content.

The client in the network-type content playback system according to the present invention is a content requesting means for requesting the server for digital content selected from a plurality of digital contents stored in the server, and digital content returned from the server in response to the request. Including a reproduction means for reproducing the. There are multiple servers. The client further comprises a connecting means and a determining means. The connection means connects to any of a plurality of servers. The determination means determines whether or not the connection with the server by the connection means is maintained at predetermined intervals. When the determining means determines that the connection with the server has been disconnected, the connecting means executes a reconnection with the server.

This client checks the connection status with the server at regular intervals. If the connection with the server is lost, the client reconnects with the server. Therefore, even if the connection is disconnected due to an abnormality in the server, the client can quickly recover the connection by itself.

Preferably, the connecting means makes a connection with another server when it cannot reconnect with the server.

In this case, the client quickly connects to the other server even if it cannot reconnect to the connected server. As a result, the client is not left unconnected to the server.

Preferably, the connecting means sends the client status before the disconnection to the reconnected server.

In this case, the client sends the client status before disconnection to the reconnected server, so the client can restore the connection status with the server. As a result, the user can use the client without being aware that the client has reconnected to the server.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. The same or corresponding parts in the figure are designated by the same reference numerals and their explanations are incorporated.

[table of contents] 1. Preferred embodiment 1.1. Configuration 1.1.1. Overall 1.1.2. Content server 1.1.3. Audio client 1.1.4. Controller 1.1.5. AV receiver 1.2. Operation 1.2.1. Initial settings of content server and audio client 1.2.1.1. Audio Client Initial Settings 1.2.1.1.1. Content server search 1.2.1.1.2. Connection with content server 1.2.1.1.3. Sending client information 1.2.1.2. Content Server Initial Settings 1.2.1.2.1. Response to content server search 1.2.1.2.2. Command port connection reception 1.2.1.2.3. Push port connection reception (1) 1.2.1.2.4. Push port connection reception (2) 1.2.2. Main operation of content server and audio client 1.2.2.1. Command reception 1.2.2.1.1. Command distribution processing 1.2.2.1.2. Status notification command processing 1.2.2.1.3. Server request issuance Command processing 1.2.2.2. Normal playback 1.2.2.2.1. Get song list 1.2.2.2.2. Song designation 1.2.2.2.3. Playing a song 1.2.2.3. Special playback 1.2.2.3.1. Fast forward playback 1.2.2.3.2. Fast rewind playback 1.2.2.3.3. Pause 1.2.2.3.4. Slow playback 1.2.3. Controller operation 1.2.3.1. Connection with content server 1.2.3.1.1. Acquisition of monitoring handle and control handle 1.2.3.2. Monitor function 1.2.3.3. Control function 1.2.3.3.1. Control command processing 1.2.3.3.2. Playback control 1.2.3.3.3. Identify and play a playable format 1.2.3.3.4. Continuous playback control 1.2.3.3.5. Continuous playback control using list construction key 1.2.3.3.6. Prioritized continuous playback control 1.2.3.3.7. Continuous playback control using the control handle 1.2.3.3.8. Continuous playback control by content server 1.2.3.3.9. Continuous playback control by the audio client itself 1.2.3.3.10. Continuous playback control using playback command management table 1.2.4. Control of AV receiver 1.2.5. Firmware update 2. Other embodiments 2.1. Audio client with built-in outlet 2.2. Get music data on the internet 2.3. Playback with acquired data length change function 2.4. Skip playback 2.5. Repeat playback 2.6. Play in the middle 2.7. Client with automatic connection recovery function

1. Preferred embodiment 1.1. Configuration 1.1.1. Overall With reference to FIG. 1, the network-type audio system 10 according to the embodiment of the present invention includes a plurality of content servers S1 to Si for accumulating music data of a large number of songs, and music data from the content servers S1 to Si. Includes multiple audio clients C1 to Cj for playing music based on, multiple controllers A1 to Ak for controlling and monitoring audio clients C1 to Cj, and AV equipment (eg, switchers, amplifiers, etc.) It has an AV receiver) AVR and an AVR client AC for controlling the AV receiver AVR. Hereinafter, the content server Si is used to list one of the content servers, the audio client Cj is used to list one of the audio clients, and the controller Ak is used to list one of the controllers.

Here, music data is stored in the content server Si, but video data may be stored in place of or together with this, and various other digital contents (for example, still images such as photographs) can be stored. It may be accumulated. In the following, music data will be described as an example. Further, although there are a plurality of content server Si, audio client Cj, and controller Ak, it is sufficient that at least one content server and audio client exist. When a plurality of content servers S1 to Si exist, the audio client Cj may acquire music data from any of the content servers S1 to Si, and may acquire music data from only one specific content server Si. May be good. Also, the controller Ak does not have to be at all. In addition, there may be a plurality of AV receivers AVR and AVR client ACs, but none of them may be present.

These are connected to each other by LAN (Local Area Network) 12, but are not limited to this, and any suitable one such as USB or IEEE1394 may be adopted for constructing a computer network. When adopting LAN, it is preferable to adopt a standard TCP / IP protocol in a PC (personal computer), but UDP protocol or the like may be adopted, and the protocol is not particularly limited. Also, in this figure, the content server and audio client are connected so as to branch off from the main wiring of the LAN, but in the case of 10BASE-T or 100BASE-TX, for example, they are connected in a star shape centered on the hub.

1.1.2. Content server With reference to FIG. 2, each content server Si 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, and the content. It is equipped with a LAN controller 22 that sends and receives signals between the server Si and LAN 12.

1.1.3. Audio client With reference to FIG. 3, each audio client Cj temporarily stores the microcomputer processing unit 28 including the network protocol processing unit 24 and the system operation unit 26, the flash memory 30, and the sequentially input compressed digital music data and the like. Memory 32 for sequential output, audio processing unit 34 for decoding compressed digital music data to generate uncompressed digital music data, and D / A converter (DAC) 36 for converting digital music data to analog music data. And a LAN controller 38 that sends and receives signals between the audio client Cj and LAN12. Unlike the content server Si, the audio client Cj does not have to be equipped with an HDD for storing compressed digital music data.

1.1.4. Controller With reference to FIG. 4, each controller Ak is determined according to an input device 301 such as a keyboard, a mouse, a tablet, and a touch panel, a display device 302 such as a liquid crystal display and a CRT (Cathode Ray Tube), and an installed computer program. It includes a CPU 303 that executes processing and a LAN controller 304 that transmits and receives signals between the controller Ak and LAN 12. The controllers A1 to Ak function as clients for the content servers S1 to Si in the same way as the audio clients C1 to Cj. The difference between the controller Ak and the audio client Cj is that the audio client Cj has a playback function, whereas the controller Ak does not have a playback function and mainly has an audio client monitoring and control function.

The audio client Cj mainly has a playback function, but may also have a monitor and control function. In this case, the audio client also acts as a controller.

1.1.5. AV receiver The AV receiver AVR is not particularly limited, but is connected to the AVR client AC by, for example, EIA-232. The AVR client AC mainly has a function of being able to communicate with the AV receiver AVR, but may also have a playback function like the audio client Cj.

1.2. Operation 1.2.1. Initial setting operation of content server and audio client With reference to Figure 5, when an audio client is powered on, the audio client first searches for a content server (S11). Of the multiple content servers Si connected to LAN12, the running content server responds (S21).

Subsequently, the audio client issues a connection request to the content server in order to enable data transmission / reception with the content server (S12). The content server establishes a connection with the audio client in response to this connection request (S22).

Finally, the audio client sends various client information about itself to the content server (S13), which the content server receives (S23).

When the above initial setting operation is completed, the next song list acquisition operation is started. Before the explanation, the details of the initial setting operation of the audio client will be described.

1.2.1.1. Initial setting operation of audio client 1.2.1.1.1. Content server search With reference to FIG. 6, the audio client first clears the server list for recording the IP address and port number of the found content server (S1101).

Subsequently, the audio client is not particularly limited, but broadcasts a predetermined magic word on the LAN 12 at the command port, for example, by the UDP protocol (S1102). If there is a running content server among multiple content servers Si connected to LAN12, the content server receives the broadcast magic word on the search port and is the same as the audio client that broadcast the magic word. It returns a magic word and also sends server identification information (specifically, IP address and port number) to identify itself.

Subsequently, the audio client resets the timer for measuring the elapsed time of receiving the server specific information (S1103), and then determines whether or not the server specific information has been received (S1104).

When the server specific information is received (when the content server is found), the audio client records the server specific information in the server list (S1105). Then, the audio client determines whether or not the server list is full (S1106), completes the search if it is full, and returns to step S1103 if it is not yet full.

On the other hand, when the server specific information is not received (when the content server is not found), the audio client determines whether the elapsed time of receiving the server specific information exceeds a predetermined time, for example, 2 seconds (S1107), and still exceeds it. If not, the process returns to step S1104. That is, the audio client waits for a response from the content server for only 2 seconds.

If the elapsed time of receiving the server specific information exceeds 2 seconds, the audio client determines whether the server list is still empty (S1108). If the server list is empty, that is, no server-specific information is recorded in the server list, the audio client returns to step S1102 and broadcasts the magic word again. On the other hand, if the server list is not empty, that is, if the server list contains server-specific information for at least one content server, the audio client completes the search. That is, the audio client continues to search until it finds at least one content server.

As a result of the content server search, the IP address and port number corresponding to one or more content servers are assigned to the server list.

1.2.1.1.2. Connection with content server With reference to FIG. 7, the audio client selects one content server from the server list according to the user's operation (S1201), and obtains the IP address and port number of the selected content server (S1202). ..

Subsequently, the audio client generates a TCP (Transmission Control Protocol) socket (1) with the acquired IP address and command port (S1203), and connects to the content server with this TCP socket (1) (S1204). The command port is a port for sending and receiving commands between the content server and the audio client. The content server accepts the connection on the command port (S2201), and if the connection is successful, proceeds to step S1206, otherwise the connection fails (S1205). This allows the audio client to establish a connection to send and receive commands to and from the content server.

The audio client then sends a client index request command to the content server over a TCP socket (1) (S1206). The content server responds to this client index request command by returning the client index from the TCP socket (1) to the audio client (S2202), which the audio client receives (S1207). The client index is an identification number assigned to each audio client by the content server. The client index request command is a command in which an audio client requests a client index from the content server.

Subsequently, the audio client generates a TCP socket (2) with the IP address and push port of the content server (S1208), and connects to the content server with this TCP socket (2) (S1209). The push port is a port in a standby state in which a request from the content server (hereinafter referred to as "server request") in response to a voluntary request from the content server or a request from the controller can always be received. The content server accepts the pushport connection (S209), and if the connection is successful, proceeds to step S1211, otherwise the connection fails (S1210). This allows the audio client to establish a connection to receive the server request.

At this point, the content server still doesn't know which audio client is connected to the pushport. Therefore, the audio client sends the client index acquired in step S1207 to the content server via the TCP socket (2) (S1211). The content server identifies the audio client connected to the pushport based on this client index. From now on, the content server will use this push port when sending server requests to the audio client.

As a result, two connections are established on the command port and push port. These two connections are established not only between the audio client Cj and the content server Si, but also between the controller Ak and the content server Si, which will be described later, and also between the AVR client AC and the content server Si.

Generally, in a server-client system, as seen in the HTTP protocol, the content server returns a response (HTML document, etc.) to a request (page request, etc.) from the client. This means that the action trigger is only on the client and the content server cannot voluntarily act on the client. Therefore, even if the content server takes some kind of request to the client, for example, a voluntary action such as notifying the client when the content server shuts down, the notification cannot be given without the request from the client.

In order for the client to receive the server request, a command is issued to the content server at regular intervals to check if there is a server request. The content server sends a server request to the client in response to a command issued by the client, and the client receives it.

It is known that even in the case of the above HTTP protocol, the page must be reloaded at regular intervals for the dynamically updated page. This method can be called acquisition of server request by polling from the client, but it has the following problems.

(1) If the polling interval is shortened to some extent and the server request is not frequently asked, there will be a difference between the time when the content server makes the request and the time when the audio client actually receives the request. ..

(2) If the polling interval is shortened as described above, the network traffic and the load on the server and client will increase.

(3) Most polling is useless because the frequency at which the content server must send server requests to clients is lower than the frequency at which it sends and receives regular commands. This is because when asked if there is a server request, it is usually answered that there is no request.

In order to solve the above problem, the server request may be sent to the client by the interrupt from the content server instead of polling from the client. As a result, it is possible to eliminate the lack of real-time performance, which is a problem in (1) above, and the wasteful load as in (2) and (3) above.

To achieve this, two connections have been established as described above. One is the connection formed in the command port used by the audio client Cj to issue commands and the content server Si to respond to them. The other is the connection formed on the push port used by the content server Si to send server requests to the audio client Cj. As a result, the content server Si can notify the audio client Cj of the server request without using polling from the audio client Cj.

The outline of the operation using these two connections will be described below.

As shown in FIG. 8, the content server Si notifies all the audio client Cj through the push port at the time of shutdown, thereby causing the audio client Cj to perform some operation (such as turning off the power).

In addition, as shown in Fig. 9, when the controller Ak controls the audio client Cj (for example, play or stop), the controller Ak issues a command to the content server Si to issue a server request including the control content through the command port. Send to server Si. In response to this command, the content server Si sends a server request to the audio client Cj through the push port. As a result, the controller Ak can control the audio client Cj.

Further, as shown in FIG. 10, when the operating state changes, the audio client Cj transmits the change in the operating state to the content server Si through the command port. The content server Si sends the change in the operating state to the controller Ak, which monitors the operating state of the audio client Cj, through the push port. Therefore, the audio client Cj can notify the controller Ak of the change in its operating state in real time.

As described above, the network traffic in the network type audio system and the load on the content server and the audio client can be minimized, and the performance of the entire system can be improved.

1.2.1.1.3. Sending client information With reference to FIG. 11, the audio client sends its attribute information to the content server (S1301 to S1303) and also its initial status (S1304 to S1305).

Specifically, the audio client sends the audio client type on the TCP socket (1) (S1301). Audio client types include the types of music formats that can be played, whether or not they can be operated by a remote controller (remote control), and whether or not there is an EIA-232 port.

The audio client then sends the product ID over the TCP socket (1) (S1302). The product ID is model information given for each type of audio client. Therefore, the same type of audio client is given the same product ID.

The audio client then sends the firmware ID over the TCP socket (1) (S1303). The firmware ID is the version information of the firmware installed in the audio client.

The audio client then sends the initial value of the volume over the TCP socket (1) (S1304). The initial value of the volume is the initial value of the volume played by the audio client.

Finally, the audio client sends the initial status of the audio client over the TCP socket (1) (S1305). The initial status of the audio client includes a stop status and the like.

The content server receives the client information sent from the client and stores it in the client information database (Fig. 13). The client information is transmitted to the content server Si not only from the audio client Cj but also from the controller Ak and the AVR client AC. The content server Si manages all clients based on this client information.

1.2.1.2. Content server initial setting operation Next, the initial setting operation of the content server corresponding to the initial setting operation of the audio client will be described.

With reference to FIG. 12, the content server reserves and clears the storage area for the client information database as shown in FIG. 13 for the maximum number of clients (S201). Each client information includes a flag indicating the presence or absence of a connection, a client type, a current status, a current volume value, a product ID, a firmware ID, a client name, a playback file name, and a list construction key. Including.

The client type records the client type such as audio client, controller, AVR client, and playable data format (MP3, WAV, etc.). The client type also records whether remote control is possible or not. For example, an audio client that can be controlled by a remote control records information that the remote control can be controlled. In the status, the status such as "play", "stop", "pause", "completed", and "firmware update in progress" is recorded. In the playback file name, the full path name of the HDD 14 in which the data of the song currently being played is stored is recorded. Further, the playback file name does not have to be the file name itself such as the full path name, and may be any information as long as the information can identify the file. For example, a table in which a predetermined identification number and a file name are associated with each other may be stored in the content server, and the content server may refer to this table and convert the identification number into a file name. In this case, it is not necessary to send and receive long file names. In addition, security is improved because the file in which the song data is stored cannot be immediately identified from the file name. Further, the list construction key is for the content server to create a list, which will be described in detail later.

Subsequently, the content server creates a socket that accepts a connection request to the command port, a socket that accepts a connection request to the push port, and a socket that accepts a server search request to the search port (S202). The search port is a port used when searching for a content server, and the content server monitors whether or not a magic word is input to this search port.

Subsequently, the content server constructs a content information database as shown in FIG. 14 and a firmware information database as shown in FIG. 15 (S203). The content information database includes content information for the number of songs. The content information of each song includes a file name, a song name, an artist name, an album name, a genre name, a song length (time), a data format, a number of plays, and a last access time. In this file name, the full path name of the HDD 14 in which the data of the song is stored is recorded. The firmware information database contains firmware information for the number of firmware files. The firmware information includes a product ID, a firmware ID, a file size, a data format, and a file name. In this file name, the full path name indicating the site on the Internet where the firmware is stored is recorded.

When there is a write in the search port (S204), the content server performs response processing to the content server search described later (S205). The content server also performs the command port connection acceptance process described later (S207) when there is a write in the command port (S206). When there is a write in the push port (S208), the content server also performs the push port connection acceptance process (No. 1) described later (S209). The content server also performs pushport connection acceptance processing (No. 2), which will be described later, when there is a write in the unprocessed pushport (S210) (S211).

1.2.1.2.1. Response to content server search With reference to FIG. 16, when there is a write in the search port, the content server acquires the written content (S2051) and determines whether the content is the correct magic word (S2052). If the magic word is correct, the content server returns the same magic word to the source client (S2053), and also returns its own IP address and port number.

1.2.1.2.2. Command port connection reception With reference to FIG. 17, when a client requests a connection to the command port, the content server determines whether the number of currently connected clients has reached the maximum number of clients (S2071). When the maximum number of clients is reached, the content server looks for low priority clients and forces them to disconnect (S2072). The priority of the client is lower as the audio client is not currently playing, the audio client is not communicating for a certain period of time, and the like. Then, the content server clears the client information of the client that was forcibly disconnected (S2073).

If the number of currently connected clients has reached the maximum number of clients, the content server may not connect to any more clients instead of the above.

If there is room in the connectable socket of the client, or if the low priority client is disconnected to secure the connectable socket, the content server starts accepting the connection request from the client (S2074).

If the reception is successful (S2075), the content server searches for free space in the client information database (S2076). Specifically, search for client information whose flag is FALSE. The content server allocates the searched area to the new client information storage area (S2077) and clears the previous client information (S2078).

Subsequently, the content server sets the flag to TRUE (S2078) and stores the socket information obtained as a result of reception in the socket field of the client information storage area (S2079).

1.2.1.2.3. Connection acceptance process to push port (1) With reference to FIG. 18, when a client requests a connection to the push port, the content server starts accepting the request (S2091). If the reception is successful (S2092), the socket information obtained as a result of the reception is stored in the queue of the raw push port (S2093). At this point, the content server has yet to identify the client connected to the pushport. Such a push port is called an unprocessed push port.

1.2.1.2.4. Push port connection acceptance processing (Part 2) With reference to Figure 19, when a client requests a connection to an open push port, the content server gets the command written to that push port (S2111). If the command size is greater than 0 (S2112) and the command is a client index notification command (S2113), the content server tells whether the client indicated by the client index is already connected to the command port. Determine (S2114).

If the connection is not yet complete, the content server sets the error code to -1 (failure) (S2115) and proceeds to step S2119. On the other hand, if the connection is already complete, the content server registers this pushport as a pushport for its client (S2116). The content server also removes this pushport from the queue of outstanding pushports (S2117) and sets the error code to 0 (success) (S2118). Then, the content server returns the set error code to the client (S2119).

1.2.2. Main operation of content server and audio client 1.2.2.1. Command reception With reference to FIG. 12 again, the content server accepts commands from the client after completing the initial settings. That is, the content server repeats steps S213 to S217 for the maximum number of clients (S212, S218, S219). n is the client index from 0 to (maximum number of clients-1) assigned to clients.

Specifically, the content server refers to the flag in the client information database to determine whether the nth client is already connected to the command port (S213). If already connected, the content server determines if there was a write to the command port for the nth client (S214). When there is a write, the content server determines whether the size of the written data is 0 or -1 (S215). If it is 0 or -1, the content server clears the nth client information because the client has been disconnected or a socket error has occurred (S216). On the other hand, if this is not the case, the content server performs the following command processing (S217).

1.2.2.1.1. Command distribution processing With reference to FIG. 20, when the client writes to the command port, the content server branches the process according to the command stored in the first 4 bytes (S2171). That is, if it is a status notification command such as notifying the content server of the status change from the audio client (S2172), the status notified from the audio client is notified to the controller (S2173). Details will be described later. If it is a content server request issuance command from the controller to the audio client (S2174), the request from the controller is notified to the audio client (S2175). Details will be described later. In addition, the content server responds to the command and performs a predetermined process.

1.2.2.1.2. Status notification command processing When the command from an audio client (hereinafter referred to as "the audio client") is a status notification command, the content server first refers to the status, volume, etc. stored in the parameters in the command, referring to FIG. Store client information in the client information database (S21731). Therefore, the content server always holds the latest client information.

Next, the content server searches for a controller from all the clients, and notifies the found controller of the status of the audio client. Therefore, the content server repeats the following steps S21733 to S21736 for the maximum number of clients (S21732, S21737, S21738).

Specifically, the content server refers to the client type in the client information to determine whether the nth client is a controller (S21733). Therefore, it is possible to prevent the status of the audio client from being notified to the other audio client that is not the controller. If it is a controller, the content server determines whether or not the controller has acquired a monitoring handle for the audio client (S21734). If the watch handle is acquired, the content server determines whether the controller has completed the connection to the push port (S21735).

If the connection to the push port is completed, the content server writes the client information of the audio client to the push port of the controller, thereby notifying the controller of the status of the audio client (S21736).

1.2.2.1.3. Server request issuance Command processing When the command from the controller is a server request issuing command, the content server first acquires the issuing controller, the destination audio client, the request contents, etc. included in the command (S21751), referring to FIG. 22.

The content server determines whether the issuing controller has acquired the control handle (described later) of the destination audio client (S21752), and if it has not acquired the control handle, sets the error code to -1 (S21753). ). Therefore, it is possible to prevent the controller that has not acquired the control handle from controlling the audio client.

If the control handle is acquired, the content server refers to the flag in the client information to determine whether the connection is established at the command port of the destination audio client (S21754), and if not, it is not established. Set the error code to -2 (S21755). Therefore, it is possible to prevent sending a command to an uncontrollable audio client.

If the connection is established on the command port of the destination audio client, the content server determines whether the connection is established on the push port of the destination audio client (S21756), and if not, an error code. Is set to 1 (S21757). On the other hand, if established, the content server sends the request from the controller to the push port of the destination audio client (S21758) and sets the error code to 0 (no error) (S21759).

Finally, the content server returns an error code to the issuing controller (S21760).

If the destination audio client is not connected to the push port, the request content from the controller may be sent to the destination audio client when the destination audio client makes an inquiry by polling.

1.2.2.2. Normal playback Next, the operation when the user causes the audio client Cj to play a desired song will be described. Here, the user does not immediately specify the desired song, but first specifies the desired song list and selects the desired song from the song list. The details will be described below.

With reference to FIG. 23, the audio client sends a song list request command to the content server in response to the user's operation (S14). The song list request command is a command for the audio client to request a desired song list from the content server. In the song list, a plurality of song titles and artist names are listed. The content server sends the song list to the requesting audio client (S24) in response to this song list request command, and the audio client receives it (S14).

The audio client specifies the songs included in the song list according to the user's operation (S15), and the content server prepares the distribution of the specified songs accordingly (S25).

Subsequently, the content server delivers the specified song to the audio client (S26), and the audio client plays the delivered song (S16). Then, the audio client stops the playback of the song after the playback is completed or according to the user's operation (S17).

The details of each of steps S14 to S16 will be described below.

1.2.2.2.1. Get song list With reference to FIG. 24, the audio client determines whether or not to request the play name list from the content server (S1401). The playlist is a list of playlist titles. A playlist is a song list that lists a plurality of songs selected by the user. A plurality of playlists created by the user are stored in the content server in advance.

When a user tries to select one of multiple playlists stored on the content server, the playlist name list is first checked on the content server to check what kind of playlist is registered. To request. The audio client requests the play name list from the content server in response to this user's operation, and receives the play name list from the content server (S1402).

The audio client then determines whether to request the specified playlist (S1403). If the user specifies a desired playlist from the playlist and the audio client requests the specified playlist in response to this operation, the process proceeds to step S1413. If not, the process returns to steps S1401 or S1403 (if not requested). S1404).

If the play name list is not requested, the audio client determines whether to request the artist list from the content server (S1405). A plurality of artist names are listed in the artist list. The artist list is not prepared in advance on the content server, but is created each time from the content information database shown in FIG. 14 in response to a request from the audio client.

When the user requests the artist list, the audio client requests the desired artist list from the content server in response to the user's operation, and receives the artist list from the content server (S1406).

The audio client then determines whether to request a song list for the specified artist (S1407). If the user specifies a desired artist from the artist list and the audio client requests a song list of the specified artist in response to this operation, the process proceeds to step S1413, otherwise the process returns to step S1401 or S1407 (). S1408). The song list of the specified artist is listed in this song list, but this song list is not prepared in advance on the content server like the above artist list, but is shown in response to a request from the audio client. It is created each time from the content information database shown in 14.

If not requesting an artist list, the audio client determines whether to request a genre list from the content server (S1409). A plurality of genre names are listed in the genre list. Like the artist list above, the genre list is not prepared in advance on the content server, but is created each time from the content information database shown in FIG. 14 in response to a request from the audio client.

When the user requests a genre list, the audio client requests the desired genre list from the content server in response to the user's operation, and receives the genre list from the content server (S1410).

Subsequently, the audio client determines whether or not to request a song list of the specified genre (S1411). If the user specifies a desired genre from the genre list and the audio client requests a song list of the specified genre in response to this operation, the process proceeds to step S1413. S1412). The song list of the specified genre is listed in this song list, but this song list is not prepared in advance on the content server like the song list of the above artist, but responds to the request from the audio client. It is created each time from the content information database shown in Fig. 14.

As a result of the above, when requesting a song list, the audio client requests the song list from the content server and receives the song list from the content server (S1413). This completes the acquisition of the song list.

Next, with reference to FIG. 25, the operation when the genre list is acquired, pops are selected as a desired genre from the genre list, and the pop song list is acquired will be described.

In this case, the audio client sends a list request command to request the genre list from the content server (S1421). The content server responds by returning a genre list (S2401). The audio client receives the genre list from the content server and stores it in memory 32 as shown in FIG. 26 (S1422).

The genre list may be created in advance and stored in the content server, but this is not the case, and each time the audio client requests it, the content server bases the genre on the content information database shown in FIG. Create a list. The method of creating a genre list will be described below. As shown in FIG. 27, the content information database has n records when n songs are stored. Each record contains a song title, a genre, an artist name, an album name, and the like.

When creating a genre list using such a content information database, the content server first initializes the index indicating the record number to 0 (S24011), referring to FIG. 28.

Subsequently, the content server determines whether or not the genre of the record indicated by the index already exists in the genre list (S24012). If it does not exist, the content server adds the genre of the record to the genre list (S24013) and then increments the index (S24014). On the other hand, if present, the content server skips step S24013 and immediately increments the index (S24014).

The content server then determines if the record number indicated by the index is less than the total number of records n (S24015), returns to step S24012 if it is smaller, and creates a genre list if it is not. Complete.

By the above process, the content server picks up the genres of all the songs stored in the content information database without duplication and creates a genre list. In this way, the genre list is not stored in a database in advance, but is temporarily created at each request from the audio client, so that a memory area for always storing the genre list is unnecessary.

Referencing Figure 25 again, the created genre list is sent from the content server to the audio client (S2401, S1422). The user selects a desired genre (pops in this example) from this genre list. The audio client requests the content server for a list of songs of the selected genre according to the user's operation (S1423). The content server returns a list of songs of the selected genre to the content server in response to a request from the audio client (S2402). The audio client receives the song list from the content server and stores it in memory 32 as shown in FIG. 29 (S1424).

Similar to the above genre list, the song list is not prepared in advance on the content server, but is created based on the content information database shown in FIG. 27. That is, the content server creates a song list based on the content information database each time the audio client requests the song list. Hereinafter, a method of creating a song list will be described with reference to FIG.

First, the content server initializes the index indicating the record number in the content information database shown in FIG. 27 to 0 (S24021).

The content server then compares the genre of records indicated by the index with the selected genre (pops in this example) and determines if they match (S24022). If there is a match, the content server adds the record's song title, artist name, album name, etc. to the song list (S24023) and then increments the index (S24024). On the other hand, if they do not match, the content server skips step S24023 and immediately increments the index (S24024).

The content server then determines whether the record number indicated by the index is less than the total number of records n (S24025), returns to step S24022 if it is smaller, and creates a song list if it is not. Complete.

By the above process, the content server picks up only the songs of the selected genre from the content information database and creates a song list. In this way, the song list is not stored in a database in advance, but is temporarily created at each request from the audio client, so that a memory area for always storing the song list is unnecessary.

When creating a song list, it is possible not to pick up all the corresponding songs, but not to pick up songs in a data format that cannot be played. Further, instead of creating a song list each time a request is made from an audio client, the song list once created may be cached. In this case, a memory area for storing the song list is required, but the content server can immediately return the song list in response to a request from the audio client.

Similar to the above genre list, the song list is not transmitted all at once, but is transmitted little by little. That is, the operation of requesting the song list (S1423, S1425), replying to the song list (S2402, S2403), and receiving the song list (S1424, S1426) is repeated. The details will be described below.

The audio client sends a list request command as shown in Figure 31 to the content server (S1423). The list request command is a command in which the audio client requests a list from the content server, and in this example, the acquisition start index, the number of acquisitions, and the list construction key are included. The acquisition start index is an index indicating the first song to be acquired by the audio client among the songs recorded in the selected genre list. The acquisition number is the number of songs that the audio client intends to acquire. The list construction key, which will be described in detail later, is composed of a filter type indicating a category to be focused on when extracting songs from the content information database, and specific keywords classified into the category. Although not particularly limited, in this example, the acquisition start index = 0, the number of acquisitions = 50, and the list construction key is set to "genre (filter type) = pops (keyword)".

In response to this list request command, the content server returns the search data as shown in Figure 32 to the audio client (S2402). The search data includes a part of the song list, as well as a valid number and a remaining number. The valid number is the number of songs actually returned by the content server to the audio client. The remaining number is the number of songs remaining after the song list returned by the content server to the audio client. Here, since the content server responds to the list request command with the acquisition start index = 0 and the number of acquisitions = 50, the content server returns the first song to the 50th song in the created song list to the audio client (S2402). .. If the total number of songs in the song list is 110, the number of valid songs is set to 50 and the number of remaining songs is set to 60 (= 110-50).

Then, since the audio client still has 60 songs remaining on the content server, the audio client sends the list request command to the content server again (S1425). Here, the acquisition start index is set to 51 and the number of acquisitions is set to 50.

The content server responds to this list request command and returns the search data to the audio client again (S2403). Here, the effective number is set to 50 and the remaining number is set to 10 (= 110- (50 + 50)). That is, the content server returns the song list to the audio client for 50 songs again (S2403). The audio client receives this song list and stores it in memory 32 (S1426).

In the above example, since the total number of songs in the song list is 110 and the number of acquired songs is 50, 50 songs that are a part of the song list are returned, but the total number of songs in the song list is less than the number of acquired songs. In this case, for example, if the total number of songs in the song list is 40 and the number of acquired songs is 50, 40 songs, which is the total number of songs in the song list, will be returned.

Also, in the above example, since the acquisition start index = 0, the song is returned from the beginning of the song list, but if the acquisition start index = 10, for example, the song is returned from the 11th song in the song list. It will be. In this case, if the total number of songs in the song list is 110 and the first list request command is the acquisition start index = 10 and the number of acquisitions = 50, the content server has the effective number = 50 and the remaining number = 50 (=). 110-10-50) search data will be returned.

If the number of songs that can be stored in the memory 32 is larger than the total number of songs in the song list, the audio client can store the entire song list at one time. However, since the capacity of the memory 32 is much smaller than that of the content server, the audio client can usually store only a part of the song list in the memory 32.

According to the above embodiment, since the audio client divides and downloads the song list from the content server, if an area for at least 50 songs is prepared in the memory 32 of the audio client, the song list of all 110 songs can be obtained. You can download it. Therefore, the capacity of the memory 32 can be kept small.

For example, as shown in FIG. 33A, if the audio client stores a song list for 50 songs in the memory 32 and then the user wishes to acquire the 51st and subsequent songs, the audio client will use the latter half of the songs as shown in FIG. 33B. Move the list to the first half of memory 32. Then, as shown in FIG. 33C, the audio client stores a song list for the 51st to 25th songs in the latter half of the memory 32.

The audio client repeats the above operation to receive the entire song list, or receives as many songs as can be stored in the memory 32.

In the example shown in FIG. 25, a song is selected from that genre immediately after selecting a genre, but as shown in FIG. 34, after selecting a genre and continuing to select an album from that genre. , You may choose a song from that album.

In this case, the audio client requests the content server for an album list of the selected genre according to the user's operation (S1427). The content server returns the album list of the selected genre to the audio client in response to the request from the audio client (S2404). The audio client receives the album list from the content server and stores it in memory 32 (S1428).

Subsequently, the audio client requests the content server for a list of songs of the album selected according to the user's operation (S1429). The content server returns the song list of the selected album to the audio client in response to the request from the audio client (S2405).

1.2.2.2.2. Song designation With reference to FIGS. 35 and 36, the audio client requests the information of the specified song from the content server (S1501), and the content server returns the information of the specified song to the audio client in response to this request (S1501). S2501), the audio client receives this (S1502).

Specifically, the audio client transmits a song information request command as shown in FIG. 37 (S1501). This song information request command includes the file name of the specified song. In response to this song information request command, the content server returns song information as shown in FIG. 38 (S2501). This song information includes the data offset and data size of the specified song. Music data such as MP3 generally has header information before the content information. The data offset is for skipping this header information and specifying the start address of the song. The content server parses the offset, eliminating the need for the audio client to parse the offset. In general, the content server has a higher processing power than the audio client, so that the processing speed of the entire system can be increased. The data size is for confirming the end time of the song.

Subsequently, the audio client requests the content server to prepare for playing the specified song (S1503), and the content server opens the file of the specified song in response to this request and returns the result to the audio client (). S2502), the audio client receives this (S1504).

Specifically, the audio client sends a song playback preparation command as shown in FIG. 39 (S1503). This song playback preparation command includes the file name of the specified song and the list construction key described later. The content server opens the file in response to this song playback preparation command and returns an error code as shown in Figure 40 (S2502). This error code will result in an error if the file does not exist and is not ready for file transfer, and will be error-free if it is ready. The client checks the error code sent, and if there is an error, performs the prescribed error handling (S1504).

1.2.2.2.3. Playing a song Subsequently, the audio client requests the content server to transfer the music data of the specified range among the music data of the specified song (S1601), and the content server returns the music data of the specified range to the audio client in response to this request. Then (S2601), the audio client receives it and stores it in memory 32 (S1602).

Specifically, the audio client transmits a song data transfer request command as shown in FIG. 41 (S1601). This song data transfer request command includes an acquisition start address and acquisition data length of music data to be transferred. As shown in FIG. 42, the content server returns music data for the length of the acquired data from the start address specified by the acquisition start address (S2601). The size of the data transmitted at one time is not particularly limited, but is preferably 1K to 32K bytes, and more preferably 4K to 16K bytes. The content server can reduce the load as the amount of data returned at one time is smaller, and the client can process faster as the amount of data received at one time is larger, but 1K to 32K bytes (especially 4K to 16K) Bytes) is the optimal value for both the content server and the client. The size of such data is preset on the audio client side.

Music data can be sequentially transferred for each specified range by sequentially adding the acquired data length of the transferred acquisition start address and repeating the above operation (S1605, S2603, S1606, S1607, S2604, S1608). it can.

In this way, the audio client can acquire the specified range of music data from the content server, so that the song can be played from the middle, as described later, and the user's fast-forward playback, fast-rewind playback, slow playback, etc. Music can be played freely according to the operation.

The memory 32 includes a plurality of buffers (eight in the example shown in FIG. 43). As shown in FIG. 44, the audio client acquires and stores one buffer of music data from the beginning of the song by the song data transfer request command. As shown in FIG. 45, the audio client similarly acquires and stores music data until the buffer is completely filled.

When all the buffers are filled as described above between steps S1601 and S1608, the audio client starts outputting music data from the first buffer to the audio processing unit 34 as shown in FIG. 46.

When the audio client outputs the music data as described above and starts playing the music, the playback status is sent to the content server (S1603). The content server receives this and sends an error code back to the audio client (S2602). The audio client checks this error code, and if there is an error, performs the prescribed error handling (S1604).

When music is played while transferring music data as described above, a space for one buffer is eventually generated as shown in FIG. 47. When the buffer becomes full (S1609), the audio client and the content server perform the above transfer operation again (S1610, S2605, S1611). As a result, the free space in the buffer is filled as shown in FIG. The audio client and the content server repeat the above transfer operation every time the buffer becomes free (S1612 to S1616, S2606, S2607).

In the above, the music data is output after the buffer is completely filled with the music data, but the output may be started before the buffer is completely filled.

Subsequently, the audio client determines whether or not all the music data of the specified song has been received based on the data size acquired in step S1502 (S1617). When all are received, the audio client determines whether or not the specified song has finished playing based on the received music data (S16171), and if it finishes playing, sends a stop or completion status to the content server. (S1618). When the user operates the audio client and the audio client plays the specified song and finishes playing the song, or when the user operates the audio client and the audio client plays the song in the middle. If stopped at, the audio client sends a stop status. On the other hand, when the user operates the controller and the audio client plays the song specified by the controller and finishes playing the song, the audio client sends a completion status. The reason for distinguishing between the stopped status and the completed status in this way will be described later.

The content server receives this status and sends an error code back to the audio client (S2608). The audio client checks this error code, and if there is an error, performs the prescribed error handling (S1619).

As described above, since the music data is divided and transferred intermittently from the content server to the audio client, the music can be played appropriately even if the buffer capacity is small.

In the above, the music data is transferred in byte units, but when transferring MP3 music data, it is preferable to transfer in frame units. This is because there are many advantages in special playback (described later) such as time display, fast forward or fast rewind playback. Therefore, in the case of MP3 music data, the audio client shall request the music data on a frame-by-frame basis. In response to this request, the content server searches the specified file for the MP3 frame header and transfers from the beginning of the frame. Since this header contains a parameter that can calculate the data length, once the header is found, it is not difficult to find the beginning of the frame thereafter.

1.2.2.3. Special playback Further, in order to enable special playback such as fast forward, fast rewind, pause, and slow, the audio client performs the following processing before a series of processing of music data transfer request, reply, and acquisition.

1.2.2.3.1. Fast forward playback For fast forward playback, see Figure 49, the audio client monitors keystrokes (S1620) and sets the skip amount to a value greater than 0 if the fast forward playback key is pressed (S1621). If not, set the skip amount to 0 (S1622).

When the buffer becomes full (S1609), the audio client calculates the music data acquisition start address by the following equation (S1624).

Acquisition start address = previous acquisition start address + acquisition data length + skip amount If the fast-forward playback key is not pressed in step S1620, the skip amount is set to 0 in step S1622, so the acquisition start address increases by the acquisition data length. In this case, since the audio client continuously acquires the music data, normal playback is performed. On the other hand, when the fast-forward playback key is pressed in step S1620, the skip amount is set to a value larger than 0 in step S1621, so that the audio client skips and acquires the music data by the skip amount. As a result, the audio client performs fast forward playback. In this example, since the skip amount is set to be the same as the acquired data length, fast-forward playback at double speed is performed. Further, for example, by setting the skip amount to twice the acquired data length, it is possible to perform playback at 3 times speed.

1.2.2.3.2. Fast rewind playback In the case of fast rewind playback, the audio client determines whether the fast rewind playback key is pressed instead of step S1620, and instead of step S1621, the skip amount is smaller than 0 and the absolute value is acquired last time. Set to a value larger than the data length. This is because if the absolute value of the skip amount is smaller than the previously acquired data length, the music data acquisition ranges overlap. If the acquired data length is constant each time, if the absolute value is doubled the acquired data length, the return reproduction can be performed at the same speed as the normal reproduction.

Further, the audio client determines whether or not the acquisition start address calculated in step S1624 is within the range in which the music data exists (S1625). If it is within range, the audio client proceeds to the next step S1610, but if it is out of range, the audio client stops playing. In the case of normal playback, the end of music data is detected, so it is not necessary to enter such an end condition, but especially in the case of fast-rewind playback, it is necessary to detect the beginning of music data, so this is the case. The end condition is entered. However, without including such an end condition, the file of the next song may be opened for fast-forward playback, or the file of the previous song may be opened for fast-rewind playback.

In the case of MP3 music data, as described above, the position of the next frame header can be almost fixed by reading the frame header. Therefore, fast-forward reproduction can be realized by repeating the operation of skipping a certain number of frames, reproducing the data of several frames thereafter, and skipping the frames again.

1.2.2.3.3. Pause For pause, see Figure 50, the audio client monitors keystrokes (S1626, S1628), sets the operation status to pause if the pause key is pressed (S1627), and the play key is If pressed, the operation status is set to playback (S1629).

When the buffer becomes full (S1609), the audio client determines whether the operational status is paused (S1631). In the case of pause, the audio client returns to step S1626 and does not start transferring the next music data. On the other hand, if it is not paused, that is, if the play key is pressed to release the pause and the operation status changes to play, the audio client proceeds to step S1610 to start transferring the next music data.

Also, when the operation status is paused, the audio client stops the buffer read operation. This is because the previously transferred music data remains in the buffer.

1.2.2.3.4. Slow playback In the case of video, not music, slow playback is required. Since video files are usually in a compressed format like MPEG-2, audio clients are equipped with a decoder to play them. In the case of slow playback, if a command is given to the decoder to instruct slow playback, the rate of decrease of the video data stored in the buffer slows down. If slow playback is performed at a speed of 30% of normal playback, the amount of video data read from the buffer by the decoder per unit time is 30%. Therefore, in step S1609, the time for the audio client to wait for the buffer to become empty becomes longer, and slow playback can be realized.

1.2.3. Controller operation 1.2.3.1. Connection with content server Like the audio client Cj, the controller Ak also first establishes a connection with the content server Si.

With reference to FIG. 51, when the controller Ak is powered on, the controller Ak connects to the command port of the content server Si (S3001). Controller Ak issues a client index request command through this command port (S3002). The content server Si responds to this command by returning the client index to the controller Ak, which stores the retrieved client index (S3003).

The controller Ak then connects to the push port of the content server Si (S3004). Controller Ak issues a client index notification command through this push port and sends the client index saved in step S3003 to the content server (S3005). This opens the push port (S3006).

The controller Ak then notifies the content server Si through the command port of the client type (S3007). Here, unlike the above audio client Cj, the controller Ak notifies that it is a controller as a client type. The content server Si can distinguish between the audio client Cj and the controller Ak by this client type.

Subsequently, the controller Ak acquires the client information of the audio client Cj from the content server Si (S3008), and displays the status included in the information on the monitor.

Then, the controller Ak requests the content server Si to acquire the monitoring handle and the control handle of the audio client Cj connected to the content server Si based on the client type and the acquired client index (S3009).

The difference between the above connection procedure and the audio client Cj is that the controller Ak notifies the content server Si of the client type indicating that it is the controller. Another difference is that the controller Ak acquires both the monitoring handle and / or the control handle. The details will be described below.

1.2.3.1.1. Acquisition of monitoring handle and control handle With reference to Figure 52, controller Ak displays a list of all audio client Cj connected to content server Si (S30091). Controller Ak selects the audio client Cj to be monitored from the list according to the user's operation (S30092). The audio client Cj to be monitored according to the user's operation is selected only when the network audio system is first started, and from the second time onward, the first selected audio client Cj is registered and the audio client Cj is registered. It is preferable to automatically select the registered audio client.

The controller Ak then sends the client index of the selected audio client Cj to the content server Si and requests its monitoring handle (S30093). The content server Si stores the client index of the source controller Ak in association with the client index of the received audio client Cj (S20001), and issues a monitoring handle to the source controller Ak (S20002). As a result, controller Ak gets the watch handle for the selected audio client Cj (S30094).

Subsequently, the controller Ak selects the audio client Cj to be controlled from the list according to the user's operation (S30095). The controller Ak then sends the client index of the selected audio client Cj to the content server Si and requests its control handle (S30096). The content server Si stores the client index of the source controller Ak in association with the client index of the received audio client Cj (S20003), and issues a control handle to the source controller Ak (S20004). As a result, controller Ak gets the control handle of the selected audio client Cj (S30097).

The monitoring handle is the authority to monitor the audio client Cj given to the controller Ak by the content server Si. As a result, when the status of the audio client Cj changes, the new status after the change is notified to the content server Si. The content server Si sends the client information of the audio client Cj to the controller Ak at any time through the push port, and the controller Ak updates the client information of the audio client Cj accordingly.

In this network-type audio system, the greater the number of audio client Cj, the greater the load on LAN12. In addition, transmissions such as controller Ak commands and audio client Cj status affect traffic on LAN12.

As shown in FIG. 53, when a plurality of controllers A1 to A3 exist on the same LAN12, the content server Si may transmit the client information of the audio clients C1 to C3 to all the controllers A1 to A3. Although possible, doing so increases the load on network traffic and content servers.

Therefore, as shown in FIG. 54, the controller A1 acquires the monitoring handle of the audio client C1 only, the controller A2 acquires the monitoring handle of the audio client C2 only, and the content server Si obtains the client information of the audio client C1. Send only to controller A1 and send the client information of audio client C2 only to controller A2.

Since the content server Si transmits the client information only to the controller Ak that has acquired the monitoring handle of the audio client Cj, the network traffic and the load on the content server are reduced. However, the controller A3 may acquire the monitoring handles of all the audio clients C1 to C3, and the content server Si may send the client information to all the controllers A1 to A3.

On the other hand, the control handle is the authority given to the controller Ak from the content server Si to control the audio client Cj.

In this network-type audio system, when there are multiple controller Aks, if any controller Ak can control the audio client Cj, the audio client Cj is playing a song according to a command from a certain controller Ak. , Another controller Ak may instruct its audio client Cj to stop playing or play another song.

Therefore, in this system, only the controller Ak that has acquired the control handle of the audio client Cj can control the audio client Cj, and the controller Ak that has not acquired the control handle of the audio client Cj is the audio client Cj. To be out of control.

If the content server limits the controllers that can get the control handle, it is possible to set the combination of the audio client and the controller that can control it. Also, the controller issues a control handle release command to the content server so that the control handle can be abandoned.

1.2.3.2. Monitor function The controller Ak can monitor the audio client Cj by acquiring the monitoring handle as described above.

With reference to FIG. 55, the controller Ak requests the client information from the content server Si (S31), the content server Si returns the client information in response (S27), and the controller Ak acquires and stores it. (S31). Alternatively, when the content server Si receives the client information from the audio client Cj, the content server Si transmits the client information to the controller Ak via the push port, and the controller Ak acquires and stores the client information. Then, the controller Ak displays the acquired client information (S32). The monitor function by this controller will be described in detail below.

With reference to FIG. 56, the content server Si transmits client information in response to a request from controller Ak or reception of client information from an audio client (S2701). When the controller Ak receives this client information, it checks each information for changes. That is, first check the client index (S3101) and remember which audio client Cj is the client information. Then, the product ID and firmware ID of the stored audio client are confirmed (S3102, S3103).

Specifically, the product ID determines the type of audio client, and the firmware ID determines the firmware version. If the firmware version applied to the audio client is out of date, the controller Ak will access customer service on the Internet and deliver the firmware to the audio client Cj for automatic updates. Details of the firmware update will be described later.

The controller Ak analyzes the received client information to check the client type, and if it is an audio client Cj, it branches to the processing for it, and if it is not, it ignores it.

Next, the controller Ak checks whether the connection information has changed (S3104), and if there is a change, changes the display of the connection status of the audio client Cj (S3105).

Therefore, it is possible to constantly monitor whether or not a plurality of audio clients Cj are turned on and connected to the content server Si by the controller Ak.

If the audio client Cj is connected, the controller Ak checks if the volume value has changed (S3106) and changes the display of the volume value if there is a change (S3107).

Subsequently, the controller Ak checks whether the list construction key (described later) has been changed (S3108), and if there is a change, requests the content server Si for the song list using the list construction key (S3109). The content server Si returns the song list in response to this request (S2702), and the controller Ak receives this song list (S3110).

The controller Ak stores the received song list as a song list being played by the audio client Cj, checks the number of the song currently being played in the song list, and stores the number (S3111).

Next, the controller Ak checks if there is any change in the song being played (S3112), if there is a change, checks the data format of the song (S3113), and changes the display of the song name and artist name being played. (S3114), check the number of the song currently playing in the song list and memorize the number (S3115).

Finally, controller Ak checks for changes in status (S3116) and changes the status display if there are changes (S3117). Even if the audio client Cj is controlled by the remote control, the controller Ak monitors and displays its status. If the status of audio client Cj is complete (S3118), controller Ak instructs audio client Cj to continue playing the next song (S3119). Details of continuous playback will be described later.

The above processing is repeated every time the client information of any of all the audio clients for which the controller has acquired the monitoring handle changes.

Also, although not shown, the controller Ak monitors the client type of each audio client Cj. In addition, the controller Ak monitors the playable data format and displays only the playable song titles.

As described above, when the content server receives the client information from the client, the controller Ak can constantly monitor the audio client Cj by forcibly sending the client information to the controller via the push port. , The content server Si sends only the minimum required information to the controller CL. Therefore, the processing load on the controller Ak is reduced. Moreover, even if there are a plurality of audio client Cj, the controller Ak can distinguish the audio client Cj by the client index and update each client information in real time.

1.2.3.3. Control function The controller Ak can control the audio client Cj by acquiring the control handle as described above.

With reference to FIG. 57, the controller Ak sends a control command to the content server Si (S33), which in turn sends it to the designated audio client Cj (S28). The audio client Cj operates according to this control command, changes its status (S18), and sends the changed status to the content server Si (S19). The content server Si sends this status to the controller Ak (S29), and the controller Ak changes the status of the stored client information accordingly (S34).

1.2.3.3.1. Control command processing Next, with reference to FIG. 58, the processing performed by the audio client Cj according to the control command received from the controller Ak through the content server Si will be described.

When some data is written to the push port (S3001), the audio client Cj receives the data and analyzes it (S3002).

If the received data is a playback command (S3003), the audio client Cj acquires the specified file name from the content server Si (S3004). The audio client Cj specifies the song title, album, genre, etc. from the acquired file name. Then, the audio client Cj specifies a song and instructs the content server Si to transfer the music data of the song (S3005). The audio client Cj plays back based on the transferred music data.

If the received data is a playback stop command (S3006), the audio client Cj stops the music data transfer by stopping the issuance of the song data transfer request command (S3007), and sends the stop status to the content server Si. (S3008). The audio client Cj also performs a predetermined process in response to a volume value set command, a pause command, an AV receiver control command, a firmware update command, and the like (S3009 to S3010).

1.2.3.3.2. Playback control Here, the operation in which the controller Ak causes the audio client Cj to play a desired song of a desired artist according to a playback command will be described.

With reference to FIG. 59, the controller Ak checks the connection of the audio client Cj (S3011), and if there is a connection, checks the firmware ID and product ID of the audio client Cj (S3012, S3013).

The controller Ak then determines whether the audio client Cj is an audio client or an AVR client based on the client type (S3014). Since it is the audio client Cj here, the controller Ak determines whether or not the song list of the desired artist has already been acquired (S3015). If not yet, controller Ak gets the song list of the desired artist from the content server Si (S3016). The controller Ak displays this song list on the display device.

If there is a song that the user wants to play in the acquired song list (S3017), the controller Ak selects the song according to the user's input operation and sends a play command to the content server Si (S3018). ). This play command includes the name of the file that contains the data for the selected song and the client index of the audio client that wants to play the song. On the other hand, if there is no desired song, controller Ak again gets the next song list of the desired artist (S3016).

The content server Si identifies the audio client Cj based on the client index sent from the controller Ak, and sends the file name of the selected song to the audio client Cj (S28).

The audio client Cj plays the desired song in response to the playback command sent from the controller Ak through the content server Si, and changes the status to the playback status (S18). The audio client Cj sends the playback status to the content server Si (S19), and the content server Si sends the playback status to the controller Ak (S29). The controller Ak changes the status of the audio client Cj to the playback status accordingly (S34).

1.2.3.3.3. Identify and play a playable format The song list includes songs in all formats, regardless of whether the audio client Cj is playable. Therefore, if the controller Ak displays the song list acquired from the content server Si as it is to the user when the user selects a desired song, the following problems occur.

That is, even if the user selects a song in a format that the audio client Cj cannot play, the controller Ak instructs the audio client Cj to play the song selected by the user, so that the display is in the playback state on the audio client Cj. However, there is no playback sound.

Therefore, as shown in FIG. 60, information about the playable format is added to the client type of the client information. Therefore, the client type is composed of information about the hardware configuration of the client and information about the format that the audio client can play.

Information about the hardware configuration includes the following: An "audio client (intelligent type)" is an audio client that can play music and receive remote control signals. An "audio client (non-intelligent type)" is an audio client that can play music but cannot receive remote control signals. A "controller" is a client that can monitor and control an audio client via a content server. An "AVR client" is a client that has an EIA-232 port and can communicate with an AV receiver. An "AVR controller" is a client that can control and monitor an AVR client via a content server. Information on playable formats includes MP3, WAV, WMA, etc.

A client type of a client may contain information about multiple hardware configurations, or it may contain information about multiple playable formats.

Next, the processing procedure when the controller Ak displays the song list to the user will be described with reference to FIG.

First, the controller Ak determines whether or not the audio client Cj that wants to play the song is connected to the content server Si (S3501). When not connected, the audio client Cj cannot play songs, so all songs in the song list are displayed as unplayable songs, or all songs are not displayed (S3502). Therefore, it is possible to prevent the user from selecting a song that cannot be played by the audio client Cj.

On the other hand, when already connected, the following steps S3505 to S3507 are repeated for the number of songs in the song list (S3503, S3504, S3508).

That is, the controller Ak determines whether or not the format of the nth song in the song list is a format that can be played by the audio client Cj (S3505). If the format is playable, the controller Ak will display the song as a playable song (S3506), and if it is a non-playable format, it will display it as a non-playable song or not (S3507). ..

For example, if the audio client C1 can play both MP3s and WAVs, the controller Ak will display all the songs in the song list (playlist in this example), as shown in Figure 62. However, if the audio client C2 can play MP3s but not WAVs, the MP3 songs in the song list will be displayed normally, but the WAV songs will be dimmed, as shown in Figure 63. Also, the song may not be displayed at all instead of being displayed lightly. Therefore, it is possible to prevent the user from selecting a WAV song that cannot be played by the audio client C2.

If the connection status or client type of the audio client Cj is changed, the controller Ak redisplays the song list and displays the client information of the current audio client in real time.

Next, the operation of the controller when the user operates the controller Ak to cause the audio client Cj to play a song will be described.

With reference to FIG. 64, when the user selects a song that he / she wants to play, the controller Ak determines whether the format of the selected song is playable by the audio client Cj (S3511). Specifically, the controller Ak compares the format of the selected song with the playable format in the client type.

If the format is playable, controller Ak instructs audio client Cj to play the selected song (S3512). On the other hand, if the format is non-playable, the audio client Cj informs the user that the selected song cannot be played (S3513).

As described above, the controller Ak displays the songs that can be played by the audio client Cj so that the user can understand them, so that the user does not request the playback of the songs that the audio client Cj cannot play.

1.2.3.3.4. Continuous playback control If the user operates the audio client Cj to play a song on the audio client Cj, the audio client Cj has acquired the song list, so the songs in the song list can be played continuously. It is possible. However, when the audio client Cj is playing the song instructed by the controller Ak, the audio client Cj itself does not acquire the song list, so the audio client Cj continuously plays the songs in the song list. In order to do so, the controller Ak needs to instruct the audio client Cj to perform the next song.

Further, if there is only one controller on the network, there is no problem, but if there are a plurality of controllers, there is a problem that the audio client cannot normally perform continuous playback. For example, if the content server notified of the completion of playback by the audio client notifies all the controllers of the completion of playback, the audio client receives commands for continuous playback from a plurality of controllers. This problem is further complicated when there are multiple content servers on the network. Therefore, in order to enable continuous playback by a controller in a network-type audio system, it is necessary to manage which controller instructs the client to perform continuous playback.

In the present embodiment, the audio client Cj plays a song according to a command from the controller Ak, and sends a completion status when the playback is finished, but at other times, for example, the audio client responds to a user operation. When Cj plays the song by itself and ends the playback, or when the audio client Cj stops playing the song in the middle according to the user's operation, a stop status different from the completion status is transmitted. When the controller receives the completion status, it determines that continuous playback processing should be performed, selects the next song of the previously selected song from the song list, and instructs the audio client to play the next song. .. Also, the controller does not instruct the audio client to play the next song when it receives a stop status. As described above, the audio client transmits the completed status and the stopped status separately according to the situation, and the controller determines whether or not to instruct the audio client to play the next song based on the received status. You can judge.

Therefore, if the audio client Cj stops the playback of the song in the middle according to the user's operation, or if the audio client Cj selects the song by itself and ends the playback, the stop status is sent to the content server. , You can prevent the controller from accidentally instructing the audio client to play the next song.

When there are a plurality of controllers, the content server that receives the completion status from the audio client transmits the completion status and the stop status to each controller separately. That is, referring to FIG. 65, when the controller A1 instructs the audio client C1 to play, the controller A1 first sends a play command to the audio client C1 to the content server Si. The content server Si receives the playback command from the controller A1 and sends it to the audio client C1. The audio client C1 receives a playback command from the content server Si and starts playing the song.

With reference to FIGS. 66 and 67, when the audio client C1 finishes playing the song, it sends a completion status to the content server (S1901), which the content server Si receives (S2901). Subsequently, the content server Si repeats the following steps S2903 to S2906 for the number of clients (S2902, S2907).

The content server Si determines whether the nth client is the controller that has acquired the watch handle of the audio client C1 based on the client index n (S2903).

In the case of the controller that has acquired the monitoring handle, the content server Si determines whether or not the nth client (controller) is the controller A1 that instructed the audio client C1 to play (S2904).

In the case of controller A1 instructing the audio client C1 to play, the content server Si sends the completion status received from the audio client C1 to the controller A1 (S2905), and the controller A1 receives this (S3401). On the other hand, in the case of the controller A2 other than the controller A1 that instructed the audio client C1 to play, the content server Si sends the stop status to the controller A2 (S2906) instead of the completion status received from the audio client C1 and the controller A2. Receives this (S3402).

Referring to FIG. 68, the controller A1 receiving the completion status selects the next song of the previously selected song from the song list, and issues a play command for playing the song to the audio client C1 on the content server. Send to Si (S3403). The content server Si receives this and sends it to the audio client C1. The audio client C1 plays the next song according to the play command sent from the content server Si.

On the other hand, the controller A2 that has received the stop status determines that the audio client C1 is in the stopped state, and does not perform continuous playback processing unlike the controller A1.

The audio client Cj sends the playback status to the content server Si when the status becomes playback, sends the pause status to the content server Si when the status is paused, and sends the stop status to the content server Si when the playback of the song specified by itself ends. It is transmitted to the server Si, but as described above, when the playback of the song specified by the controller Ak is completed, the completion status is transmitted to the content server Si.

As described above, by distinguishing the status that the content server Si sends to the controller Ak when the audio client Cj finishes playing the song into the stop status and the completion status, the controller Ak orders the playback by itself. It is possible to determine whether Cj has finished playing the song. As a result, the controller Ak can determine whether the audio client Cj needs to be instructed to play continuously or just needs to display the stop status of the audio client Cj.

When the audio client Cj finishes playing the song, the song is played according to the command from the controller Ak that has acquired both the monitoring handle and the control handle, and the song is played according to the command from the dedicated remote controller. The status to be notified to the content server Si may be distinguished from the case where the content server Si has been displayed. This is because the dedicated remote controller that has acquired only the control handle cannot receive the status from the content server Si, and therefore cannot perform continuous playback processing.

1.2.3.3.5. Continuous playback control using list construction key The controller Ak acquires various song lists from the content server Si, selects a song from the list, and causes the audio client Cj to play the song. Then, the controller Ak monitors the status of the audio client Cj, and when the audio client Cj finishes playing the selected song, it selects the next song from the acquired song list and selects that song from the audio client. Let Cj play it. The controller Ak causes the audio client Cj to play songs continuously in this way, but it is necessary to store the song list in order to instruct the playback of the next song. Therefore, the power of the controller Ak that commands the playback of the song cannot be turned off during the playback of the song.

Therefore, the following method is adopted so that the controller Ak can instruct the audio client Cj to continuously play even if the power of the controller Ak that instructed the audio client Cj to play is turned off in the middle.

When the user selects a song to be played from the content information database, various song lists are used, such as selecting from a song list of a certain artist or selecting from a song list of a certain genre. Therefore, a list construction key is defined so that a song list can be uniquely created from the content information database. Then, this list construction key is added to the client information as information for identifying the song list being played by the audio client Cj.

With reference to FIG. 69, the list construction key is composed of "filter type" and "keyword". The type of filter specifies which category in the content information database to focus on when creating the song list, and is as shown in FIG. 70. If the filter type is "TITLE =", "GENRE =", "ARTIST =", "ALBUM =", or "FILENAME =", the song name, genre name, artist name, and album name from the content information database. Or, find songs whose file names match the keywords and create a song list. If the filter type is "PLAYLIST =", the songs registered in the playlist whose playlist file name matches the keyword are searched from the content information database and the song list is created.

For example, in the case of a song list with the artist name "xxxx", the filter type is "ARTIST =" and the keyword is "xxxx", so the list construction key is "ARTIST = xxxx". Also, if you specify "*" (asterisk) as a keyword, a list of keywords that can be used for that filter type is created. For example, the list created from the list construction key "ARTIST = *" creates a list of artist names of songs registered in the content information database.

The procedure for the controller to perform continuous playback processing for the audio client that has finished playing the song specified by the controller will be described below.

With reference to FIG. 71, when the audio client Cj instructed to play the song from the controller Ak finishes playing the song, the completion status is sent to the content server Si. Since the status of the audio client Cj has changed, the content server Si sends client information including the completion status, the file name of the song being played, the list construction key, etc. to the controller Ak.

When the controller Ak receives the client information, it starts the client information display process shown in FIG. 56. Since this process has already been described, the part related to continuous playback control mainly using the list construction key will be described here.

The controller Ak checks whether the list construction key has been changed (S3108), and if there is a change, the audio client Cj uses the list construction key to acquire the song list being played from the content server Si (S3110). Specifically, the received list construction key is sent to the content server, and the content server creates a list based on this list construction key and sends it to the controller. Even if the power is turned off and the controller Ak does not remember the song list being played by the audio client Cj, the song list being played is obtained from the content server Si using the list construction key acquired after connecting to the content server. To do.

Here, since the status has changed to the completed status, the controller Ak performs the completion process (S3119). That is, the controller Ak selects the song next to the song whose playback has ended by the audio client Cj from the song list, and instructs the audio client Cj to play the selected song.

The details of the completion process will be described with reference to FIG. 72. The controller Ak increments the playback song number n stored in step S3111 in FIG. 56 (S31191), and specifies the song to be played next. Subsequently, the controller Ak determines whether or not the reproduced song number n is equal to or less than the number of songs in the song list (S31192). If the playback song number n exceeds the number of songs in the song list, the controller Ak determines that the audio client Cj has played to the end of the song list, sets the playback song number n to 1 (S31193), and then sets the playback song number n to 1. Move the song to be played back to the first song in the song list.

If the playback song number n is less than or equal to the number of songs in the song list, the controller Ak checks whether the nth song is in a format that can be played by the audio client Cj (S31194), and if it is in a playable format, Instructs the audio client Cj to play the nth song in the song list (S31195). If the format is non-reproducible, this completion process is recursively performed to play the next song. In short, the controller Ak instructs the audio client Cj to skip a song in a format that cannot be played by the audio client Cj and play the next song.

As described above, if the power of the controller Ak is turned off after instructing the audio client Cj to play a song, the controller Ak loses the song list when the audio client Cj is instructed to play the song. However, when the power is turned on again and the connection with the content server is completed, the controller Ak acquires the client information of the audio client Cj from the content server Si as described in S3008 of FIG. Since this client information includes a list build key, the controller Ak can retrieve the list of songs being played by the client CL again based on this list build key. Therefore, even if the controller Ak commands the audio client Cj to play the song and then its power is turned off, the audio client Cj finishes playing the song, sends a completion status, and sets this completion status. When the controller Ak receives it, it can instruct the audio client Cj to play the next song according to the reacquired song list.

In order to stop the playback operation of the audio client Cj, the controller Ak may send a stop command to the audio client Cj through the content server Si. In this case, the stop status is returned from the audio client Cj to the controller Ak through the content server Si. Further, in order to suspend the playback operation of the audio client Cj, the controller Ak may send a pause command to the audio client Cj through the content server Si. In this case, the pause status is returned from the audio client Cj to the controller Ak through the content server Si.

1.2.3.3.6. Prioritized continuous playback control This embodiment will be described focusing on the content server S1 and the audio client C1. In the present embodiment, the controller management table is stored in the HDD 14 of the content server S1. An example of the controller management table is shown in Table 1 below. In the controller management table, the priority for controlling the audio client C1 and the controller index assigned to the controllers A1 to Ak are recorded in association with each other.<tables num="1"><img file="JP4929520B2_D0001.tif" /></tables>

In the present embodiment, computer programs for executing the steps shown in FIG. 73 are installed in the content servers S1 to Si, the audio clients C1 to Cj, and the controllers A1 to Ak, respectively. Hereinafter, the operation of the network-type audio system 10 according to the present embodiment will be described with reference to the flow chart shown in FIG. 73.

First, controller A1 requests a connection to content server S1, and when content server S1 accepts this request, a connection is established between controller A1 and content server S1 (S30301).

Following controller A1, controller A2 requests a connection to content server S1, and when content server S1 accepts this request, a connection is established between controller A2 and content server S1 (S30401).

On the other hand, the content server S1 records the controller index of the controller A1 in the controller management table in association with the priority "first place", and further associates it with the priority "second place" in the controller of the controller A2. Record the index (S20101). As a result, the controller management table shown in Table 1 above is obtained. According to this controller management table, the controller A1 has the highest priority and the authority for continuous reproduction processing, and then the controller A2 has the authority for continuous reproduction processing.

Hereinafter, the operation when the controller A1 instructs the audio client C1 to continuously play a plurality of songs via the content server S1 will be described.

The controller A1 requests the content server S1 for a list of songs to be continuously played (S30302). Specifically, the list construction key required to create the song list is sent to the content server S1.

When a user selects a song to be played from the content server S1, the user uses various song lists such as selecting from a song list of a certain artist or selecting from a song list of a certain genre. The list construction key is a search key for extracting such a song list from the content server S1 and uniquely creating it. As shown in Fig. 69, the list construction key consists of two parameters: filter type and keyword.

The type of filter specifies the category of songs to be included in the song list, specifically as shown in FIG. 70.

The content server S1 creates a song list based on the list construction key sent from the controller A1 and sends it to the controller A1 (S20102). Specifically, if the filter type is "TITLE =", "GENRE =", "ARTIST =", "ALBUM =", or "FILENAME =", the song name, genre name, artist name, album name, or Find one or more songs whose file names match the keywords, and create a song list that lists the songs. If the filter type is "PLAYLIST =", the songs registered in the playlist whose file name of the playlist matches the keyword are searched for, and a song list (playlist) listing the songs is created. In addition, the content server S1 registers the list construction key as one of the client information of the audio client C1 in association with the client index (identification information of the audio client C1).

The controller A1 instructs the audio client C1 to play the song specified in response to the user's operation from the acquired song list via the content server S1 (S30303). The audio client C1 requests the music content of the specified song from the content server S1 in response to the playback command from the controller A1 (S10201). The content server S1 delivers the music content requested by the audio client C1 to the audio client C1 (S20103). The audio client C1 starts playing a song based on the music content transmitted from the content server S1 (S10202).

When the audio client C1 finishes playing the specified song to the end, it sends a completion status to that effect to the content server S1 (S10203). When the content server S1 receives the completion status from the audio client C1, it refers to the controller management table 104 as shown in FIG. 74, transfers the completion status to the highest-ranked controller A1 as it is, and transfers the completion status to the lower controller A2 as it is. Send a stop status that is different from the completion status (S20104).

As shown in FIG. 74, the controller A1 instructs the audio client C1 via the content server S1 to continuously play the next song according to the song list (S30304). The audio client C1 plays the next song in response to the continuous playback command from the controller A1. After that, the audio client C1 repeats the operations after step S201. On the other hand, the controller A2 does not take any particularly active action even if it receives the stop status from the content server S1, and simply monitors the status of the audio client C1.

When the controllers A1 to Ak are disconnected from the content server S1, the content server S1 updates the controller management table 104. Specifically, the controller index of the controller disconnected from the content server S1 is deleted, and the priority of the controller index lower than that is sequentially moved up. For example, as shown in FIG. 75, when the controller A1 having the highest priority is disconnected from the content server S1, the controller A2 having the next priority moves up and acquires the authority for continuous playback processing in place of the controller A1. To do.

Further, in the above example, the controller A1 first commands the playback, and the same controller A1 again commands the continuous playback, but even if the controller A2 first commands the playback, the priority of the controller A1 is high. Controller A1 commands continuous playback as long as it is the best. In this case, the controller A1 does not have the song list even if the completion status is received from the content server S1, so the song from the content server S1 is used by using the list construction key of the audio client C1 registered in the content server S1. Get the list and specify the next song accordingly.

Further, not all songs included in the song list are stored in one content server S1, and may be distributed and stored in a plurality of content servers S1 and Si. In this case, the audio client C1 needs to play the song of the content server S1 and then continue to play the song of another content server Si. Therefore, the audio client C1 that has finished playing the song of the content server S1 temporarily disconnects from the content server S1 and reconnects to the content server Si, which is a server switching process.

The audio client C1 reconnected to the content server Si requests the music content of the specified song from the content server Si in response to the playback command from the controller A1, and the content server Si requests the requested music content to the audio client. Deliver to C1.

When the audio client C1 finishes playing the song, it sends the completion status to the content server Si. When the content server Si receives the completion status, it refers to the controller management table inside the content server Si, transfers the completion status to the highest-ranked controller, and sends the stop status to the controller below it.

Here, the controller management table in the content server Si may be the same as or different from the controller management table in the content server S1. In order for a plurality of content servers to use the same controller management table, for example, one content server may determine the priority of the controller management table and transfer the controller management table to another content server. On the other hand, in order for a plurality of content servers to use different controller management tables, for example, each content server may independently determine the priority of the controller management table.

As described above, according to the present embodiment, when the content server S1 receives the completion status from the audio client C1, it refers to the controller management table, sends the completion status only to the highest priority controller A1, and other controllers. Since the stop status is transmitted to A2, only the controller A1 having the highest priority commands continuous playback, and the other controllers A2 do not command continuous playback. Therefore, it is possible to eliminate the conflict of continuous reproduction instructions and execute the continuous reproduction process normally.

In the above embodiment, the priority is determined in the order of connection with the content server S1, but the priority is not limited to this, and may be determined in the order in which commands are issued to the audio client C1, for example. Also, there is no need to have multiple content servers, only at least one. You don't have to have multiple audio clients, just one.

1.2.3.3.7. Continuous playback control using the control handle In the present embodiment, the computer programs for executing the steps shown in FIG. 76 are installed in the content servers S1 to Si, the audio clients C1 to Cj, and the controllers A1 to Ak, respectively. Similar to the above embodiment, this embodiment can be applied to a network type audio system including a plurality of controllers A1 to Ak, and at least one content server or audio client is required.

Unlike the above embodiment, in the present embodiment, the control handle management table is stored in the controllers A1 to Ak. An example of the control handle management table is shown in Table 2 below. In the control handle management table, the client index of the audio clients C1 to Cj and the controller index of the controllers A1 to Ak that acquire the control handles of the audio clients C1 to Cj are recorded in association with each other. The control handle indicates the authority to control the audio client. In the example of Table 2, the control handle of the audio client C1 is acquired by the controller A1, but the control handle of the audio clients C2 and Cj is not acquired by any of the controllers.<tables num="2"><img file="JP4929520B2_D0002.tif" /></tables>

Hereinafter, the operation of the present embodiment will be described with reference to the flow chart shown in FIG. 76, focusing on the content server S1, the audio client C1 and the controller A1. In FIG. 76, the song list acquisition steps (S30302, S20102 in FIG. 73) detailed in the first embodiment are omitted.

The controller A1 acquires the control handle required to control the audio client C1 before instructing the audio client C1 to play. Specifically, the controller A1 refers to the control handle management table and determines whether or not the control handle of the audio client C1 is locked (S30311).

If the control handle of audio client C1 has already been acquired by any of the other controllers A2 to Ak, in the control handle management table shown in Table 2, the controller index of that controller corresponds to the client index of audio client C1. Is recorded. The state in which the control handle has already been acquired in this way is called "the control handle is locked". On the other hand, if the control handle of the audio client C1 has not yet been acquired by any of the other controllers A2 to Ak, no controller index is recorded corresponding to the client index of the audio client C1. The state in which the control handle has not been acquired in this way is called "the control handle is not locked (unlocked)". For example, in the control handle management table shown in Table 2, the control handle of audio client C2 is not locked.

If the control handle of audio client C1 is locked, controller A1 fails to get the control handle. On the other hand, if it is not locked, controller A1 requests the content server S1 to acquire the control handle (S30312). In response to this request, the content server S1 allows controller A1 to acquire the control handle (S20111). As a result, controller A1 acquires a control handle and further locks this control handle so that it cannot be acquired by other controllers A2 to Ak (S30313). Specifically, controller A1 updates the control handle management table, thereby recording the controller index of controller A1 in association with the client index of audio client C1. The content server S1 also updates the control handle management tables of other controllers A2 to Ak to synchronize with this.

The controller A1 that has acquired the control handle instructs the audio client C1 to play the song specified in response to the user's operation from the song list via the content server S1 (S30314). The content server S1 transfers this playback instruction to the audio client C1 (S20112). The audio client C1 starts playing the specified song in response to this playback command (S10211).

When the audio client C1 finishes playing the song to the end, it sends the completion status to the content server S1 as shown in FIG. 77 (S10212). The content server S1 transfers this completion status to all controllers A1 to Ak (S20113).

Controller A1 determines whether it is the completion status from the audio client C1 that has acquired the control handle (S30315), executes continuous playback processing (S30316) if it is, and if not, the completion status. Ignore and simply monitor the status of audio client C1. In this example, since the controller A1 has acquired the control handle of the audio client C1, the continuous playback process is executed (S30316), and the playback of the next song is instructed according to the song list (S30314).

On the other hand, the audio client C1 transmits the stop status to the content server S1 when the playback is stopped in the middle of the song without playing the song to the end (S10213). The content server S1 transfers this stop status to all controllers A1 to Ak (S20114).

Controller A1 determines whether the status is stopped from the audio client C1 that has acquired the control handle (S30317), and if so, unlocks (unlocks) the control handle of the audio client C1 (S30318). , Otherwise ignore the stop status.

In addition to receiving the stop status from the audio client C1 for which the controller A1 has acquired the control handle as described above, the controller A1 also releases the acquired control handle when the content server S1 is disconnected. When the control handle of the audio client C1 is released, all of the controllers A1 to Ak can acquire this control handle.

When the songs included in the song list are distributed and stored in the plurality of content servers S1 and Si, the audio client C1 is the content server S1 as shown in FIG. 77, as in the first embodiment. Will switch the connection to another content server Si. Even if the content server Si receives the completion status from the audio client C1, it is unknown which controller A1 to Ak has finished playing the song instructed by the audio client C1. Therefore, in this case as well, the content server Si transfers the completion status to all the controllers A1 to Ak, but since the controllers A1 to Ak have the control handle management table, the audio client that has acquired the control handle itself. The continuous playback process is executed only when the completion status from is received. In this example, since the controller A1 has acquired the control handle of the audio client C1, only this controller A1 executes the continuous playback process.

As described above, according to the present embodiment, since each of the controllers A1 to Ak has a control handle management table, the content server S1 sets the completion status transmitted from the audio client C1 to all the controllers A1 to Ak. Even if it is transferred to, each of the controllers A1 to Ak executes the continuous playback process only when the completion status from the audio client that has acquired the control handle is received. Therefore, it is possible to eliminate the conflict of continuous reproduction instructions and execute the continuous reproduction process normally.

In the present embodiment, the control handle management table is stored in the controllers A1 to Ak, but may be stored in the content servers S1 to Si.

Also, instead of locking the control handle, the last commanded controller may be able to acquire the control handle. That is, if one controller A1 acquires the control handle of one client C1 and another controller A2 commands the client C1 to play, the controller A2 acquires the control handle and the controller A1 loses the control handle. You may do so.

1.2.3.3.8. Continuous playback control by content server First, a simple example with one content server, one audio client, and one controller will be described with reference to FIG. 78.

Similar to the above embodiment, the controller A1 instructs the audio client C1 to play the song via the content server S1. The audio client C1 requests the music content of the song from the content server S1 in response to this command, and the content server S1 delivers the music content to the audio client C1 in response to this request. The audio client C1 starts playing a song based on the delivered music content, and sends a completion status to the content server S1 when the song has been played to the end. When the content server S1 receives this completion status, unlike the above embodiment, the content server S1 instructs the audio client C1 to continuously play the next song by itself, and transmits the stop status to the controller A1.

Hereinafter, this detail will be described with reference to the flow chart shown in FIG. 79. In the present embodiment, the computer programs for executing the steps shown in FIG. 79 are installed in the content server S1, the audio client C1 and the controller A1, respectively. Since steps S30323, S10221, and S20123 to S21125 in FIG. 79 are different from the embodiments shown in FIG. 73, they will be mainly described here.

The controller A1 instructs the audio client C1 to play the song in the same manner as in the above embodiment, but unlike the above embodiment, the controller A1 further gives the audio client C1 the list construction key used to acquire the song list in step S30302. Send (S30323).

The audio client C1 requests the music content of the specified song from the content server S1 as in the first embodiment, and transfers the list construction key transmitted from the controller A1 to the content server S1 (S10221).

The content server S1 delivers the music content of the specified song to the audio client C1 in the same manner as in the above embodiment, but unlike the above embodiment, the song list is created based on the list construction key transferred from the audio client C1. Create (S20123). The list construction key and the song list are recorded as client information in association with the client index of the audio client C1. As a result, the content server S1 knows the song list that the audio client C1 is playing in response to the instruction from the controller A1.

After the music has finished playing, the content server S1 that has received the completion status from the audio client C1 transmits the stop status to the controller A1 (S20124), unlike the above embodiment. Then, the content server S1 instructs the audio client C1 to play the next song according to the song list created in step S20123 (S20125).

As described above, according to the present embodiment, since the content server S1 itself commands continuous playback, the continuous playback instructions from the controller do not conflict with each other, and the continuous playback process can be normally executed.

The above example has only one audio client, but there can be more than one. For example, in the example shown in FIG. 80, the audio clients C1 and C2 are connected to the content server S1. Similar to step S123, the content server S1 stores the list construction key and the song list being played by the audio clients C1 and C2, respectively. When the completion status is transmitted from the audio client C1 to the content server S1, the content server S1 instructs the audio client C1 to continuously play according to the stored song list of the audio client C1 and transmits the stop status to the controller A1. When the completion status is transmitted from the audio client C2 to the content server S1, the content server S1 instructs the audio client C2 to continuously play according to the stored song list of the audio client C2, and transmits the stop status to the controller A1. In this way, since the content server S1 distinguishes between the audio clients C1 and C2 and instructs continuous playback, the continuous playback instructions do not conflict with each other.

In addition to the audio client, there may be two or more content servers. For example, in the example shown in FIG. 81, the audio clients C1 and C2 are connected to the content server S1, and the audio client C3 is connected to the content server S2. Again, since there is only one content server connected to each client, the audio client sends the completion status only to the connected content server. Similar to the above, when the content server S1 receives the completion status from the audio client C1, it instructs the audio client C1 to continuously play, and when it receives the completion status from the audio client C2, it orders the audio client C2 to play continuously. Further, in this case, when the content server S2 receives the completion status from the audio client C3, the content server S2 instructs the audio client C3 to play continuously. Therefore, in this case as well, since the content server that instructs the audio client to perform continuous playback is the only one on the network, the continuous playback instructions do not conflict with each other.

Further, in the case shown in FIG. 81, when the controller A1 instructs the audio client C2 to play the songs stored in the content server S2 via the content server S1, the audio client C2 is the content server as shown in FIG. 82. Disconnect from S1 and reconnect to content server S2. At this time, the content server S2 creates a song list based on the list construction key transmitted from the audio client C2, and stores the list construction key and the song list as client information of the audio client C2. When the audio client C2 finishes playing the song distributed from the content server S2, it sends a completion status to the content server S2. The content server S2 instructs the audio client C2 to play continuously according to this completion status, and sends the stop status to the controller A1. Therefore, in this case as well, since the content server that instructs the audio client to perform continuous playback is the only one on the network, the continuous playback instructions do not conflict with each other.

In addition to the audio client and content server, there may be two or more controllers. For example, in the example shown in FIG. 83, there are controllers A1 and A2. When the content server S1 receives the completion status from the audio client C1 or C2, it sends the stop status not only to the controller A1 but also to the controller A2. When the content server S2 also receives the completion status from the audio client C3, it also sends the stop status to controller A2 as well as controller A1. As described above, the controllers A1 and A2 do not have a function of instructing continuous playback, but merely have a function of monitoring the status of the audio clients C1 to C3, and therefore do not affect the continuous playback processing at all.

1.2.3.3.9. Continuous playback control by the audio client itself In the present embodiment, the computer programs for executing the steps shown in FIG. 84 are installed in the content servers S1 to Si, the audio clients C1 to Cj, and the controllers A1 to Ak, respectively. Since steps S10233 to S10235 in FIG. 84 are different from the embodiments shown in FIG. 79, they will be mainly described here.

Similar to the embodiment shown in FIG. 79, the controller A1 instructs the audio client C1 to play the specified song, sends the list construction key to the audio client C1 (S30323), and the audio client C1 is designated. The song is requested to the content server S1, and the song distributed from the content server S1 is started to be played in response to this request (S10202). At this time, the audio client C1 stores the list construction key sent from the controller A1.

Subsequently, the audio client C1 sends the stored list construction key to the content server S1 and requests the content server S1 for the same song list as the song list used for song selection by the controller A1 (S10233). The content server S1 creates a song list based on the received list construction key and sends it to the audio client C1 (S20133). The audio client C1 stores the received song list and identifies the currently playing song from the song list (S10234).

When the audio client C1 finishes playing the song to the end, it plays the next song according to the stored song list (S10235).

When the songs included in the song list are distributed and stored in a plurality of content servers, the audio client C1 performs the server switching process in the same manner as described above.

As described above, according to the present embodiment, since the audio client C1 itself holds the list construction key and uses it to acquire the song list, the continuous playback process can be executed by itself. Therefore, the audio client C1 does not receive the continuous playback instruction from the controller A1 or the content server S1, and the continuous playback instruction does not conflict.

In the present embodiment, the audio client C1 acquires the song list by using the list construction key during the playback of the song, but it may be after the playback of the song is completed. Further, although the audio client C1 stores the acquired song list, the song list may be acquired by using the list construction key each time the continuous playback process is executed without storing the acquired song list.

1.2.3.3.10. Continuous playback control using playback command management table In the present embodiment, the computer programs for executing the steps shown in FIG. 85 are installed in the content servers S1 to Si, the audio clients C1 to Cj, and the controllers A1 to Ak, respectively. Since steps S30341 to S30345 and S20141 in FIG. 85 are different from the embodiments shown in FIG. 76, they will be mainly described here.

The content server S1 in the present embodiment stores a playback instruction management table in which the client index and the controller index are associated with each other. An example of this table is shown in Table 3 below. The playback instruction management table shown in Table 3 records the controller index of the latest controller A1 that ordered the audio client C1 to play. In addition, the controller index of the latest controller A2 that instructed the audio client C2 to play is recorded.<tables num="3"><img file="JP4929520B2_D0003.tif" /></tables>

Next, the operation of the present embodiment will be described with reference to the flow chart shown in FIG. 85.

A controller instructs an audio client to play a song stored on a content server (S30341).

First, as shown in FIG. 86, a case where the controller A1 instructs the audio client C1 to play the songs stored in the content server S1 via the content server S1 will be described. In this example, the audio clients C1 and C2 and the controllers A1 to A3 are connected to the content server S1.

The controller A1 determines whether or not the audio client C1 is connected to the content server S1 (S30342). In this example, the audio client C1 is connected to the content server S1, so the process proceeds to step S30314.

The controller A1 instructs the audio client C1 to play the song specified from the song list via the content server S1 (S30314). The content server S1 executes a predetermined reproduction instruction management process in response to the reproduction instruction (S20141).

Specifically, referring to FIG. 87, the content server S1 records the controller index of the controller A1 in association with the client index of the audio client C1 in the playback instruction management table (S201441). As a result, the content server S1 remembers that the controller A1 is the controller that last ordered the audio client C1 to play. The content server S1 transfers the playback instruction from the controller A1 to the audio client C1 (S201412).

The audio client C1 starts playing the song in response to the playback command from the controller A1 (S10211), and when the playback is finished, sends the completion status to the content server S1 (S10212).

When the content server S1 receives the completion status from the audio client C1, it refers to the playback instruction management table to identify the controller A1 that last ordered the audio client C1 to play, sends the completion status to the controller A1, and others. Send the stop status to controllers A2 and A3 of (S201413). Upon receiving the completion status, controller A1 executes continuous playback processing on audio client C1 (S30316). On the other hand, the controllers A2 and A3 that receive the stop status do not take any active action and simply monitor the status of the audio client C1.

Also, if audio client C1 is playing a song according to a command from controller A1, and another controller A2 commands the same audio client C1 to play another song, audio client C1 will play the current song. Stop and start playing a new song according to the command from controller A2. At this time, the content server S1 updates the playback instruction management table and rewrites the controller index of the controller A1 to the controller index of the controller A2 as shown in Table 4 below.<tables num="4"><img file="JP4929520B2_D0004.tif" /></tables>

Next, as shown in FIG. 88, a case where the controller A3 instructs the audio client C1 to play a song stored in another content server S2 via the content server S1 will be described.

Controller A3 determines whether the audio client C1 is connected to the content server S2 (S30342). In this example, the audio client C1 is not connected to the content server S2, so the controller A3 executes a predetermined server switching process (S30343).

Specifically, referring to FIG. 89, the controller A3 instructs the audio client C1 to switch from the content server S1 to the content server S2 via the content server S1 (S303431). The content server S1 transfers this switching instruction to the audio client C1 (S201401). The audio client C1 disconnects the currently connected content server S1 (S102401) and requests a connection to the new content server S2 in response to a switching instruction (S102402). The content server S2 establishes a connection with the audio client C1 in response to this request (S201402). Controller A3 confirms the connection with the content server S2 (S30344).

Subsequently, the controller A3 instructs the audio client C1 to play the song via the content server S2 (S30314). In response to this playback instruction, the content server S2 records the controller index of controller A3 in association with the client index of audio client C1 in the playback instruction management table, as shown in Table 5 below (S201441).<tables num="5"><img file="JP4929520B2_D0005.tif" /></tables>

The content server S2 transfers the playback instruction from the controller A3 to the audio client C1 (S201412).

The audio client C1 starts playing the song in response to the playback command from the controller A3 (S10211), and when the playback is finished, sends the completion status to the content server S2 (S10212). When the content server S2 receives the completion status from the audio client C1, it refers to the playback instruction management table to identify the controller A3 that last ordered the audio client C1 to play, sends the completion status to the controller A3, and others. Send the stop status to controllers A1 and A2 of (S1413). Upon receiving the completion status, controller A3 executes continuous playback processing on audio client C1 (S30316). On the other hand, the controllers A1 and A2 that receive the stop status do not take any active action and simply monitor the status of the audio client C1.

As described above, according to the present embodiment, since the content server manages the controller that last ordered the audio client to play and transfers the completion status from the audio client only to that controller, only that controller Instruct the audio client to play continuously. Therefore, the continuous reproduction instructions do not conflict with each other, and the continuous reproduction process can be executed normally.

1.2.4. Control of AV receiver As shown in FIG. 90, AVR clients AC1 and AC2 are connected to LAN12. The AV receiver AVR1 is connected to the AVR client AC1 by EIA-232. The AV receiver AVR2 is connected to the AVR client AC1 via USB. The AV receiver AVR3 is connected to the AVR client AC2 by a manufacturer-specific serial interface.

Each of the AVR clients AC1 and AC2 may notify the content server Si of information about the interface such as EIA-232 and USB when the connection with the content server is completed.

In the case of USB, the AVR client AC1 can acquire model information such as the vendor ID and product ID of the AV receiver AVR2 when the AV receiver AVR2 is connected, so it notifies the content server Si of it. In the case of EIA-232, it is usually difficult for the AVR client AC1 to acquire the model information of the AV receiver AVR1, so the vendor ID and product ID of the connected AV receiver AVR1 are registered in advance in the AVR client AC1. , AVR client AC1 notifies the content server Si of it.

If there are multiple AV receivers that may be connected, the communication protocol with the AVR client may be defined so that the AVR client can acquire the model information of the AV receiver. For example, the AVR client sends a packet asking for model information at regular time intervals (for example, 1 second) under certain communication conditions (bit rate, bit length, parity, etc.), and the AV receiver responds with a packet containing model information. You just have to reply. This allows the AVR client to identify the connected AV receiver. In such cases, including the case of USB, the AVR client may acquire the model information of the AV receiver after the connection with the content server is established, so that model information is obtained when the model information of the AV receiver is acquired. Notify the content server Si of the change.

As a result, the content server Si can acquire the model information of all AV receivers AVR1 to AVR3 connected to or will be connected to the AVR clients AC1 and AC2. Since the model information is also notified from the content server Si to the controller Ak, the controller Ak also acquires the model information.

As shown in FIG. 91, the AV receiver AVR has various controlled elements such as a volume, an input selector switch, and a DSP for sound field control. The controller Ak specifies such a controlled element and issues a control command. Therefore, the controller has model information about what kind of controlled element the AV receiver AVR has.

Since the content server Si has the model information, the controller Ak may request the model information from the content server Si using the vendor ID and product ID of the AV receiver AVR as keys.

The control command is output from the controller Ak and transmitted to the AV receiver AVR via the content server Si and the AVR client AC. On the contrary, the status is output from the AV receiver AVR and transmitted to the controller Ak via the AVR client AC and the content server Si.

When the AVR client AC confirms that the control command is for the AV receiver AVR, it outputs the control command to the AV receiver AVR. If the control command controls the value of the volume, the control command issued by the controller Ak is sent to the AV receiver ACR via the content server Si and the AVR client AC, thereby controlling the volume.

With reference to Figure 92, the controller Ak sends a control command to the content server Si (S35), the content server Si sends it to the specified AVR client AC (S28), and the AVR client sends it to the AV receiver. Send to AVR (S101). The AVR client AC receives its status from the AV receiver AVR and sends it to the content server Si (S102), the content server sends the SV to the controller Ak (S29), and the controller Ak responds to the AV receiver AVR. Update the status (S36).

As shown in FIG. 93, the content server Si, the AVR clients AC1 to AC3, and the AV receivers AVR11, AVR12, AVR21, AVR31, and AVR32 issue control commands via a tree-shaped route rooted in the content server Si. introduce.

With reference to FIG. 94, the controller Ak determines the AV receiver AVR to be controlled and the control content (S3501), and generates a command body based on the control content (S3502). Subsequently, as shown in FIG. 95A, the controller Ak sends a control command in which the destination information is added to the command body to the content server Si (S3503). The destination information here includes an AV receiver designation unit that specifies the AV receiver AVR to be controlled, and an AVR client designation unit that specifies the AVR client AC connected to the AV receiver AVR.

The content server Si receives this control command and retrieves the AVR client specification from the received control command, as shown in Figure 95B (S2801). The content server Si determines the AVR client AC specified based on this AVR client designation unit. Subsequently, the content server Si sends a control command from which the AVR client specification part has been removed to the specified AVR client AC (S2802).

The AVR client AC receives this control command and retrieves the AV receiver designation from the received control command, as shown in Figure 95C (S1011). The AVR client AC determines the specified AV receiver based on this AV receiver designation unit. Subsequently, the AVR client AC sends a control command consisting only of the command body to the specified AV receiver (S2802).

Network traffic can be reduced by sequentially removing unnecessary designated parts and forwarding control commands in this way. However, the control command may be transferred as it is without removing the specified part.

At each stage, the character strings in the command body do not have to be exactly the same, as long as their meanings are the same. That is, the control command finally transmitted from the AVR client AC to the AV receiver AVR may be in a format that can be understood by the AV receiver AVR.

The AV receiver AVR that receives the control command in this way controls the controlled element according to the control command. As a result, if the status of the controlled element changes, the AV receiver AVR transmits the status to the AVR client AC. This status consists only of the status body, as shown in Figure 96A.

The AVR client AC receives and stores the status of the AV receiver AVR (S1021), adds source information to the received status, and sends it to the content server Si (S1022). .. The source information here includes an AV receiver designation unit that specifies the AV receiver AVR that transmitted the status.

The content server Si receives the status from the AVR client AC, adds an AVR client specification to the received status, and sends it to the controller Ak (S2901).

The controller Ak receives the status from the content server Si, extracts the AVR client designation part and the AV receiver designation part from the received status, and updates the status of the AV receiver AVR (S3601).

The status may include not only the status of the controlled element but also the status of an element that cannot be controlled by the controller Ak (for example, the level information of the audio signal). Such status is also transmitted to the controller Ak via the AVR client AC and the content server Si. Further, the status is transmitted not only when the controlled element of the AV receiver AVR is controlled by the control command but also when the status changes. That is, even when the connection between the AVR client AC and the AV receiver AVR is confirmed, the AVR client AC acquires the status of the AV receiver AVR and sends it to the content server Si.

In this way, the controller Ak that finally receives the status can grasp the status of each AV receiver AVR. As a result, the controller confirms the control and displays the status.

For the status to be displayed and which may change frequently, the AV receiver AVR or the AVR client AC may appropriately reduce the transmission frequency of the status. This is because it is difficult to recognize even if the status that changes frequently is displayed as it is, and if the transmission frequency is high, unnecessary traffic is generated in the network and the load on the content server increases.

A controlled element having a complicated configuration may have a plurality of controlled units. For example, the DSP for sound field control in FIG. 91 requires the setting of a lot of coefficient data, and the setting is performed by the microcontroller that controls the DSP. When changing this setting, in a stand-alone system, the status status is displayed on the AV receiver main unit or the display device connected to the AV receiver, and the user's key operation is performed. It is the firmware of the microcontroller that performs this operation, and in order to realize complicated settings and easy-to-use operations, the program capacity increases and a high-performance display device is required. Development costs may be affected.

In this system, it is also possible to have a number of coefficient data setting patterns in the content server Si, select one of them from the hierarchical menu displayed on the controller Ak, and set the coefficient data via the AVR client AC. ..

Moreover, since a plurality of AV receiver AVRs can be placed under the control of the controller Ak at the same time, settings such as time adjustment of the AV receiver AVR can be performed at the same time. Furthermore, by monitoring the status of these AV receivers AVR, linked operations such as relay recording become possible.

Next, the case of increasing the volume of the AV receiver AVR connected to the AVR client AC will be described.

With reference to Figure 97, controller Ak checks the client's connection (S3011), determines if the client is an AVR client AC (S3014) if there is a connection, and volume up if it is an AVR client AC. A control command indicating the above is sent to the content server Si (S35). The content server Si sends this to the AVR client AC (S28), and the AVR client AC sends it to the AV receiver AVR (S101). The AVR client AC receives a status indicating that the volume has been increased from the AV receiver AVR and sends this to the content server Si (S102). The content server Si sends this to the controller Ak (S29), which updates the status of the AV receiver AVR accordingly and restarts the monitor shown in Figure 34 (S36).

Next, the operation in which the AVR client AC transfers the status of the AV receiver AVR to the content server will be described with reference to FIG. 98.

When the AVR client AC receives packet data from the AV receiver AVR (S1021), it determines whether it is volume information (S1022). When the data from the AV receiver AVR is EIA-232, the packet reception is performed by the serial reception interrupt and the data is queued. The queue is read out on a regular basis, and subsequent processing is performed.

Then, if the received data is volume information, the AVR client AC stores the volume value (S1023). The determination of whether or not the volume information is present (S1022) and the storage of the volume information (S1023) are performed before the data is queued. On the other hand, if the received data is not volume information, the AVR client AC adds an AV receiver specification unit indicating the status from the AV receiver AVR to the received packet data and sends it to the content server Si (S1024). ).

After storing the volume value, it is determined whether or not the volume information is received for the first time (S1025). If this is the first time, the process proceeds to step S1028, but if it is not the first time, the AVR client AC determines whether or not 200 milliseconds or more have passed since the volume value was sent to the content server (S1026). If more than 200 milliseconds have passed, the AVR client AC compares the previously transmitted volume value with the stored volume value (S1027), and if it is different, the AV receiver designation indicates that the status is from the AV receiver AVR. Add the part to the volume information and send it to the content server Si (S1028).

Since the status of the volume value may come at a shorter interval than other statuses, it may burden the content server Si and controller Ak, or cause unnecessary increase in traffic to the network. Since the volume information is only used for display on the controller Ak, there is no problem if it is sent at intervals that do not interfere with the display. Therefore, when the volume information is received, only the value is stored and sent to the content server Si at an appropriate interval (here, 200 milliseconds) only when there is a change.

Next, the operation in which the AVR client AC transfers the command from the content server Si to the AV receiver AVR will be described with reference to FIG. 99.

When the AVR client AC receives the control packet for the AV receiver AVR (S1031), it extracts the control command for the AV receiver AVR from the packet (S1032). The AVR client AC determines whether the control command is a volume value query command (S1033). In the case of the volume value inquiry command, the AVR client AC generates volume information from the stored volume value (appropriate initial value if not received) (S1034), and indicates that the status is from the AV receiver AVR. The AV receiver specification part is added to the volume information and sent to the content server Si (S1035).

On the other hand, if it is not a volume value inquiry command, the control command for the AV receiver AVR is sent to the AV receiver AVR (S1036). When the interface between the AVR client AC and the AV receiver AVR is EIA-232, the transmission from the AVR client AC to the AV receiver AVR is performed by an interrupt in byte units. The control command from the content server Si is temporarily stored in the queue. The queue is read by a regular interrupt or a serially transmitted buffer empty interrupt and is sent in bytes.

In the above mode, the volume information is sent to the content server Si only when there is a change except for the first time. Therefore, even if the AV receiver AVR returns the volume value in response to the volume value inquiry command from the content server Si, the AVR client AC does not return the volume value to the content server Si unless the volume value changes. As a countermeasure, the AVR client AC responds to the volume value inquiry command from the content server Si without going through the AV receiver AVR. This form is based on the premise that the AV receiver AVR sends the initial value of the volume as the status to the AVR client AC whenever the power is turned on to the AV receiver AVR. However, depending on the power-on timing, the AVR client AC may not be able to receive this initial value.

Therefore, as shown in FIG. 100, it is preferable that the AVR client AC responds via the AV receiver AVR only for the first time. That is, when the control command from the content server Si is the volume value inquiry command, the AVR client AC determines whether or not the volume value has not been received yet (S1034). If it has not been received yet, the process proceeds to step S1036, and if it has already been received, the process proceeds to step S1034.

When there are multiple types of AV receivers and the controller Ak controls these AV receivers, the controller Ak may issue a dedicated control command according to the type of AV receiver, but the AV receiver A general-purpose control command may be issued regardless of the type of, and the content server may convert this general-purpose control command into a dedicated control command.

1.2.5. Firmware update The content server can update the firmware installed on the client, as described below. Here, there are cases where the client requests an update from the content server, cases where the content server makes an inquiry to the client and updates are performed, and cases where the content server forcibly updates.

First, the outline when the client requests the update from the content server will be described. With reference to FIG. 101, the client requests the firmware information from the content server (S103), the content server replies the firmware information to the client (S201), and the client receives it (S103). The client then specifies the firmware (S104) and the content server prepares to transfer the specified firmware accordingly (S202). The client then requests the firmware from the content server (S105), the content server transfers the firmware to the client accordingly (S203), and the client receives it (S105). Subsequently, the client updates the firmware (S106), and when the update is completed, sends an exit status to the content server (S107), and the content server receives this (S204).

Next, the details of the firmware update will be described with reference to FIG. 102. When starting the update from the content server, start the process from step S2012. If the update is to be started from the client, the process is started from step S1033.

The content server first reads the firmware information file and creates the firmware information database shown in FIG. 15 (S2011). For example, the content server reads the files required for the update for each client and creates an update information file. Therefore, based on this information file, it is possible to determine whether the client firmware is new or old. The client sends the product ID and firmware ID to the content server at startup (S1031).

When starting an update from the content server, for example, when the content server determines that the firmware is out of date based on the client's product ID and firmware ID, or when the content server obtains new firmware from a site on the Internet. , The content server issues a firmware update request command to request the client to update the firmware, and if necessary, provides the client with information on new firmware that recommends the update (S2012). If the user does not want the recommended firmware update, the client rejects the update request from the content server and the process ends immediately (S1032). Also, if the user suspends the recommended firmware update, this process ends immediately (S1032). However, in this case, the client instructs the content server to request the update again after a predetermined time has elapsed. Also, if the user accepts the recommended firmware update, the client continues processing (S1032). In this case, if the content server is presenting specific firmware to the client, the client proceeds to step S1035 and immediately starts updating the firmware. Also, if the content server simply requests an update without presenting the client with specific firmware, the client proceeds to step S1033 to get the firmware list.

The firmware update request command may be issued by the controller as a server request. In this case, the controller acquires a firmware list for the client to be controlled and monitored from the content server in the same manner as in S1033 to S1034 described later, and the user selects the desired firmware. The firmware selected by the controller is presented to the client as firmware information that recommends updating.

When accepting an update request or initiating an update from a client, the client requests a firmware list from the content server (S1033). The firmware list is a list of firmware applicable to a specific client. The content server does not always have a firmware list, but creates it each time in response to a request from a client. The method of creating the firmware list is basically the same as the method of creating the song list described above. However, when creating the firmware list, the content server uses the firmware information database shown in FIG. This database stores firmware information for the number of firmwares. The method of creating the firmware list will be described in detail below.

With reference to FIG. 103, the content server first initializes the index indicating the number of the firmware information stored in the firmware information database to 0 (S20131).

Subsequently, the content server determines whether or not the product ID of the firmware information indicated by the index matches the product ID of the client (S20132). If there is a match, the content server adds the firmware information to the firmware list (S20133) and then increments the index (S20134). On the other hand, if they do not match, the content server skips step S20133 and immediately increments the index (S20134).

The content server then determines if the firmware information number indicated by the index is less than the number n of all firmware information (S20135) and returns to step S20132 if it is smaller, while the firmware list if it is not. Complete the creation of.

By the above process, the content server picks up the firmware information whose product ID matches from the firmware information database and creates a firmware list. In this way, the firmware list is not stored in a database in advance, but is temporarily created at each request from the client, so that a memory area for always storing the firmware list is unnecessary.

The content server then returns the created firmware list to the requesting client (S2013). Like the above song list, this firmware list is also divided and sent from the content server to the client.

Specifically, referring to FIG. 104, the client obtains its own product ID, an acquisition start index indicating the first firmware information to be acquired, and an acquisition number indicating the number of firmware information to be acquired. Send the including firmware list request command to the content server (S1033). In response to this firmware list request command, the content server extracts firmware information that has the same product ID as the client's product ID, and returns the firmware information to the client as many as the number of acquisitions indicates from the firmware information indicated by the acquisition start index. (S2031). At this time, the content server transmits the effective number indicating the number of firmware information to be transmitted and the remaining number indicating the number of firmware remaining after the firmware list returned by the content server to the client. The client receives a portion of such a firmware list and stores it in memory (S10331). The above process is repeated until the entire firmware list is sent from the content server to the client.

The client then continues processing if there is firmware (such as a new version) that the user wants to download in the returned firmware list, otherwise it aborts processing (S1034).

Since the content server transmits firmware information of all versions regardless of old or new, the client can change to the old firmware due to a problem or the like.

When updating, the client notifies the content server of the status indicating that it has moved to the update section (S1035). The content server responds to this status with an error code indicating the presence or absence of an error (S2014). The client specifies the firmware file to download (S1036). Specifically, specify the full path name stored in the acquired firmware information list. The content server reads the specified file and stores it in the buffer (S2015).

Subsequently, the client specifies the acquisition start address and the data size (number of bytes), and acquires the firmware data (S1037). The content server reads the data from the buffer for the specified number of bytes from the specified acquisition start address and sends it to the client (S2016).

The client determines whether or not the firmware data has been acquired to the end (S1038), and if not, returns to step S1037 and repeats the acquisition of the data. When the acquisition is completed, the client rewrites the firmware (S1039) and finishes the update (S1040). The content server closes the open firmware file and releases the buffer (S2017).

Furthermore, when the client completes the firmware rewrite, it sends an unknown status to the content server. The client interrupts the connection with the content server, resets (that is, launches the updated firmware), and notifies the content server of the client information. Further, when the client fails to acquire the firmware data, the failure status may be transmitted. The failure status can be used for retransmitting firmware data and the like.

When requesting an update from the content server, it can be processed as follows. That is, in FIG. 102, the content server always presents the firmware information to the client when requesting an update (S2012). Proceed to S1035 when updating the firmware recommended by the content server, and proceed to S1033 when the user selects the desired firmware from the firmware list instead of updating the firmware recommended by the content server. You can also.

As described above, since the firmware data is transmitted from the content server to the audio client via the LAN, the firmware of the client can be updated in a short time, and the firmware of a plurality of clients can be updated at the same time. Also, since the product ID is used, it is possible to automatically select and update the firmware suitable for the client. Also, since the firmware ID is used, the latest version of firmware can be automatically selected and updated.

2. Other embodiments 2.1. Audio client with built-in outlet The audio client may be built into the outlet box 50 as shown in FIGS. 105 and 106. The outlet box 50 generally includes a front panel 54 mounted on the wall 52 and a housing 56 mounted on the back surface of the front panel 54. In the embodiment of the present invention, the circuit for the audio client shown in FIG. 3 is provided in the housing 56. The LAN cable is connected to the circuit for this audio client. The front panel 54 has a power outlet 58, a power switch 60, a modular jack (not shown), a TV antenna terminal (not shown), and audio for outputting an audio signal from an audio client. An output terminal 62 is provided. These audio output terminals 62 are connected to the left and right speaker devices, respectively.

An audio client usually includes a display for displaying a song list and switches for selecting a desired song from the displayed song list. The display and switches are necessary to monitor and control the audio client, but by using the controller connected to the same LAN12 as the audio client, the display and switches can be removed from the audio client. Alternatively, instead of using a controller, a portable remote controller wirelessly connected to the same LAN 12 as the audio client may be used.

By simplifying the audio client in this way, it can be built into the outlet box 50 of a general household. The simplified audio client with a built-in outlet has only a function of extracting music or video from a network and playing it, and does not have a display function or a control function.

With the spread of the Internet, especially the development of broadband (high-speed, large-capacity) infrastructure, it is expected that the demand for connecting to the Internet from multiple PCs in a family will increase. The most common way to connect multiple PCs to the Internet in your home is to build a LAN in your home, and it is only a matter of time before the number of households equipped with such a home LAN increases. By using this LAN, it is possible to distribute the above-mentioned music and videos to various places in the house with a single cable. In addition to music / video signals, control signals can also be transmitted to a single cable, so no specialized knowledge of audio / video is required to install this system. Furthermore, since it is extremely advantageous in terms of cost, it can be widely used not only for business use but also for home use.

In general households, the number of cases where a home LAN is laid in consideration of the convenience of Internet connection at the time of new construction or remodeling is increasing, but at this time, it is extremely common to provide a LAN connector in the outlet box 50. Therefore, a plurality of audio clients can be easily installed at the same time as the LAN laying work. That is, an audio client can be constructed simply by connecting a speaker (including powered), and a video client can be constructed simply by connecting a video monitor such as a television. Therefore, it is possible to set an audio client that looks good in the interior. Furthermore, from the viewpoint of product development, it is no longer necessary to design a gorgeous design of the product itself, and an extremely simple design method that emphasizes functions leads to a reduction in product development costs. It is also beneficial in terms of ease of recycling due to its simple structure.

Unlike conventional audio / video equipment, home LAN distribution does not require content media such as CDs and tapes. That is, once the content is stored in the content server, the management of the media becomes unnecessary. According to the configuration of the server client by such a home network, the audio client does not require any mechanical device such as a mechanism for inserting media or a rotation drive device. Therefore, the miniaturization of the device is achieved, and a product with higher reliability and a long life is enabled.

2.2. Get music data on the internet In the above embodiment, the audio client searches for the content server by broadcasting when the power is turned on. However, if all the content servers on LAN12 are turned off, the audio client will continue to search for the content server forever because there is no response from the content server. In order to prevent this, the audio client may perform processing such as a timeout error, but in the case of a timeout error, the audio client cannot perform any operation such as playing music.

To solve these problems, if the audio client cannot find the content server after repeating the broadcast a predetermined number of times, it is possible to access the WWW server on the Internet and connect to this server. ..

In this case, LAN 12 is connected to Internet 52 through gateway 50, as shown in FIG. 107. A list of songs placed on the music distribution site 56 is registered in advance on the WWW (World Wide Web) server 54 on the Internet 52. In this list, in addition to song information such as song titles and artist names, URLs (Uniform Resource Locators) where music data are stored are recorded.

As shown in FIG. 108, if the server list is empty, the audio client determines whether the number of retries has reached a predetermined number, eg, three, before returning to step S1102 to retry the broadcast. (S1109). If the number of retries has not reached 3, the audio client increments the number of retries (S1110) and then returns to step S1102 to retry the broadcast. On the other hand, if the number of retries has reached 3, the audio client connects to the WWW server 54 on the Internet 52 via HTTP (S1111). If the audio client succeeds in connecting, the search is completed (S1112), but if the connection is not successful and the timeout occurs, an error occurs (S1113).

When the audio client accesses the WWW server 52, it receives and analyzes song information and a URL from the WWW server 52, and receives music data from the music distribution site 56 at that URL.

As described above, if the content server does not exist on LAN12, or if it exists but is not running, the audio client automatically accesses site 56 on the Internet 52 and acquires music data, so LAN12 It does not continue to search the above content server forever.

In the above example, when the number of retries reaches a predetermined number, the audio client connects to the WWW server 54 on the Internet 52. Instead, the audio client broadcasts a magic word for a predetermined time. If there is no response from any of the content servers on LAN12 even though the above has passed, the connection may be made to the WWW server 54 on the Internet 52.

2.3. Playback with acquired data length change function In the above embodiment, when the audio client Cj requests the content server Si to transfer the song data, it always requests a certain amount of song data. Therefore, there is no problem if the number of audio client Cj that requests the content server Si to transfer song data is small, but if this number is large, the load on the content server Si increases, and the audio client Cj becomes the content server Si. There arises a problem that the time from requesting the transfer of song data to the actual transfer of song data becomes long. Therefore, the amount of song data requested by the audio client Cj at one time may be changed each time so that the load applied to the content server Si is equalized. Hereinafter, the amount of song data requested by the audio client Cj at one time is changed according to the time from when the audio client Cj requests the content server Si to transfer the song data until the song data is actually transferred. An example will be described.

With reference to FIG. 109, the audio client Cj sends a song data transfer command requesting the transfer of song data to the content server Si (S1601), and at the same time, operates a timer to transfer the song data from the content server Si. Start counting the response time until the end (S16011). When the audio client Cj first issues a song data transfer command, the amount of appropriate song data to be requested at one time is unknown, so the acquired data length is predetermined.

Subsequently, when the audio client Cj starts receiving the song data (S16012), the timer is stopped and the response time of the song data by the content server Si is acquired (S16013).

The audio client Cj refers to the comparison table shown in FIG. 110 and determines the acquired data length corresponding to the acquired response time (S16021). In this comparison table, a predetermined response time and a predetermined acquired data length are associated with each other. Here, since the load on the content server Si is greater as the response time is longer, the acquired data length is set to be shorter as the response time is longer. For example, when the audio client Cj acquires a response time of 20 msec, the acquired data length is determined to be 8 kbytes.

The audio client Cj requests the content server Si to transfer the song data again, but here, the acquired data length determined above is transmitted (S1605). After that, the same operation as above is repeated (S16051 to S16061).

As described above, according to this embodiment, since the acquisition data length of the song data requested by the audio client Cj from the content server Si is shortened as the response time becomes longer, the song data is transferred to the content server Si. Even if the number of requested audio client Cj increases, the amount of song data transferred by the content server Si to the audio client Cj at one time decreases. As a result, the load of the content server Si for each audio client Cj is averaged, and the content server Si can smoothly transfer the song data to a plurality of audio client Cj.

In the above example, the acquired data length is determined according to the response time of the content server, but instead, the acquired data length may be determined according to the data format of the song to be acquired. .. That is, in FIG. 35, the audio format of the song is acquired based on the search data shown in FIG. 32 before the song data transfer request (S1601). Then, the acquired data length is set based on the audio format of the song. Generally, MP3 format data is small because it is compressed, while WAV format data is large. Therefore, if the data format of the song to be acquired is MP3, for example, 4K bytes of data will be acquired at one time, and if it is WAV, for example, 16K bytes of data will be acquired at one time. Good.

2.4. Skip playback In the above embodiment, the audio client Cj requests the content server Si to transfer the song data in the order of the song list. However, the user may want to re-listen to the currently playing song from the beginning. The user may also want to skip the currently playing song and listen to another song. Therefore, the audio client Cj may be able to request song data transfer in response to such a user's request.

With reference to FIG. 111, when the audio client Cj is playing the song 3 in the song list shown in FIG. 112, the audio client Cj transfers the music data in the specified range of the music data of the song 3 as the content. A request is made to the server Si (S1607), the content server Si returns a specified range of music data to the audio client Cj (S2604) in response to this request, and the audio client Cj receives this and stores it in the memory 32 (S1608). ). Song 3 is played by repeating this operation.

During the playback of song 3, if the user finishes playing song 3 and tries to listen to song 4 (case (1) in FIG. 112), the user requests the audio client Cj to skip to song 4. Do. The audio client Cj receives a skip request from the user (S1640), checks the contents of the song list stored in the memory 32, and acquires the file name of the song 4 (S1641). If there is no skip request from the user, the process returns to step S1607 and requests the data transfer of song 3.

Since the subsequent operations of the audio client Cj and the content server Si are the same as those shown in FIG. 35, the explanation is not repeated.

With the above operation, the audio client Cj can skip to song 4 while playing song 3.

When the audio client Cj is playing song 3 and the user wants to listen to song 3 again from the beginning (case (2) in FIG. 112), the user wants to listen to song 5 (in FIG. 112). In (3) case), when the user wants to listen to song 2 ((4) case in FIG. 112), the audio client Cj can skip playback by the same operation.

As described above, according to this embodiment, the audio client Cj can skip-play the currently playing song to another song by using the song list stored in the memory.

2.5. Repeat playback In addition, repeat reproduction between ABs, in which data is repeatedly reproduced between the first address and the second address specified by the user, can be performed. First, the user performs the first repeat operation between ABs and specifies the first address indicating the start of the repetition. That is, referring to FIG. 113, the audio client receives an operation from the user (S1642) at the time of requesting transfer of song data (and acquisition of song data) (S1642), and the operation from the user is between AB. Since it is a repeat request (S1643) and is the first request (S1644), the address specified by the user is stored as the first address (addr1). Then, the acquisition start address (addr) is calculated by adding the acquisition data length (size) to the previous acquisition start address (addr) (S1646), and the process returns to S1601.

Next, the user performs the second inter-AB repeat operation, specifies the second address indicating the end of the repetition, and starts the repeat operation. That is, in S1644, since the repeat request between ABs from the user is the second request (not the first request), the address specified by the user is stored as the second address (addr2) (S1647).

Then, the audio client enters the inter-AB repeat mode (S1648). That is, the acquisition start address is changed to the first address (S1649), and the song data transfer request (and song data acquisition) is performed (S1601). Here, the audio client determines that it is in the repeat state between ABs (S1650), and determines whether or not the acquisition start address (= previous acquisition start address + acquisition data length) is larger than the second address (S1651). ). If the acquisition start address is still less than or equal to the second address, the song data transfer request is continued (S1646 and S1601). Then, in S1651, when the acquisition start address becomes larger than the second address, the acquisition start address is changed to the first address again (S1652), and the song data transfer request is made (S1601). Therefore, repeat reproduction can be performed between the first address and the second address. In addition, the user can cancel the repeat state by performing the repeat cancel operation (S1643, S1653 and S1654).

2.6. Play in the middle Further, by the user specifying the acquisition start address (for example, inputting the start time), the song can be played from the specified address. That is, referring to FIG. 114, for example, when a song data transfer request (and song data acquisition) is performed (S1601), there is an operation from the user (S1656), and an address is specified (S1657). ), The audio client gets the address specified by the user (S1658). For example, the address is calculated from the total playback time of the song and the start time input by the user. Then, the acquisition start address is changed to the address specified by the user (S1659), and the song data transfer request (and song data acquisition) is performed (S1601). Therefore, the song can be played back from the address specified by the user. Further, the user can specify the address not only when the audio client is in the playback state, but also when the audio client is in the stopped state or the paused state, for example.

2.7. Client with automatic connection recovery function In the network audio system, as described above, the audio client is connected to the content server and plays the music distributed from the content server, but the audio client is disconnected from the content server due to an abnormality in the content server during distribution. If so, the audio client will not be able to play music unless it is reconnected to the content server. In the case of a normal audio client having an input device, the audio client may be made to execute the connection process with the content server again as shown in FIG. 5 by operating the input device. However, since the above-mentioned audio client with a built-in outlet does not have an input device, once it is disconnected from the content server, it is left as it is. Therefore, it is desirable that the audio client has the following automatic connection recovery functions.

With reference to FIG. 115, the audio client Cj determines whether or not a predetermined period has elapsed since the connection with the content server Si (S110). After the lapse of a predetermined period, the audio client Cj determines whether or not the connection with the content server Si is maintained (S111, S112). Specifically, the audio client Cj sends a connection confirmation command to the content server Si (S111). If the content server Si responds to the connection confirmation command to the audio client Cj (S112), it is determined that the connection is maintained. On the other hand, if there is no response or a transmission error occurs (S112), it is determined that the connection has been disconnected. As a reply method, for example, there is a method of replying the same command as the connection confirmation command sent by the content server Si.

If there is a response in step S112, the audio client Cj returns to S110 again to determine whether the connection is maintained after a predetermined period of time (S110 to S112). As a result, the audio client Cj checks the connection status with the content server Si at regular intervals. If the connection is lost, the audio client Cj attempts to reconnect to the same content server Si (S12).

If the connection with the content server Si is successful as a result of attempting to reconnect (S113), the audio client Cj sends the client status immediately before disconnection to the content server Si (S13). The client status includes, for example, a playback state such as "play", "stop", and "pause", volume information, a list construction key, and the like. Therefore, the audio client Cj can restore the connection state with the content server Si. As a result, the user can use the audio client Cj without being aware that the audio client Cj has reconnected to the content server Si.

On the other hand, if the connection with the content server Si fails as a result of trying to reconnect (S113), the audio client Cj gives up the connection recovery with the same content server Si and executes the connection process with other content server Si. (S11 ~ S13). Specifically, the audio client Cj searches for the content server Si that can be connected by broadcasting (S11), and connects to the searched content server Si (S12). After connecting, the audio client Cj sends the client status immediately before disconnection to the content server Si (S13).

The audio client Cj has the above-mentioned automatic connection recovery function by installing the connection recovery program shown in FIG. 115.

By the above operation, the connection status is confirmed from the audio client Cj at regular intervals, and if the connection status is disconnected, the audio client Cj itself reconnects. Therefore, even if the connection is disconnected due to an abnormality in the content server Si, the audio client Cj is not left disconnected from the content server Si. Further, even if the connected content server Si cannot be reconnected due to an abnormality, the audio client Cj connects to another content server Si. As a result, the user can always control the audio client Cj using the controller Ak.

Moreover, since the audio client Cj sends the client status immediately before disconnection to the connection destination content server Si, the audio client Cj can be in the same state as immediately before disconnection even if it is connected to another content server Si. As a result, the user can use the audio client Cj without being aware that the audio client Cj has been disconnected from the content server Si.

In the present embodiment, the audio client Cj has an automatic connection recovery function, but the controller Ak may also have an automatic connection recovery function. Further, it is preferable that the passive client having only the music playing function has the automatic connection recovery function rather than the active client having both the music playing function and the control function. Since the passive audio client Cj, which has no control function, does not send commands to the content server Si by itself, once the connection with the content server Si is disconnected, it is left as it is, and the user can use the audio client. This is because the connection with the content server Si cannot be restored unless Cj is restarted.

Each step in all the embodiments described above forms an action program to be executed by the computer. Therefore, a network-type audio system can be constructed by installing this operation program on the content server Si, the audio client, the controller, and the AVR client. Further, this operation program may be distributed as it is through a telecommunication line such as the Internet, or may be stored and distributed in a computer-readable storage medium such as a CD-ROM or a DVD-ROM.

Although 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 the above-described embodiment can be appropriately modified and implemented within a range that does not deviate from the gist thereof.

<figref num="1">It is a functional block diagram which shows the whole structure of the network type audio system by embodiment of this invention.</figref><figref num="2">It is a functional block diagram which shows the configuration of each server in FIG.</figref><figref num="3">It is a functional block diagram which shows the structure of each audio client in FIG.</figref><figref num="4">It is a functional block diagram which shows the structure of each controller in FIG.</figref><figref num="5">It is a flow chart which shows the operation in the initial connection phase of the server and the audio client shown in FIGS. 1 to 3.</figref><figref num="6">It is a flow chart which shows the server search operation by the audio client in FIG.</figref><figref num="7">It is a flow chart which shows the connection operation by a client and a server in FIG.</figref><figref num="8">It is a figure which shows the push operation by the server which finished the connection operation shown in FIG.</figref><figref num="9">Following FIG. 8, it is a diagram showing the server request operation from the controller to the server to the audio client.</figref><figref num="10">Following FIG. 9, it is a diagram showing an operation of notifying the controller of the status from the audio client through the server.</figref><figref num="11">It is a flow chart which shows the client information transmission operation by the audio client in FIG.</figref><figref num="12">It is a flow chart which shows the initial setting operation and the main operation by the server shown in FIG. 1 and FIG.</figref><figref num="13">It is a figure which shows the client information database stored in the server shown in FIG.</figref><figref num="14">It is a figure which shows the content information database stored in the server shown in FIG.</figref><figref num="15">It is a figure which shows the firmware information database stored in the server shown in FIG.</figref><figref num="16">It is a flow chart which shows the subroutine of the response to the server search in FIG.</figref><figref num="17">It is a flow chart which shows the subroutine of the command port connection acceptance processing in FIG.</figref><figref num="18">It is a flow chart which shows the subroutine of the push port connection acceptance processing (the 1) in FIG.</figref><figref num="19">It is a flow chart which shows the subroutine of the push port connection acceptance processing (the 2) in FIG.</figref><figref num="20">It is a flow chart which shows the subroutine of command processing in FIG.</figref><figref num="21">It is a flow chart which shows the subroutine of the status notification command processing in FIG.</figref><figref num="22">It is a flow chart which shows the subroutine of the server request issuance command processing in FIG.</figref><figref num="23">It is a flow chart which shows the music list acquisition and playback operation by the server and the audio client shown in FIGS. 1 to 3.</figref><figref num="24">It is a flow chart which shows the music list acquisition operation by the audio client in FIG. 23.</figref><figref num="25">It is a flow chart which shows the genre list and song list acquisition operation in FIG. 24.</figref><figref num="26">It is a figure which shows the area which stored the genre list acquired in FIG.</figref><figref num="27">It is a figure which shows the record structure of the content information database shown in FIG.</figref><figref num="28">It is a flow chart which shows the genre list creation operation by the server in FIG.</figref><figref num="29">It is a figure which shows the area which stored the song list acquired in FIG.</figref><figref num="30">It is a flow chart which shows the music list creation operation by the server in FIG.</figref><figref num="31">It is a figure which shows the format of the list request command in FIG.</figref><figref num="32">It is a figure which shows the format of the search data in FIG.</figref><figref num="33">It is a figure which shows the transition state of the buffer memory in the music list acquisition operation in FIG.</figref><figref num="34">In addition to the genre list and song list acquisition operations shown in FIG. 25, it is a flow chart showing an album list acquisition operation.</figref><figref num="35">It is a flow chart which shows the operation of music designation, play and stop by an audio client in FIG. 23, and music distribution preparation and distribution by a server.</figref><figref num="36">It is a flow chart following FIG. 35.</figref><figref num="37">It is a figure which shows the music information request command in FIG. 35.</figref><figref num="38">It is a figure which shows the music information in FIG. 35.</figref><figref num="39">It is a figure which shows the music play preparation command in FIG. 35.</figref><figref num="40">It is a figure which shows the error code in FIG. 35.</figref><figref num="41">It is a figure which shows the music data transfer request command in FIG. 35.</figref><figref num="42">It is a figure which shows the music data in FIG. 35.</figref><figref num="43">It is a figure which shows the structure of the buffer memory for storing the music data shown in FIG. 42.</figref><figref num="44">It is a figure which shows the state which stored the song data for one buffer from the beginning of a song in the buffer memory shown in FIG. 43.</figref><figref num="45">Following FIG. 44, it is a diagram showing a state in which song data for all buffers is stored.</figref><figref num="46">Following FIG. 45, it is a diagram showing a state in which song data is output from the head buffer.</figref><figref num="47">Following FIG. 46, it is a diagram showing a state in which one buffer is free.</figref><figref num="48">Following FIG. 47, it is a diagram showing a state in which the empty buffer is filled.</figref><figref num="49">It is a flow chart which shows the fast-forward play operation by a client and a server shown in FIGS. 1 to 3.</figref><figref num="50">It is a flow chart which shows the pause operation by a client and a server shown in FIGS. 1 to 3.</figref><figref num="51">It is a flow chart which shows the connection operation with a server by the controller in FIG.</figref><figref num="52">It is a flow chart which shows the monitoring handle and control handle acquisition operation in FIG. 51.</figref><figref num="53">It is a figure which shows the status notification from a plurality of audio clients to a plurality of controllers by a server.</figref><figref num="54">FIG. 54 is a diagram showing a status notification when the controller acquires a monitoring handle.</figref><figref num="55">It is a flow chart which shows the monitor operation of the audio client by the controller in FIG.</figref><figref num="56">It is a flow chart which shows the detail of the monitor operation shown in FIG. 55.</figref><figref num="57">It is a flow chart which shows the control operation of the audio client by the controller in FIG.</figref><figref num="58">It is a flow chart which shows the subroutine of the control command processing operation by the audio client in FIG. 57.</figref><figref num="59">It is a figure which shows the subroutine of the reproduction control operation in FIG. 58.</figref><figref num="60">It is a figure which shows the detail of the client type included in the client information database shown in FIG.</figref><figref num="61">FIG. 5 is a flow chart showing a song list display processing operation in the playback control shown in FIG. 59.</figref><figref num="62">FIG. 6 is a diagram showing a display screen of a song list relating to an audio client capable of playing both MP3 and WAV in the song list display in FIG. 61.</figref><figref num="63">In the song list display in FIG. 61, MP3 is playable, but WAV is a diagram showing a display screen of a song list relating to an audio client that cannot be played.</figref><figref num="64">It is a flow chart which shows the reproduction instruction processing operation from a user in the reproduction control shown in FIG. 59.</figref><figref num="65">It is a figure which shows the transmission of the reproduction command in the continuous reproduction control by the controller in FIG.</figref><figref num="66">Following FIG. 65, it is a diagram showing transmission of completion and stop status.</figref><figref num="67">It is a flow chart which shows the transmission operation of the completion and stop status shown in FIG.</figref><figref num="68">Following FIG. 66, it is a diagram showing transmission of a reproduction command.</figref><figref num="69">It is a figure which shows the structure of the list construction key used in the continuous play control shown in FIGS. 65 to 68.</figref><figref num="70">It is a figure which shows the type of the filter included in the list construction key shown in FIG. 69.</figref><figref num="71">It is a sequence diagram which shows the continuous reproduction control operation using the list construction key shown in FIG. 69.</figref><figref num="72">It is a flow chart which shows the completion processing operation by the controller shown in FIG. 56 and FIG. 71.</figref><figref num="73">It is a flow chart which shows the operation of the continuous reproduction processing which gave priority.</figref><figref num="74">It is a functional block diagram which shows the continuous reproduction processing shown in FIG. 73.</figref><figref num="75">FIG. 5 is a functional block diagram showing a continuous reproduction process when the controller having the highest priority is disconnected in the continuous reproduction process shown in FIG. 73.</figref><figref num="76">It is a flow figure which shows the operation of the continuous reproduction processing using a control handle.</figref><figref num="77">It is a functional block diagram which shows the continuous reproduction processing shown in FIG. 76.</figref><figref num="78">It is a functional block diagram which shows the continuous reproduction processing by a content server.</figref><figref num="79">It is a flow chart which shows the operation of the continuous reproduction processing shown in FIG. 78.</figref><figref num="80">FIG. 5 is a functional block diagram showing a continuous playback process when there are a plurality of audio clients in the continuous playback process shown in FIG. 78.</figref><figref num="81">FIG. 5 is a functional block diagram showing a continuous playback process when there are a plurality of content servers in the continuous playback process shown in FIG. 80.</figref><figref num="82">FIG. 5 is a functional block diagram showing a continuous playback process when the content server is switched in the continuous playback process shown in FIG. 81.</figref><figref num="83">FIG. 5 is a functional block diagram showing a continuous reproduction process when there are a plurality of controllers in the continuous reproduction process shown in FIG. 81.</figref><figref num="84">It is a flow chart which shows the operation of the continuous play processing by an audio client itself.</figref><figref num="85">It is a flow chart which shows the operation of the continuous reproduction processing using the reproduction instruction management table.</figref><figref num="86">It is a functional block diagram which shows the continuous reproduction processing shown in FIG. 85.</figref><figref num="87">It is a flow chart which shows the detail of the reproduction instruction management processing in FIG. 85.</figref><figref num="88">FIG. 5 is a functional block diagram showing a continuous playback process when the content server is switched in the continuous playback process shown in FIG. 85.</figref><figref num="89">It is a flow chart which shows the detail of the server switching process in FIG. 85.</figref><figref num="90">It is a functional block diagram which shows the structure of the network type audio system including a server, a controller, an AVR client, and an AV receiver.</figref><figref num="91">It is a functional block diagram which shows the status and the flow of a command in the network type audio system shown in FIG. 90.</figref><figref num="92">FIG. 5 is a flow chart showing a control operation of an AV receiver by a controller in the network type audio system shown in FIGS. 90 and 91.</figref><figref num="93">In the network type audio system shown in FIG. 90, it is a functional block diagram which shows the transmission path of a control command and a status.</figref><figref num="94">It is a flow chart which shows the command and status transmission operation shown in FIG. 93.</figref><figref num="95">It is a figure which shows the control command in each stage shown in FIG. 94.</figref><figref num="96">It is a figure which shows the status at each stage shown in FIG. 94.</figref><figref num="97">In the network type audio system shown in FIGS. 90 to 96, it is a flow diagram which shows the operation which the controller raises the volume of the AV receiver AVR through an AVR client.</figref><figref num="98">In the network type audio system shown in FIGS. 90 to 96, it is a flow diagram which shows the operation of the AVR client when the status of an AV receiver is transferred to a server.</figref><figref num="99">In the network type audio system shown in FIGS. 90 to 96, it is a flow diagram which shows the operation of the AVR client when the control command from a server is transferred to an AV receiver.</figref><figref num="100">It is a flow chart which shows the improvement example of the operation shown in FIG.</figref><figref num="101">It is a flow chart which shows the firmware update operation by a client and a server in FIG.</figref><figref num="102">It is a flow chart which shows the detail of the firmware update operation shown in FIG. 101.</figref><figref num="103">It is a flow chart which shows the firmware list creation operation in FIG. 102.</figref><figref num="104">It is a flow chart which shows the transmission operation of the firmware list in FIG. 102.</figref><figref num="105">It is a front view which shows the appearance structure of the audio client by another embodiment of this invention.</figref><figref num="106">It is a side view of the audio client shown in FIG. 105.</figref><figref num="107">It is a functional block diagram which shows the whole structure of the network type audio system and the Internet by another embodiment of this invention.</figref><figref num="108">It is a flow chart which shows the server search operation in the network type audio system shown in FIG. 107.</figref><figref num="109">It is a flow chart which shows the transfer operation of music data by another Embodiment of this invention.</figref><figref num="110">It is a figure which shows the comparison table referred to by S16021, S16061 in FIG. 109.</figref><figref num="111">It is a flow figure which shows the skip reproduction operation of the audio client by another embodiment of this invention.</figref><figref num="112">It is a figure which shows the music list stored in the memory of an audio client in the skip play operation shown in FIG. 111.</figref><figref num="113">It is a flow figure which shows the repeat reproduction operation of the audio client by another embodiment of this invention.</figref><figref num="114">It is a flow figure which shows the mid-way reproduction operation of the audio client by another embodiment of this invention.</figref><figref num="115">It is a flow chart which shows the monitoring processing and connection recovery processing of an audio client by another embodiment of this invention.</figref>