Data transmission system, data transmission method, and media apparatus

[0029]Fig. 1 is a block diagram showing an example of a transmission system according to the present invention. The media server MS, the media renderer MR, and the 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 programs according to the UPnP AV protocol. The UPnP AV protocol and the specifications related to the UPnP AV protocol are in, for example, "http://www.upnp.org/standardizeddcps/mediaserver.asp", "UPnP AVArchiteture v0.83, June 12, 2002", "Connection Manager v1.0, June 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_v1_0-XF.pdf)".

[0030] In FIG. 1, the media server MS is, for example, a DVD player, a CD player, a satellite broadcast receiver, a cable TV receiver, etc. The media source storage unit 21 in the media server MS stores the content to be reproduced by the media renderer MR.

[0031] The media presenter MR is, for example, a television, a stereo, a loudspeaker, a mobile audio player, and the like. The reproduction device 31 in the media renderer MR reproduces the data content acquired from the media server MS via the network.

[0032] The control point CP controls the media server MS and the media renderer MR. The control point CP can be operated by the user through, for example, an input interface (not shown).

[0033] The actual connection management unit 22 in the media server MS performs data communication with the actual connection management unit 32 in the media renderer MR through the actual data communication path 11. More specifically, in the actual data communication path 11, the actual connection management unit 22 forms an actual connection with the actual connection management unit 32 to transfer AV data. The actual connection management units 22 and 32 manage the status of the actual connection as actual connection information.

[0034] The virtual connection management unit 23 in the media server MS and the virtual connection management unit 33 in the media renderer MR perform operations of the AV transmission service (AVTS) and the connection management service (CMS) of the UPnP AV protocol. The virtual connection management units 23 and 33 perform various processing together with the control point CP through the UPnP communication path 12 in accordance with UPnP. The UPnP communication path 12 and the actual data communication path 11 may be included in, for example, the same transmission medium (for example, a cable), or may be included in different transmission media. The virtual connection management units 23 and 33 generate virtual connection information according to instructions executed by the control point CP (execution instructions of the PrepareForConnectin() action in the connection manager service). In this way, on the UPnP communication path between the virtual connection management units 23 and 33, the control point CP forms a virtual connection. 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 virtual connection management unit 23 and 33 generates and manages a plurality of pieces of virtual connection information.

[0035] The content directory service unit (CDS) 25 in the media server MS transmits information such as identifiers of various content data that can be supplied to the media renderer MR, a transmission protocol compatible with the content data, and a data format compatible with the content data. Depends on the request from the control point CP.

[0036] The connection map (connection map) 24 in the media server MS and the connection map 34 in the media renderer MR manage the units forming the actual connection resources as channels. In this embodiment, the connection map 24 has 7 channels 24(1) to 24(7), and the connection map 34 also has 7 channels 34(1) to 34(7). Each channel includes a pair of virtual connection information and actual connection information registered in the channel.

[0037] Figure 2 shows the basic format of virtual connection information and actual connection information.

[0038] The virtual connection information is a collection of the following four pieces of information shown in the connection manager specification.

[0039] Peer Manager: the identifier of the other party's device (UDN: unique device name)

[0040] Peer Service ID (Peer Service Id): The service ID (service Id) of the connection manager service of the other party's device.

[0041] Peer Connection ID: The virtual connection ID issued by the connection manager of the other party's device.

[0042] Connection ID (Connection ID): The virtual connection ID issued by the connection manager service of the own device.

[0043] Here, the own device is the media server MS or the media renderer MR, and the other device is the media renderer MR for the media server MS or the media server MS for the media renderer MR.

[0044] 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" Given. The service Id of the connection manager service in each media server MS and the media renderer MR is given by the same "urn:upnp-org:serviceId:ConnectionManager".

[0045] On the other hand, the actual connection information is a collection of the following three pieces of information.

[0046] Handle: The identifier of the actual connection.

[0047] Status: A flag (active or inactive) that represents the status of the actual connection.

[0048] Final closing time: the time when the actual connection finally becomes inactive (for example, the connection obtained by the transmission protocol is disconnected, data does not flow for a predetermined period of time, etc.) (final inactive transition time).

[0049] In each channel, when the virtual connection information and the actual connection information are not registered, it means that the channel is not used in the virtual connection management unit and the actual connection management unit. For example, this corresponds to a situation where the virtual connection and the actual connection are not established.

[0050] On the other hand, when the virtual connection information and the actual connection information are registered, it means that the channel is used in the virtual connection management unit and the actual connection management unit. This corresponds to the situation where a virtual connection and an actual connection have been established.

[0051] When only the virtual connection information is registered, this means that although the channel has been used by the virtual connection management unit, the channel is not used by the actual connection management unit. For example, this corresponds to a situation where the actual channel is not established although the virtual channel has been established.

[0052] In addition, when only the actual connection information is registered, this means that although the channel has been used by the actual connection management unit, the channel is not used by the virtual connection management unit. For example, this corresponds to a situation where a virtual channel is not established by the virtual connection management unit, but an actual channel is established. More specifically, this corresponds to the case where the transmission path to the other party is established without the connection manager service of UPnP AV.

[0053] Fig. 3 is a sequence table showing basic operations performed by the transmission system in Fig. 1.

[0054] The http server in the media server MS includes, for example, the actual connection unit 22 shown in FIG. 1, and the UPnP unit includes the virtual connection management unit 23. The http client in the media renderer MR includes, for example, the reproduction device 31 shown in FIG. 1 and the actual connection management unit 32, and the UPnP unit includes the virtual connection management unit 33.

[0055] The control point CP instructs the content directory service unit 25 in the media server MS to execute the Brower() action (step S11). The content directory service unit 25 instructed to perform the Brower() action gives the control point CP information such as the identifier (URI) of the content data held in the media source storage unit 21, a transmission protocol compatible with the content data, and compatibility with the content data Data format.

[0056] The control point CP instructs the control manager service of the virtual connection management unit 33 in the media renderer MR to execute the GetProtocolInfo() action (step S12). The virtual connection management unit 33 commanded to execute the GetProtocolInfo() action gives the control point CP information such as a compatible transmission protocol and a compatible data format.

[0057] The control point CP instructs the connection manager service of the virtual connection management unit 23 in the media server MS to perform a connection preparation action (PFC() action) (step S13). At this time, as arguments, the UDN of the media renderer MR allocated in the media renderer, the service ID of the connection manager service, and the virtual connection ID (PeerConnectionID) are given. According to the UPnP protocol, the UDN and service Id are notified in advance from the media renderer MR to the control CP through multicast. On the other hand, regarding the equivalent connection ID, since the virtual connection information is not registered in the media renderer as the virtual connection ID of the media renderer MR at this time, the control point CP gives "-1" or "0", where The connection ID is one of the arguments used when the control point CP calls the PFC() action of the connection manager service of the media server MS. The virtual connection management unit 23 in the media server MS that is instructed by the control point CP to perform the PFC() action executes the virtual connection information generation process as shown in the flowchart in FIG. 4.

[0058] The connection map 24 is searched for available (free) channels (step A1). The available (idle) channel is a channel for which neither the virtual connection information nor the actual connection information is registered.

[0059] When there is an available channel (Yes in step A2), a channel is acquired, and a virtual connection ID is generated (step A3).

[0060]The generated virtual connection ID is registered in this channel, and the UDN and service Id given as arguments of the PFC() action are also registered in this channel. In this way, the connection map 24 is updated (step A4). In this case, assume that "25" is assigned to the acquired channel as the virtual connection ID (ConnectionID), and that "uuid: E6CAB760-6863-43e8-8184-CC22FB4CB62C" is registered as UDN (PeerManager) and "urn: upnp- org: serviceId: ConnectionManager" is registered as the server ID (PeerServiceId). Since the virtual connection information is not registered in the media presenter MR at this time, it is assumed that it is the virtual connection ID (PeerConenctionID) of the media presenter MR, and the above-mentioned "-1" is registered. Fig. 5 shows the contents registered as virtual connection information. It is obvious from Figure 5 that the actual connection information is not registered (the handle is empty). The media server MS returns the registered virtual connection information to the control point CP.

[0061] When there is no available channel in step A2 (No in step A2), as a result of the execution of the PFC() action, an error is returned to the control point CP (step A5). Instead of returning an error, the channel in use can be released, and the virtual connection information can be registered in the released channel. The processing steps executed in this case are shown in the flowchart in FIG. 6.

[0062] More specifically, when there is no available channel (No in step A2), a channel for which no actual connection information is registered is searched (step A6). When such a channel exists (Yes in step A7), the found channel is released (step A12), and the flow returns to step A1.

[0063] When a channel without registered actual connection information cannot be found (No in step A7), that is, when actual connection information is registered in all channels, channels without registered virtual information are searched for from these channels (step A8). When the channel is found (Yes in step A9), the found channel is released (step A12), and the flow returns to step A1.

[0064] When a channel without registered virtual connection information cannot be found (No in step A9), that is, when both the virtual connection information and the actual connection information are registered in all channels, the inactive time for searching the actual connection on it is predetermined Channel for a period of time or longer (step A10). When such a channel is found (Yes in step A11), the found channel is released (step A12), and the flow returns to step A1. When no such channel is found (No in step A11), an error is returned (step A5).

[0065] Returning to FIG. 3, the control point CP similarly instructs the connection manager service of the virtual connection management unit 33 in the media renderer MR to execute the PrepareForconnection() action (PFC() action) (step S14). At this time, as arguments, the UDN of the media server MS, the service ID of the connection manager service, and the virtual connection ID are included in the virtual connection information received from the media server MS in step S13, and are served by the connection manager of the media server MS To distribute. According to UPnP, through multipoint transmission, the media server MS informs the control point CP of the UDN and service ID of the media server MS in advance. The virtual connection management unit 33 in the media renderer MR commanded by the control point CP to execute the PFC() action executes the process shown in the flowchart in FIG. 4 or 6 described above. When the virtual channel information can be registered in the channel on the connection map 34, the media renderer returns the virtual channel information to the control point CP.

[0066] As an example, in the connection manager service of the media renderer MR, it is assumed that "ConnectionID=3" is allocated. Therefore, the virtual connection information on the MR side of the media renderer is given by:

[0067] PeerManager="uuid: E6CAB760-6863-43e8-8184-CC22FB4CB62C"

[0068] PeerServiceID="urn:upnp-org:serviceId:ConnectionManager"

[0069] PeerConnectionID="25"

[0070] ConnectionID="3"

[0071] In this way, 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.

[0072] The control point CP instructs the media renderer MR to execute the SetAVTransport URI() action of the AV transport service. At this time, as an argument, the control point CP gives virtual connection information acquired in advance from the media renderer MR. As a result of the execution of the SetAVTransportURI() action, the media renderer MR obtains the URI of the content data specified by the user of the control point CP from the control point CP.

[0073] The control point CP instructs the media renderer MR to execute the Play() action of the AV transmission service (step S16). At this time, as an argument, the control point CP also gives the virtual connection information obtained in advance from the media renderer MR. As a result of the execution of the Play() action, the media renderer MR obtains content data from the media server MS to reproduce the content data, the content data having the URI given by the control point CP in step S15.

[0074] More specifically, the actual connection management unit 32 in the media renderer MR establishes an actual connection to the actual connection management unit 22 in the media server MS (steps S17 and S18).

[0075] FIG. 7 is a flowchart showing the flow of the actual connection establishment process (step S17) on the side of the media presenter MR.

[0076] The actual connection management unit 32 in the media renderer MR searches the connection map 34 to find a channel. When the actual connection management unit 32 is instructed to execute the SetAVTransportURI() action or the Play() action, the virtual connection information received from the control point CP is registered in this In the channel (step B1).

[0077] When the channel is found (Yes in step B2), the actual connection information is registered in the channel (step S3). More specifically, the value identifying the actual connection is set in the handle field (see Figure 2), the status field is set to inactive, and the appropriate initial value is set in the final closing time field.

[0078] The actual connection management unit 32 transmits the actual connection establishment request to the actual connection management unit 22 of the media server MS (step B4), where the actual connection establishment request includes virtual connection information. More specifically, the actual connection establishment request is transmitted through a GET (get) request of HTTP. In this request, for example, the following pieces of information are added to the user-defined field of the request header field of the GET request.

[0079] Get/foo/bar.mpgHTTP/1.0

[0080] X-AV-ConnectionInfo: PeerUDN=uuid: E6CAB760-6863-43e8-8184-CC22FB4CB62C;

[0081] PeerServiceID=urn: upnp-org: serviceId: ConnectionManager;

[0082] PeerConnectionID=25

[0083] UDN=uuid: B7DA4840-C028-4259-A56D-59551C79BF30;

[0084] ServiceID=urn: upnp-org: serviceId: ConnectionManager;

[0085] ConnectionID=3

[0086] This example includes all request headers. "X-AV-ConnectionInfo:" to "ConnectionID=25" are expressed as one line. In this example, the virtual connection information associated with the actual connection establishment request is stored in the X-AV-ConnectionInfo field. The X-AV-ConnectionInfo field consists of six parts separated by a semicolon (;). In the four parts, namely PeerUDN, PeerServiceId, PeerConnecionID and ConnecionID, the values ​​corresponding to the PeerManager, PeerServiceID, PeerConneeionID and ConnecionID of the virtual connection information managed by the media renderer MR and allocated in step S14 are hidden. In the two remaining parts, UDN and ServieeId, the UDN of the media renderer holding the virtual connection information and the ServiceId of the connection manager service are hidden. The uniqueness of the virtual connection information expressed by the previous four parts is ensured. Since the X-AV-ConneetionInfo field is not included in the standard specification and is defined by the user, the HTTP server of the present invention does not use the HTTP server of the present invention to execute the process by ignoring this field. At this time, the HTTP server is not blocked in any way.

[0087] Returning to FIG. 7, the actual connection management unit 32 in the media renderer MR that transmits the actual connection establishment request waits for a response from the actual connection management unit 22 in the media server MS (step B5). When the actual connection management unit 32 is notified from the actual connection management unit 22 that the actual connection information is registered, that is, when the actual connection is established between the actual connection management units 22 and 32, the connection map is updated (step B6). That is, the status field on the channel is activated. Thereafter, the actual connection management unit 32 in the media renderer MR receives content data from the actual connection management unit 22 in the media server MS according to HTTP and reproduces the received content data.

[0088] When the channel is not acquired in step S2 (No in step B2), the media renderer MR returns an error to the control point CP (step B7).

[0089] FIG. 8 is a flowchart showing the flow of the actual connection establishment process (step S18 in FIG. 3) on the side of the media server MS.

[0090] The actual connection management unit 22 in the media server MS that receives the actual connection establishment request (step C1) in step B4 of FIG. 7 extracts virtual connection information from the received establishment request (step C2).

[0091] The actual connection management unit 22 searches the connection map 24 for a channel corresponding to the extracted virtual connection information (YES in step C3, step C4). For example, the actual connection management unit 22 searches the connection map 24 for a channel that includes the same value as the connection ID of the media server MS, and the value of the connection ID of the media server MS is included in the virtual connection information.

[0092]In this case, the ConnectionID (in X-AV-ConnectionInfo) allocated in the media renderer MR and included in the virtual connection information extracted from step C3 is "3". This is different from the ConnectionID (=Peer ConnectionID) = "-1" recognized by the media server MS on the media presenter MR side. This difference is based on the difference between the content of the argument when the PFC() action of the media server MS and the media renderer MR is called by the control point CP. In the media server MS, this difference is negligible.

[0093] When there is no corresponding channel (No in step C5) or when the actual connection establishment request does not include virtual connection information (No in step C3), an available channel is searched (steps C6 and C7).

[0094] When the channel can be acquired in step C5 or C7 (YES in step C5, yes in step C5), the actual connection management unit 22 updates the actual connection information in the acquired channel (step C8). That is, the value for identifying the actual connection is set in the handle field, the activation state field, and the appropriate initial value is set in the final closing time field. Here, it is assumed that virtual connection information is included in step C3, and it is assumed that the information shown in FIG. 14 is registered as actual connection information.

[0095] When the virtual connection information is not included in step C3 (No in step C3), the flow continues to step C6 to register the actual connection information without linking it with the virtual connection information. That is, it is determined that the actual connection establishment request is not based on the reserved virtual connection. Update the connection map without associating it with a specific virtual connection. In this way, the connection compatibility with the other party's device operating based on the conventional method can be maintained. The actual connection that is not related to the specific virtual connection can be processed, so that after the establishment, the priority of maintaining the actual connection is reduced (see steps A8 and A9 in FIG. 6).

[0096] The actual connection management unit 22 that has registered the actual connection information responds to the actual connection management unit 32 in the media renderer MR to inform the actual connection management unit 32 that the actual connection has been established between the actual connection management unit 22 and the media renderer MR. Between the management units 32 (step C10).

[0097] When the actual connection management unit 22 informs the media renderer MR that the actual connection has been established, the actual connection management unit 22 hides the virtual connection information on the media server side into the HTTP GET response header field in the following manner. This example includes the entire response header. X-AV-ConnectionInfo:" to "Connection=25" are expressed by one line. HTTP/1.1 200 OKDate: MON, 29 Mar 2004 05:37; 17 GMTServer: Apache/1.3.29(Unix) Last-Modified: Thu , 25 Jul 2002 06:51:36 GMTEtag: "7e0aa2-bf8-3d3f9ff8" Accept-Ranges: bytesContent-Lenghth: 3064000Connection: closeContent-Type: video/mpegX-AV-ConnectionInfo:

[0098] PeerUDN=uuid: B7DA4840-C028-4259-A56D-59551C79BF30;

[0099] PeerServiceId=urn: upnp-org: serviceId: ConnectionManager;

[0100] PeerConnectionID=-1;

[0101] UDN=uuid: E6CAB760-6863-43e8-8184-CC22FB4CB62C;

[0102] ServiceId=urn: upnp-org: serviceId: ConnectionManager;

[0103] ConnectionID=25

[0104] The content is basically the same as the information hidden in the GET request in step B4. However, the difference between the content and the information hidden in the GET request is that the content has a viewpoint from the HTTP server, that is, the media server MS side. The HTTP client, that is, the media renderer, can recognize that the virtual connection is connected to the actual connection in the other party's device by receiving the virtual connection information.

[0105] The ConnectionID (PeerConnectionID in X-AV-ConnectionInfo) of the media renderer MR side identified by the media server MS is "-1" and is different from the ConnectionID="3" allocated in the media renderer MR. This difference is based on the difference in the content of the argument used when the PFC() action of the media server MS and the media renderer MR is called by the control point CP. In the media renderer MR, this difference can be ignored.

[0106] When the response from the media server MS is the result of the process performed by "Yes" in step C7, the actual connection information in the media server MS is not properly associated with the virtual connection information. As a result, the information stored in the X-AV-ConnectionInfo may be incomplete, or there may be no X-AV-ConnectionInfo field. In this case, the media renderer MR can recognize that although the actual connection can be established, the actual connection cannot be associated with the virtual connection in the media server MS.

[0107] In the above series of programs, the information that can be used to identify the uniqueness of the virtual connection can be limited to the ConnectionID allocated in the media server MS, and important information is assigned to the ConnectionID. The ConnectionID is used by the media server MS and the media renderer. MR to distinguish, it has a matching value in the two devices.

[0108] In this case, the virtual connection information is defined as a set of ConnectionID, the virtual connection information is such as the information managed by the media server MS and the media renderer MR and related to the actual connection information and such information as stored in steps B4 and C10 The information in the X-AV-ConnectionInfo, the ConnectionID is identified and used to be allocated to the media server MS, the UDN and serviceID of the media server MS, the media server MS and the media renderer MR, and can perform the above-mentioned series of processes .

[0109] Moreover, the other virtual connection information may be composed of any piece of information or a combination of multiple pieces of information.

[0110] Returning to FIG. 8, when the channel cannot be acquired in step C7 (No in step C7), the actual connection management unit 22 responds to the actual connection management unit 32 in the media renderer MR to inform the actual connection management unit 32 of the actual connection establishment Failed (step C9).

[0111] Returning to FIG. 3, the control point CP instructs the virtual connection management units 23 and 33 in the media server MS and the media renderer MR to execute the ConnectionComplete() action (steps S19 and S20) according to, for example, the user's instruction. At this time, the respective virtual connection information is assigned to the virtual connection management units 23 and 33. In this way, the virtual connection corresponding to the designated virtual connection information and the actual connection related to the virtual connection are released (connection release process).

[0112] FIG. 9 is a flowchart for explaining the flow of the connection release process (first connection release process). The following processes are respectively executed in the media server MS and the media renderer MR.

[0113] A channel including virtual connection information designated by the control point CP is searched on the connection map (step D1).

[0114] When the channel is found (Yes in step D2), the virtual connection information is deleted from the channel (the virtual connection is released) (step D3).

[0115] The actual connection information corresponding to the deleted virtual connection information is deleted from the channel (for example, at least the handle is empty and the state is inactive) (the actual connection is released) (step D4). In the case of data transmission, the actual connection information is deleted after the data transmission is stopped. In this way, the channel is released.

[0116] When the channel is not found in step D2 (No in step D2), the error is returned to the control point CP (step D5).

[0117] In the above-mentioned first connection release process, the control point CP causes the media server MS and the media renderer MR to execute the ConnectionComplete() action to confirm the release of the connection, that is, the user releases the connection through instructions. The automatic release of the connection will be described below.

[0118] FIG. 10 is a flowchart for explaining the flow of the automatic release process (second connection release process) of the connection.

[0119] The virtual connection management units 23 and 33 in the media server MS and the media renderer MR select a channel (step E1) to determine whether actual connection information is registered (step E2).

[0120] When the actual connection information is registered (Yes in step E2), it is judged whether the actual connection is active or inactive.

[0121] When the actual connection is inactive (Yes in step E3), the "final inactive transition time + pause time (time out)-current time" is calculated based on the final inactive transition time included in the actual connection information (step E4) . The pause time is a predetermined value. Although the actual connection is inactive, the virtual connection continues during the time represented by the pause time. This is effective in repeatedly establishing and disconnecting the connection in the reproduction process.

[0122] When the calculated value is 0 or greater than 0 (Yes in step E4), that is, after the pause time has elapsed after the final inactive transition time, the connection release process is executed according to the flowchart in FIG. 9 (step E5).

[0123] When the actual connection information is not registered in step E2 (No in step E2), when the actual connection is activated in step E3 (No in step E3), and when the value calculated in step E4 is less than 0 (step E4 Yes), if the process continues (Yes in step E6), select the next channel (step E1) to perform the same process as described above.

[0124] Fig. 11 is a flowchart for explaining the update process of the final inactive transition time.

[0125] When the actual connection state transitions to the inactive state (step F1), the actual connection management units 22 and 32 in the media server MS and the media renderer MR search the connection map for a channel corresponding to the actual connection (step F2).

[0126] When the virtual connection information is not registered in the found channel (No in step F3), the actual connection information is deleted in the same manner as step D4 in FIG. 9 to release the channel (step F6).

[0127] On the other hand, when the virtual connection information is registered in the found channel (Yes in step F3), the status field in the actual connection information is activated (step F4), and the final inactive transition time in the final closing time field is updated (step F4). F5).

[0128] In this case, although the connection release process can also be executed according to the first and second connection release processes (see Figs. 9 and 10), it can be performed in the manner shown in the flowcharts in Figs. 12 and 13, The connection release process is performed by adding the function of the UPnP control point to the media server MS and the media renderer MR.

[0129] FIG. 12 is a flowchart for explaining the flow of the third connection release process.

[0130] The media server MS or the media renderer MR receives an end notification (for example, SSDP: Goodbye) from the media renderer MR, the media server MS, or a peripheral UPnP device (media server or media renderer) (step G1). The end notification includes the UDN of the device and so on.

[0131] The UDN included in the end notification is extracted to search the connection map to check whether there is a channel with the extracted UDN (steps G2 and G3).

[0132] When a channel is found (Yes in step G4), the channel is released according to the flowchart in FIG. 9 (step G5). When the channel is not found (No in step G4), no special process is performed.

[0133] FIG. 13 is a flowchart for explaining the flow of the fourth connection release process.

[0134] The media server MS or the media renderer MR selects a channel from the connection map (step H1). When the virtual connection information is registered in the selected channel (Yes in step H2), SSDP: Discovery (search program for searching UPnP) is executed to discover the UDN in the virtual channel information (steps H3 and H4).

[0135] When a response cannot be obtained from the device having the UDN (No in step H5), it is determined that the device is not connected to the network, and the channel is released (step H6).

[0136] When virtual connection information is not registered in step H2 (No in step H2), when a response is obtained in step H5 (Yes in step H5), and when the process continues after step H6 (Yes in step H7), select One channel (step H1).

[0137] In this way, when the action of the other device ends or is not recognized by the program as shown in FIGS. 12 and 13, the channel allocated to the other device can be released.

[0138] In the above-described embodiment, pull-type streaming is performed in which an actual connection is established from a media reproducing party such as HTTP-GET to a media provider to request data transmission. However, the present invention can also be applied to Push-type streaming. In this case, in the traditional method, the media server side serving as the media sender associates the actual connection with the virtual connection when establishing the actual connection. In the media renderer of the media reproducing party, the virtual connection can be associated with actual resources according to the present invention.

[0139] The present invention can be applied to a protocol in which virtual connection information is hidden in the establishment of an actual connection, and the hidden virtual connection information can be extracted. For example, when using RTSP/RTP/UDP, user-defined headers can be added to RTSP. Therefore, when the virtual connection is hidden in RTSP, the present invention can be applied.

[0140] Think of this embodiment as similar to cookies or session IDs used in web applications. However, one of the differences between them is that, for example, in a normal network application, only session information is exchanged between the server and the client. In contrast to this, in this embodiment, the control point can transmit session information between the server and the client.

[0141] In the above description, all or some of the functions of the components shown in FIG. 1 can be implemented as hardware, can be implemented by causing a computer to execute a program generated by a common programming technique, or can be implemented in the above two ways.

[0142] As described above, according to this embodiment, during the establishment of the actual connection, the virtual connection information is transmitted to the other party's device. For this reason, although the actual connection is formed after the virtual connection is formed, the actual connection and the virtual connection can be linked to each other. Therefore, the actual connection can be appropriately controlled through the virtual connection.

[0143] According to this embodiment, based on the other party's device identifier (UDN) extracted from the virtual connection information, the action state of the other party's device is recognized. When it is determined that the other party's device is in an inactive state, the channel is released. Therefore, channel management can be appropriately performed.

[0144] According to this embodiment, the channel is released after a predetermined period of time or more from the final inactive transition time of the actual connection. Therefore, channel management can be appropriately performed.

[0145] According to this embodiment, when the virtual connection information is not included in the actual connection establishment request, the channel registered in the virtual connection establishment is not allocated to the establishment request (see No in steps C6 and C7). Perform data transmission based on the UPnP AV protocol more appropriately.