JP2005182763A - Network type content reproduction system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a network type content reproduction system by which a client freely selects and reproduces contents such as sounds and video images accumulated in a server. <P>SOLUTION: The network type content reproduction system is provided with a content server S which accumulates many pieces of music data, an audio client C which reproduces music and a controller A which monitors and controls the audio client C via the content server S. The audio client C requests music data of selected music to the content server S and the content server S returns the music data in response to the request from the audio client C. Pieces of the music data are distributed from the content server S to the audio client C by specified amount. The controller A instructs the audio client C to reproduce the selected music to the audio client C via the content server S. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  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 conventional typical 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 one by one in each room, it becomes expensive as a whole. On the other hand, a centralized audio system that can store all music data in one place and reproduce music selected in each room is also provided.

  However, in the centralized audio system, a large number of wires such as a music signal wire and a control signal wire must be laid in each room. In addition, it is possible to play one song in each room at the same time, but it is not possible to play the same song from the beginning in another room while playing one song in another room.

  If you install an application program for music playback on a general-purpose personal computer, you can get music data from a site on the Internet and play music. In addition, you cannot play a song from the middle, fast forward, or fast reverse. That is, special reproduction cannot be performed on data that has not yet been received.

  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.

  Another object of the present invention is to provide a network type content reproduction system that allows a user to freely reproduce data that has not yet been received by a client, such as reproducing data from the middle.

  Still another object of the present invention is to provide a network type content reproduction system that enables continuous reproduction of content by a client in a client-server environment.

  Still another object of the present invention is to provide a network type content playback system that eliminates contention of continuous playback commands to clients.

  Still another object of the present invention is to provide a client with an automatic connection recovery function that can quickly recover a connection even if the connection with the server is disconnected.

Means for Solving the Problems and Effects of the Invention

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

  In this network-type content reproduction system, desired content is selected from a large number of contents stored in the server in response to a client request. The selected content is transmitted from the server to the client, and the content is reproduced. Therefore, the client can freely select and reproduce 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 in response to a request from the first client. The data of the selected music is transmitted from the server to the first client, and the music selected based on the data is reproduced. Therefore, the first client can freely select and reproduce a plurality of songs stored in the server.

  Preferably, the first client is attached to an outlet box embedded in a wall.

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

  Preferably, the first client further includes content list requesting means for requesting a server for a content list listing a plurality of contents. The server further includes content list return means for returning the content list in response to a request from the first client. The first client further includes content list receiving means for receiving the content list returned from the server. The content requesting unit selects the content to be requested from the content list.

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

  More preferably, the content list request means requests the server for a specified amount of content list, preferably a part of the content list. The content list return means returns a specified amount of 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 transmitted from the server to the first client, the memory capacity necessary 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 content 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 content of the acquired number from the first content indicated by the acquisition start index.

  More preferably, the content list reply unit further replies with the number of contents included in the reply content list 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 yet been acquired, and can request the remaining content list from the server.

  Preferably, the first client further includes category list requesting means for requesting a server for a category list listing a plurality of categories. The server further includes means for returning a category list in response to a request from the first client. The first client further includes means for receiving a category list returned from the server. The content list requesting unit selects a 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 obtains a category list from the server, and selects a desired category from the category list. Subsequently, the first client acquires a content list from the server and selects desired content from the content list. Therefore, it is possible to gradually narrow down and select a desired content from among a large number of contents.

  Preferably, the content list requesting means transmits a list construction key necessary for creating 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 transmitting the list construction key to the server when the content list is necessary, and therefore does not need to store the acquired content list.

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

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

  More preferably, the content requesting unit calculates an acquisition start address indicating a first 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 transmitted from the first client.

  More preferably, the content request 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. In response to the content transfer request command, the content return means returns the content for the acquired data length from the acquisition start address.

  In this case, by setting the acquisition start address arbitrarily, it is possible to perform special playback even for content that has not been received by the client.

  More preferably, the content requesting unit calculates the next acquisition start address by adding the acquisition data length to the previous acquisition start address.

  More preferably, the first client further includes means for setting the first and second addresses in response to a user operation, and an acquisition start address when the calculated acquisition start address exceeds the second address. Means for setting to the first address.

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

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

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

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

  In this case, the first client can obtain the content discontinuously from the server and thereby perform fast forward playback and fast reverse playback.

  Preferably, the first client further includes means for transmitting identification information of the selected content to the server. The server further includes means for returning to the first client the offset of the content selected in response to the identification information transmitted from the first client. The first client further includes means for detecting the start of the selected content based on the offset returned from the server.

  In this case, since the first client detects the start of the content based on the offset of the content transmitted from the server, the content can be reproduced immediately.

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

  In this case, since the first client detects the end of the content based on the size of the content transmitted from the server, the reproduction of the content can be immediately terminated.

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

  In this case, the first client decreases the content designation amount when the server load is large, and increases the content designation amount when the server load is small. The amount can be adjusted appropriately.

  Furthermore, since the server returns only the “part of song data” specified by the client, the client arbitrarily changes the “part of song data” specified by the client, Special playback (for example, fast forward, fast reverse, playback from the middle, etc.) can be performed. Furthermore, since the server only transmits "part of the song data", if the client fails to receive, only the failed part needs to be received from the server again, and the processing at the time of reception failure is accelerated. Can do.

  Further, if the music format requested by the client is compressed data (such as MP3), the load on the server can be reduced by reducing the specified amount of data. This is because the amount of data of the compressed data is increased by being decoded at the time of reproduction.

  Preferably, the first client further includes means for transmitting the client information to the server whenever the client information about itself changes.

  In this case, the client information is not always transmitted 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 network traffic.

  Preferably, the network type content reproduction system further includes a second client connected to the server through the network and monitoring the first client.

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

  More preferably, the first client further includes means for 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 for receiving client information from the server.

  In this case, the user can know information related to the first client, for example, a connection state with the server, a client type, a current operation state, a current volume, and the like, on a second client different from the first client.

  Preferably, the server transmits the client information to the second client through a push port for forcibly transmitting the request to the second client.

  In this case, the server can transmit 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 client information when the received client information is changed.

  Preferably, the second client further includes content list requesting means for requesting the server for a content list listing a plurality of contents. The server further includes content list return means for returning the content list in response to a request from the second client. The second client further includes content list receiving means for receiving the content list returned from the server.

  Preferably, the client information includes a list construction key necessary for creating the content list. When the list construction key included in the received client information is changed, the content list requesting unit transmits the list construction key to the server. The content list reply means creates a content list based on the list construction key transmitted from the second client.

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

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

  More preferably, the client information includes a list construction key necessary for creating the content list. The content list requesting unit transmits 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 transmitted from the second client.

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

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

  In this case, the user can know the data format that can be reproduced by the first client by using a second client different from the first client.

  More preferably, the second client further displays a content list that lists a plurality of contents from the server, and displays content that can be played back by the first client among the contents included in the acquired content list. And means for not displaying content that cannot be reproduced by the first client or displaying the content in a manner different from the content that can be reproduced.

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

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

  In this case, since the second client does not attempt to monitor unless the client to be monitored is the first client, malfunction can be prevented.

  Preferably, the second client includes means for acquiring a monitoring handle necessary for monitoring the first client and means for monitoring the first client when the monitoring handle is acquired.

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

  Preferably, the network type content reproduction system further includes a second client connected to the server through the network and controlling the first client.

  More preferably, the second client includes server request means for requesting the server to control the first client. The server further includes means for 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 transmits information for specifying the first client and information for specifying the selected content to the server.

  In this case, the user can cause the first client to reproduce desired content.

  Preferably, the second client includes means for 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, control is not performed, so that malfunction can be prevented.

  Preferably, the second client is selected if the data format matches the means for determining whether the data format of the selected content matches the data format of the content that can be played back by the first client. Means for instructing the first client to reproduce the content based on the content data.

  In this case, since the second client commands the reproduction of content only for the content that can be reproduced by the first client, it is possible to prevent malfunction.

  Preferably, the second client includes means for obtaining a control handle necessary for controlling the first client, and means for controlling the first client when the control handle is obtained.

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

  Preferably, the first client further finishes playing the content commanded by the second client, sends a completion status to the server, and finishes playing the content selected by the first client, or the user's operation When the reproduction is finished in the middle of the content, a stop status different from the completion status is transmitted to the server.

  In this case, the server distinguishes between the completion status and the stop status, so that the first client has finished playing the content instructed by the second client or has finished playing the content selected by itself. Alternatively, it is possible to determine whether the reproduction has been completed in the middle of the content in accordance with the user operation.

  Preferably, the server includes means for receiving the completion status transmitted from the first client and transmitting it to the second client. The second client includes means for instructing the first client to play the content next to the played content in response to the completion status transmitted from the server.

  In this case, the first client that has finished reproducing the content transmits a completion status to the second client that instructed the reproduction of the content, so that the second client continuously transmits the content to the first client according to the content list. Can be reproduced automatically.

  Preferably, the network type content reproduction system further includes a plurality of second clients connected to the server through the network and controlling the first clients. Each of the second clients includes playback instruction means for instructing the first client to play back the content. The content reproduction means of the first client reproduces the content in accordance with a command from the second client. The first client further includes means for transmitting a completion status to the server when the content has been played. The server receives the completion status transmitted from the first client, transmits the completion status to the second client instructing the first client among the plurality of second clients, and receives the other second second Means for sending a stop status to the client. In response to the completion status transmitted from the server, the reproduction instruction means of the second client instructs the first client to reproduce the content next to the content that has been reproduced.

  In this case, the first client that has finished reproducing the content transmits the completion status through the server to the second client that has instructed the reproduction of the content, so that the second client is correctly connected to the first client. Order playback. On the other hand, since the server transmits a stop status to the other second client, the other second client recognizes that the first client is in an operation stop state, and erroneously commands the first client to perform continuous playback. Never do.

  Preferably, the first client further includes broadcast means for broadcasting the predetermined information. The server includes means for returning 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 the server specifying information returned from the server and registering it in the server list.

  In this network type content reproduction 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 specifying information (IP address, port number, etc.). Therefore, the client can find a server existing on the network.

  Preferably, the first client further includes means for determining whether or not server specifying information is registered in the server list. If the server identification information is not registered in the server list as a result of the determination, the broadcast means broadcasts the predetermined information again.

  In this case, the first client starts searching for a server again if no server identification information is registered in the server list. Therefore, the first client continues to search for at least one server.

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

  In this case, the first client does not continue to search for a server when no server exists on the local network, and in that case, a server on the Internet can be found.

  Preferably, the first client establishes a connection with a command port for transmitting and receiving a command between the server and the first client, and forcibly transmits a request from the server to the first client. Means for establishing a connection at a push port.

  In this network type content reproduction system, commands and status are transmitted and received between the server and the client through a command port. A command from the server is forcibly transmitted to the client through the push port.

  Preferably, the first client further includes means for sending a client index request command requesting a client index necessary for identifying itself to the server through the command port. The server further includes means for returning the client index to the client in response to the client index request command transmitted from the first client. The first client further includes means for transmitting the client index returned from the server to the server through the push port.

  Preferably, there are a plurality of first clients. The server includes connection limiting means for limiting the number of connectable clients.

  Preferably, the connection limiting unit disconnects the connection with the already connected client according to a predetermined priority when an unconnected client tries to connect.

  Yet another network type content reproduction system according to the present invention includes a server, a first client connected to the server via a network, an AV device connected to the first client, and a server connected to the server via the network. And a second client that controls the device. The second client includes means for transmitting a control command for controlling the AV device to the server. The server includes means for transmitting the control command transmitted from 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 the control command transmitted from the first client.

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

  Yet another network type content reproduction system according to the present invention includes a server, a first client connected to the server, an AV device connected to the first client, and a server connected to the server via the network. A second client to be monitored. The AV device includes means for transmitting information about itself to the first client. The first client includes AV device information transmitting means for transmitting information transmitted from the AV device to the server. The server includes means for transmitting information transmitted from the first client to the second client.

  In this case, the information regarding 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 a predetermined time interval.

  In this case, network traffic can be reduced.

  Preferably, the server further includes firmware updating means for updating the firmware of the first client.

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

  Preferably, the server further registers means for registering information on a plurality of firmware suitable for the first client, and firmware list transmitting means for transmitting a firmware list listing the information on the registered plurality of firmware to the first client. Including. The first client further includes means for receiving a firmware list transmitted from the server, and firmware request means for requesting the server to transmit 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 an appropriately selected version.

  Preferably, the first client further includes means for transmitting client information about itself to the server. The server further includes means for creating a firmware list based on the client information transmitted from the first client.

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

  Preferably, the first client requests a specified amount of firmware, preferably a part 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 transmits only the specified amount of firmware, if the client fails to receive, only the failed part needs to be received from the server again, and the processing at the time of reception failure can be accelerated. . Further, since only a part of the firmware list is transmitted from the server to the first client, the memory capacity necessary for storing the firmware list in the first client can be reduced.

  Another network type content reproduction 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 content storage means for storing a plurality of contents. Each of the second clients includes means for designating a content from a plurality of contents and instructing the first client to reproduce the designated content. The first client includes means for reproducing the content designated in response to a command from the second client, and means for transmitting a completion status to the server when the reproduction of the content is completed. The server further includes status transmission means for selecting one of the plurality of second clients when the completion status is received from the first client and transmitting the completion status to the selected second client. Further, each of the second clients, when receiving the completion status from the server, designates the content next to the content that the first client has finished playing, and instructs the first client to play the designated content. Means.

  Preferably, the server further comprises means for managing the priority of the second client capable of controlling the first client. The status transmission means selects the second client having the highest priority as the second client to which the completion status is to be transmitted. Alternatively, the server further includes means for storing identification information of the second client that has instructed reproduction. The status transmission means selects the second client that has instructed reproduction based on the identification information of the second client stored as the second client to which the completion status is to be transmitted.

  In this system, when the server receives the completion status from the first client that has completed the reproduction of the content, the server selects one second client and transmits the completion status to the second client. Therefore, only the second client commands the first client to perform continuous playback. As a result, the present system can eliminate the contention of the continuous playback command to the first client, and enable continuous playback of content by the first client.

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

  In this case, the second client other than the second client with the highest priority is sent a stop status instead of a completion status, so that the other second client does not take any active action, Only the status of the first client can be monitored.

  Another network type content reproduction 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 content storage means for storing a plurality of contents. Each of the second clients specifies a control handle acquisition means for acquiring a control handle necessary for controlling the first client, and specifies the content from the plurality of contents after acquiring the control handle. Means for instructing the first client to reproduce the content. The first client includes means for reproducing the content designated in response to a command from the second client, and means for transmitting a completion status to the server when the reproduction of the content is completed. The server further comprises means for transferring the completion status transmitted from 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 is acquiring the control handle, the second client specifies the content next to the content that the first client has finished playing, and the specified Means for instructing the first client to reproduce the content.

  In this system, the second client obtains a control handle necessary for controlling the client, and instructs the first client to reproduce the content. When the first client completes the reproduction of the content, the first client transmits a completion status. When the second client receives the completion status from the first client that has acquired the control handle, it instructs the first client to play continuously. As a result, the present system can eliminate the contention of the continuous playback command to the first client, and enable continuous playback of content by the first client.

  Preferably, the control handle acquisition unit prohibits the acquisition of the control handle by the other second client 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, it is possible to completely eliminate the contention of the reproduction command to the first client.

  More preferably, the first client further includes means for transmitting a stop status to the server when the reproduction of the content is stopped halfway. The server further comprises means for forwarding the stop status sent from the first client to each of the second clients. Each of the second clients further comprises means for releasing the prohibition of acquisition of the control handle when receiving a stop status from the first client acquiring the control handle.

  In this case, the first client that has stopped playing the content transmits the stop status to all the second clients, and the second client that has received the stop status from the first client that has acquired the control handle. Releases the control handle. Therefore, any second client can obtain the control handle of the first client.

  Yet another network type content reproduction 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 content storage means for storing a plurality of contents. The second client includes means for designating content from a plurality of contents and instructing the first client to play the designated content. The first client includes means for reproducing the content designated in response to a command from the second client, and means for transmitting a completion status to the server when the reproduction of the content is completed. Further, when the server receives the completion status from the first client, the server designates the next content of the content that has been reproduced by the first client, and instructs the first client to reproduce the designated content. Instruction means are provided.

  In this system, when the first client that has finished reproducing the content transmits a completion status to the server, the server itself instructs the first client to perform continuous reproduction. As a result, the present system can eliminate the contention of the continuous playback command to the first client, and enable continuous playback of content by the first client.

  Preferably, the server further includes means for storing a list construction key necessary for creating a content list listing contents to be played by the first client, and means for creating a content list based on the list construction key With. The continuous reproduction command means commands the first client to reproduce the content according to the content list.

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

  Yet another network type content reproduction 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 content storage means for storing a plurality of contents, and the second client designates the contents from the plurality of contents and instructs the first client to play the designated contents; Means for transmitting a list construction key necessary for creating a content list to be played by one client to the first client. The first client includes means for reproducing the content designated in response to a command from the second client, and means for transmitting the list construction key transmitted from the second client to the server. The server further includes means for creating a content list based on the list construction key transmitted from the first client and transmitting the content list to the first client. The first client further includes means for reproducing the content next to the content that has been reproduced by the first client in accordance with the content list transmitted from the server.

  In this system, the content list created by the server based on the list construction key is transmitted to the first client. The first client performs continuous reproduction by itself according to the content list. As a result, the present system can eliminate the contention of the continuous playback command to the first client, and enable continuous playback of content by the first client.

  The client in the network type content reproduction system according to the present invention has a content request means for requesting the server for digital content selected from a plurality of digital contents stored in the server, and the digital content returned from the server in response to the request. And reproducing means for reproducing. There are multiple servers. The client further includes connection means and determination means. The connection means connects to one of a plurality of servers. The determination means determines whether or not the connection with the server by the connection means is maintained for each predetermined period. When the determination unit determines that the connection with the server is disconnected, the connection unit performs reconnection with the server.

  The client checks the connection status with the server every predetermined period. When the connection with the server is disconnected, the client performs reconnection with the server. Therefore, even when the connection is disconnected due to an abnormality in the server, the client can quickly recover the connection by itself.

  Preferably, the connection means executes connection with another server when reconnection with the server is impossible.

  In this case, even if the reconnection to the connected server is not possible, the client quickly connects to another server. As a result, the client will not be left disconnected from the server.

  Preferably, the connection means transmits the client status before the connection is disconnected to the reconnected server.

  In this case, since the client transmits the client status before disconnection to the reconnected server, the client can recover the connection state with the server as it was. 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. In the drawings, the same or corresponding parts are denoted by the same reference numerals, and the description thereof is incorporated.

[table of contents]
1. 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 setting of content server and audio client 1.2.1.1. Initial setting of audio client 1.2.1.1.1. Content server search 1.2.1.1.2. Connection with content server 1.2.1.1.3. Transmission of client information 1.2.1.2. Initial setting of content server 1.2.1.2.1. Response to content server search 1.2.1.2.2. Command port connection reception 1.2.1.2.2.3. Push port connection reception (part 1)
1.1.2.2.4. Push port connection reception (part 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 issue command processing 1.2.2.2. Normal playback 1.2.2.2.1. Song list acquisition 1.2.2.2.2. Designation of song 1.2.2.2.3. Playing songs 1.2.2.3. Special playback 1.2.2.3.1. Fast forward playback 1.2.2.3.2. Fast reverse playback 1.2.2.3.3. Pause 1.2.2.3.4. Slow playback 1.2.3. Operation of controller 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.2.3. Control function 1.2.3.3.1. Control command processing 1.2.3.3.2. Playback control 1.2.3.3.3. Recognize whether the format is reproducible and replay 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. Continuous playback control with priorities 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 Other Embodiments 2.1. Audio client with built-in outlet 2.2. Acquire music data on the Internet 2.3. Playback with acquisition data length change function 2.4. Skip playback 2.5. Repeat playback 2.6. Halfway playback 2.7. Client with automatic connection recovery function

1. Preferred Embodiment 1.1. Configuration 1.1.1. 1. Referring to FIG. 1, a network audio system 10 according to an embodiment of the present invention includes a plurality of content servers S1 to Si for storing music data of a large number of songs, and music from the content servers S1 to Si. A plurality of audio clients C1 to Cj for reproducing music based on data, a plurality of controllers A1 to Ak for controlling and monitoring the audio clients C1 to Cj, and an AV device (for example, a switcher or an amplifier) The AV receiver includes an AVR and an AVR client AC for controlling the AV receiver AVR. Hereinafter, when one of the content servers is listed, the content server Si is used. When one of the audio clients is listed, the audio client Cj is used. When one of the controllers is listed, the controller Ak is used.

  Here, the music data is stored in the content server Si, but video data may be stored instead of or together with this, and various other digital contents (for example, still images such as photographs) may be stored. It may be accumulated. Hereinafter, music data will be described as an example. Further, although there are a plurality of content servers Si, audio clients Cj, and controllers Ak, it is sufficient that at least one content server or audio client exists. When there are a plurality of content servers S1 to Si, the audio client Cj may acquire music data from any of the content servers S1 to Si, or acquire music data from only one specific content server Si. Also good. Further, the controller Ak may not be provided at all. Also, there may be a plurality of AV receivers AVR and AVR clients AC, but they may not be present at all.

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

1.1.2. Content Server Referring 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, A LAN controller 22 that transmits and receives signals between the content server Si and the LAN 12 is provided.

1.1.3. Audio Client Referring to FIG. 3, each audio client Cj temporarily receives a microcomputer processing unit 28 including a network protocol processing unit 24 and a system operation unit 26, a flash memory 30, and sequentially input compressed digital music data. A memory 32 for storing and sequentially outputting; a sound processing unit 34 for decoding compressed digital music data to generate uncompressed digital music data; and a D / A converter (DAC) for converting the digital music data into analog music data ) 36, and a LAN controller 38 that transmits and receives signals between the audio client Cj and the LAN 12. Unlike the content server Si, the audio client Cj may not include an HDD for storing compressed digital music data.

1.1.4. Controller Referring to FIG. 4, each controller Ak has predetermined inputs 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. And a LAN controller 304 that transmits and receives signals between the controller Ak and the LAN 12. Like the audio clients C1 to Cj, the controllers A1 to Ak function as clients for the content servers S1 to Si. The controller Ak is different from the audio client Cj in that the audio client Cj has a reproduction function, whereas the controller Ak does not have a reproduction function and mainly has an audio client monitoring and control function.

  The audio client Cj mainly has a playback function, but may have a monitor and control function. In this case, the audio client also functions 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 capable of communicating with the AV receiver AVR, but may also have a reproduction function in the same manner as the audio client Cj.

1.2. Operation 1.2.1. Initial Setting Operation of Content Server and Audio Client Referring to FIG. 5, when a certain audio client is turned on, the audio client first searches for a content server (S11). The active content server among the plurality of content servers Si connected to the LAN 12 responds to this (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). In response to this connection request, the content server establishes a connection with the audio client (S22).

  Finally, the audio client transmits various client information about itself to the content server (S13), and the content server receives it (S23).

  When the initial setting operation is completed, the process proceeds to the next music list acquisition operation. Before the description, 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 Referring 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).

  Next, the audio client is not particularly limited, but broadcasts a magic word predetermined at the command port on the LAN 12 by, for example, the UDP protocol (S1102). If there is an active content server among the plurality of content servers Si connected to the LAN 12, the content server receives the broadcast magic word at the search port and is the same as the audio client that broadcast the magic word. A magic word is returned, and server identification information (specifically, an IP address and a port number) for identifying itself is transmitted.

  Subsequently, the audio client resets a timer for measuring the elapsed reception time of the server identification information (S1103), and then determines whether the server identification 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), and if it is full, the search is completed, and if it is not full yet, the process returns to step S1103.

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

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

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

1.2.1.1.2. Connection with Content Server Referring to FIG. 7, the audio client selects one content server from the server list in accordance with a user operation (S1201), and sets the IP address and port number of the selected content server. Obtain (S1202).

  Subsequently, the audio client generates a TCP (Transmission Control Protocol) socket (1) using the acquired IP address and command port (S1203), and connects to the content server using the TCP socket (1) (S1204). The command port is a port for transmitting and receiving commands between the content server and the audio client. The content server accepts connection at the command port (S2201), and if the connection is successful, the process proceeds to step S1206. Otherwise, the connection fails (S1205). As a result, the audio client establishes a connection for transmitting and receiving commands to and from the content server.

  Subsequently, the audio client transmits a client index request command to the content server through the TCP socket (1) (S1206). In response to the client index request command, the content server returns a client index from the TCP socket (1) to the audio client (S2202), and the audio client receives this (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 the audio client requests a client index from the content server.

  Subsequently, the audio client generates a TCP socket (2) using the IP address and push port of the content server (S1208), and connects to the content server using this TCP socket (2) (S1209). The push port is a port in a standby state that can always receive 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. The content server accepts the connection at the push port (S209), and if the connection is successful, the process proceeds to step S1211. Otherwise, the connection fails (S1210). As a result, the audio client establishes a connection for receiving the server request.

  At this point, the content server still does not know which audio client is connected to the push port. Therefore, the audio client transmits the client index acquired in step S1207 to the content server using the TCP socket (2) (S1211). The content server specifies an audio client connected to the push port based on the client index. Thereafter, the content server uses this push port when sending a server request to the audio client.

  As a result, two connections are established between the command port and the 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.

  In general, in a server client system, as seen in the HTTP protocol, a content server returns a response (such as an HTML document) in response to a request (such as a page request) from a client. This means that only the client has an action trigger, and the content server cannot voluntarily act on the client. For this reason, even if the content server takes a voluntary action such as notifying the client of some request to the client, for example, when the content server is shut down, the notification cannot be made without a request from the client.

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

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

  (1) If the polling interval is shortened to some extent and it is not frequently asked whether there are server requests, there is a difference between the time when the content server makes a request and the time until 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 client increase.

  (3) Since the frequency with which the content server has to send a server request to the client is lower than the frequency with which normal commands are sent and received, most polling is wasted. This is because even if there is a server request, it is usually answered that there is no request.

  In order to solve the above problem, a server request may be transmitted to the client not by polling from the client but by an interrupt from the content server. Thereby, it is possible to eliminate the lack of real-time property, which is a problem in the above (1), and useless loads such as the above (2) and (3).

  In order to realize this, two connections are established as described above. One is a connection formed in the command port used by the audio client Cj to issue a command and the content server Si responding to it. The other is a connection formed in a push port used by the content server Si to send a server request to the audio client Cj. As a result, the content server Si can notify the audio client Cj of the server request without using the polling from the audio client Cj.

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

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

  Also, as shown in FIG. 9, when the controller Ak controls the audio client Cj (for example, playback or stop), a command requesting the content server Si to issue a server request including the control content is sent through the command port. Send to server Si. In response to this command, the content server Si transmits a server request to the audio client Cj through the push port. As a result, the controller Ak can control the audio client Cj.

  Furthermore, 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 transmits the change in the operation state to the controller Ak that monitors the operation state of the audio client Cj through the push port. Therefore, the audio client Cj can notify the controller Ak of the change in the operation state in real time.

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

1.2.1.1.3. Transmission of Client Information Referring to FIG. 11, the audio client transmits its own attribute information to the content server (S1301 to S1303), and further transmits its initial status (S1304 to S1305).

  Specifically, the audio client transmits the audio client type using the TCP socket (1) (S1301). Audio client types include the types of music formats that can be played back, the availability of operations by a remote controller (remote controller), the presence or absence of an EIA-232 port, and the like.

  Subsequently, the audio client transmits a product ID through the TCP socket (1) (S1302). The product ID is model information given to each type of audio client. Therefore, the same product ID is assigned to the same type of audio client.

  Subsequently, the audio client transmits the firmware ID through the TCP socket (1) (S1303). The firmware ID is firmware version information installed in the audio client.

  Subsequently, the audio client transmits the initial value of the volume using the TCP socket (1) (S1304). The initial value of the volume is the initial value of the volume that is played back by the audio client.

  Finally, the audio client transmits the initial status of the audio client using the TCP socket (1) (S1305). The initial status of the audio client includes a stop status.

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

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

  Referring to FIG. 12, the content server secures 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 presence / absence of connection, a client type, a current status, a current volume value, a product ID, a firmware ID, a client name, a reproduction file name, and a list construction key. Including.

  In the client type, a client type such as an audio client, a controller, and an AVR client, and a reproducible data format (MP3, WAV, etc.) are recorded. The client type also records whether or not remote control is possible. For example, information that remote control is possible is recorded in an audio client that can be controlled by a remote control. In the status, statuses such as “play”, “stop”, “pause”, “complete”, “firmware update in progress” are recorded. In the reproduction file name, the full path name of the HDD 14 in which the data of the currently reproduced music is stored is recorded. Further, the playback file name does not need 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 is associated with a file name 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 transmit / receive a long file name. Further, since the file in which the song data is stored cannot be identified immediately from the file name, security is improved. Furthermore, the list construction key is used by 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 has been input to the 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, the number of times of reproduction, and a last access time. In this file name, the full path name of the HDD 14 in which the music data is stored is recorded. The firmware information database includes firmware information for the number of firmware files. The firmware information includes a product ID, firmware ID, file size, data format, and file name. In this file name, a full path name indicating a 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 a response process to the content server search described later (S205). The content server also performs a command port connection reception process (S207) described later when the command port is written (S206). The content server also performs push port connection acceptance processing (part 1) described later (S209) when the push port is written (S208). The content server also performs push port connection acceptance processing (part 2) described later (S211) when there is a write in the unprocessed push port (S210).

1.2.1.2.1. Response to Content Server Search Referring to FIG. 16, when the search port is written, the content server acquires the written content (S2051), and determines whether the content is a correct magic word. (S2052). If it is a correct magic word, the content server returns the same magic word to the transmission source client (S2053), and also returns its own IP address and port number.

1.2.1.2.2. Command Port Connection Acceptance Referring to FIG. 17, when there is a connection request from a client to the command port, the content server determines whether the number of currently connected clients has reached the maximum number of clients (S2071). ). If the maximum number of clients has been reached, the content server searches for clients with low priority and forcibly disconnects them (S2072). The client priority is lower for audio clients that are not currently playing, audio clients that are not communicating for a certain period of time, and the like. Then, the content server clears the client information of the client that has been forcibly disconnected (S2073).

  When the number of clients currently connected reaches the maximum number of clients, the content server may not be connected to any more clients instead of the above.

  If there is a margin in sockets that can be connected by the client, or if a socket that can be connected is secured by disconnecting the low-priority client, the content server starts accepting a connection request from the client (S2074).

  If the reception is successful (S2075), the content server searches for a free area in the client information database (S2076). Specifically, the client information whose flag is FALSE is searched. 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 the reception in the socket field of the client information storage area (S2079).

1.1.2.2.3. Push port connection acceptance process (1)
Referring to FIG. 18, when a connection request is made from a client to the push port, the content server starts accepting the request (S2091). When the reception is successful (S2092), the socket information obtained as a result of the reception is stored in the queue of the unprocessed push port (S2093). At this point, the content server has not yet identified the client connected to the push port. Such a push port is called an unprocessed push port.

1.1.2.2.4. Push port connection acceptance process (2)
Referring to FIG. 19, when there is a connection request from a client to an unprocessed push port, the content server acquires a command written to the push port (S2111). If the size of the command is larger than 0 (S2112) and the command is a client index notification command (S2113), the content server determines whether or not the client indicated by the client index is already connected to the command port. It is determined (S2114).

  If the connection has not yet been completed, the content server sets the error code to -1 (failure) (S2115), and proceeds to step S2119. On the other hand, if the connection has already been completed, the content server registers this push port as a push port for the client (S2116). The content server further deletes this push port from the queue of unprocessed push ports (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 Referring again to FIG. 12, the content server receives a command from the client after completing the initial setting. That is, the content server repeats steps S213 to S217 for the maximum number of clients (S212, S218, S219). n is a client index from 0 to (maximum number of clients−1) assigned to the client.

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

1.2.2.1.1. Command Distribution Processing Referring to FIG. 20, when writing from the client to the command port, the content server branches the processing according to the command stored in the first 4 bytes (S2171). That is, if the status notification command is to notify the status change from the audio client to the content server (S2172), the status notified from the audio client is notified to the controller (S2173). Details will be described later. If the command is a content server request issue 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 performs a predetermined process in response to the command.

1.2.2.1.2. Status Notification Command Processing When a command from an audio client (hereinafter referred to as “the audio client”) is a status notification command, referring to FIG. 21, the content server first stores the status stored in the parameter in the command. The client information such as volume and volume is stored 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 clients, and notifies the searched 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 of the client information and determines whether or not 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 monitoring handle has been acquired, the content server determines whether or not the controller has completed connection to the push port (S21735).

  If the connection to the push port has been 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 issuance command, referring to FIG. 22, the content server first obtains the issuance source controller, destination audio client, request content, etc. included in the command (S21751).

  The content server determines whether or not the issuer controller has acquired the control handle (described later) of the destination audio client (S21752). If the control handle has not been acquired, the content server 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 has been acquired, the content server refers to the flag in the client information to determine whether or not the connection is established at the command port of the destination audio client (S21754). The error code is set to -2 (S21755). Therefore, it is possible to prevent a command from being transmitted to an uncontrollable audio client.

  If the connection is established at the command port of the destination audio client, the content server determines whether or not the connection is established at the push port of the destination audio client (S21756). Is set to 1 (S21757). On the other hand, if established, the content server transmits the request content 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 transmission destination audio client is not connected to the push port, the request content from the controller may be transmitted to the transmission destination audio client when the transmission 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 designate a desired song, but first designates a desired song list, and selects the desired song from the song list. Details will be described below.

  Referring to FIG. 23, the audio client transmits a song list request command to the content server in accordance with a user 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 names and artist names are listed. In response to the song list request command, the content server transmits a song list to the requesting audio client (S24), and the audio client receives it (S14).

  The audio client designates a song included in the song list according to the user's operation (S15), and the content server prepares delivery of the designated song according to this (S25).

  Subsequently, the content server distributes the designated song to the audio client (S26), and the audio client plays the delivered song (S16). Then, the audio client stops the reproduction of the music after the end of the reproduction or according to the user's operation (S17).

  Hereinafter, details of each of Steps S14 to S16 will be described.

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

  When the user wants to select one of a plurality of playlists stored in the content server, first, in order to confirm what playlist is registered, the playlist name list is stored in the content server. Request. The audio client requests the play name list from the content server in response to the user's operation, and receives the play name list from the content server (S1402).

  Subsequently, the audio client determines whether to request the designated playlist (S1403). If the user designates a desired playlist from the playlist name list and the audio client requests the designated playlist in response to this operation, the process proceeds to step S1413; otherwise, the process returns to step S1401 or S1403 ( S1404).

  If the play name list is not requested, the audio client determines whether to request an artist list from the content server (S1405). In the artist list, a plurality of artist names are listed. The artist list is not prepared in advance in 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 an artist list, the audio client requests a desired artist list from the content server according to the user's operation, and receives the artist list from the content server (S1406).

  Subsequently, the audio client determines whether or not to request a song list of the designated artist (S1407). If the user designates a desired artist from the artist list and the audio client requests a song list of the designated artist in response to this operation, the process proceeds to step S1413. Otherwise, the process returns to step S1401 or S1407 ( S1408). This song list lists the names of the designated artist's songs, etc., but this song list is not prepared in advance in the content server in the same manner as the above artist list, but is displayed in response to a request from the audio client. 14 from the content information database shown in FIG.

  If the artist list is not requested, the audio client determines whether to request the genre list from the content server (S1409). In the genre list, a plurality of genre names are listed. Similarly to the artist list, the genre list is not prepared in advance in the content server, but is generated 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 a desired genre list from the content server according to the user's operation, and receives the genre list from the content server (S1410).

  Subsequently, the audio client determines whether to request a song list of the designated genre (S1411). If the user designates a desired genre from the genre list and the audio client requests a song list of the designated genre in response to this operation, the process proceeds to step S1413. Otherwise, the process returns to step S1401 or S1411 ( S1412). This song list lists the names of songs of the specified genre, etc. This song list is not prepared in advance in the content server like the artist's song list, but in response to a request from an audio client. Each time it is created from the content information database shown in FIG.

  As a result, 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, an operation when a genre list is acquired and a pop is selected as a desired genre and a pop music list is acquired will be described.

  In this case, the audio client transmits a list request command for requesting a genre list to the content server (S1421). In response to this, the content server returns a genre list (S2401). The audio client receives the genre list from the content server and stores it in the memory 32 as shown in FIG. 26 (S1422).

The genre list may be created in advance and stored in the content server. However, this is not the case here, and the genre list is generated by the content server based on the content information database shown in FIG. Create a list. Hereinafter, a method for creating a genre list will be described.
As shown in FIG. 27, the content information database has n records when n songs are stored. Each record includes a song name, genre, artist name, album name, and the like.

  When a genre list is created using such a content information database, with reference to FIG. 28, the content server first initializes an index indicating a record number to 0 (S24011).

  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 not, 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 it exists, the content server skips step S24013 and immediately increments the index (S24014).

  Subsequently, the content server determines whether or not the record number indicated by the index is smaller than the total number of records n (S24015). If it is smaller, the process returns to step S24012. Complete.

  Through the above processing, the content server picks up the genres of all the songs stored in the content information database without duplication, and creates a genre list. As described above, the genre list is not stored in a database in advance, but is temporarily created every time a request is made from the audio client. Therefore, a memory area for always storing the genre list is unnecessary.

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

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

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

  Subsequently, the content server compares the genre of the record indicated by the index with the selected genre (pops in this example), and determines whether or not they match (S24022). If they match, the content server adds the song name, artist name, album name, etc. of the record 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).

  Subsequently, the content server determines whether or not the record number indicated by the index is smaller than the total number n of records (S24025). If it is smaller, the process returns to step S24022. Complete.

  Through the above processing, the content server picks up only the music of the selected genre from the content information database and creates a music list. As described above, the music list is not stored in advance in a database, but is temporarily created every time a request is made from the audio client. Therefore, a memory area for always storing the music list is unnecessary.

  When creating a song list, it is possible not to pick up all applicable songs, but not to pick up songs that cannot be reproduced. Further, instead of creating a song list every 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 genre list, the entire song list is not sent all at once, but is sent little by little. That is, the music list request (S1423, S1425), the music list reply (S2402, S2403) and the music list reception (S1424, S1426) are repeated. The details will be described below.

  The audio client transmits a list request command as shown in FIG. 31 to the content server (S1423). The list request command is a command for the audio client to request a list from the content server. In this example, the list request command includes an acquisition start index, an acquisition count, and a list construction key. The acquisition start index is an index indicating the first song that the audio client intends to acquire among the songs recorded in the selected genre list. The acquisition number is the number of songs that the audio client intends to acquire. As will be described in detail later, the list construction key is composed of a filter type indicating a category to which attention is paid when a song is extracted from the content information database, and specific keywords classified into the category. Although not particularly limited, in this example, the acquisition start index = 0 and the number of acquisitions = 50 are set, and the list construction key is set to “genre (filter type) = pops (keyword)”.

  In response to the list request command, the content server returns search data as shown in FIG. 32 to the audio client (S2402). The search data includes the effective number and the remaining number in addition to a part of the song list. The effective number is the number of songs that the content server actually returns to the audio client. The remaining number is the number of songs remaining after the song list returned from the content server to the audio client. Here, since it responds to the list request command with the acquisition start index = 0 and the acquisition number = 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 = 110, the effective number = 50 and the remaining number = 60 (= 110-50) are set.

  Subsequently, since 60 songs still remain in the content server, the audio client transmits a list request command to the content server again (S1425). Here, the acquisition start index = 51 and the acquisition number = 50 are set.

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

  In the above example, since the total number of songs in the song list is 110 and the number of acquisitions is 50, 50 songs that are part of the song list are returned, but the total number of songs in the song list is less than the acquisition number. In this case, for example, if the total number of songs in the song list = 40 and the number of acquisitions = 50, 40 songs that are all in the song list are returned.

  In the above example, since the acquisition start index = 0, the song is returned from the beginning of the song list. For example, if the acquisition start index = 10, the song is returned from the eleventh 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 acquisition start index = 10 and acquisition number = 50, the content server has an effective number = 50 and the remaining number = 50 (= 110-10-50) is returned.

  If the number of songs that can be stored in the memory 32 is greater 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 very small compared to 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 is stored. Can be downloaded. Therefore, the capacity of the memory 32 can be kept small.

  For example, as shown in FIG. 33A, after the audio client stores a song list for 50 songs in the memory 32, if the user desires to acquire the 51st song and the subsequent songs, the audio client sends the latter song as shown in FIG. 33B. The list is moved to the first half of the memory 32. Then, as shown in FIG. 33C, the audio client stores the music list for the 25th music from the 51st music 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, after selecting a genre, a song is selected immediately from that genre. However, as shown in FIG. 34, after selecting a genre and subsequently selecting an album from that genre. A song may be selected from the album.

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

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

1.2.2.2.2. Designation of Song Referring to FIG. 35 and FIG. 36, the audio client requests the content server for information on the designated song (S1501), and the content server sends the information on the song designated in response to this request to the audio client. A reply is made (S2501), and 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 designated song. In response to the 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 designated song. Music data such as MP3 generally has header information before content information. The data offset is for skipping this header information and designating the head address of the song. When the content server analyzes the offset, the audio client does not need to analyze the offset. Generally, a content server has a higher processing capability than an 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 designated song (S1503), and the content server opens the designated song file in response to this request, and returns the result to the audio client ( In S2502), the audio client receives this (S1504).

  Specifically, the audio client transmits a song playback preparation command as shown in FIG. 39 (S1503). This song playback preparation command includes the file name of the designated song and a list construction key to be described later. The content server opens the file in response to the song reproduction preparation command, and returns an error code as shown in FIG. 40 (S2502). This error code indicates that there is an error when the file transfer cannot be prepared, such as the file does not exist, and there is no error when the file can be prepared. The client confirms the transmitted error code, and if there is an error, performs a predetermined error process (S1504).

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

  Specifically, the audio client transmits a song data transfer request command as shown in FIG. 41 (S1601). This music data transfer request command includes an acquisition start address and an acquisition data length of music data to be transferred. As shown in FIG. 42, the content server returns music data corresponding to the acquired data length from the head address specified by the acquisition start address (S2601). The size of 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 sent back at a time is small, and the client can speed up the processing as the amount of data received at a time is large, but 1K to 32K bytes (especially 4K to 16K). Byte) is an optimum value for both the content server and the client. The size of such data is preset on the audio client side.

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

  In this way, the audio client can acquire music data in the specified range from the content server, so that the user can play the song from the middle as described later, as well as fast forward playback, fast reverse playback, slow playback, etc. Music can be freely played according to the operation.

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

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

  When the audio client outputs the music data and starts playing the music as described above, the audio client transmits the playback status to the content server (S1603). The content server receives this and returns an error code to the audio client (S2602). The audio client confirms this error code, and if there is an error, performs a predetermined error process (S1604).

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

  In the above description, the music data is started to be output after the buffer is completely filled with the music data. However, 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 designated song has been received based on the data size acquired in step S1502 (S1617). When all the audio data have been received, the audio client determines whether or not the designated song has been reproduced based on the received music data (S16171), and when reproduction has been completed, transmits 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 is playing the song If stopped at, the audio client sends a stop status. On the other hand, when the user operates the controller and the audio client reproduces the music designated by the controller and finishes reproducing the music, the audio client transmits a completion status. The reason for distinguishing the stop status and the completion status in this way will be described later.

  The content server receives this status and returns an error code to the audio client (S2608). The audio client confirms this error code, and if there is an error, performs a predetermined error process (S1619).

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

  In the above, music data is transferred in units of bytes, but when MP3 music data is transferred, it is preferable to transfer in units of frames. This is because there are many advantages in special reproduction (described later) such as time display, fast forward, and fast reverse reproduction. Therefore, in the case of MP3 music data, the audio client requests music data in units of frames. In response to this request, the content server searches for the MP3 frame header from the designated file, and transfers it from the beginning of the frame. Since this header includes a parameter capable of calculating 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 Also, in order to enable special playback such as fast forward, fast reverse, pause, slow, etc., the audio client performs the following processing before a series of processing such as transfer request, reply and acquisition of music data. Do.

1.2.2.3.1. Fast forward playback In the case of fast forward playback, referring to FIG. 49, the audio client monitors key input (S1620), and when the fast forward playback key is pressed, sets the skip amount to a value greater than 0 (S1621). Otherwise, the skip amount is set to 0 (S1622).

  When an empty space is generated in the buffer (S1609), the audio client calculates a music data acquisition start address according to the following equation (S1624).

Acquisition start address = Previous acquisition start address + Acquired 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 is incremented by the acquisition data length. To increase. In this case, since the audio client continuously acquires music data, normal playback is performed. On the other hand, if 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 the audio client acquires the music data by skipping 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, double-speed fast-forward playback is performed. Further, for example, by setting the skip amount to twice the acquired data length, it is possible to perform reproduction at 3 times speed.

1.2.2.3.2. Fast-Reverse 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 Set to a value larger than the previous acquired data length. This is because if the absolute value of the skip amount is smaller than the previous acquisition data length, the music data acquisition ranges overlap. If the acquired data length is constant every time, if the absolute value is set to twice the acquired data length, the backward reproduction can be performed at the same speed as the normal reproduction.

  Also, the audio client determines whether or not the acquisition start address calculated in step S1624 is within the range where music data exists (S1625). If it is within the range, the audio client proceeds to the next step S1610. If it is out of the range, the audio client stops playback. Since the end of music data is detected in normal playback, it is not necessary to enter such an end condition, but in the case of fast reverse playback, it is necessary to detect the start of music data. An end condition is entered. However, without entering 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 reverse playback.

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

1.2.2.3.3. Pause In the case of pause, referring to FIG. 50, the audio client monitors key input (S1626, S1628), and when the pause key is pressed, sets the operation status to pause (S1627) and plays back. If the key is pressed, the operation status is set to playback (S1629).

  When an empty space is generated in the buffer (S1609), the audio client determines whether or not the operation status is temporarily stopped (S1631). If it is paused, 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 playback key is pressed to release the pause and the operation status changes to playback, the audio client proceeds to step S1610 and starts transferring the next music data.

  When the operation status is suspended, the audio client stops the buffer reading operation. This is because the previously transferred music data remains in the buffer.

1.2.2.3.4. Slow playback Slow playback is required for movies, not music. Usually, since a moving image file is in a compression format such as MPEG-2, the audio client includes a decoder for reproducing it. In the case of slow playback, when a command for instructing slow playback is given to the decoder, the rate of reduction of the video data stored in the buffer becomes slow. 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%. For this reason, in step S1609, the audio client waits for a buffer to be vacant, thereby realizing slow playback.

1.2.3. Operation of controller 1.2.3.1. Connection with Content Server Controller Ak establishes a connection with content server Si in the same manner as audio client Cj.

  Referring to FIG. 51, when the controller Ak is powered on, the controller Ak connects to the command port of the content server Si (S3001). The controller Ak issues a client index request command through this command port (S3002). In response to this command, the content server Si returns a client index to the controller Ak, and the controller Ak stores the acquired client index (S3003).

  Subsequently, the controller Ak connects to the push port of the content server Si (S3004). The controller Ak issues a client index notification command through this push port, and transmits the client index stored in step S3003 to the content server (S3005). As a result, the push port is opened (S3006).

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

  Subsequently, the controller Ak acquires 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 and acquires the monitoring handle and 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 connection procedure is different from the audio client Cj in that the controller Ak notifies the content server Si of a client type indicating that it is a controller. Another difference is that the controller Ak acquires the monitoring handle and / or the control handle. Details will be described below.

1.2.3.1.1. Acquisition of Monitoring Handle and Control Handle Referring to FIG. 52, the controller Ak displays a list of all audio clients Cj connected to the content server Si (S30091). The controller Ak selects the audio client Cj to be monitored from the list according to the user 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 activated, and after the second time, the audio client Cj selected first is registered, It is preferable to automatically select a registered audio client.

  Subsequently, the controller Ak transmits the client index of the selected audio client Cj to the content server Si, and requests the monitoring handle (S30093). The content server Si stores the client index of the transmission source controller Ak and the received client index of the audio client Cj in association with each other (S20001), and issues a monitoring handle to the transmission source controller Ak (S20002). As a result, the controller Ak acquires the monitoring handle of the selected audio client Cj (S30094).

  Subsequently, the controller Ak selects an audio client Cj to be controlled from the list in accordance with a user operation (S30095). Then, the controller Ak transmits the client index of the selected audio client Cj to the content server Si, and requests the control handle (S30096). The content server Si associates and stores the client index of the transmission source controller Ak and the client index of the received audio client Cj (S20003), and issues a control handle to the transmission source controller Ak (S20004). As a result, the controller Ak acquires the control handle of the selected audio client Cj (S30097).

  The monitoring handle is an authority to monitor the audio client Cj given from the content server Si to the controller Ak. Thus, 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 transmits the client information of the audio client Cj to the controller Ak as needed 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 load on the LAN 12 increases as the number of audio clients Cj increases. Further, the transmission of the command of the controller Ak and the status of the audio client Cj affects the traffic on the LAN 12.

  As shown in FIG. 53, when a plurality of controllers A1 to A3 exist on the same LAN 12, 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 network traffic and content server load.

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

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

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

  In this network type audio system, when there are a plurality of controllers Ak, if any controller Ak can control the audio client Cj, the audio client Cj is playing a song in accordance with a command from the controller Ak. The other controller Ak may instruct the audio client Cj to stop the reproduction or instruct the reproduction of 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 can control the audio client Cj. To make it impossible to control.

  If the content server restricts the controllers that can acquire the control handle, it is possible to set a combination of the audio client and the controller that can control it. Further, the controller can abandon the control handle by issuing a control handle release command to the content server.

1.2.3.2. Monitoring (Monitoring) Function The controller Ak can monitor the audio client Cj by acquiring the monitoring handle as described above.

  Referring to FIG. 55, controller Ak requests client information from content server Si (S31), content server Si returns client information accordingly (S27), and controller Ak obtains and stores it. (S31). Alternatively, when the content server Si receives client information from the audio client Cj, the content server Si transmits client information to the controller Ak through a push port, and the controller Ak acquires and stores the client information. Then, the controller Ak displays the acquired client information (S32). Hereinafter, the monitoring function by this controller will be described in detail.

  Referring to FIG. 56, 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 whether there is any change in the information. That is, the client index is checked first (S3101), and the audio information of which audio client Cj is stored. Then, the stored product ID and firmware ID of the audio client are confirmed (S3102, S3103).

  Specifically, the type of the audio client is determined based on the product ID, and the firmware version is determined based on the firmware ID. If the firmware version applied to the audio client is old, the controller Ak accesses customer service on the Internet, distributes the firmware to the audio client Cj, and automatically updates it. Details of the firmware update will be described later.

  The controller Ak analyzes the received client information to confirm the client type. If the audio client Cj, the controller Ak branches to the processing for that, and otherwise ignores it.

  Subsequently, the controller Ak checks whether there is a change in the connection information (S3104), and if there is a change, changes the display of the connection state of the audio client Cj (S3105).

  Therefore, the controller Ak can always monitor whether or not the plurality of audio clients Cj are turned on and connected to the content server Si.

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

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

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

  Subsequently, the controller Ak checks whether there is any change in the song being played back (S3112), and if there is a change, checks the data format of the song (S3113), and changes the display of the name of the song being played and the artist name. (S3114) The number of the currently reproduced song in the song list is checked and the number is stored (S3115).

  Finally, the controller Ak checks whether the status is changed (S3116), and if there is a change, changes the status display (S3117). Even when the audio client Cj is controlled by the remote controller, the controller Ak monitors and displays the status. If the status of the audio client Cj is the completion status (S3118), the controller Ak instructs the audio client Cj to continuously play the next song (S3119). Details of the continuous reproduction will be described later.

  The above process is repeated each time client information of any audio client from which the controller has acquired a monitoring handle changes.

  Although not shown, the controller Ak monitors the client type of each audio client Cj. The controller Ak also monitors the reproducible data format and displays only the reproducible music title.

  As described above, when the content server receives client information from the client, the controller Ak can always monitor the audio client Cj by forcibly transmitting the client information to the controller via the push port. Only the minimum necessary information is transmitted from the content server Si to the controller CL. Therefore, the processing load on the controller Ak is reduced. Even if there are a plurality of audio clients Cj, the controller Ak can distinguish the audio clients 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.

  Referring to FIG. 57, controller Ak transmits a control command to content server Si (S33), and content server Si transmits this to designated audio client Cj (S28). The audio client Cj operates according to this control command, changes its status (S18), and transmits the changed status to the content server Si (S19). The content server Si transmits 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, 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 with reference to FIG.

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

  If the received data is a playback command (S3003), the audio client Cj obtains the designated file name from the content server Si (S3004). The audio client Cj specifies the song name, album, genre, and the like from the acquired file name. Then, the audio client Cj designates a song and instructs the content server Si to transfer the music data of the song (S3005). The audio client Cj performs reproduction 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 transmits the stop status to the content server Si. (S3008). In addition, the audio client Cj performs predetermined processing 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, an 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.

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

  Subsequently, the controller Ak determines whether the audio client Cj is an audio client or an AVR client based on the client type (S3014). Here, since it is the audio client Cj, the controller Ak determines whether or not the song list of the desired artist has already been acquired (S3015). If not yet acquired, the controller Ak acquires a song list of a desired artist from the content server Si (S3016). The controller Ak displays the music list on the display device.

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

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

  The audio client Cj reproduces the desired music in response to the reproduction command transmitted from the controller Ak through the content server Si, and changes the status to the reproduction status (S18). The audio client Cj transmits the reproduction status to the content server Si (S19), and the content server Si transmits the reproduction status to the controller Ak (S29). In response to this, the controller Ak changes the status of the audio client Cj to the reproduction status (S34).

1.2.3.3.3. Recognizing whether or not the format is reproducible The replay list includes all formats of music regardless of whether or not the audio client Cj is reproducible. For this reason, when the controller Ak displays the music list acquired from the content server Si when the user selects a desired music as it is, the following problem occurs.

  That is, even when the user selects a song in a format that cannot be played back by the audio client Cj, 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 in the audio client Cj. However, there is no playback sound.

  Therefore, as shown in FIG. 60, information relating to a reproducible format is added to the client type of the client information. Therefore, the client type includes information related to the hardware configuration of the client and information related to a format that can be reproduced by the audio client.

  Information related to the hardware configuration includes the following. The “audio client (intelligent type)” is an audio client that can play music and receive a remote control signal. An “audio client (non-intelligent type)” is an audio client that can play music but cannot receive a remote control signal. 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. The “AVR controller” is a client that can control and monitor the AVR client via the content server. Information relating to the reproducible format includes MP3, WAV, WMA and the like.

  A client type of one client may include information related to a plurality of hardware configurations, and may include information related to a plurality of reproducible formats.

  Next, a processing procedure when the controller Ak displays a 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 a song is connected to the content server Si (S3501). When not connected, the audio client Cj cannot reproduce a song, and therefore displays all the songs in the song list as unreproducible songs or does not display all the songs (S3502). Therefore, it is possible to prevent the user from selecting a song that cannot be reproduced by the audio client Cj.

  On the other hand, if 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 reproduced by the audio client Cj (S3505). If the format is reproducible, the controller Ak displays the song as a reproducible song (S3506). If the format is not reproducible, the controller Ak displays it as an unreproducible song or does not display it (S3507). .

  For example, when the audio client C1 can reproduce both MP3 and WAV, the controller Ak displays all the songs in the song list (playlist in this example) as shown in FIG. However, if the audio client C2 can play back MP3 but cannot play back WAV, as shown in FIG. 63, the MP3 song in the song list is displayed normally, but the WAV song is displayed lightly. Also, the music may not be displayed at all, rather than displayed lightly. Therefore, it is possible to prevent the user from selecting a WAV song that cannot be reproduced by the audio client C2.

  When the connection state or client type of the audio client Cj is changed, the controller Ak redisplays the music 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.

  Referring to FIG. 64, when the user selects a song to be played back, controller Ak determines whether the format of the selected song is a format that can be played back by audio client Cj (S3511). Specifically, the controller Ak compares the format of the selected song with the reproducible format in the client type.

  If the format is reproducible, the controller Ak instructs the audio client Cj to play the selected song (S3512). On the other hand, if the format is not reproducible, the audio client Cj notifies the user that the selected music cannot be replayed (S3513).

  As described above, the controller Ak displays the music that can be played back by the audio client Cj so that the user can recognize it, thereby preventing the user from requesting playback of the music that cannot be played back by the audio client Cj.

1.2.3.3.4. Continuous playback control When the user operates the audio client Cj to play a song on the audio client Cj, the audio client Cj acquires the song list, so the songs in the song list are played continuously. Is possible. However, when the audio client Cj is playing a song designated by the controller Ak, the audio client Cj does not acquire a song list, and therefore the audio client Cj continuously plays the songs in the song list. For this purpose, the controller Ak needs to instruct the audio client Cj of the next song.

  Further, when there is only one controller on the network, there is no problem, but when there are a plurality of controllers, there is a problem that the audio client cannot normally perform continuous reproduction. For example, if the content server notified of the completion of reproduction from the audio client notifies the completion of reproduction to all the controllers, the audio client receives a continuous reproduction instruction from a plurality of controllers. This problem is further complicated when there are a plurality of content servers on the network. Therefore, in order to enable continuous playback by the controller in the 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 reproduces a song in accordance with a command from the controller Ak, and transmits a completion status when the reproduction is finished. In other cases, for example, the audio client Cj responds to a user operation. When Cj reproduces a song by itself and ends the reproduction, or when the audio client Cj stops reproduction of a song in response to a user 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, when the controller receives the stop status, it does not instruct the audio client to play the next song. As described above, the audio client transmits the completion status and the stop status separately according to the situation, so that the controller determines whether or not the audio client should be instructed to play the next song based on the received status. Judgment can be made.

  Therefore, when the audio client Cj stops playing a song in response to a user operation or when the audio client Cj selects a song by itself and finishes playing the song, the stop status is transmitted to the content server. , It is possible to prevent the controller from instructing the audio client to play the next song by mistake.

  Further, when there are a plurality of controllers, the content server that has received the completion status from the audio client transmits the completion status and the stop status separately to each controller. That is, referring to FIG. 65, when controller A1 instructs audio client C1 to play back, controller A1 first transmits a playback command for audio client C1 to content server Si. The content server Si receives the reproduction command from the controller A1, and transmits it to the audio client C1. The audio client C1 receives the playback command from the content server Si and starts to play the music.

  66 and 67, when the audio client C1 finishes the reproduction of the music, the completion status is transmitted to the content server (S1901), and the content server Si receives this (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 or not the nth client is a controller that has acquired the monitoring 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 instructs the audio client C1 to play back (S2904).

  In the case of the controller A1 that instructs the audio client C1 to play back, the content server Si transmits 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 instructs the audio client C1 to play back, the content server Si transmits a stop status to the controller A2 instead of the completion status received from the audio client C1 (S2906), and the controller A2 This is received (S3402).

  Referring to FIG. 68, controller A1, which has received the completion status, selects the next song of the previously selected song from the song list, and issues a playback command for causing audio client C1 to play the song. It transmits to Si (S3403). The content server Si receives this and transmits it to the audio client C1. The audio client C1 reproduces the next song in accordance with the reproduction command transmitted 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 stop state, and does not perform the continuous playback process as in the controller A1.

  The audio client Cj sends a playback status to the content server Si when the status becomes playback, sends a pause status to the content server Si when the status is paused, and sends a stop status to the content server Si when playback of the song designated by the audio client Cj is finished. As described above, when the reproduction of the music designated 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 transmits to the controller Ak when the audio client Cj finishes playing the song into the stop status and the completion status, the controller Ak has instructed the playback itself. It can be determined whether or not Cj has finished playing the song. As a result, the controller Ak can determine whether it is necessary to instruct the audio client Cj to perform continuous playback or only the stop status of the audio client Cj needs to be displayed.

  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 when the song is played according to the command from the dedicated remote controller. You may make it distinguish the status notified to the content server Si by the case where it was doing. This is because the dedicated remote controller that has acquired only the control handle cannot receive the status from the content server Si and cannot perform the continuous reproduction process.

1.2.3.3.5. Continuous playback control using the list construction key The controller Ak acquires various song lists from the content server Si, selects songs from them, and causes the audio client Cj to play the songs. Then, the controller Ak monitors the status of the audio client Cj, and when the audio client Cj finishes playing the selected song, the controller Ak selects the next song from the acquired song list, and selects the song as the audio client. Let Cj play. In this way, the controller Ak causes the audio client Cj to continuously reproduce the music. In order to instruct the reproduction of the next music, it is necessary to store the music list. For this reason, the power source of the controller Ak instructing the reproduction of the music cannot be turned off during the reproduction of the music.

  Therefore, the following method is adopted so that the controller Ak can instruct the audio client Cj to perform continuous reproduction even if the controller Ak that instructed the audio client Cj to perform reproduction is turned off halfway.

  When the user selects a song to be reproduced 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 music list can be created uniquely from the content information database. Then, the list construction key is added to the client information as information for specifying the music list being reproduced by the audio client Cj.

  Referring to FIG. 69, the list construction key includes “filter type” and “keyword”. The type of filter designates which category in the content information database is focused on to create the song list, such as shown in FIG. If the filter type is “TITLE =”, “GENRE =”, “ARTIST =”, “ALBUM =”, or “FILENAME =”, the song name, genre name, artist name, album name from the content information database Or search for a song whose file name matches the keyword and create a song list. If the type of filter is “PLAYLIST =”, the music file registered in the playlist whose file name of the playlist matches the keyword is searched from the content information database to create the song list.

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

  A procedure for the controller to perform continuous playback processing for an audio client that has finished playing the music designated by the controller will be described below.

  Referring to FIG. 71, when the audio client Cj instructed to reproduce from the controller Ak finishes the reproduction of the song, the completion status is transmitted to the content server Si. Since the status of the audio client Cj has changed, the content server Si transmits client information including the completion status, the file name of the song being played back, the list construction key, and the like to the controller Ak.

  Upon receiving the client information, the controller Ak starts the client information display process shown in FIG. Since this process has already been described, here, a part relating to continuous reproduction control using a list construction key will be mainly described.

  The controller Ak checks whether there is a change in the list construction key (S3108). If there is a change, the controller Ak uses the list construction key to acquire the list of songs being played by the audio client Cj from the content server Si (S3110). Specifically, the received list construction key is transmitted to the content server, and the content server creates a list based on the list construction key and transmits it to the controller. Even when the power is turned off and the controller Ak does not store the song list being played back by the audio client Cj, the song list being played back is obtained from the content server Si using the list construction key obtained after connecting to the content server. To do.

  Here, since the status is changed to the completion status, the controller Ak performs a completion process (S3119). That is, the controller Ak selects a song next to the song that the audio client Cj has finished playing from the song list, and instructs the audio client Cj to play the selected song.

  Details of the completion process will be described with reference to FIG. The controller Ak increments the reproduction music number n stored in step S3111 in FIG. 56 (S31191), and designates the music to be reproduced next. Subsequently, the controller Ak determines whether or not the reproduction 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 Return 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 or not the nth song is in a format that can be played back by the audio client Cj (S31194). The audio client Cj is instructed to play the nth song in the song list (S31195). If the format is not reproducible, this completion process is recursively performed to reproduce the next song. In short, the controller Ak instructs the audio client Cj to skip a song in a format that the audio client Cj cannot reproduce and to play the next song.

  As described above, if the controller Ak is turned off after the audio client Cj is instructed to reproduce the music, the controller Ak loses the music list when the audio client Cj is instructed to reproduce. 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 the list construction key, the controller Ak can acquire again the music list being reproduced by the client CL based on the list construction key. Therefore, even when the controller Ak instructs the audio client Cj to play a song and the power is turned off, the audio client Cj finishes playing the song, sends a completion status, and sends this completion status. When the controller Ak receives it, the audio client Cj can be instructed to play the next song in accordance with the newly acquired song list.

  In order to stop the reproduction operation of the audio client Cj, the controller Ak may transmit 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. In order to pause 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. Continuous Playback Control with Priorities This embodiment will be described focusing on the content server S1 and the audio client C1. In the present embodiment, a 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 order for controlling the audio client C1 and the controller index assigned to the controllers A1 to Ak are recorded in association with each other.

  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 flowchart shown in FIG.

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

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

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

  The operation when the controller A1 instructs the audio client C1 to continuously reproduce a plurality of songs via the content server S1 will be described below.

  The controller A1 requests the content server S1 for a music list to be continuously reproduced (S30302). Specifically, a list construction key necessary for creating a music list is transmitted to the content server S1.

  When the user selects a song to be reproduced 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 music list from the content server S1 and creating it uniquely. As shown in FIG. 69, the list construction key is composed of two parameters such as a filter type and a keyword.

  The type of filter designates the category of music to be included in the music list, and is specifically as shown in FIG.

  The content server S1 creates a music list based on the list construction key transmitted from the controller A1, and transmits 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 keyword, and create a song list listing the songs. If the type of filter is “PLAYLIST =”, a song registered in a playlist whose playlist file name matches the keyword is searched, and a song list (playlist) listing the songs is created. Further, the content server S1 registers the list construction key in association with the client index (identification information of the audio client C1) as one of the client information of the audio client C1.

  The controller A1 instructs the audio client C1 to play the music specified in accordance with the user operation from the acquired music list via the content server S1 (S30303). The audio client C1 requests the music content of the designated song from the content server S1 in response to the playback command from the controller A1 (S10201). The content server S1 distributes the music content requested from 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 designated song to the end, the audio client C1 transmits a completion status indicating that to the content server S1 (S10203). When the content server S1 receives the completion status from the audio client C1, as shown in FIG. 74, the content server S1 refers to the controller management table 104, transfers the completion status as it is to the highest-order controller A1, and sends it to the lower-order controller A2. A stop status different from the completion status is transmitted (S20104).

  As shown in FIG. 74, the controller A1 instructs the audio client C1 via the content server S1 to continuously play the next music according to the music list (S30304). The audio client C1 reproduces the next song in response to a continuous reproduction command from the controller A1. Thereafter, the audio client C1 repeats the operations after step S201. On the other hand, even if the controller A2 receives the stop status from the content server S1, it does not take any particularly active action, but simply monitors the state 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 order of the lower controller index is sequentially raised. For example, as shown in FIG. 75, when the controller A1 with the highest priority is disconnected from the content server S1, the controller A2 with the next priority is moved up and acquires the authority for continuous playback processing on behalf of the controller A1. To do.

  In the above-described example, the controller A1 first instructs reproduction, and the same controller A1 again instructs continuous reproduction. However, even when the controller A2 first instructs reproduction, the priority order of the controller A1 is As long as it is the highest, the controller A1 commands continuous reproduction. In this case, since the controller A1 does not have a song list even when the completion status is received from the content server S1, the controller A1 uses the list construction key of the audio client C1 registered in the content server S1 to send a song from the content server S1. Get a list and specify the next song accordingly.

  In addition, all the songs included in the song list are not necessarily stored in one content server S1, but may be distributed and stored in a plurality of content servers S1, Si. In this case, after the audio client C1 reproduces the music of the content server S1, it is necessary to continuously reproduce the music of another content server Si. Therefore, the audio client C1 that has finished playing the music of the content server S1 performs a server switching process of once disconnecting from the content server S1 and reconnecting to the content server Si.

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

  When the audio client C1 finishes playing the song, the audio client C1 transmits a completion status to the content server Si. When the content server Si receives the completion status, the content server Si refers to the controller management table in the content server Si, transfers the completion status to the highest-order controller, and transmits the stop status to the lower-order controller.

  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, a certain content server determines the priority order of the controller management table and transfers 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, the controller management table is referred to, and the completion status is transmitted only to the highest-priority controller A1. Since the stop status is transmitted to A2, only the highest priority controller A1 commands continuous playback, and other controllers A2 do not command continuous playback. Accordingly, it is possible to eliminate the contention of the continuous reproduction command and to normally execute the continuous reproduction processing.

  In the above-described embodiment, the priority order is determined in the order of connection with the content server S1, but is not limited thereto, and may be determined in the order in which commands are issued to the audio client C1, for example. Further, there is no need for a plurality of content servers, and at least one content server is sufficient. There is no need for a plurality of audio clients, and at least one audio client is sufficient.

1.2.3.3.7. In the present embodiment, 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. . Similarly to the above embodiment, this embodiment can be applied to a network type audio system including a plurality of controllers A1 to Ak, and it is sufficient that there is at least one content server or audio client.

Unlike the above embodiment, in this 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 indexes of the audio clients C1 to Cj and the controller indexes of the controllers A1 to Ak that obtain 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 handles of the audio clients C2 and Cj are not acquired by any controller.

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

  The controller A1 obtains a control handle necessary for controlling the audio client C1 before instructing the audio client C1 to perform reproduction. 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).

  When the control handle of the 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 the controller corresponding to the client index of the audio client C1 Is recorded. A state in which the control handle has already been acquired in this way is referred to as “the control handle is locked”. On the other hand, when the control handle of the audio client C1 is not yet 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. A state in which the control handle has not yet been acquired in this way is referred to as “the control handle is not locked (unlocked)”. For example, in the control handle management table shown in Table 2, the control handle of the audio client C2 is not locked.

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

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

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

  The controller A1 determines whether or not the status is the completion status from the audio client C1 that has acquired the control handle (S30315). If so, the continuous playback process is executed (S30316). Is simply monitored and the state of the audio client C1 is monitored. In this example, since the controller A1 has acquired the control handle of the audio client C1, the controller A1 executes the continuous reproduction process (S30316), and commands the reproduction of the next song according to the song list (S30314).

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

  The controller A1 determines whether or not the status is the stop status from the audio client C1 that has acquired the control handle (S30317). If so, the control handle of the audio client C1 is released (unlocked) (S30318). , Otherwise ignore the stop status.

  The controller A1 cancels the acquired control handle not only when the stop status is received from the audio client C1 that has acquired the control handle as described above, but also when the controller A1 is disconnected from the content server S1. When the control handle of the audio client C1 is released, any of the controllers A1 to Ak can obtain this control handle.

  Note that when the songs included in the song list are distributed and stored in the plurality of content servers S1, Si, the audio client C1 is the content server S1 as shown in FIG. 77, as in the first embodiment. The connection is switched to another content server Si. Even if the content server Si receives the completion status from the audio client C1, it is unclear which controller A1 to Ak has finished playing the music commanded by the audio client C1. Accordingly, in this case as well, the content server Si transfers the completion status to all the controllers A1 to Ak. However, 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 acquires the control handle of the audio client C1, only this controller A1 executes the continuous reproduction process.

  As described above, according to the present embodiment, since each of the controllers A1 to Ak has the control handle management table, the content server S1 displays the completion status transmitted from the audio client C1 by all the controllers A1 to Ak. However, each of the controllers A1 to Ak executes the continuous reproduction process only when receiving the completion status from the audio client that has acquired the control handle. Accordingly, it is possible to eliminate the contention of the continuous reproduction command and to normally execute the continuous reproduction processing.

  In this 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.

  Further, instead of locking the control handle, the controller that last commanded may acquire the control handle. That is, when a controller A1 obtains a control handle of a client C1 and another controller A2 commands the client C1 to play, the controller A2 obtains the control handle, and the controller A1 loses the control handle. You may do it.

1.2.3.3.8. Continuous Playback Control by Content Server First, a simple example including one content server, one audio client, and one controller will be described with reference to FIG.

  Similar to the above-described embodiment, the controller A1 instructs the audio client C1 to reproduce the music via the content server S1. In response to this command, the audio client C1 requests the music content of the song from the content server S1, and the content server S1 distributes the music content to the audio client C1 in response to this request. The audio client C1 starts playing a song based on the distributed music content, and transmits 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, and transmits a stop status to the controller A1.

  The details will be described below with reference to the flowchart shown in FIG. In the present embodiment, 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, S20123-S21125 in FIG. 79 are different from the embodiment shown in FIG. 73, these will be mainly described here.

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

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

  The content server S1 distributes the music content of the designated song to the audio client C1 as in the above embodiment, but unlike the above embodiment, the content server S1 generates a song list 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 music list that the audio client C1 is playing in response to a command from the controller A1.

  The content server S1 that has received the completion status from the audio client C1 after the music reproduction ends, transmits a 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 in accordance with 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, continuous playback commands from the controller do not compete and normal playback processing can be executed normally.

  The above example has only one audio client, but there may be more than one. For example, in the example shown in FIG. 80, audio clients C1 and C2 are connected to the content server S1. Similar to step S123, the content server S1 stores a list construction key and a song list being reproduced 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 perform continuous reproduction according to the stored music list of the audio client C1, and transmits a 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 perform continuous reproduction according to the stored music list of the audio client C2, and transmits a stop status to the controller A1. As described above, since the content server S1 distinguishes the audio clients C1 and C2 and commands continuous playback, the continuous playback commands do not conflict.

  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. Also in this case, since there is one content server connected to each client, the audio client transmits a completion status only to the connected content server. Similarly to the above, when receiving the completion status from the audio client C1, the content server S1 instructs the audio client C1 to perform continuous reproduction, and when receiving the completion status from the audio client C2, instructs the audio client C2 to perform continuous reproduction. Furthermore, 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 perform continuous reproduction. Accordingly, in this case as well, the content server that commands the audio client to perform continuous playback is the only one on the network, so there is no contention for continuous playback commands.

  In the case shown in FIG. 81, when the controller A1 instructs the audio client C2 to play back the music stored in the content server S2, the audio client C2 receives the content server as shown in FIG. The connection with S1 is once released, and the connection with the content server S2 is made again. At this time, the content server S2 creates a music list based on the list construction key transmitted from the audio client C2, and stores the list construction key and the music list as client information of the audio client C2. When the audio client C2 finishes reproducing the music distributed from the content server S2, the audio client C2 transmits a completion status to the content server S2. In response to this completion status, the content server S2 instructs the audio client C2 to perform continuous playback, and transmits a stop status to the controller A1. Accordingly, in this case as well, the content server that commands the audio client to perform continuous playback is the only one on the network, so there is no contention for continuous playback commands.

  In addition to the audio client and the 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, the content server S1 transmits a 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, the content server S2 transmits a stop status not only to the controller A1 but also to the controller A2. As described above, the controllers A1 and A2 do not have a function of instructing continuous reproduction, but merely have a function of monitoring the states of the audio clients C1 to C3, and thus do not affect the continuous reproduction process.

1.2.3.3.9. Continuous playback control by the audio client itself In this embodiment, 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 embodiment shown in FIG. 79, these will be mainly described here.

  As in the embodiment shown in FIG. 79, the controller A1 instructs the audio client C1 to play the designated song, and transmits a list construction key to the audio client C1 (S30323). The audio client C1 is designated. Requested to the content server S1, and in response to this request, reproduction of the music distributed from the content server S1 is started (S10202). At this time, the audio client C1 stores the list construction key transmitted from the controller A1.

  Subsequently, the audio client C1 transmits the stored list construction key to the content server S1, and requests the content server S1 for the same music list as the music list used for music selection by the controller A1 (S10233). The content server S1 creates a music list based on the received list construction key and transmits 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 music to the end, the audio client C1 plays the next music according to the stored music list (S10235).

  When songs included in the song list are distributed and accumulated in a plurality of content servers, the audio client C1 performs server switching processing 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, it can execute the continuous reproduction process itself. Therefore, the audio client C1 does not receive a continuous playback command from the controller A1 or the content server S1, and the continuous playback command does not compete.

  In the present embodiment, the audio client C1 acquires the song list using the list construction key while the song is being played back, but may be after the song has been played back. Further, although the audio client C1 stores the acquired song list, the audio client C1 may acquire the song list by using the list construction key every time continuous playback processing is performed without storing it.

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

The content server S1 in the present embodiment stores a playback command management table in which client indexes and controller indexes are associated with each other. An example of this table is shown in Table 3 below. In the playback command management table shown in Table 3, the controller index of the latest controller A1 that commands the audio client C1 to play back is recorded. In addition, the controller index of the latest controller A2 instructing the audio client C2 to reproduce is recorded.

  Next, the operation of this embodiment will be described with reference to the flowchart shown in FIG.

  A certain controller instructs a certain audio client to reproduce the music stored in a certain content server (S30341).

  First, as shown in FIG. 86, a case will be described in which the controller A1 instructs the audio client C1 to play the music stored in the content server S1 via the content server S1. In this example, audio clients C1 and C2 and 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, since the audio client C1 is connected to the content server S1, the process proceeds to step S30314.

  The controller A1 instructs the audio client C1 to play the music designated from the music list via the content server S1 (S30314). The content server S1 executes a reproduction command management process determined in advance according to the reproduction command (S20141).

  Specifically, with reference 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 reproduction command management table (S201441). Thus, the content server S1 stores that the controller A1 is the controller that last instructed the audio client C1 to play back. The content server S1 transfers the playback command from the controller A1 to the audio client C1 (S201412).

  The audio client C1 starts playback of the music in response to the playback command from the controller A1 (S10211), and when the playback ends, transmits a completion status to the content server S1 (S10212).

  When the content server S1 receives the completion status from the audio client C1, the content server S1 refers to the reproduction command management table to identify the controller A1 that last instructed the audio client C1 to reproduce, and transmits the completion status to the controller A1. The stop status is transmitted to the controllers A2 and A3 (S201413). The controller A1 that has received the completion status executes a continuous reproduction process on the audio client C1 (S30316). On the other hand, the controllers A2 and A3 receiving the stop status do not take any active action and simply monitor the state of the audio client C1.

Further, when the audio client C1 is reproducing a song in accordance with a command from the controller A1, if another controller A2 commands the same audio client C1 to reproduce another song, the audio client C1 reproduces the current song. Stop and start playing a new song according to the command from the controller A2. At this time, the content server S1 updates the reproduction command 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.

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

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

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

Subsequently, the controller A3 instructs the audio client C1 to reproduce the music via the content server S2 (S30314). In response to this playback command, the content server S2 records the controller index of the controller A3 in association with the client index of the audio client C1 in the playback command management table as shown in Table 5 below (S201441).

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

  The audio client C1 starts playback of the music in response to the playback command from the controller A3 (S10211). When the playback ends, the audio client C1 transmits a completion status to the content server S2 (S10212). When the content server S2 receives the completion status from the audio client C1, the content server S2 refers to the playback command management table to identify the controller A3 that last commanded the audio client C1 to play, and sends the completion status to the controller A3. The stop status is transmitted to the controllers A1 and A2 (S1413). Receiving the completion status, the controller A3 executes continuous playback processing on the audio client C1 (S30316). On the other hand, the controllers A1 and A2 receiving the stop status do not take any active action, but simply monitor the state of the audio client C1.

  As described above, according to the present embodiment, the content server manages the controller that last instructed the audio client to play, and transfers the completion status from the audio client only to that controller. Instructs the audio client to play continuously. Therefore, the continuous reproduction command does not compete 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 the LAN 12. 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 by USB. The AV receiver AVR3 is connected to the AVR client AC2 through a manufacturer-specific serial interface.

  Each of the AVR clients AC1 and AC2 may notify the content server Si of information related to an interface such as EIA-232 or 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 a vendor ID and a product ID of the AV receiver AVR2 when the AV receiver AVR2 is connected, and notifies the content server Si of it. In the case of EIA-232, since it is usually difficult for the AVR client AC1 to acquire the model information of the AV receiver AVR1, the vendor ID and product ID of the AV receiver AVR1 to be connected are registered in the AVR client AC1 in advance. The AVR client AC1 notifies the content server Si of it.

  If there are a plurality of AV receivers that may be connected, a communication protocol with the AVR client may be determined so that the AVR client acquires model information of the AV receiver. For example, the AVR client transmits a packet for inquiring model information every certain time (for example, 1 second) under a certain communication condition (bit rate, bit length, parity, etc.), and the AV receiver responds to the packet including the model information. Should be replied. As a result, the AVR client can specify the connected AV receiver. In such a case 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. Therefore, when the model information of the AV receiver is acquired, the model information is acquired. Is notified to the content server Si.

  As a result, the content server Si can acquire the model information of all AV receivers AVR1 to AVR3 connected to or scheduled to 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 sound field control DSP. The controller Ak designates such a controlled element and issues a control command. For this reason, the controller has model information indicating what controlled elements the AV receiver AVR has.

  Since the model information is held by the content server Si, 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 is transmitted to the AV receiver AVR via the content server Si and the AVR client AC. Conversely, the status is output from the AV receiver AVR and is 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, the AVR client AC 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.

  Referring to FIG. 92, controller Ak transmits a control command to content server Si (S35), content server Si transmits this to designated AVR client AC (S28), and the AVR client further transmits it to AV receiver. It transmits to AVR (S101). The AVR client AC receives the status from the AV receiver AVR and transmits it to the content server Si (S102). The content server transmits the SV to the controller Ak (S29), and the controller Ak responds to the AV receiver AVR. The status is updated (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 send a control command through a path shaped like a tree rooted in the content server Si. introduce.

  Referring to FIG. 94, 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 transmits a control command with destination information added to the command body to the content server Si (S3503). The destination information here includes an AV receiver designating unit that designates the AV receiver AVR to be controlled, and an AVR client designating unit that designates the AVR client AC connected to the AV receiver AVR.

  The content server Si receives this control command and, as shown in FIG. 95B, extracts the AVR client designation unit from the received control command (S2801). The content server Si determines the AVR client AC specified based on the AVR client specifying unit. Subsequently, the content server Si transmits a control command from which the AVR client designation unit is removed to the designated AVR client AC (S2802).

  The AVR client AC receives this control command, and extracts an AV receiver designation section from the received control command as shown in FIG. 95C (S1011). The AVR client AC determines the designated AV receiver based on the AV receiver designation unit. Subsequently, the AVR client AC transmits a control command including only the command body to the designated AV receiver (S2802).

  In this way, network traffic can be reduced by transferring unnecessary control parts in order and transferring control commands. However, the control command may be transferred as it is without removing the designation portion.

  At each stage, the character strings in the command body do not have to be exactly the same, but only need to have the same meaning. 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 has received the control command in this manner 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. As shown in FIG. 96A, this status consists only of the status main body.

  The AVR client AC receives and stores the status of the AV receiver AVR (S1021), adds sender information to the received status, and transmits it to the content server Si as shown in FIG. 96B (S1022). . Here, the transmission source information includes an AV receiver designating unit that designates the AV receiver AVR that has transmitted the status.

  The content server Si receives the status from the AVR client AC, and further adds an AVR client designation unit to the received status as shown in FIG. 96C, and transmits it to the controller Ak (S2901).

  The controller Ak receives the status from the content server Si, extracts the AVR client designation unit and the AV receiver designation unit 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, level information of an audio signal). Such a status is also transmitted to the controller Ak via the AVR client AC and the content server Si. 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 transmits it to the content server Si.

  Thus, 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.

  Note that the status of display status that may change frequently may be appropriately reduced by the AV receiver AVR or the AVR client AC. This is because even if the frequently changing status is displayed as it is, it is difficult to recognize it, and if the transmission frequency is high, unnecessary traffic occurs on the network and the load on the content server also increases.

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

  In this system, the content server Si can have a number of coefficient data setting patterns, one of which can be selected from the hierarchical menu displayed on the controller Ak, and the coefficient data can be set via the AVR client AC. .

  In addition, since a plurality of AV receivers AVR 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 simultaneously. Furthermore, by monitoring the status of these AV receivers AVR, cooperative operations such as relay recording can be performed.

  Next, a case where the volume of the AV receiver AVR connected to the AVR client AC is raised will be described.

  Referring to FIG. 97, controller Ak confirms the connection of the client (S3011), and if there is a connection, determines whether or not the client is an AVR client AC (S3014). Is transmitted to the content server Si (S35). The content server Si transmits this to the AVR client AC (S28), and the AVR client AC transmits this to the AV receiver AVR (S101). The AVR client AC receives the status indicating that the volume has been increased from the AV receiver AVR and transmits it to the content server Si (S102). The content server Si transmits this to the controller Ak (S29), and the controller Ak updates the status of the AV receiver AVR accordingly and restarts the monitor shown in FIG. 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.

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

  Subsequently, if the received data is volume information, the AVR client AC stores the volume value (S1023). The determination of whether or not it is volume information (S1022) and the storage of 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 designating unit indicating the status from the AV receiver AVR to the received packet data and transmits it to the content server Si (S1024). ).

  After the volume value is stored, it is determined whether or not volume information is received for the first time (S1025). If it is the first time, the process proceeds to step S1028. If it is not the first time, the AVR client AC determines whether 200 milliseconds or more have elapsed since the volume value was transmitted to the content server (S1026). If 200 milliseconds or more have elapsed, the AVR client AC compares the previously transmitted volume value with the stored volume value (S1027), and if different, specifies an AV receiver indicating that the status is from the AV receiver AVR. The part is added to the volume information and transmitted to the content server Si (S1028).

  Since the status of the volume value may come at a shorter interval than other statuses, it may be a burden on the content server Si and the controller Ak, and may cause unnecessary increase in traffic on 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 hinder display. Therefore, when volume information is received, only that value is stored, and only when there is a change, it is transmitted to the content server Si with an appropriate interval (200 milliseconds here).

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

  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 or not the control command is a volume value inquiry 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), indicating that the status is from the AV receiver AVR. The AV receiver designation part is added to the volume information and transmitted 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 transmitted to the AV receiver AVR (S1036). When the interface between the AVR client AC and the AV receiver AVR is EIA-232, 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 periodic interrupt or a serial transmission buffer empty interrupt, and is sent in byte units.

  In the above embodiment, the volume information is transmitted 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 if there is no change in the volume value. 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 premised on that whenever the AV receiver AVR is powered on, the AV receiver AVR transmits the initial value of the volume as a status to the AVR client AC. However, depending on the power-on timing, the AVR client AC may not 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 a volume value inquiry command, the AVR client AC determines whether or not the volume value has yet been received (S1034). If it has not been received, the process proceeds to step S1036. If it has already been received, the process proceeds to step S1034.

  When there are a plurality of 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 the AV receiver. A general-purpose control command may be issued regardless of the type, and the content server may convert the 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 will be described later. Here, there are a case where the client requests an update from the content server, a case where the content server makes an inquiry after making an inquiry to the client, and a case where the content server updates forcibly.

  First, an outline when the client requests an update from the content server will be described. Referring to FIG. 101, the client requests firmware information from the content server (S103), and the content server returns the firmware information to the client accordingly (S201), and the client receives this (S103). Subsequently, the client designates firmware (S104), and the content server prepares transfer of designated firmware accordingly (S202). Subsequently, the client requests firmware from the content server (S105), and the content server transfers the firmware to the client accordingly (S203), and the client receives this (S105). Subsequently, the client updates the firmware (S106). When the update is completed, the client transmits an end status to the content server (S107), and the content server receives this (S204).

  Next, details of the firmware update will be described with reference to FIG. When the update is started from the content server, the process starts from step S2012. When the update is 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 a file necessary for update for each client and creates an update information file. Therefore, it is possible to determine whether the client firmware is new or old based on this information file. The client transmits the product ID and firmware ID to the content server at startup (S1031).

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

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

  When accepting the update request or starting the update from the client, the client requests the 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 a firmware list in response to a request from the client. The method for creating the firmware list is basically the same as the method for 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 firmware. Hereinafter, a method for creating a firmware list will be described in detail.

  Referring to FIG. 103, first, the content server initializes an index indicating the number of 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 they 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).

  Subsequently, the content server determines whether or not the number of firmware information indicated by the index is smaller than the number n of all firmware information (S20135). If it is smaller, the process returns to step S20132, while if not smaller, the firmware list Complete the creation.

  Through the above processing, the content server picks up firmware information having a matching product ID from the firmware information database, and creates a firmware list. As described above, the firmware list is not stored in a database in advance, but is temporarily created for each request from the client. Therefore, a memory area for always storing the firmware list is unnecessary.

  Subsequently, the content server returns the created firmware list to the requesting client (S2013). This firmware list is also divided and sent from the content server to the client in the same manner as the music list.

  Specifically, referring to FIG. 104, the client sets 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. The firmware list request command including it is transmitted to the content server (S1033). In response to this firmware list request command, the content server extracts firmware information having the same product ID as the client product ID, and returns the firmware information as many as the number of acquisitions from the firmware information indicated by the acquisition start index to the client. (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 from the content server to the client. The client receives a part of the firmware list and stores it in the memory (S10331). The above process is repeated until the entire firmware list is sent from the content server to the client.

  Subsequently, the client continues the process if there is firmware (such as a new version) that the user wants to download in the returned firmware list, and stops the process if there is no firmware (S1034).

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

  When updating, the client notifies the content server of the status indicating that the client has moved to the update section (S1035). In response to this status, the content server returns an error code indicating the presence or absence of an error (S2014). The client designates the firmware file to be downloaded (S1036). Specifically, the full path name stored in the acquired firmware information list is designated. The content server reads the designated file and stores it in the buffer (S2015).

  Subsequently, the client designates an acquisition start address and a data size (number of bytes), and acquires firmware data (S1037). The content server reads data from the buffer by the designated number of bytes from the designated acquisition start address, and transmits 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 data acquisition. When the acquisition is completed, the client rewrites the firmware (S1039) and ends the update (S1040). The content server closes the opened firmware file and releases the buffer (S2017).

  Further, when the client completes rewriting of the firmware, an unknown status is transmitted to the content server. The client interrupts the connection with the content server, resets (that is, starts up the updated firmware), and notifies the content server of the client information. Further, when the client fails to acquire firmware data, a failure status may be transmitted. The failure status can be used for retransmitting firmware data.

  When an update request is made from the content server, the following processing can be performed. That is, in FIG. 102, the content server always presents firmware information to the client when an update request is made (S2012). When updating the firmware recommended by the content server, the process proceeds to S1035, and when the user selects desired firmware from the firmware list, the process proceeds to S1033 instead of updating the firmware recommended by the content server. You can also.

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

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

  The 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 for monitoring and controlling the audio client. By using a controller connected to the same LAN 12 as the audio client, the display and switches can be removed from the audio client. Further, instead of using the controller, a portable remote controller connected to the same LAN 12 as the audio client by wireless may be used.

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

  With the spread of the Internet, especially the broadband (high-speed, large-capacity) infrastructure, it is expected that the demand for connecting to the Internet from multiple personal computers will increase. The most common method for connecting a plurality of personal computers to the Internet at home is to build a LAN in the home, and the increase in the number of households equipped with such a home LAN is a problem of time. If this LAN is used, the above-mentioned music and video can be distributed to various places in the house with a single cable. Further, since a single cable can transmit a control signal in addition to a music / video signal, installation of this system does not require specialized knowledge about audio / video. Furthermore, since it is extremely advantageous in terms of cost, it can be spread not only for business use but also for home use.

  In general homes, the number of cases in which a home LAN is laid in consideration of the convenience of Internet connection at the time of new construction or renovation is increasing. At this time, it is very common to provide a LAN connector in the outlet box 50. Therefore, a plurality of audio clients can be easily installed simultaneously with 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 on the interior. In addition, from the viewpoint of product development, the product itself does not require a gorgeous design, and the product development cost is reduced by an extremely simple design method that emphasizes functions. In addition, since the structure is simple, it is also beneficial in terms of ease of recycling.

  Unlike conventional audio / video devices, distribution via a home LAN does not require content media such as CDs and tapes. That is, once the content is stored in the content server, 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, it is possible to reduce the size of the device, and to achieve a product with a longer life with higher reliability.

2.2. Acquiring 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 the LAN 12 are turned off, there is no response from the content server, so the audio client continues to search for the content server forever. In order to prevent this, the audio client may perform processing such as a time-out error, but in the case of a time-out error, the audio client cannot perform any operation such as playing music.

  In order to solve these problems, if an audio client cannot find a content server even after repeating broadcasting a predetermined number of times, it is only necessary to access a WWW server on the Internet and connect to this server. .

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

  As shown in FIG. 108, when the server list is empty, the audio client determines whether the number of retries has reached a predetermined number of times, for example, three times before returning to step S1102 and retrying 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 by HTTP (S1111). If the audio client succeeds in the connection, the search is completed (S1112), but if the connection is not successful and a timeout occurs, an error occurs (S1113).

  When the audio client accesses the WWW server 52, it receives and analyzes the music information and URL from there, and receives music data from the music distribution site 56 of the URL.

  As described above, when the content server does not exist on the LAN 12 or does not operate even if it exists, the audio client automatically accesses the site 56 on the Internet 52 and acquires the music data. The above content server is never searched forever.

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

2.3. Playback with Acquisition Data Length Change Function In the above embodiment, when the audio client Cj requests the content server Si to transfer song data, it always requests a certain amount of song data. Therefore, there is no problem when the number of audio clients Cj requesting transfer of music data to the content server Si is small. However, when this number increases, the load on the content server Si increases, and the audio client Cj sends to the content server Si. There arises a problem that it takes a long time until the music data is actually transferred after the music data is requested to be transferred. Therefore, the amount of music data requested by the audio client Cj at a time may be changed each time so that the load on the content server Si is equalized.
Hereinafter, the amount of song data requested at one time by the audio client Cj 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.

  Referring to FIG. 109, audio client Cj transmits a song data transfer command for requesting transfer of song data to content server Si (S1601), and at the same time, operates a timer to transfer song data from content server Si. The response time until the start of counting is started (S16011). Note that when the audio client Cj first issues a song data transfer command, the appropriate amount of song data to be requested at one time is unknown, so the acquired data length is predetermined.

  Subsequently, when the audio client Cj starts to receive the song data (S16012), the audio client Cj stops the timer and acquires the response time of the song data by the content server Si (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 is associated with a predetermined acquired data length. Here, since the load applied to the content server Si is larger 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 transmits the acquired data length determined above (S1605). Thereafter, the same operation as described above is repeated (S16051 to S16061).

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

  In the above example, the acquisition data length is determined according to the response time of the content server, but instead, the acquisition data length may be determined according to the data format of the song to be acquired. . That is, in FIG. 35, the song audio format 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. In general, MP3 format data is compressed and thus has a small size, whereas WAV format data has a large size. Therefore, when the data format of the song to be acquired is MP3, for example, 4 Kbytes of data is acquired at a time, and in the case of WAV, for example, 16 Kbytes of data is acquired at a time. Good.

2.4. Skip playback In the above embodiment, the audio client Cj requests the content server Si to transfer music data in accordance with the order of the music list. However, there is a case where the user wants to listen to the music currently being reproduced from the beginning. In some cases, the user may want to skip the currently playing song and listen to other songs. Therefore, the audio client Cj may make a music data transfer request in response to such a user request.

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

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

  Subsequent operations of the audio client Cj and the content server Si are the same as those in FIG. 35, and thus description thereof will not be repeated.

  With the above operation, the audio client Cj can perform skip playback to the song 4 while the song 3 is being played.

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

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

2.5. Repeat playback Further, it is possible to perform A-B repeat playback in which data is repeatedly played between a first address and a second address designated by the user. First, the user performs a first AB repeat operation and designates a first address indicating the start of repetition. That is, referring to FIG. 113, the audio client receives a song data transfer request (and obtains song data) (S1601), there is an operation from the user (S1642), and the operation from the user is A−. Since it is a repeat request between B (S1643) and the first request (S1644), the address designated by the user is stored as the first address (addr1). Then, the acquisition data length (size) is added to the previous acquisition start address (addr) to calculate the acquisition start address (addr) (S1646), and the process returns to S1601.

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

  Then, the audio client enters an A-B repeat mode (S1648). That is, the acquisition start address is changed to the first address (S1649), and a music piece data transfer request (and music piece data acquisition) is performed (S1601). Here, the audio client determines that the state is a repeat state between A and B (S1650), and determines whether or not the acquisition start address (= previous acquisition start address + acquired data length) is greater than the second address. (S1651). If the acquisition start address is still below the second address, the music data transfer request is continued (S1646 and S1601). If the acquisition start address is larger than the second address in S1651, the acquisition start address is changed to the first address again (S1652), and a music piece data transfer request is made (S1601). Therefore, repeat reproduction can be performed between the first address and the second address. Further, the user can cancel the repeat state by performing a repeat cancel operation (S1643, S1653, and S1654).

2.6. In-progress playback Further, when the user specifies an acquisition start address (for example, by inputting a start time), the music from the specified address can be played back. That is, referring to FIG. 114, for example, when a song data transfer request (and song data acquisition) is made (S1601), there is an operation from the user (S1656), and an address is designated (S1657). ) The audio client acquires an address designated by the user (S1658). For example, the address is calculated from the total playback time of the music and the start time input by the user. Then, the acquisition start address is changed to an address designated by the user (S1659), and a music data transfer request (and music data acquisition) is performed (S1601). Therefore, it is possible to reproduce the music from the address designated by the user. Furthermore, the user can specify an address not only when the audio client is in a playback state, but also when the user is in a stop state or a pause 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. When disconnected from the content server, the audio client cannot play music unless reconnected to the content server. In the case of a normal audio client having an input device, it is only necessary to cause the audio client to execute connection processing with the content server again as shown in FIG. 5 by operating the input device. However, since the above-described outlet-equipped audio client does not include an input device, it is left as it is once disconnected from the content server. Therefore, it is desirable that the audio client has the following automatic connection recovery function.

  Referring to FIG. 115, audio client Cj determines whether or not a predetermined period has elapsed since connection with content server Si (S110). After 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 transmits a connection confirmation command to the content server Si (S111). If there is a response to the connection confirmation command from the content server Si to the audio client Cj (S112), it is determined that the connection is maintained. On the other hand, when there is no response or when a transmission error occurs (S112), it is determined that the connection is disconnected. As a response method, for example, there is a method of returning the same command as the connection confirmation command transmitted from the content server Si.

  If there is a response in step S112, the audio client Cj returns to S110 again and determines whether or not the connection is maintained after a predetermined period of time (S110 to S112). Thereby, the audio client Cj checks the connection state with the content server Si every predetermined period. If the connection is disconnected, the audio client Cj tries to reconnect to the same content server Si (S12).

  As a result of the reconnection, if the connection with the content server Si is successful (S113), the audio client Cj transmits the client status immediately before disconnection to the content server Si (S13). The client status includes, for example, playback states such as “play”, “stop”, “pause”, volume information, list construction key, and the like. Therefore, the audio client Cj can recover the connection state with the content server Si as it was. As a result, the user can use the audio client Cj without being aware that the audio client Cj is reconnected to the content server Si.

  On the other hand, if the connection with the content server Si fails as a result of the reconnection attempt (S113), the audio client Cj gives up the connection recovery with the same content server Si and executes the connection process with another content server Si. (S11 to S13). Specifically, the audio client Cj searches for a connectable content server Si by broadcasting (S11), and connects to the searched content server Si (S12). After the connection, the audio client Cj transmits the client status immediately before disconnection to the content server Si (S13).

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

  With the above operation, the connection state is confirmed every predetermined period from the audio client Cj, and if disconnected, the audio client Cj itself performs reconnection. Therefore, even if the connection is disconnected due to an abnormality of the content server Si, the audio client Cj is not left disconnected from the content server Si. Further, even when the connected content server Si cannot be reconnected due to an abnormality of the connected content server Si, 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.

  Also, since the audio client Cj transmits 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 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 is disconnected from the content server Si.

  In this embodiment, the audio client Cj has an automatic connection recovery function, but the controller Ak may have an automatic connection recovery function. Further, it is preferable that a passive client having only a music playback function has an automatic connection recovery function rather than an active client having both a music playback function and a control function. Since the passive audio client Cj that does not have the control function does not send a command to the content server Si itself, once it is disconnected from the content server Si, the passive audio client Cj is left as it is, and the user does not receive the audio client. This is because the connection with the content server Si cannot be recovered unless Cj is restarted.

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

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

1 is a functional block diagram showing an overall configuration of a network type audio system according to an embodiment of the present invention. It is a functional block diagram which shows the structure of each server in FIG. It is a functional block diagram which shows the structure of each audio client in FIG. It is a functional block diagram which shows the structure of each controller in FIG. It is a flowchart which shows the operation | movement in the initial connection phase of the server and audio client shown in FIGS. It is a flowchart which shows the server search operation | movement by the audio client in FIG. It is a flowchart which shows the connection operation | movement by the client and server in FIG. It is a figure which shows the push operation | movement by the server which finished the connection operation | movement shown in FIG. FIG. 9 is a diagram illustrating a server request operation to the audio client from the controller to the server, following FIG. FIG. 10 is a diagram illustrating an operation for notifying the controller of the status from the audio client through the server following FIG. It is a flowchart which shows the client information transmission operation | movement by the audio client in FIG. FIG. 3 is a flowchart showing an initial setting operation and a main operation by the server shown in FIGS. 1 and 2. It is a figure which shows the client information database preserve | saved at the server shown in FIG. It is a figure which shows the content information database preserve | saved at the server shown in FIG. It is a figure which shows the firmware information database preserve | saved at the server shown in FIG. It is a flowchart which shows the subroutine of the response with respect to the server search in FIG. It is a flowchart which shows the subroutine of the command port connection reception process in FIG. It is a flowchart which shows the subroutine of the push port connection reception process (the 1) in FIG. It is a flowchart which shows the subroutine of the push port connection reception process (the 2) in FIG. FIG. 16 is a flowchart showing a subroutine of command processing in FIG. 15. FIG. 21 is a flowchart showing a subroutine of status notification command processing in FIG. 20. FIG. 21 is a flowchart showing a subroutine of server request issue command processing in FIG. 20. It is a flowchart which shows the music list acquisition and reproduction | regeneration operation | movement by the server and audio client shown in FIGS. It is a flowchart which shows the music list acquisition operation | movement by the audio client in FIG. It is a flowchart which shows the genre list and music list acquisition operation | movement in FIG. It is a figure which shows the area | region which stored the genre list | wrist acquired in FIG. It is a figure which shows the record structure of the content information database shown in FIG. It is a flowchart which shows the genre list creation operation | movement by the server in FIG. It is a figure which shows the area | region which stored the music list acquired in FIG. It is a flowchart which shows the music list creation operation | movement by the server in FIG. It is a figure which shows the format of the list request command in FIG. It is a figure which shows the format of the search data in FIG. It is a figure which shows the transition state of the buffer memory in the music list acquisition operation | movement in FIG. FIG. 26 is a flowchart showing an album list acquisition operation in addition to the genre list and song list acquisition operation shown in FIG. 25. It is a flowchart which shows the music designation | designated by the audio client in FIG. 23, reproduction | regeneration and stop, and the operation | movement of music distribution preparation and distribution by a server. FIG. 36 is a flowchart following on from FIG. 35. It is a figure which shows the music information request command in FIG. It is a figure which shows the music information in FIG. It is a figure which shows the music reproduction preparation command in FIG. It is a figure which shows the error code in FIG. It is a figure which shows the music data transfer request command in FIG. It is a figure which shows the music data in FIG. It is a figure which shows the structure of the buffer memory for storing the music data shown in FIG. FIG. 44 is a diagram showing a state where music data for one buffer is stored from the beginning of the music in the buffer memory shown in FIG. 43. FIG. 45 is a diagram illustrating a state in which music data for all buffers is stored following FIG. 44. FIG. 46 is a diagram illustrating a state in which music data is output from the head buffer, following FIG. 45. FIG. 47 is a diagram illustrating a state in which one buffer has been left following FIG. FIG. 48 is a diagram illustrating a state in which a buffer is full following FIG. It is a flowchart which shows the fast-forward reproduction | regeneration operation | movement by the client and server shown in FIGS. It is a flowchart which shows the temporary stop operation | movement by the client and server shown in FIGS. It is a flowchart which shows the connection operation | movement with the server by the controller in FIG. FIG. 52 is a flowchart showing a monitoring handle and control handle acquisition operation in FIG. 51. It is a figure which shows the status notification from the some audio client by a server to several controllers. In FIG. 54, it is a figure which shows status notification when a controller acquires a monitoring handle. It is a flowchart which shows the monitoring operation | movement of the audio client by the controller in FIG. FIG. 56 is a flowchart showing details of a monitoring operation shown in FIG. 55. It is a flowchart which shows the control operation of the audio client by the controller in FIG. FIG. 58 is a flowchart showing a subroutine of control command processing operation by the audio client in FIG. 57. FIG. 59 is a diagram showing a subroutine of playback control operation in FIG. 58. It is a figure which shows the detail of the client type contained in the client information database shown in FIG. FIG. 60 is a flowchart showing a song list display processing operation in the reproduction control shown in FIG. 59. FIG. 62 is a diagram showing a song list display screen related to an audio client capable of reproducing both MP3 and WAV in the song list display in FIG. 61. In the song list display in FIG. 61, the MP3 can be played back, but the WAV cannot be played back. FIG. 60 is a flowchart showing a playback command processing operation from a user in the playback control shown in FIG. 59. It is a figure which shows transmission of the reproduction | regeneration command in the continuous reproduction | regeneration control by the controller in FIG. FIG. 66 is a diagram illustrating transmission of completion and stop status following FIG. 65. FIG. 67 is a flowchart showing a transmission operation of completion and stop status shown in FIG. 66. FIG. 67 is a diagram illustrating transmission of a playback command following FIG. 66. FIG. 69 is a diagram showing a configuration of a list construction key used in the continuous reproduction control shown in FIGS. 65 to 68. FIG. 70 is a diagram showing the types of filters included in the list construction key shown in FIG. 69. FIG. 70 is a sequence diagram showing a continuous playback control operation using the list construction key shown in FIG. 69. FIG. 72 is a flowchart showing a completion processing operation by the controller shown in FIGS. 56 and 71. It is a flowchart which shows the operation | movement of the continuous reproduction | regeneration processing which gave the priority. FIG. 74 is a functional block diagram showing the continuous reproduction process shown in FIG. 73. FIG. 74 is a functional block diagram showing continuous playback processing when the controller with the highest priority is disconnected in the continuous playback processing shown in FIG. 73. It is a flowchart which shows the operation | movement of the continuous reproduction | regeneration processing using a control handle. FIG. 77 is a functional block diagram showing the continuous reproduction process shown in FIG. 76. It is a functional block diagram which shows the continuous reproduction process by a content server. FIG. 79 is a flowchart showing an operation of the continuous reproduction process shown in FIG. 78. 79 is a functional block diagram showing continuous playback processing when there are a plurality of audio clients in the continuous playback processing shown in FIG. 78. FIG. FIG. 81 is a functional block diagram showing continuous playback processing when there are a plurality of content servers in the continuous playback processing shown in FIG. 80. FIG. 82 is a functional block diagram showing continuous playback processing when a content server is switched in the continuous playback processing shown in FIG. 81. FIG. 82 is a functional block diagram showing continuous playback processing when there are a plurality of controllers in the continuous playback processing shown in FIG. 81. It is a flowchart which shows the operation | movement of the continuous reproduction process by the audio client itself. It is a flowchart which shows the operation | movement of the continuous reproduction | regeneration processing using a reproduction | regeneration command management table. FIG. 86 is a functional block diagram showing the continuous reproduction process shown in FIG. 85. FIG. 88 is a flowchart showing details of a reproduction command management process in FIG. 85. FIG. 86 is a functional block diagram showing continuous playback processing when a content server is switched in the continuous playback processing shown in FIG. 85. It is a flowchart which shows the detail of the server switching process in FIG. It is a functional block diagram which shows the structure of the network type audio system containing a server, a controller, an AVR client, and an AV receiver. FIG. 91 is a functional block diagram showing a flow of status and commands in the network type audio system shown in FIG. 90. FIG. 92 is a flowchart showing an AV receiver control operation by a controller in the network type audio system shown in FIGS. 90 and 91. FIG. 91 is a functional block diagram showing a control command and status transmission path in the network type audio system shown in FIG. 90. FIG. 94 is a flowchart showing a command and status transmission operation shown in FIG. 93. FIG. 95 is a diagram showing control commands at each stage shown in FIG. 94. FIG. 95 is a diagram showing a status in each stage shown in FIG. 94. FIG. 97 is a flow diagram showing an operation in which the controller increases the volume of the AV receiver AVR through the AVR client in the network type audio system shown in FIGS. 90 to 96. FIG. 97 is a flowchart showing an operation of the AVR client when transferring the status of the AV receiver to the server in the network type audio system shown in FIGS. 90 to 96. FIG. 97 is a flowchart showing an operation of an AVR client when a control command from a server is transferred to an AV receiver in the network type audio system shown in FIGS. 90 to 96. FIG. 99 is a flowchart showing an improved example of the operation shown in FIG. 99. It is a flowchart which shows the firmware update operation | movement by the client and server in FIG. It is a flowchart which shows the detail of the firmware update operation | movement shown in FIG. FIG. 103 is a flowchart showing a firmware list creation operation in FIG. 102. FIG. 103 is a flowchart showing a firmware list transmission operation in FIG. 102. It is a front view which shows the external appearance structure of the audio client by other embodiment of this invention. FIG. 106 is a side view of the audio client shown in FIG. 105. It is a functional block diagram which shows the network type audio system by other embodiment of this invention, and the whole structure of the internet. FIG. 108 is a flowchart showing a server search operation in the network type audio system shown in FIG. 107. It is a flowchart which shows the transfer operation | movement of the music data by other embodiment of this invention. It is a figure which shows the comparison table referred by S16021 and S16061 in FIG. It is a flowchart which shows the skip reproduction | regeneration operation | movement of the audio client by other embodiment of this invention. FIG. 111 is a diagram showing a song list stored in the memory of the audio client in the skip reproduction operation shown in FIG. 111. It is a flowchart which shows the repeat reproduction | regeneration operation | movement of the audio client by other embodiment of this invention. It is a flowchart which shows the audio | voice reproduction | regeneration operation | movement of the audio client by other embodiment of this invention. It is a flowchart which shows the monitoring process and connection recovery process of the audio client by other embodiment of this invention.

Claims (30)

A network type content reproduction system comprising a server and at least one client connected to the server,
The server
Storage means for storing a plurality of contents;
Content transmitting means for transmitting content selected from the plurality of contents to the client;
The client
Including reproduction means for reproducing the content transmitted from the server,
The server further includes:
Firmware updating means for updating the firmware of the client;
Means for registering information of a plurality of firmware suitable for the client;
Firmware list transmission means for transmitting to the client a firmware list listing information of the plurality of registered firmwares,
The client further includes:
Means for receiving a firmware list transmitted from the server;
Firmware request means for requesting the server to transmit firmware selected from the received firmware list,
The network-type content reproduction system, wherein the firmware update unit returns the selected firmware to the client in response to a request from the client. The network type content playback system according to claim 1,
The client further includes:
Means for sending client information about itself to the server;
The server further includes:
A network type content reproduction system comprising means for creating the firmware list based on client information transmitted from the client. The network type content reproduction system according to claim 1 or 2,
The client further includes:
Firmware list request means for requesting the server for a specified amount of firmware list;
The network-type content reproduction system, wherein the firmware list transmission unit transmits the specified amount of firmware list to the client in response to a request from the client. The network type content playback system according to claim 3,
The firmware list requesting unit includes an acquisition start index that indicates information of the first firmware that the client is to acquire from the server, and an acquisition number that indicates the number of pieces of firmware information that the client is to acquire from the server. Send firmware list request command including
In response to the firmware list request command, the firmware list transmission unit transmits a firmware list including information on the number of pieces of firmware acquired from the first firmware information indicated by the acquisition start index. Type content playback system. A network type content reproduction system comprising a server and at least one client connected to the server,
The server
Storage means for storing a plurality of contents;
Content transmitting means for transmitting content selected from the plurality of contents to the client;
The client
Including reproduction means for reproducing the content transmitted from the server,
The server further includes:
Firmware update means for updating the firmware of the client,
The client further includes:
Firmware request means for requesting the server for a specified amount of firmware;
The network-type content playback system, wherein the firmware update unit returns the specified amount of firmware in response to a request from the client. The network type content reproduction system according to claim 5,
The firmware request means includes an acquisition start address indicating an initial address at which firmware to be acquired by the client from the server is stored, and acquisition data indicating a length of firmware to be acquired by the client from the server Send the long and
The network-type content reproduction system, wherein the firmware update unit returns firmware for the acquired data length from the acquisition start address in response to a request from the client. A network type content reproduction system comprising a server and at least one client connected to the server,
The server
Storage means for storing a plurality of contents;
Content transmitting means for transmitting content selected from the plurality of contents to the client;
The client
Including reproduction means for reproducing the content transmitted from the server,
The server further includes:
Firmware updating means for updating the firmware of the client;
Means for requesting the client to update the firmware, and transmitting information relating to the firmware to the client. A network-type content reproduction system comprising a server and at least one first client connected to the server,
The server
Storage means for storing a plurality of contents;
Content transmitting means for transmitting content selected from the plurality of contents to the first client;
The first client is
Including reproduction means for reproducing the content transmitted from the server,
The server further includes:
Firmware update means for updating the firmware of the first client;
The network content reproduction system further includes:
A second client connected to the server and controlling the first client;
The second client is
A network-type content reproduction system comprising means for requesting the server to update firmware of the first client.   The server used for the network type content reproduction system of any one of Claims 1-8.   The server program for functioning a server as a means of any one of Claims 1-8.   The client used for the network type content reproduction system of any one of Claims 1-8.   A client program for causing a client to function as the means according to claim 1. A server that can connect to the client,
Storage means for storing a plurality of contents;
Content transmitting means for transmitting content selected from the plurality of contents to the client;
Firmware updating means for updating the firmware of the client;
Means for registering information of a plurality of firmware suitable for the client;
Firmware list transmission means for transmitting to the client a firmware list listing information of the plurality of registered firmwares,
The server, wherein the firmware update unit returns the firmware selected from the firmware list to the client in response to a request from the client. The server according to claim 13, further comprising:
A server comprising: means for creating the firmware list based on client information relating to the client transmitted from the client. A server according to claim 13 or claim 14, wherein
The server, wherein the firmware list transmitting means transmits a firmware list of a specified amount requested by the client to the client. The server according to claim 15, wherein
The firmware list transmission unit includes an acquisition start index indicating initial firmware information that the client intends to acquire from the server, and an acquisition number that indicates the number of pieces of firmware information that the client intends to acquire from the server. In response to a firmware list request command from the client, the server transmits to the client a firmware list including firmware information corresponding to the acquired number from the first firmware information indicated by the acquisition start index. A server that can connect to the client,
Storage means for storing a plurality of contents;
Content transmitting means for transmitting content selected from the plurality of contents to the client;
Firmware update means for updating the firmware of the client,
The server, wherein the firmware update means transmits a specified amount of firmware requested by the client to the client. The server according to claim 17, wherein
The firmware update unit returns firmware corresponding to an acquisition data length indicating the length of firmware to be acquired by the client from an acquisition start address indicating an initial address at which the firmware to be acquired by the client is stored. A server characterized by that. A server program for causing a server connectable to a client to execute,
Storing a plurality of contents in a storage means;
A content transmission step of transmitting content selected from the plurality of contents to the client;
A firmware update step for updating the firmware of the client;
Registering information of a plurality of firmware suitable for the client;
Causing the server to execute a firmware list transmission step of transmitting to the client a firmware list listing the information of the plurality of registered firmwares,
In the firmware update step, a firmware selected from the firmware list is returned to the client in response to a request from the client. The server program according to claim 19, further comprising:
A server program for causing a server to execute the step of creating the firmware list based on client information relating to the client transmitted from the client. A server program for causing a server connectable to a client to execute,
Storing a plurality of contents in a storage means;
A content transmission step of transmitting content selected from the plurality of contents to the client;
Firmware update step for updating the firmware of the client is executed by the server,
The server update program, wherein the firmware update step transmits a specified amount of firmware requested by the client to the client. A client that can connect to the server,
Reproducing means for reproducing the content transmitted from the server;
Means for receiving a firmware list transmitted from the server;
Firmware request means for selecting firmware from the received firmware list and requesting transmission of the firmware. 23. The client of claim 22, further comprising:
A client comprising means for transmitting client information about itself to the server. 24. A client according to claim 22 or claim 23, further comprising:
A client comprising: firmware list requesting means for requesting a specified amount of firmware list from the server. A client according to claim 24, comprising:
The firmware list requesting means includes a firmware list request command including an acquisition start index indicating information on the first firmware to be acquired from the server, and an acquisition number indicating the number of pieces of firmware information to be acquired from the server. A client characterized by sending. A client that can connect to the server,
Reproducing means for reproducing the content transmitted from the server;
Firmware request means for requesting the server to transmit a specified amount of firmware. The client of claim 26, wherein
The firmware request means transmits an acquisition start address indicating a first address where firmware to be acquired from the server is stored, and an acquisition data length indicating a length of firmware to be acquired from the server. Featuring clients. A client program for causing a client connectable to a server to execute the program,
A reproduction step of reproducing the content transmitted from the server;
Receiving a firmware list sent from the server;
A client program for selecting a firmware from the received firmware list and causing the client to execute a firmware requesting step for requesting transmission of the firmware. The client program according to claim 28, further comprising:
A client program for causing a client to execute a step of transmitting client information about itself to the server. A client program for causing a client connectable to a server to execute the program,
A reproduction step of reproducing the content transmitted from the server;
A client program for causing a client to execute a firmware requesting step for requesting the server to transmit a specified amount of firmware.

Images