Abstract:
According to an aspect of the present invention, there is provided with a data transmission method that uses first and second media devices which communicate with each other according to a predetermined transmission protocol and a control device which controls the first and second media devices based on a UPnP AV protocol, including: establishing a virtual connection between the first and second media devices under control of the control device; transmitting a real connection establishment request from the first media device to the second media device, the real connection establishment request including information of the virtual connection; establishing a real connection between the first and second media devices, the established real connection being related to the virtual connection; and transmitting media data from the second media device to the first media device or versa by using the established real connection.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
       [0001]     This application claims the benefit of priority under 35USC § 119 to Japanese Patent Application No. 2004-268291, filed on Sep. 15, 2004 and No. 2005-229897, filed on Aug. 8, 2005, the entire contents of which are incorporated herein by reference.  
       BACKGROUND OF THE INVENTION  
       [0002]     1. Field of the Invention  
         [0003]     The present invention relates to a data transmission system, a data transmission method, and a media apparatus.  
         [0004]     2. Related Art  
         [0005]     Scenes in which audio devices and video devices (to be referred to AV devices hereinafter) are coupled to each other through a network to exchange video data or audio data with each other increase. In order to couple the AV devices to perform data transfer between the AV devices, some protocol is necessary. For example, a protocol such as IEEE (The Institute of Electrical and Electronics Engineers) 1394 scheme using a serial bus, HTTP (Hyper Text Transport Protocol), or RTSP (Realtime Streaming Protocol) is known. HTTP and RTSP are defined on TCP/IP protocol on an IEEE802 network.  
         [0006]     Protocols used in the AV devices are various. Therefore, devices using various protocols can be arranged on the same network. Therefore, a procedure that controls transmission of data between the AV devices on the network is required to be compatible with the various protocols. One that realizes the procedure is a Universal Plug and Play (UPnP) protocol. In particular, a UPnP AV protocol is developed to associate the AV devices with each other.  
         [0007]     In the UPnP AV protocol, AV data transmission between the AV devices is performed by using the concept of a virtual connection. Although the virtual connection is associated with actual transmission path or input/output plugs of the devices, the virtual connection is treated in the UPnP AV protocol in a way that the virtual connection does not depend on actual transmission path or transmission protocols. AV data transmission and control performed by the UPnP AV are managed by using the virtual connection. That is, AV data transmission is controlled by using the virtual connection as an argument.  
         [0008]     However, a conventional virtual connection used in the UPnP AV is not always related to actual AV data transmission. For this reason, it is frequent that the management and the control of the AV data transmission cannot be effectively performed.  
         [0009]     For example, in an IEEE1394 protocol, communication is performed by establishing a continuous connection between an input plug of an AV device and an output plug of another AV device. In this case, the real connection and a virtual connection can be easily related to each other. This is because a real connection is established in advance, and a virtual connection can be related to the real connection. More specifically, it can be understood that both the ends of the virtual connection are related to the input plug of an actual AV device and the output plug of another actual AV device, and it can be understood that data transmission is performed in a period in which a real connection continues so that the virtual connection also continues.  
         [0010]     On the other hand, in an HTTP protocol, when a virtual connection is established, any real connection is not established. The real connection is established when a SetAVTransportURI( ) action of an AV Transport service of UPnP AV after a virtual connection is established, a Play action, and a transmission request from a reproduction side or a transmission side of AV data transmission are performed. In establishment of the real connection, by control performed by a control point, in a media renderer or a media server, the virtual connection and the real connection can be related to each other on the basis of a virtual connection ID and a URI which are arguments of the SetAVTransportURI action. However, for a media server or a media renderer as the other party, there is no information that relates to the virtual connection and the real connection. Here, the media renderer is a device that reproduces media data, the media server is a device that supplies media data to the media renderer, and the control point is a device that controls the media renderer and the media server.  
         [0011]     This problem has been pointed out. For example, in Chapters 5.4 to 5.6 of a reference “Designing a UPnP AV Media Renderer v1.0 Intel Corporation, 2003”, it is described that a virtual connection and a real connection must be related to each other. However, any concrete method is not described in the reference. In addition, in section 5.14.1 of a reference “Designing a UPnP AV Media Server v1.0 Intel Corporation, 2003”, it is described that when HTTP_GET is used in delivery of content, a virtual connection and a real connection cannot be related to each other. Japanese Patent Application Laid-open No. 2002-304333 “TRANSMISSION METHOD AND TRANSMISSION APPARATUS” explains procedures of content search, content transmission, and content reproduction which are employed in the UPnP AV. This reference does not refer to any relating between a virtual connection and a real connection.  
       SUMMARY OF THE INVENTION  
       [0012]     According to an aspect of the present invention, there is provided with a data transmission system including first and second media devices that communicate with each other according to a predetermined transmission protocol and a control device that controls the first and second media devices according to a UPnP AV protocol, the control device comprising: a virtual connection establisher which establishes a virtual connection in accordance with the UPnP AV protocol between the first and second media devices; and a communication controller which transmits instruction data to the first media device for instructing the first media device to receive media data from the second media device or transmit media data to the second media device by using the virtual connection; the first media device comprising: a real connection establishment requester which generates a real connection establishment request for requesting the second media device to establish a real connection for receiving or transmitting the media data in a case of receiving the instruction data, and which transmits the real connection establishment request to the second media device, the real connection establishment request including information of the virtual connection; and a first communicator which receives the media data from the second media device or transmits the media data to the second media device by using the established real connection; and the second media device comprising: a real connection establisher which establishes the real connection with the first media device on a basis of the real connection establishment request from the first media device, the established real connection being related to the virtual connection; and a second communicator which transmits the media data to the first media device or receives the media data from the first media device by using the established real connection.  
         [0013]     According to an aspect of the present invention, there is provided with a data transmission method that uses first and second media devices which communicate with each other according to a predetermined transmission protocol and a control device which controls the first and second media devices based on a UPnP AV protocol, comprising: establishing a virtual connection between the first and second media devices under control of the control device; transmitting a real connection establishment request from the first media device to the second media device, the real connection establishment request including information of the virtual connection; establishing a real connection between the first and second media devices, the established real connection being related to the virtual connection; and transmitting media data from the second media device to the first media device or versa by using the established real connection.  
         [0014]     According to an aspect of the present invention, there is provided with a media device which communicates with a further media device according to a predetermined transmission protocol and which is controlled by a control device in accordance with a UPnP AV protocol, comprising: a virtual connection establisher which establishes a virtual connection with the further media device in a case of receiving instruct of instructing to establish the virtual connection from the control device; a request generator which, in a case of being instructed to receive media data from the further media device or transmit media data to the further media device by using the virtual connection from the control device, generates a request for requesting the further media device to establish a real connection for receiving or transmitting the media data, the request including information of the established virtual connection; a request transmitter which transmits the generated request including the information of the established virtual connection to the further media device; and a data communicator which, in a case where the real connection is established, receives the media data from the further media device or transmits the media data to the further media device by using the established real connection.  
         [0015]     According to an aspect of the present invention, there is provided with a media device which communicates with a further media device according to a predetermined transmission protocol and which is controlled by a control device in accordance with a UPnP AV protocol, comprising: a virtual connection establisher which establishes a virtual connection with the further media device in a case of receiving instruct of instructing to establish the virtual connection from the control device, and which transmits information of the established virtual connection to the control device; a request receiver which receives an establishment request of a real connection for transmitting media data to the further media device or receiving media data from the further media device, from the further media device; a real connection establisher which, in a case where the information of the established virtual connection is included in the establishment request, establishes the real connection related to the virtual connection; and a data communicator which transmits the media data to the further media device or receives the media data from the further media device, by using the real connection. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0016]      FIG. 1  is a block diagram showing an illustrative example of a transmission system according to the present invention;  
         [0017]      FIG. 2  is a diagram showing basic formats of virtual connection information and real connection information;  
         [0018]      FIG. 3  is a sequence diagram showing a basic operation performed by the transmission system in  FIG. 1 ;  
         [0019]      FIG. 4  is a flow chart showing a flow of a virtual connection information generating process;  
         [0020]      FIG. 5  is a diagram showing a concrete example of virtual connection information;  
         [0021]      FIG. 6  is a flow chart showing a flow of another example of the virtual connection information generating process;  
         [0022]      FIG. 7  is a flow chart showing a flow of a real connection establishing process on a media renderer MR side;  
         [0023]      FIG. 8  is a flow chart showing a flow of a real connection establishing process on a media server MS side;  
         [0024]      FIG. 9  is a flow chart for explaining a flow of a first connection releasing process;  
         [0025]      FIG. 10  is a flow chart for explaining a flow of a second connection releasing process;  
         [0026]      FIG. 11  is a flow chart for explaining an updating process of last inactivity shift time;  
         [0027]      FIG. 12  is a flow chart for explaining a flow of a third connection releasing process;  
         [0028]      FIG. 13  is a flow chart for explaining a flow of a fourth connection releasing process; and  
         [0029]      FIG. 14  is a diagram showing concrete examples of virtual connection information and real connection information. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0030]      FIG. 1  is a block diagram showing an illustrative example of a transmission system according to the present invention. A media server MS, a media renderer MR, and a control point CP are connected to each other through a network such as a home network. The media server MS, the media renderer MR, and the control point CP can execute procedure according to a UPnP AV protocol. The UPnP AV protocol and specifications related to the UPnP AV protocol are closely described in, e.g., “http://www.upnp.org/standardizeddcps/mediaserver.asp” “UPnP AV Architecture v0.83, Jun. 12, 2002” “ Connection Manager V1.0, Jun. 25, 2002” “Designing a UPnP AV Media Renderer v1.0, Intel Corporation, 2003 (http://www.intel.com/technology/upnp/download/Designing_a_UPnP_AV_MediaRenderer_v1 — 0-XF.pdf)” “Designing a UPnP AV Media Server v1.0, Intel Corporation, 2003 (http://www.intel.com/technology/upnp/download/Designing_a_UPnP_AV_MediaServer.pdf)”.  
         [0031]     In  FIG. 1 , the media server MS is, for example, a DVD player, a CD player, a satellite broadcasting receiver, a cable television receiver, or the like. A media source storing unit  21  in the media server MS stores content data to be reproduced by the media renderer MR.  
         [0032]     The media renderer MR is, for example, a television, a stereo set, a loudspeaker, a mobile audio player, or the like. A reproducer  31  in the media renderer MR reproduces content data acquired from the media server MS through a network.  
         [0033]     The control point CP controls the media server MS and the media renderer MR. The control point CP can be operated by a user through, for example, an input interface (not shown).  
         [0034]     A real connection management unit  22  in the media server MS performs data communication with a real connection management unit  32  in the media renderer MR through a real data communication path  11 . More specifically, the real connection management unit  22  forms a real connection with the real connection management unit  32  in the real data communication path  11  to transmit AV data. The real connection management units  22  and  32  manage the status of the real connection as real connection information.  
         [0035]     A virtual connection management unit  23  in the media server MS and a virtual connection management unit  33  in the media renderer MR performs operations of an AV Transport service (AVTS) and a Connection Manager service (CMS) of the UPnP AV protocol. The virtual connection management units  23  and  33  perform various processing with the control point CP through a UPnP communication path  12  according to UPnR The UPnP communication path  12  and the real data communication path  11  may be included in, e.g., the same transmission medium (for example, a cable), or may be included in different transmission medium. The virtual connection management units  23  and  33  generate virtual connection information according to instructions by the control point CP (execution instruction of PrepareForConnection( ) action in the Connection Manager service). In this manner, the control point CP forms a virtual connection on the UPnP communication path  12  between the virtual connection management units  23  and  33 . The virtual connection management units  23  and  33  manage the respective generated virtual connection information. A plurality of virtual connections can be formed between the virtual connection management units  23  and  33 . In this case, each of the virtual connection management units  23  and  33  generates and manages plural pieces of virtual connection information.  
         [0036]     A Content Directory service unit (CDS)  25  in the media server MS transmits information such as identifiers (URI) of various content data which can be supplied to the media renderer MR, a transmission protocol which is compatible with the content data, and a data format which is compatible with the content data, depending on a request from the control point CR  
         [0037]     A connection map  24  in the media server MS and a connection map  34  in the media renderer MR manage units of resources for forming real connections, as channels. In this embodiment, the connection map  24  has seven channels  24 ( 1 ) to  24 ( 7 ), and the connection map  34  also has seven channels  34 ( 1 ) to  34 ( 7 ). Each channel includes a pair of virtual connection information and real connection information registered in the channel.  
         [0038]      FIG. 2  shows basic formats of the virtual connection information and the real connection information.  
         [0039]     The virtual connection information is a set of the following four pieces of information shown in Connection Manager specifications.  
         [0040]     Peer Manager: Identifier of other party device (UDN: Unique Device Name)  
         [0041]     Peer Service Id: service ID (service Id) of Connection Manager service of other party device  
         [0042]     Peer Connection ID: Virtual connection ID issued by Connection Manager service of other party device  
         [0043]     Connection ID: Virtual connection ID issued by Connection Manager service of own device  
         [0044]     Here, the own device is the media server MS or the media renderer MR, and the other party device is the media renderer MR for the media server MS or the media server MS for the media renderer MR.  
         [0045]     In the following description, the UDN of the media server MS is given by “uuid:E6CAB760-6863-43e8-8184-CC22FB4CB62C” and the UDN of the media renderer MR is given by “uuid: B7DA4840-C028-4259-A56D-59551C79BF30”. The service Id of the Connection Manager service in each of the media server MS and the media renderer MR is given by the same “urn: upnp-org: serviceId:ConnectionManager”.  
         [0046]     On the other hand, the real connection information is a set of the following three pieces of information.  
         [0047]     handle: Identifier of real connection  
         [0048]     status: flag representing status (active or inactive) of real connection  
         [0049]     Last closed time: time (last inactivity shift time) at which real connection becomes inactive (for example, connection obtained by transfer protocol is disconnected, data do not flow for predetermined period of time, or the like) at last  
         [0050]     In each channel, when both virtual connection information and real connection information are not registered, it means that the channel is not used in both the virtual connection management unit and the real connection management unit. For example, this corresponds to a case in which both a virtual connection and a real connection are not established.  
         [0051]     On the other hand, when both the virtual connection information and the real connection information are registered, it means that the channel is used in both the virtual connection management unit and the real connection management unit. This corresponds to a case in which both the virtual connection and the real connection are established.  
         [0052]     When only the virtual connection information is registered, it means that although the channel is used by the virtual connection management unit, the channel is not used by the real connection management unit. For example, this corresponds to a case in which although the virtual channel is established, the real channel is not established.  
         [0053]     Furthermore, when only the real connection information is registered, it means that although the channel is used by the real connection management unit, the channel is not used by the virtual connection management unit. For example, this corresponds to a case in which although a virtual connection is not established by the virtual connection management unit, a real connection is established. More specifically, this corresponds to a case in which a transmission path to other party device is established without a Connection Manager service of UPnP AV.  
         [0054]      FIG. 3  is a sequence diagram showing a basic operation by the transmission system in  FIG. 1 .  
         [0055]     An http server in the media server MS includes, for example, the real connection management unit  22  shown in  FIG. 1 , and a UPnP unit includes the virtual connection management unit  23 . An http client in the media renderer MR includes, for example, the reproducer  31  and the real connection management unit  32  shown in  FIG. 1 , and a UPnP unit includes the virtual connection management unit  33 .  
         [0056]     The control point CP orders the Content Directory service unit  25  in the media server MS to perform Browser( ) action (step S 11 ). The Content Directory service unit  25  ordered to perform the Browse( ) action gives information such as an identifier (URI) of the content data held in the media source storing unit  21 , a transmission protocol which is compatible with the content data, and a data format which is compatible with the content data, to the control point CP.  
         [0057]     The control point CP orders the Control Manager service of the virtual connection management unit  33  in the media renderer MR to perform a GetProtocolInfo( ) action (step S 12 ). The virtual connection management unit  33  ordered to perform the GetProtocolInfo( ) action gives the information such as the compatible transmission protocol and the compatible data format to the control point CP.  
         [0058]     The control point CP orders the Connection Manager service of the virtual connection management unit  23  in the media server MS to perform a Prepare For connection( ) action (PFC( ) action) (step S 13 ). At this time, as an argument, a UDN of the media renderer MR, a service Id of a Connection Manager service, and a virtual connection ID (PeerConnectionID) allocated in the media renderer MR are given. The UDN and the service Id are notified from the media renderer MR to the control point CP in advance by multicast delivery according to a UPnP protocol. On the other hand, with respect to the Peer Connection ID, since virtual connection information is not registered in the media renderer MR at this time, as a virtual connection ID of the media renderer MR which is one of arguments used when the control point CP calls a PFC( ) action of the Connection Manager service of the media server MS, “−1” or “0” is given from the control point CR The virtual connection management unit  23  in the media server MS ordered by the control point CP to perform the PFC( ) action executes a virtual connection information generating process shown in the flow chart in  FIG. 4 .  
         [0059]     The connection map  24  is searched for an available (blank) channel (step A 1 ). The available (blank) channel is a channel in which both the virtual connection information and the real connection information is not registered.  
         [0060]     When an available channel is present (YES in step A 2 ), one channel is acquired, and a virtual connection ID is generated (step A 3 ).  
         [0061]     The generated virtual connection ID is registered in the channel, and the UDN and the service Id given as the arguments of the PFC( ) action are also registered in the channel. In this manner, the connection map  24  is updated (step A 4 ). In this case, it is assumed that “25” is allocated as a virtual connection ID (ConnectionID) for the acquired channel, that “uuid: E6CAB760-6863-43e8-8184-CC22FB4CB62C” is registered as UDN (PeerManager), and “urn:upnp-org:serviceId:ConnectionManager” is registered as the service Id (PeerServiceId). Since virtual connection information is not registered in the media renderer MR at this time, it is assumed that, as the virtual connection ID (PeerConnectionID) of the media renderer MR, the above “−1” is registered.  FIG. 5  shows contents registered as the virtual connection information. As is apparent from  FIG. 5 , real connection information is not yet registered (handle is null). The media server MS returns the registered virtual connection information to the control point CP.  
         [0062]     When an available channel is absent in step A 2  (NO in step A 2 ), as an execution result of the PFC( ) action, an error is returned to the control point CP (step A 5 ). In place of returning the error, the channel in use may be released, and the virtual connection information is registered in the released channel. Process steps performed in this case are shown in the flow chart in  FIG. 6 .  
         [0063]     More specifically, when an available channel is absent (NO in step A 2 ), a channel in which real connection information is not registered is searched for (step A 6 ). When the channel is present (YES in step A 7 ), the found channel is released (step A 12 ), and the flow returns to step A 1 .  
         [0064]     When the channel in which real connection information is not registered cannot be found (NO in step A 7 ), i.e., when the real connection information are registered in all the channels, from among these channel, a channel in which virtual connection information is not registered is searched for (step A 8 ). When the channel is found (YES in step A 9 ), the found channel is released (step A 12 ), and the flow returns to step A 1 .  
         [0065]     When the channel in which virtual connection information is not registered cannot be found (NO in step A 9 ), i.e., when both the virtual connection information and the real connection information are registered in all the channels, a channel on which inactive time of the real connection is a predetermined period of time or longer is searched for (step A 10 ). When such channel is found (YES in step A 11 ), the found channel is released (step A 12 ), and the flow returns to step A 1 . When such channel is not found (NO in step A 11 ), an error is returned (step A 5 ).  
         [0066]     Returning to  FIG. 3 , the control point CP similarly orders a Connection Manager service of the virtual connection management unit  33  in the media renderer MR to perform a PrepareForconnection( ) action (PFC( ) action) (step S 14 ). At this time, as arguments, a UDN of the media server MS, a serviceID of the Connection Manager service, and a virtual connection ID included in the virtual connection information received from the media server MS in step S 13  and allocated by the Connection Manager service of the media server MS. The media server MS notifies the control point CP of the UDN and serviceID of the media server MS by multicast delivery according to UPnP in advance. The virtual connection management unit  33  in the media renderer MR ordered by the control point CP to perform the PFC( ) action executes processes shown in the flow chart in  FIG. 4  or  6  as described above. When virtual channel information could be registered in a channel on the connection map  34 , the media renderer MR returns the virtual channel information to the control point CP.  
         [0067]     As an example, in the Connection Manager service of the media renderer MR, it is assumed that ConnectionID=“3” is allocated. Therefore, virtual connection information on the media renderer MR side is given by:  
         [0068]     PeerManager=“uuid: E6CAB760-6863-43e8-8184-CC22FB4CB62C” 
         [0069]     PeerServiceID=“urn:upnp-org:serviceId:ConnectionManager” 
         [0070]     PeerConnectionID=“25” 
         [0071]     ConnectionID=“3”.  
         [0072]     In this manner, a virtual connection between the virtual connection management unit  23  in the media server MS and the virtual connection management unit  33  in the media renderer MR is established.  
         [0073]     The control point CP orders the media renderer MR to perform a SetAVTransport URI( ) action of an AV Transport service (step S 15 ). At this time, as an argument, the control point CP gives virtual connection information acquired from the media renderer MR in advance. The media renderer MR acquires, as an execution result of the SetAVTransportURI( ) action, a URI of content data designated by a user for the control point CP from the control point CP.  
         [0074]     The control point CP orders the media renderer MR to perform a Play( ) action of the AV Transport service (step S 16 ). At this time, as an argument, the control point CP also gives the virtual connection information acquired from the media renderer MR in advance. The media renderer MR acquires, as an execution result of the Play( ) action, content data having the URI given by the control point CP in step S 15  from the media server MS to reproduce the content data.  
         [0075]     More specifically, the real connection management unit  32  in the media renderer MR establishes a real connection to the real connection management unit  22  in the media server MS (steps S 17  and S 18 ).  
         [0076]      FIG. 7  is a flow chart showing a flow of a real connection establishing process (step S 17 ) on the media renderer MR side.  
         [0077]     The real connection management unit  32  in the media renderer MR searches the connection map  34  for a channel in which the virtual connection information received from the control point CP when the real connection management unit  32  is ordered to perform the SetAVTransportURI( ) action or the Play( ) action is registered (step B 1 ).  
         [0078]     When the channel is found (YES in step B 2 ), real connection information is registered in the channel (step B 3 ). More specifically, a value which identifies a real connection is set in a handle field (see  FIG. 2 ), a status field is made inactive, and an appropriate initial value is set in a Last closed time field.  
         [0079]     The real connection management unit  32  transmits an establishment request of the real connection including the virtual connection information to the real connection management unit  22  in the media server MS (step B 4 ). More specifically, the establishment request of the real connection is transmitted by a GET request of HTTP. In this request, for example, the following pieces of information are added to a user-defined field of a request header field of the GET request. 
    GET/foo/bar.mpgHTTP/1.0     X-AV-ConnectionInfo:PeerUDN=uuid: E6CAB760-6863-43e8-8184-CC22FB4CB62C;     PeerServiceId=urn:upnp-org:serviceId:ConnectionManager; Peer ConnectionID=25;     UDN=uuid:B7DA4840-C028-4259-A56D-59551C79BF30;     ServiceID=urn:upnp-org:serviceId:ConnectionManager; ConnectionID=3    
 
         [0085]     This example includes the entire request header. The part of “X-AV-ConnectionInfo:” to “ConnectionID=25 is expressed as one line. In this example, virtual connection information associated with a real connection establishment request is stored in an X-AV-ConnectionInfo field. The X-AV-ConnectionInfo field is constituted by six parts sectioned by semicolons (;). In the four parts, i.e., PeerUDN, PeerServiceId, PeerConnectionID, and ConnectionID, values corresponding to PeerManager, PeerServiceID, PeerConnectionID, and ConnectionID of the virtual connection information managed by the media renderer MR and allocated in step S 14  are buried. In the two remaining parts, i.e., UDN and ServiceId, the UDN of the media renderer MR holding the virtual connection information and the ServiceId of the Connection Manager service are buried. The uniqueness of the virtual connection information expressed by the four former parts is assured. Since the X-AV-connectionInfo field is a field that is not included in the standard specifications and that is defined by a user, an HTTP server that do not adapt to the present invention performs the processes in a way that the field is neglected. At this time, the HTTP server is not obstructed in any way.  
         [0086]     Returning to  FIG. 7 , the real connection management unit  32  in the media renderer MR which transmits an establishment request of a real connection waits for a response from the real connection management unit  22  in the media server MS (step B 5 ). When the real connection management unit  32  is informed from the real connection management unit  22  that the real connection information is registered, i.e., when a real connection is established between the real connection management units  22  and  32 , the connection map is updated (step B 6 ). That is, the status field on the channel is made active. Thereafter, the real connection management unit  32  in the media renderer MR receives content data from the real connection management unit  22  in the media server MS according to HTTP and reproduces the received content data.  
         [0087]     When a channel is not obtained in step S 2  (NO in step B 2 ), the media renderer MR returns an error to the control point CP (step B 7 ).  
         [0088]      FIG. 8  is a flow chart showing a flow of a real connection establishing process (step S 18  in  FIG. 3 ) on the media server MS side.  
         [0089]     The real connection management unit  22  in the media server MS which receives an establishment request of the real connection in step B 4  in  FIG. 7  (step C 1 ) extracts virtual connection information from the received establishment request (step C 2 ).  
         [0090]     The real connection management unit  22  searches the connection map  24  for a channel corresponding to the extracted virtual connection information (YES in step C 3 , step C 4 ). For example, the real connection management unit  22  searches the connection map  24  for a channel including the same value as that of the connection ID of the media server MS included in the virtual connection information.  
         [0091]     In this case, a ConnectionID (in X-AV-ConnectionInfo) allocated in the media renderer MR and included in the virtual connection information extracted in step C 3  is “3”. This is different from ConnectionID (=PeerConnectionID)=“−1” on the media renderer MR side recognized by the media server MS. This difference is based on a difference between the contents of arguments when PFC( ) actions of the media server MS and the media renderer MR are called by the control point CP. In the media server MS, this difference can be neglected.  
         [0092]     When the corresponding channel is absent (NO in step C 5 ) or when the establishment request of the real connection does not include the virtual connection information (NO in step C 3 ), an available channel is searched for (steps C 6  and C 7 ).  
         [0093]     When the channel can be acquired in step C 5  or C 7  (YES in step C 5 , and YES in step C 7 ), the real connection management unit  22  updates the real connection information in the acquired channel (step C 8 ). That is, a value which identifies a real connection is set in the handle field, the status field is made active, and an appropriate initial value is set in a Last closed time field. Here, it is assumed that the virtual connection information is included in step C 3 , and it is assumed that information shown in  FIG. 14  is registered as real connection information.  
         [0094]     When the virtual connection information is not included in step C 3  (NO in step C 3 ), the flow proceeds to step C6, and the real connection information is registered without being related to the virtual connection information. That is, it is determined that the establishment request of the real connection is not based on the reserved virtual connection. The connection map is updated without being related to a specific virtual connection. In this manner, connection compatibility with the other party device operated on the basis of a conventional method can be kept. A real connection that is not related to the specific virtual connection may be handled such that the priority of maintenance of the real connection after the establishment is decreased (see steps A 8  and A 9  in  FIG. 6 ).  
         [0095]     The real connection management unit  22  in which the real connection information is registered responds to the real connection management unit  32  in the media renderer MR to notify the real connection management unit  32  that the real connection is established between the real connection management unit  22  and the real connection management unit  32  in the media renderer MR (step C 10 ).  
         [0096]     When the real connection management unit  22  notifies the media renderer MR that the real connection is established, the real connection management unit  22  buries the virtual connection information on the media server side into an HTTP GET response header field by the following manner. This example includes an entire response header. A part of “X-AV-ConnectionInfo:” to “ConnectionID=25” is expressed by one line. 
    HTTP/1.1 200 OK     Date: MON, 29 Mar. 2004 05:37:17 GMT     Server: Apache/1.3.29 (Unix)     Last-Modified: Thu, 25 Jul. 2002 06:51:36 GMT     Etag: “7e0aa2-bf8-3d3f9ff8”    Accept-Ranges: bytes     Content-Length: 3064000     Connection: close     Content-Type: video/mpeg     X-AV-ConnectionInfo:     PeerUDN=uuid: B7DA4840-C028-4259-A56D-59551C79BF30;     PeerServiceId=urn:upnp-org:serviceId: ConnectionManager;     PeerConnectionID=−1;     UDN=uuid: E6CAB760-6863-43e8-8184-CC22FB4CB62C;     ServiceId=urn:upnp-org:serviceId: ConnectionManager;     ConnectionID=25    
 
         [0113]     The contents are basically the same as the information buried into the GET request in step B 4 . However, the contents are different from the information buried into the GET request in that the contents have a viewpoint from the HTTP server, i.e., the media server MS side. An HTTP client, i.e., the media renderer MR, by receiving the virtual connection information, can recognize that the virtual connection and the real connection are associated in the other party device.  
         [0114]     ConnectionID (PeerConnectionID in X-AV-ConnectionInfo) on the media renderer MR side recognized by the media server MS is “−1”, and is different from ConnectionID=“3” allocated in the media renderer MR. This difference is based on a difference of the contents of arguments used when PFC( ) actions of the media server MS and the media renderer MR are called by the control point CR The difference can be neglected in the media renderer MR.  
         [0115]     When the response from the media server MS are results of the processes performed through YES in step C 7 , the real connection information in the media server MS is not appropriately related to the virtual connection information. As a result, information stored in X-AV-ConnectionInfo may be imperfect, or an X-AV-ConnectionInfo field may be absent. In this case, the media renderer MR can recognize that, although a real connection could be established, the real connection could not be related to the virtual connection in the media server MS.  
         [0116]     In the above series of procedures, information which can be used to recognize the uniqueness of the virtual connection may be limited to only the ConnectionID allocated in the media server MS, to which significant information is assigned, which is recognized by both the media server MS and the media renderer MR, which has a matched value in both device.  
         [0117]     In such a case, virtual connection information, such as information managed by the media server MS and the media renderer MR and associated with the real connection and such as information stored in X-AV-ConnectionInfo in steps B 4  and C 10 , is defined as a set of ConnectionID recognized to be allocated in the media server MS, UDN and serviceID of the media server MS, in both the media server MS and the media renderer MR, and the above series of processes may be performed.  
         [0118]     Further, another virtual connection information may be constituted by arbitrary pieces of information or a combination of the pieces of information.  
         [0119]     Returning to  FIG. 8 , when a channel cannot be obtained in step C 7  (NO in step C 7 ), the real connection management unit  22  makes a response to the real connection management unit  32  in the media renderer MR to notify the real connection management unit  32  that establishment of a real connection fails (step C 9 ).  
         [0120]     Returning to  FIG. 3 , the control point CP orders the virtual connection management units  23  and  33  in the media server MS and the media renderer MR to execute ConnectionComplete( ) actions depending on, e.g., a instruction by a user (steps S 19  and S 20 ). At this time, the respective virtual connection information is specified to the virtual connection management units  23  and  33 . In this manner, virtual connection corresponding to the specified virtual connection information and real connection related to the virtual connection are released (connection releasing process).  
         [0121]      FIG. 9  is a flow chart for explaining a flow of a connection releasing process (first connection releasing process). The following processes are performed in the media server MS and the media renderer MR, respectively.  
         [0122]     A channel including the virtual connection information specified by the control point CP is searched for on the connection map (step D 1 ).  
         [0123]     When the channel is found (YES in step D 2 ), the virtual connection information is erased from the channel (virtual connection is released) (step D 3 ).  
         [0124]     Real connection information corresponding to the erased virtual connection information is erased from the channel (for example, at least handle is made null, and status is made inactive) (real connection is released) (step D 4 ). In a case of being execution of data transmission, the real connection information is erased after the data transmission is stopped. In this manner way, the channel is released.  
         [0125]     When a channel is not found in step D 2  (NO in step D 2 ), an error is returned to the control point CP (step D 5 ).  
         [0126]     In the first connection releasing process described above, the control point CP causes the media server MS and the media renderer MR to execute ConnectionComplete( ) actions to explicitly release the connection, that is to say, the connection is released by a instruction by a user. Automatic releasing of the connection will be described below.  
         [0127]      FIG. 10  is a flow chart for explaining a flow of an automatic releasing process (second connection releasing process) of the connection.  
         [0128]     The virtual connection management units  23  and  33  in the media server MS and the media renderer MR select one channel (step E 1 ) to determine whether real connection information is registered (step E 2 ).  
         [0129]     When the real connection information is registered (YES in step E 2 ), whether the real connection is active or inactive is judged (step E 3 ).  
         [0130]     When the real connection is inactive (YES in step E 3 ), “last inactivity shift time+time-out time−current time” is calculated on the basis of last inactivity shift time included in the real connection information (step E 4 ). The time-out time is a predetermined value. The virtual connection continues for the time represented by the time-out time even though the real connection is inactive. This is effective in a transmission protocol that repeats establishment and disconnection of the connection in a reproducing process.  
         [0131]     When the calculated value is 0 or more (YES in step E 4 ), i.e., when the time-out time has elapsed after the last inactivity shift time, the connection releasing process is performed according to the flow chart shown in  FIG. 9  (step E 5 ).  
         [0132]     When the real connection information is not registered in step E 2  (NO in step E 2 ), when the real connection is active in step E 3  (NO in sep E 3 ), and when the value calculated in step E 4  is smaller than 0 (YES in step E 4 ), if the process is continued (YES in step E 6 ), the next channel is selected (step E 1 ) to perform the same processes as described above.  
         [0133]      FIG. 11  is a flow chart for explaining an updating process of the last inactivity shift time.  
         [0134]     The real connection management units  22 ,  32  in the media server MS and the media renderer MR search the connection map for a channel corresponding the real connection (step F 2 ) when the status of the real connection shifts to an inactive status (step F 1 ).  
         [0135]     When the virtual connection information is not registered in the found channel (NO in step F 3 ), the real connection information is erased by the same manner as that in step D 4  in  FIG. 9  to release the channel (step F 6 ).  
         [0136]     On the other hand, when the virtual connection information is registered in the found channel (YES in step F 3 ), the status field in the real connection information is made active (step F 4 ), and the last inactivity shift time in the Last closed time field is updated (step F 5 ).  
         [0137]     In this case, although the connection releasing process can also be performed according to the first and second connection releasing processes (see  FIGS. 9 and 10 ), the connection releasing process can be performed in a manner shown in the flow charts in  FIGS. 12 and 13  by adding the functions of UPnP control points to the media server MS and the media renderer MR.  
         [0138]      FIG. 12  is a flow chart for explaining a flow of a third connection releasing process.  
         [0139]     The media server MS or the media renderer MR receives a notice of ending (for example SSDP: byebye) from the media renderer MR, the media server MS or a peripheral UPnP device (media server or media renderer) (step G 1 ). The notice of ending includes an UDN or the like of the device.  
         [0140]     The UDN included in the notice of ending is extracted to search the connection map to check whether a channel having the extracted UDN is present (steps G 2  and G 3 ).  
         [0141]     When the channel is found (YES in step G 4 ), the channel is released according to the flow chart in  FIG. 9  (step G 5 ). When the channel is not found (NO in step G 4 ), any special process is not performed.  
         [0142]      FIG. 13  is a flow chart for explaining a flow of a fourth connection releasing process.  
         [0143]     The media server MS or the media renderer MR selects a channel from the connection map (step H 1 ). When virtual connection information is registered in the selected channel (YES in step H 2 ), SSDP: discover (searching procedure for UPnP) is executed for an UDN in the virtual channel information (steps H 3  and H 4 ).  
         [0144]     When a response cannot be obtained from a device having the UDN (NO in step H 5 ), it is determined that the device is not connected to the network, and the channel is released (step H 6 ).  
         [0145]     When the virtual connection information is not registered in step H 2  (NO in step H 2 ), when a response is obtained in step H 5  (YES in step H 5 ), and when the process is continued after step H 6  (YES in step H 7 ), the next channel is selected (step H 11 ).  
         [0146]     In this manner, when an action of other device is end or is not recognized by the procedures shown in  FIGS. 12 and 13 , a channel allocated to the other device can be released.  
         [0147]     In the embodiment described above, pull-type stream transmission in which a real connection is established from a media reproducing side such as an HTTP-GET to a media supply side to request data transmission is performed. However, the present invention can also be applied to push-type stream transmission. In this case, on a media server side serving as a media sending side, as in the conventional method, a real connection is related to a virtual connection in establishment of the real connection. In a media renderer on the media reproducing side, a virtual connection can be related to an actual resource according to the present invention.  
         [0148]     The present invention can be applied to a protocol in which virtual connection information is buried in establishment of a real connection and the buried virtual connection information can be extracted. For example, when RTSP/RTP/UDP is used, a user-defined header can be added to the RTSP. Therefore, when the virtual connection information is buried in the RTSP, the present invention can be applied.  
         [0149]     The embodiment is considered to be similar to a cookie or a session ID used in a Web application. However, as one of the differences therebetween, for example, session information is exchanged between only a server and a client in a normal Web application. In contrast to this, in the embodiment, a control point may transfer session information between a server and a client.  
         [0150]     In the above description, all or some functions of the elements shown in  FIG. 1  may be realized as hardware, may be realized by causing a computer to execute a program generated by a normal programming technique, or may be realized by both of the above means.  
         [0151]     As described above, according to the embodiment, virtual connection information is transmitted to the other party device in an establishing process of a real connection. For this reason, even though the real connection is formed after a virtual connection is formed, the real connection and the virtual connection can be related to each other. Therefore, the real connection can be properly controlled through the virtual connection.  
         [0152]     According to the embodiment, on the basis of an identifier (UDN) of other party device extracted from virtual connection information, an action status of the other party device is recognized. When it is determined that the other party device is in an inactive status, the channel is released. Therefore, channel management can be properly performed.  
         [0153]     According to the embodiment, for a predetermined period of time or longer from the last inactivity shift time of the real connection, the channel is released. Therefore, the channel management can be appropriately performed.  
         [0154]     According to the embodiment, when virtual connection information is not included in an establishment request of the real connection, a channel registered in establishment of the virtual connection is not to be allocated to the establishment request (see NO in steps C 6  and C 7 ). Data transmission based on a UPnP AV protocol is more properly performed.