WO2016159727A1 - 멀티미디어 시스템에서 디바이스들 간에 통신 방법 및 장치 - Google Patents

멀티미디어 시스템에서 디바이스들 간에 통신 방법 및 장치 Download PDF

Info

Publication number
WO2016159727A1
WO2016159727A1 PCT/KR2016/003433 KR2016003433W WO2016159727A1 WO 2016159727 A1 WO2016159727 A1 WO 2016159727A1 KR 2016003433 W KR2016003433 W KR 2016003433W WO 2016159727 A1 WO2016159727 A1 WO 2016159727A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
request
service
content
communication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/KR2016/003433
Other languages
English (en)
French (fr)
Inventor
류영선
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020150080209A external-priority patent/KR102335007B1/ko
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Priority to CN202210172370.8A priority Critical patent/CN114501118B/zh
Priority to EP16773508.3A priority patent/EP3280148B1/en
Priority to CN201680019429.2A priority patent/CN107431843B/zh
Priority to CN202210173221.3A priority patent/CN114513696B/zh
Priority to JP2017551303A priority patent/JP6728218B2/ja
Priority to US15/562,296 priority patent/US11159844B2/en
Publication of WO2016159727A1 publication Critical patent/WO2016159727A1/ko
Anticipated expiration legal-status Critical
Priority to US17/509,557 priority patent/US11606601B2/en
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display

Definitions

  • the present invention relates to a method and apparatus for transmitting and receiving various information such as broadcast service and content related information between devices in a multimedia system.
  • a digital TV installed in a home and a mobile terminal such as a smart phone or a tablet communicate with each other to continuously watch content that the user watched on the digital TV on the mobile terminal, or to continuously watch content that the user watched on the mobile terminal on the TV.
  • Multi-screen services are provided.
  • the digital TV or a set top box (STB) connected to the digital TV is referred to as a primary device (PD) for use of a broadcast service or content
  • the portable terminal is used for a broadcast service or content. It will be referred to as an auxiliary terminal (Companion Device: CD) for.
  • FIG. 1 is a diagram schematically illustrating an example of a general multimedia system supporting a multi-screen service.
  • the PD 110 may receive various broadcast services such as terrestrial broadcast and cable broadcast by wire or wirelessly.
  • the PD 110 may be installed with various applications 111 related to the use of the broadcast service, and includes a CS (Companion Screen) manager 113 for communicating with the CD 130 for the multi-screen service.
  • various applications 131 related to the use of a broadcast service may be installed on the CD 130.
  • FIG. 1 only one PD 110 and CD 130 are shown for convenience of description, but one or more PDs and CDs may exist.
  • the PD 110 and the CD 130 may communicate with each other through various wireless or wired communication methods such as WiFi.
  • the CD 130 discovers whether there is a PD 110 available for use of the multi-screen service according to the execution of the application 131 (101).
  • the application 131 of the CD 130 communicates with the CS manager 113 to launch an application 111 of the PD 110 (103).
  • the CS manager 113 drives 105 the application 111 of the PD 110.
  • the PD 110 and the CD 130 exchange data necessary for using the multi-screen service through the applications 111 and 131.
  • the multimedia system of FIG. 1 is suitable for an application-centric model in which applications 111 and 131 are driven in the PD 110 and the CD 130 to transmit and receive necessary information through inter-application communication.
  • the application 111 of the PD 110 when the application 111 of the PD 110 is not provided through the multimedia system or the application 111 cannot be driven, only the application 131 of the CD 130 is driven, so that the PD 110 is executed. ) And the CD 130 does not communicate between the applications. In this case, since the PD 1110 cannot run a related application for communication between applications, the PD 1110 cannot stably provide a multi-screen service using the PD 110 and the CD 130.
  • the present invention provides a communication method and apparatus for efficiently transmitting and receiving information between devices in a multimedia system.
  • the present invention provides a method and apparatus for transmitting and receiving broadcast related information between a PD and a CD without running an application in the PD in a multimedia system.
  • a communication method between devices includes a process in which a first device searches for a second device for use of a broadcast service or content, and the first device broadcasts the broadcast from the second device. Acquiring second information about at least one service endpoint for receiving a first information related to a service or the content, and the first device using the second information, the second information related to the broadcast service or the content; Requesting the transmission of the first information, and in response to the request, the first device receiving the first information from the second device.
  • a first device for performing communication between devices in a multimedia system may include a communication interface for communicating with a second device for using a broadcast service or content, and the second device through the communication interface.
  • Search for a device obtain second information on at least one service endpoint for receiving first information related to the broadcast service or the content from the second device, and use the second information to determine the broadcast service or
  • a control unit for requesting transmission of the first information related to the content and controlling receiving the first information from the second device in response to the request.
  • FIG. 1 is a diagram schematically illustrating an example of a general multimedia system supporting a multi-screen service
  • FIG. 2 is a diagram illustrating a configuration of a multimedia system for performing communication between devices according to an embodiment of the present invention
  • FIG. 3 is a diagram illustrating a method for transmitting and receiving PD status information through communication between devices in a multimedia system according to an embodiment of the present invention
  • FIG. 4 is a view for explaining a procedure for selecting a method for requesting PD status information according to an embodiment of the present invention
  • FIG. 5 is a diagram illustrating a procedure of processing a response of a PD to a request using a WebSocket protocol according to an embodiment of the present invention
  • FIG. 6 is a diagram illustrating an operation of transmitting and receiving PD status information through communication between devices according to an embodiment of the present invention.
  • the sub-device may include broadcast related information that is being played by a main device (eg, PD) that is receiving and playing a broadcast.
  • a main device eg, PD
  • CD broadcast program information
  • the PD and CD may include a primary device and a secondary device capable of transmitting and receiving a broadcast service, information necessary for receiving broadcast content, public information, or broadcast program information (hereinafter, the broadcast related information) through communication between devices. It may be understood in a generic sense.
  • One or more PD and CD may be present.
  • the PD may be a digital TV, an STB, or the like
  • the CD may be a mobile terminal such as a smartphone or a tablet.
  • a plurality of digital TVs may operate as a PD or a CD
  • a plurality of portable terminals may operate as a PD or a CD.
  • the CD directly requests the PD for the broadcast related information on the broadcast service or broadcast content being played in the PD in which the application for communication with the CD is not driven (or not provided), and according to the request,
  • the PD provides a specific method of providing the broadcast related information to the CD.
  • the application of the CD may receive the broadcast related information from the PD and provide the user with a broadcast service provided in the PD without the driving of the application of the PD.
  • the broadcast associated information is various state information such as an identifier, data, playback information, alarm information, etc. for a broadcast service or broadcast content being played in the PD
  • the broadcast related information may be referred to as PD state information (or “PD”).
  • Information related to the services and / or content of the " The PD status information may include, for example, identification information (content ID (CID)) of a broadcast service or content, electronic service guide (ESG) information, media data, media timeline information, media playback information, and emergency. It may include at least one of emergency alert information (eam).
  • FIG. 2 is a diagram illustrating a configuration of a multimedia system for performing communication between devices according to an embodiment of the present invention.
  • the PD 210 controls an application 211, a CS manager 213, a web socket (WS) server / web server 215, and an electronic service guide (ESG) handler / media player 217.
  • the CD 230 includes an application 231 for requesting and receiving the PD status information from the PD 210.
  • the CD 230 may provide a user with a broadcast service or broadcast content being played in the PD 210 using the PD state information.
  • the application 211 may be a variety of applications associated with the broadcast service or broadcast content. Also, the application 211 may perform communication between the CD 230 and the application in the same manner as the application 111 described with reference to FIG. 1. Therefore, the application 211 is not an essential component in an embodiment of the present invention, and may be optionally included in the PD 210.
  • the CS manager 213 performs operations for interworking between the PD 210 and the CD 230. The operations are in response to an available PD discovery request 201 received from the CD 230, processing of a launch request of the application 211 from the CD 230, and the present invention.
  • the PD status is transmitted from the ESG handler / media player 217. At least one of receiving information (ie, information related to the service and / or content of the PD) and providing the same to the CD 230.
  • the WS server / Web server 215 is used as a communication interface for communicating with the CD 230 and is illustrated as a separate component from the CS manager 213. It is also possible that 213 includes a WS server / Web server 215.
  • the WS server / Web server 215 may use a Web Socket protocol for bidirectional communication with the CD 230.
  • the PD status information ie, information related to the service and / or content of the PD
  • the Web Socket protocol is handled at the WS server.
  • the WS server / Web server 215 also transmits the PD status information (ie, information related to the PD's service and / or content) to the CD 230 using the HTTP protocol.
  • the HTTP protocol is handled in a web server.
  • the ESG handler processes the ESG carried on the broadcast program, and for providing the PD status information 205, at least one requested from the CS manager 213.
  • the information is transmitted to the CS manager 213 or the WS server / Web server 215.
  • the media player in the ESG handler / media player 217 plays a broadcast program, and the CS manager 213 provides at least one information requested from the CS manager 213 to provide the PD status information 205. Or to the WS server / Web server 215.
  • the configuration of the PD 210 and the CD 230 illustrated in FIG. 2 illustrates one embodiment in the form of a functional block.
  • the PD 210 communicates with at least one processor (that is, a controller) and a WS server / Web server 215 for the functions of the CS manager 213 and the ESG handler / media player 217.
  • Application 211 of PD 210 may be omitted as it is an optional component as described above.
  • the CD 230 controls a storage unit in which the application 231 is installed, a communication interface for communicating with the PD 210, an overall operation for driving the application 231, and requesting and receiving the PD status information. It may be implemented to include a control unit.
  • the WS server / Web server 215 and the ESG handler / media player 217 respectively show the WS server and the Web server, and the ESG handler and the media player as one block.
  • related components are shown in one block.
  • the WS server and the web server may be implemented in separate blocks, and the SG handler and the media player may be implemented in separate blocks.
  • FIG. 3 is a diagram illustrating a method of transmitting and receiving PD status information through communication between devices in a multimedia system according to an exemplary embodiment of the present invention.
  • the CD 230 searches whether there is a PD available in the network in step 303.
  • the discovery process can generally use the Simple Service Discovery Protocol (SSDP) or the Discovery and Launch Protocol (DIAL), and other protocols may be used depending on how it is implemented.
  • SSDP Simple Service Discovery Protocol
  • DIAL Discovery and Launch Protocol
  • the PD 210 and the CD 230 may perform communication in various wireless communication or wired communication networks such as WiFi, Bluetooth, and Near Field Communication (NFC).
  • NFC Near Field Communication
  • the CS manager 213 of the PD 210 responds to the discovery request of the CD 230.
  • the information transmitted by the PD 210 in response to the CD 230 is information about the PD 210 and a service endpoint where the CD 230 can request PD status information from the PD 210. At least one of information (eg, URL information used to receive PD status information, etc.).
  • the information providing method of the service endpoint will be described later.
  • the service endpoint includes, for example, at least one of a service endpoint of a Web server and a service endpoint of a WS server.
  • the CD 230 requests PD status information (ie, information related to the service and / or content of the PD) from the PD 210 using the information of the service endpoint.
  • the request for the PD status information may be performed through an HTTP GET Method or a Web Socket, and the PD status information may be, for example, as described above, for example, identification information (CID), ESG information, media data, and media timeline of a broadcast service or content. It may include at least one of (timeline) information, media playback information (playback), and emergency alert (Emergency Alert) information (eam).
  • the request for the PD status information is received by the WS server / Web server 215 is delivered to the ESG handler / media player 217, which is a functional block for processing the information.
  • the function block may be an emergency alarm manager for processing emergency alarm information.
  • the information processed by the ESG handler / media player 217 or the emergency alarm manager is transmitted to the WS server / Web server 215 in step 311, and the WS server / Web server 215 includes the transmitted information in step 313.
  • PD status information is transmitted to the CD 230.
  • the CS manager 213 may control the request reception of the PD status information and the transmission of the PD status information.
  • the PD status information may be transmitted together with a predetermined status code.
  • the status code may be set to correspond to each piece of information included in the PD status information.
  • the application 231 (hereinafter referred to as CD application) of the CD 230 performs a search of available PDs in the network by using the SSDP protocol including specific ST (Search Target) header information as shown in Table 1 below. request.
  • the PD 210 Upon receiving the SSDP request, the PD 210 transmits an HTTP / 1.1 response including a LOCATION header as shown in Table 2 below.
  • the LOCATION header may include information for requesting a device description file of the PD 210.
  • the CD application receiving the response from the available PD 210 sends a request for the device description file of the PD as shown in Table 3 below with the LOCATION information received in step 2.
  • the PD 210 sends an Application-URL header as a response as shown in Table 4 together with the device description file.
  • the CD application requests service endpoint information using the Application-URL information received in step 4 as shown in Table 5 below.
  • the 'Hybrid broadcast broadband TV (HbbTV)' at the end of the Application-URL may be modified according to an embodiment according to the present invention.
  • the PD 210 responds with the HTTP / 1.1 OK header to the body as shown in Table 6 below.
  • Table 6 An example of configuring in XML (Extensible Markup Language) has been presented.
  • JSON JavaScript Object Notation
  • ⁇ X_HbbTV_App2AppURL> was used to provide the service endpoint of the WebSocket (WS) server.
  • the remaining ⁇ X_HbbTV_InterDevSyncURL> and ⁇ X_HbbTV_UserAgent> information may not be used depending on the implementation.
  • two pieces of information ie, ⁇ X_HbbTV_InterDevSyncURL> and ⁇ X_HbbTV_UserAgent>
  • ⁇ X_HbbTV_InterDevSyncURL> ie, ⁇ X_HbbTV_InterDevSyncURL>
  • ⁇ X_HbbTV_UserAgent> two pieces of information (ie, ⁇ X_HbbTV_InterDevSyncURL> and ⁇ X_HbbTV_UserAgent>) are not used.
  • a new field can be defined and used.
  • the endpoint information of the Web server that can send the HTTP GET request in step 4 is obtained, and the endpoint information of the WebSocket server is obtained in step 6. Can be.
  • the PD status information (ie, information related to the service and / or content of the PD) may include at least one of the information illustrated in Table 7 below.
  • Each information that may be included in the PD state information may be divided into two methods using HTTP GET or Web Socket protocol according to the frequency of information requested and the communication method (for example, bidirectional (not required)).
  • Table 1 exemplifies these two methods, but other methods may be used.
  • the service endpoint to which the HTTP request is to be sent may use the Application-URL obtained in Table 4 above. At this time, to distinguish the status information of the desired PD, it can be sent by attaching the status information ID illustrated in Table 7 above to the Application-URL. For example, an example of an HTTP GET request for requesting service and content ID information is shown in Table 8 below.
  • the PD's response can be sent in the HTTP status code and body.
  • Examples of the response are shown in Tables 9 to 12 below, and show an example of implementation of the PD status information response to the HTTP request.
  • the examples in ⁇ Table 9> to ⁇ Table 12> show an example of XML configuration, but depending on the implementation, any text-based format that can be sent as a body of an HTTP response such as JSON can be used.
  • each field included may also vary depending on implementation.
  • Table 9 Description Value deviceID Device ID ofprimary device deviceID serviceType The type of service contentID, esg, timeline, playback, eam service The information of current service esg The information of ESG timeline The media timeline ofcurrent service UTC time playbackState The playback state ofcurrent service EAM Emergency Alert Message
  • ⁇ Table 10> shows an example of configuration of the information included in the "service” field in the ⁇ Table 9>
  • ⁇ Table 11> is one of the information included in the "playbackState” field in the ⁇ Table 9>
  • An example configuration is shown.
  • ⁇ Table 12> shows an example of configuration of information included in the "EAM" field in the ⁇ Table 9>.
  • ⁇ deviceID> Describes the device ID of the PD that transmits PD status information.
  • ⁇ seviceType> Indicates the type of PD status information. Values that can be included in the PD state information include contentID, esg, timeLine, playbackState, and EAM.
  • ⁇ service> Contains information about the service currently being provided (running) by the PD.
  • the subfields of ⁇ service> are shown in ⁇ Table 10>.
  • ⁇ esg> Represents an ESG (Electronic Service Guide) information.
  • ⁇ timeline> Contains media timeline information of the service currently being provided.
  • the timeline information is described in Coordinated Universal Time (UTC) Time (ie, universal time). This timeline information is used for synchronization between a plurality of services or services between a plurality of devices in the same device.
  • UTC Coordinated Universal Time
  • This timeline information is used for synchronization between a plurality of services or services between a plurality of devices in the same device.
  • ⁇ playbackState> Contains the playback state information of the service currently being provided.
  • the subfields of ⁇ playbackState> are shown in ⁇ Table 11>.
  • ⁇ EAM> Contains an Emergency Alert Message.
  • the CD application of Table 8 or Table 10 can be transmitted from the PD to the CD application without the request process to the PD.
  • the subfields of the ⁇ EAM> are shown in Table 12.
  • ⁇ serviceName> Contains the name (text) of the service being provided by the PD.
  • ⁇ serviceID> Contains the ID of the service being provided by the PD.
  • ⁇ MPState> Represents reproduction state information of a service being provided. It can have values of PLAYING, PAUSED, STOPPED, FFOWARD, REWIND, BUFFERING, UNKNOWN.
  • ⁇ MPSpeed> Indicates the playback speed of the service being provided. It has a constant of 1 when playing at normal speed, and can take positive and negative values, respectively, when playing FFWOWRD (fast-forward) or REWIND.
  • ⁇ MediaURL> Describes the URL where the service (or content) is retransmitted when allowing the retransmission of the service (or content) being provided to another device.
  • the MediaURL may be understood, for example, as a network address for accessing a service (or content) that is retransmitted from the PD to the CD or from the CD to the PD.
  • ⁇ EAMID> Represents the ID of the Emergency Alert Mesasge.
  • ⁇ setnTimeStamp> Contains time information generated by the EAM.
  • the EAM contains valid time information.
  • ⁇ urgency> Indicates the importance of the EAM.
  • ⁇ Geo-loc> indicates the specific area information to which the EAM is applied.
  • ⁇ EAMContent> Contains an EAM message (text).
  • ⁇ RichEAMURL> Describes URL information that can be accessed when additional information such as image, video, and voice other than text is provided.
  • Information of the service endpoint to which the WebSocket request is sent may use ⁇ X_HbbTV_App2AppURL> obtained in Table 6. Since the WebSocket supports two-way communication and allows any format as its payload format, an embodiment of the present invention proposes the following XML payload format. However, as described above, depending on the implementation, any form supported by the WebSocket protocol such as JSON as well as XML can be used, and fields can be added or deleted as needed. Table 13 below shows an example of a service and content ID information request by a web socket.
  • the ⁇ statusID> field is used for requesting specific information, and the above example specifically illustrates a method for requesting service and content ID information. If this field is omitted, it is treated as a request for updating all the status information, and it is also possible to provide it to the CD whenever there is a change in the status information in the PD.
  • the command field indicates request and / or cancellation of corresponding information.
  • the CD application may request the PD to transmit the updated information. .
  • These requests are described in subscribe in the command field as shown in ⁇ Table 14> below. If you want to update an existing request, specify renew or cancel if you want to cancel. Each meaning is shown in the following ⁇ Table 14>.
  • the request for updated information is described through the commands of subscribe, renew, and cancel as shown in Table 14 below, but this is an example, and is related to the service and / or content as well as the update.
  • the command field may be understood as a subscription related command (or message) related to a request for request / update / cancellation of information related to the service and / or content.
  • Table 14 Command value meaning subscribe If there is an update to the information described as ⁇ statusID> in the PD, the PD is requested to be sent the updated information. If the default value is not specified, it is determined to subscribe. renew Update the update request. cancel Cancel the update request.
  • the duration field indicates the time duration of the request for the information.
  • the PD only sends an update of this information for the time described in the duration field. You can send infinite (or -1) if you want to keep getting information until the CD application sends a cancel request.
  • the duration field is not described, it may also be determined to be infinite.
  • the PD may inform the CD application of the processing result of the PD status information update request.
  • the PD status information update request may be understood as requesting transmission of updated PD status information to the PD when there is updated PD status information in the PD.
  • the processing result of the PD status information update request indicates that the PD has received the PD status information update request.
  • Table 15 shows an example of a processing result transmitted to a CD application when a PD receives a service and content ID information request by a web socket.
  • the processing result may be transmitted for at least one of the PD status information (ie, information related to the service and / or content of the PD) illustrated in Table 7.
  • the ⁇ statusID> field shows an example of a processing result for a service and content ID request by a web socket in ⁇ Table 13>.
  • ⁇ responseCode> indicates a result of the service and content ID information request in ⁇ Table 13>.
  • the ⁇ responseCode> may have the same meaning as a Status code in general HTTP. In the example of Table 15, "200", that is, the service and content ID information request has been successfully processed. If the service and content ID information request is rejected for some reason, for example, 400 number status codes may be transmitted.
  • ⁇ ack> indicates which request for ACK in ⁇ Table 13>. In the example, it indicates ACK for subscribe request, and the meaning of each is as shown in Table 16 below.
  • the duration field informs the CD application of the duration (that is, the subscription period) for transmitting the corresponding information (or updated information) in response to the request for service and content ID information in the ⁇ Table 13>.
  • the CD application requested the duration of the update to be infinite, for example, but the PD may determine and transmit the duration of the update to, for example, 1000 seconds.
  • the PD may transmit the updated service and content ID information to the CD.
  • Table 16 ack meaning subscribeAck Shows the result of processing the update request. renewAck Indicates that the processing result for the update request. cancelAck Indicates that the processing result for the cancellation request.
  • ack is mapped 1: 1 with the command value of Table 14. Therefore, in some cases, instead of using a separate ⁇ ack> field, the command field of ⁇ Table 14> may be jointly used and only its value may use the value defined in ⁇ Table 16>.
  • the status information update of the PD for the PD status information request using the WebSocket protocol can also be described by the formats described in Tables 9 to 16 above.
  • FIG. 5 is a diagram illustrating a procedure for processing a response of a PD to a request using the WebSocket protocol according to an embodiment of the present invention.
  • the procedure of FIG. 5 includes an event (for example, updating of PD status information) in the PD. When it occurs, it can be performed.
  • a PD first receives a request for PD status information from a CD application through a WebSocket protocol.
  • the received value is the same as the example of Table 13 above.
  • step 503 the PD analyzes the ⁇ command> field of the request using the received WebSocket protocol, and if the value of the ⁇ command> field is subscribed, an event is generated in this WebSocket connection when an event occurs in the PD in step 505. Subscribe (register) to send. If the value of the ⁇ command> field is canceled in step 503, the PD determines that the request is for canceling the subscription for the corresponding event, and in step 507, cancels the subscription and ends the response procedure.
  • step 505 the PD registers the requested event.
  • step 509 if the registration succeeds (or is accepted), the PD transmits the processing result to the CD application in step 513. On the other hand, if registration fails for any reason in step 509, the processing result is transmitted to the CD application in step 511, and the response procedure is terminated.
  • step 517 the PD analyzes the ⁇ statusID> field of the received request in step 501 Determine whether a request for PD status information has been received. If the request for the PD status information has not been received, there is no need to send the corresponding event to the CD application. In step 523, the event is ignored and the response procedure is terminated.
  • step 517 determines whether the request for the PD status information in the ⁇ statusID> field. If the request of the PD status information is not valid because the time described in the ⁇ duration> field has elapsed, the event does not need to be transmitted to the CD application. Therefore, the process is ignored and the response procedure is terminated. . If the request time described in the ⁇ duration> field is valid in step 519, the process proceeds to step 521. The PD transmits the corresponding event to the CD application using a web socket.
  • FIG. 4 is a diagram illustrating a procedure for selecting a method for requesting PD status information according to an embodiment of the present invention.
  • step 401 it is first determined whether the PD state information has a high request frequency. It is recommended to use HTTP, which is relatively inexpensive for requests when the request status of PD status information is low, and if the request is frequent, instead of making an HTTP request every time a request occurs, the channel continues to be connected once the connection is made. It is cost-effective to use a web socket that can maintain and transfer data through it. Therefore, it is better to use WebSockets when requests are frequent. In addition, the web socket can easily provide asynchronous communication.
  • step 403 it is determined whether bidirectionality is necessary.
  • Bidirectional refers to whether a CD application unilaterally requests a request for information from a CD application or when a change of state occurs in the PD, the information can be sent to the CD application without the request of the CD application.
  • WebSocket supports two-way communication, so if you need two-way communication, use WebSocket.
  • step 405 it is determined whether binary data is required to be transmitted.
  • HTTP can also send binaries, but WebSocket is more suitable for binary transfers because there is no limit to the data sent in both directions.
  • the PD state information may be requested using HTTP in step 407, or the PD state information may be requested using a web socket in step 409.
  • the method of transmitting the PD state information using the method of FIG. 4 described above is as follows.
  • service and content ID information it is generally sufficient to request the first time the CD application is launched. Therefore, it can be determined that the request frequency is low, and since the information is enough to be sent at the request of the initial CD application, there is no need for bidirectionality.
  • service information can generally be described as text information such as XML or JSON, it is sufficient to use HTTP when applied to the flowchart of FIG. 4.
  • the media play information In the case of the media play information, it indicates the status (playing, stopping, FF, etc.) of the media currently playing in the PD.
  • the request frequency is relatively low compared to the above media timeline information.
  • bidirectional communication is necessary because it is necessary to inform the CD application when the media's playback state has changed (e.g., from playback to interruption). Therefore, it is better to use a web socket in this case.
  • a broadcast service or broadcast content is provided from a service provider 601 or 603 to a plurality of devices 611 and 613 through a broadcasting network or a broadband network 61 and 63.
  • the CD application provides a method for requesting (65) and receiving (67) the PD status information, so that the CD application can be used to link with the PD without the PD application.
  • the existing companion screen structure and protocol it provides a way to receive the status information of the PD without additional configuration and cost.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

본 발명은 멀티미디어 시스템에서 디바이스들 간에 효율적으로 정보를 송수신하는 방법 및 장치에 대한 것으로서, 본 발명의 실시 예에 따른 멀티미디어 시스템에서 디바이스들 간의 통신 방법은, 제1 디바이스가 방송 서비스 또는 콘텐츠의 이용을 위한 제2 디바이스를 탐색하는 과정과, 상기 제1 디바이스가 상기 제2 디바이스로부터 상기 방송 서비스 또는 상기 콘텐트와 관련된 제1 정보를 수신하기 위한 적어도 하나의 서비스 종단점에 대한 제2 정보를 획득하는 과정과, 상기 제1 디바이스가 상기 제2 정보를 이용하여 상기 방송 서비스 또는 상기 콘텐츠와 관련된 상기 제1 정보의 전송을 요청하는 과정과, 상기 요청에 대한 응답으로, 상기 제1 디바이스가 상기 제2 디바이스로부터 상기 제1 정보를 수신하는 과정을 포함한다.

Description

멀티미디어 시스템에서 디바이스들 간에 통신 방법 및 장치
본 발명은 멀티미디어 시스템에서 디바이스들 간에 방송 서비스, 콘텐츠 관련 정보 등 각종 정보를 송수신하는 방법 및 장치에 대한 것이다.
멀티미디어 서비스를 제공하는 방송 시스템의 발전에 따라 유선 또는 무선 방송 시스템에서 다수의 디바이스들이 서로 통신하여 방송 서비스를 이용할 수 있는 기술들이 개발되고 있다. 일 예로 댁내 설치된 디지털 TV와, 스마트 폰, 테블릿 등의 휴대 단말이 서로 통신하여 사용자가 디지털 TV에서 시청하던 콘텐츠를 휴대 단말에서 이어서 시청하거나, 휴대 단말에서 사용자가 시청하던 콘텐츠를 TV에서 이어서 시청할 수 있는 멀티스크린 서비스 등이 제공되고 있다.
이하 본 명세서에서 상기 디지털 TV 또는 디지털 TV와 연결된 셋탑 박스(STB) 등을 방송 서비스 또는 콘텐츠의 이용을 위한 프라이머리 디바이스(Primary Device : PD)라 칭하고, 상기 휴대 단말 등을 방송 서비스 또는 콘텐트의 이용을 위한 보조 단말(Companion Device : CD)라 칭하기로 한다.
도 1은 멀티스크린 서비스를 지원하는 일반적인 멀티미디어 시스템의 예를 간략히 나타낸 도면이다.
도 1을 참조하면, PD(110)는 지상파 방송, 케이블 방송 등의 각종 방송 서비스를 유선 또는 무선으로 수신할 수 있다. PD(110)에는 방송 서비스의 이용과 관련된 각종 애플리케이션(111)이 설치될 수 있으며, 멀티스크린 서비스 등을 위해 CD(130)와 통신을 위한 CS(Companion Screen) 매니저(113)를 포함한다. 그리고 CD(130)에도 방송 서비스의 이용과 관련된 각종 애플리케이션(131)이 설치될 수 있다. 도 1에서 PD(110)와 CD(130)는 설명의 편의상 하나만 도시하였으나, 하나 또는 복수의 PD, CD가 존재할 수 있다. 상기 PD(110)와 CD(130)는 WiFi 등의 각종 무선 또는 유선 통신 방식을 통해 서로 통신할 수 있다.
도 1에서 CD(130)는 애플리케이션(131)의 실행에 따라 멀티스크린 서비스의 이용을 위해 가용한 PD(110)가 있는지 탐색(discovery)한다(101). 가용한 PD(110)가 탐색된 경우, 상기 CD(130)의 애플리케이션(131)은 PD(110)의 애플리케이션(111)을 구동(launch)하기 위해 CS 매니저(113)와 통신한다(103). 그러면 CS 매니저(113)는 PD(110)의 애플리케이션(111)을 구동시킨다(105). 상기한 동작과 같이 PD(110)와 CD(130)는 애플리케이션(111, 131)를 통해 멀티스크린 서비스의 이용을 위해 필요한 데이터를 주고 받는다. 도 1의 멀티미디어 시스템은 PD(110)와 CD(130)에서 각각 애플리케이션(111, 131)이 구동되어 애플리케이션간 통신을 통해 필요한 정보를 주고 받는 애플리케이션 중심 모델에 적합하다.
그러나 도 1의 시스템에서 PD(110)의 애플리케이션(111)이 멀티미디어 시스템을 통해 제공되지 않거나 또는 애플리케이션(111)을 구동할 수 없는 경우, CD(130)의 애플리케이션(131)만 구동되므로 PD(110)와 CD(130)에서 애플리케이션간 통신이 이루어지지 않는다. 이 경우 PD(1110)에서는 애플리케이션간 통신을 위한 관련 애플리케이션을 구동시킬 수 없게 되므로 PD(110)와 CD(130)를 이용한 멀티스크린 서비스 등을 안정적으로 제공할 수 없게 된다.
본 발명은 멀티미디어 시스템에서 디바이스들 간에 효율적으로 정보를 송수신하기 위한 통신 방법 및 장치를 제공한다.
또한 본 발명은 멀티미디어 시스템에서 PD에서 애플리케이션의 구동 없이도 PD와 CD 간에 방송 관련 정보를 송수신하는 방법 및 장치를 제공한다.
본 발명의 실시 예에 따른 멀티미디어 시스템에서 디바이스들 간의 통신 방법은, 제1 디바이스가 방송 서비스 또는 콘텐츠의 이용을 위한 제2 디바이스를 탐색하는 과정과, 상기 제1 디바이스가 상기 제2 디바이스로부터 상기 방송 서비스 또는 상기 콘텐트와 관련된 제1 정보를 수신하기 위한 적어도 하나의 서비스 종단점에 대한 제2 정보를 획득하는 과정과, 상기 제1 디바이스가 상기 제2 정보를 이용하여 상기 방송 서비스 또는 상기 콘텐츠와 관련된 상기 제1 정보의 전송을 요청하는 과정과, 상기 요청에 대한 응답으로, 상기 제1 디바이스가 상기 제2 디바이스로부터 상기 제1 정보를 수신하는 과정을 포함한다.
또한 본 발명의 실시 예에 따른 멀티미디어 시스템에서 디바이스들 간의 통신을 수행하는 제1 디바이스는, 방송 서비스 또는 콘텐츠의 이용을 위한 제2 디바이스와 통신을 위한 통신 인터페이스와, 상기 통신 인터페이스를 통해 상기 제2 디바이스를 탐색하고, 상기 제2 디바이스로부터 상기 방송 서비스 또는 상기 콘텐트와 관련된 제1 정보를 수신하기 위한 적어도 하나의 서비스 종단점에 대한 제2 정보를 획득하며, 상기 제2 정보를 이용하여 상기 방송 서비스 또는 상기 콘텐츠와 관련된 상기 제1 정보의 전송을 요청하고, 상기 요청에 대한 응답으로, 상기 제2 디바이스로부터 상기 제1 정보를 수신하는 것을 제어하는 제어부를 포함한다.
도 1은 멀티스크린 서비스를 지원하는 일반적인 멀티미디어 시스템의 예를 간략히 나타낸 도면,
도 2는 본 발명의 실시 예에 따라 디바이스들 간에 통신을 수행하는 멀티미디어 시스템의 구성을 나타낸 도면,
도 3은 본 발명의 실시 예에 따른 멀티미디어 시스템에서 디바이스들 간의 통신을 통해 PD 상태 정보를 송수신하는 방법을 나타낸 도면,
도 4는 본 발명의 실시 예에 따라 PD 상태 정보를 요청하는 방법을 선택하는 절차를 설명하기 위한 도면,
도 5는 본 발명의 실시 예에 따라 WebSocket 프로토콜을 이용한 요청에 대한 PD의 응답을 처리하는 절차를 설명하기 위한 도면,
도 6은 본 발명의 실시 예에 따른 디바이스들 간의 통신을 통해 PD 상태 정보를 송수신하는 동작을 예시한 도면.
하기에서 본 발명의 실시 예들을 설명함에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다.
이하 설명될 본 발명의 실시 예는 복수의 디바이스들이 연결되어 있는 멀티미디어 시스템에서 멀티스크린 서비스를 제공하는 경우, 방송을 수신하여 재생하고 있는 주 디바이스(예컨대, PD)가 재생 중인 방송 관련 정보를 부 디바이스(예컨대, CD)에게 제공하는 방안을 제안한 것이다. 상기 PD, CD는 디바이스들 간에 통신을 통해 방송 서비스, 방송 콘텐츠의 수신을 위해 필요한 정보, 공공 정보, 또는 방송 프로그램 정보 등(이하, 상기 방송 관련 정보)를 송수신할 수 있는 주 디바이스와 부 디바이스를 통칭하는 의미로 이해될 수 있다. 상기 PD와 CD는 각각 하나 또는 복수 개가 존재할 수 있다.
일 예로 상기 PD는 전술한 것처럼 디지털 TV, STB 등이 될 수 있으며, 상기 CD는 스마트폰, 태블릿 등의 휴대 단말이 될 수 있다. 다른 예로 다수의 디지털 TV들이 PD 또는 CD로 동작할 수도 있으며, 다수의 휴대 단말들이 PD 또는 CD로 동작할 수도 있다. 본 발명의 실시 예에서 CD와 통신을 위한 애플리케이션이 구동되지 않은(또는 제공되지 않은) PD에서 재생중인 방송 서비스 또는 방송 콘텐츠 등에 대한 상기 방송 관련 정보를 CD가 PD에게 직접 요청하고, 그 요청에 따라 PD가 CD에게 상기 방송 관련 정보를 제공하는 구체적인 방안을 제공한다. 본 발명의 실시 예에서는 PD의 애플리케이션의 구동 없이도 CD의 애플리케이션은 PD로부터 상기 방송 관련 정보를 수신하여 사용자에게 PD에서 제공되는 방송 서비스 등을 사용자에게 제공할 수 있다. 본 발명의 실시 예에서 상기 방송 관련 정보는 PD에서 재생중인 방송 서비스 또는 방송 콘텐츠 등에 대한 식별자, 데이터, 재생 정보, 알람 정보 등의 각종 상태 정보이므로 상기 방송 관련 정보를 이하 PD 상태 정보(또는 "PD의 서비스 및/또는 콘텐츠와 관련된 정보")라 칭하기로 한다. 상기 PD 상태 정보는 예컨대, 방송 서비스 또는 콘텐츠의 식별 정보(콘텐츠 ID(CID)), ESG(Electronic Service Guide) 정보, 미디어 데이터, 미디어 타임라인(timeline) 정보, 미디어 재생 정보(playback), 그리고 긴급 알람(Emergency Alert) 정보(emergency alert message : eam) 중 적어도 하나를 포함할 수 있다.
도 2는 본 발명의 실시 예에 따라 디바이스들 간에 통신을 수행하는 멀티미디어 시스템의 구성을 나타낸 도면이다.
도 2를 참조하면, PD(210)는 애플리케이션(211), CS 매니저(213), WS(Web Socket) 서버/Web 서버(215), ESG(Electronic Service Guide) 핸들러/미디어 재생부(217)를 포함하며, CD(230)는 PD(210)에게 상기 PD 상태 정보를 요청하여 수신하기 위한 애플리케이션(231)을 포함한다. 상기 CD(230)는 상기 PD 상태 정보를 이용하여 PD(210)에서 재생중인 방송 서비스 또는 방송 콘텐츠 등을 사용자에게 제공할 수 있다.
도 2에서 상기 PD(210)의 구성을 설명하면, 애플리케이션(211)은 방송 서비스 또는 방송 콘텐츠와 연계된 각종 애플리케이션이 될 수 있다. 또한 상기 애플리케이션(211)은 도 1에서 설명한 애플리케이션(111)과 동일한 방식으로 CD(230)와 애플리케이션간 통신을 수행할 수도 있다. 따라서 상기 애플리케이션(211)은 본 발명의 실시 예에서 필수 구성은 아니며, 선택적으로 PD(210)에 포함될 수 있다. 상기 CS 매니저(213)는 PD(210)와 CD(230) 간의 연동을 위한 동작들을 수행한다. 상기 동작들은 CD(230)로부터 수신한 가용한 PD 탐색(discovery) 요청(201)에 대한 응답과, 상기 CD(230)로부터 애플리케이션(211)의 구동(Launch) 요청에 대한 처리, 그리고 본 발명의 실시 예에 따라 CD(230)로부터 WS(Web Socket) 서버/Web 서버(215)를 통해 상기 PD 상태 정보의 요청(203)을 수신한 경우, ESG 핸들러/미디어 재생부(217)로부터 상기 PD 상태 정보(즉 PD의 서비스 및/또는 콘텐츠와 관련된 정보)를 전달 받아서 CD(230)에게 제공하는 동작 중 적어도 하나를 포함한다.
도 2의 실시 예에서 WS 서버/Web 서버(215)는 CD(230)와 통신을 위한 통신 인터페이스로 이용되며, CS 매니저(213)와 분리된 구성 요소로 도시되어 있으나, 다른 구현 예로 상기 CS 매니저(213)가 WS 서버/Web 서버(215)를 포함하는 것도 가능하다. 상기 WS 서버/Web 서버(215)는 CD(230)와 양방향 통신을 위해 웹소켓(Web Socket) 프로토콜을 이용할 수 있다. 이 경우 웹소켓(Web Socket) 프로토콜을 이용하여 CD(230)에게 상기 PD 상태 정보(즉 PD의 서비스 및/또는 콘텐츠와 관련된 정보)를 전송한다. 상기 웹소켓(Web Socket) 프로토콜은 WS 서버에서 처리된다. 또한 상기 WS 서버/Web 서버(215)는 HTTP 프로토콜을 이용하여 CD(230)에게 상기 PD 상태 정보(즉 PD의 서비스 및/또는 콘텐츠와 관련된 정보)를 전송한다. 상기 HTTP 프로토콜은 Web 서버에서 처리된다. 도 2의 ESG 핸들러/미디어 재생부(217)에서 ESG 핸들러는 방송 프로그램에 실려 전송된 ESG를 처리하며, 상기 PD 상태 정보의 제공(205)을 위해, CS 매니저(213)로부터 요청된 적어도 하나의 정보를 상기 CS 매니저(213) 또는 WS 서버/Web 서버(215)로 전달한다. 상기 ESG 핸들러/미디어 재생부(217)에서 미디어 재생부는 방송 프로그램을 재생하며, 상기 PD 상태 정보의 제공(205)을 위해, CS 매니저(213)로부터 요청된 적어도 하나의 정보를 상기 CS 매니저(213) 또는 WS 서버/Web 서버(215)로 전달한다.
도 2에서 예시된 PD(210)와 CD(230)의 구성은 일 구현 예를 기능블록 형태로 나타낸 것이다. 상기 PD(210)는 CS 매니저(213)와 ESG 핸들러/미디어 재생부(217)의 기능을 담당하는 적어도 하나의 프로세서(즉 제어부)와 WS 서버/Web 서버(215)의 기능을 담당하는 통신 인터페이스, 그리고 애플리케이션(211)이 설치되는 저장부를 포함하여 구현될 수 있다. 상기 PD(210)의 애플리케이션(211)은 전술한 것처럼 선택적인 구성 요소이므로 생략될 수 있다. 또한 CD(230)는 애플리케이션(231)이 설치되는 저장부와, PD(210)와 통신을 위한 통신 인터페이스와, 애플리케이션(231)의 구동과 상기 PD 상태 정보의 요청 및 수신을 위한 전반적인 동작을 제어하는 제어부를 포함하여 구현될 수 있다.
한편 도 2의 예에서 WS 서버/Web 서버(215), ESG 핸들러/미디어 재생부(217)는 각각 WS 서버와 Web 서버, 그리고 ESG 핸들러와 미디어 재생부를 하나의 블록으로 함께 도시하였으나, 이는 설명의 편의를 위해 관련 구성 요소들을 하나의 블록으로 도시한 것이다. 상기 WS 서버와 Web 서버는 구분된 블록으로 구현될 수 있으며, 상기 SG 핸들러와 미디어 재생부도 구분된 블록으로 구현될 수 있다.
도 3은 본 발명의 실시 예에 따른 멀티미디어 시스템에서 디바이스들 간의 통신을 통해 PD 상태 정보를 송수신하는 방법을 나타낸 도면이다.
도 3을 참조하면, 301 단계에서 사용자의 키 조작 등에 의해 CD(230)의 애플리케이션(231)이 구동되면, 303 단계에서 CD(230)는 네트워크에서 가용한 PD가 존재하는 지 탐색한다. 이 탐색 과정은 일반적으로 SSDP(Simple Service Discovery Protocol)나 DIAL(Discovery and Launch Protocol)을 사용할 수 있으며, 구현하는 방식에 따라 다른 프로토콜이 사용될 수도 있다. PD(210)와 CD(230)는 WiFi, 블루투스, NFC(Near Field Communication) 등의 각종 무선 통신 또는 유선 통신 네트워크에서 통신을 수행할 수 있다. 305 단계에서 PD(210)의 CS 매니저(213)는 CD(230)의 탐색 요청에 응답한다. 이때 PD(210)가 CD(230)에게 그 응답으로 전송하는 정보는 PD(210)에 대한 정보, CD(230)가 PD(210)에게 PD 상태 정보를 요청할 수 있는 서비스 종단점(Service-endpoint)의 정보(예컨대, PD 상태 정보를 수신하는데 이용되는 URL 정보 등) 중 적어도 하나를 포함한다. 상기 서비스 종단점의 정보 제공 방법은 후술하기로 한다. 상기 서비스 종단점은 예컨대, Web 서버의 서비스 종단점과 WS 서버의 서비스 종단점 중 적어도 하나를 포함한다.
307 단계에서 CD(230)는 상기 서비스 종단점의 정보를 이용하여 PD(210)에게 PD 상태 정보(즉 PD의 서비스 및/또는 콘텐츠와 관련된 정보)를 요청한다. 상기 PD 상태 정보의 요청은 HTTP GET Method 또는 Web Socket을 통해 수행될 수 있으며, 상기 PD 상태 정보는 상기한 것처럼 예컨대, 방송 서비스 또는 콘텐츠의 식별 정보(CID), ESG 정보, 미디어 데이터, 미디어 타임라인(timeline) 정보, 미디어 재생 정보(playback), 그리고 긴급 알람(Emergency Alert) 정보(eam) 중 적어도 하나를 포함할 수 있다. 309 단계에서 상기 PD 상태 정보의 요청은 WS 서버/Web 서버(215)에서 수신하여 해당 정보를 처리하는 기능 블록인 ESG 핸들러/미디어 재생부(217)에 전달된다. 상기 해당 정보가 긴급 알람 정보인 경우, 상기 기능 블록은 긴급 알람 정보를 처리하는 긴급 알람 매니저가 될 수 있다. 311 단계에서 ESG 핸들러/미디어 재생부(217) 또는 긴급 알람 매니저에서 처리된 정보는 WS 서버/Web 서버(215)로 전달되고, 313 단계에서 WS 서버/Web 서버(215)는 전달된 정보를 포함하는 PD 상태 정보를 CD(230)에게 전송한다. 또한 상기 PD 상태 정보의 요청 수신, 그리고 상기 PD 상태 정보의 전송을 위한 제어는 CS 매니저(213)에서 수행될 수 있다. 그리고 상기 PD 상태 정보는 미리 정해진 상태 코드와 함께 전송할 수 있다. 상기 상태 코드는 상기 PD 상태 정보에 포함된 각 정보에 대응되게 설정될 수 있다.
이하 본 발명의 실시 예에서 수행되는 가용한 PD의 탐색 및 서비스 종단점 정보의 제공 방법에 대해 구체적으로 설명한다.
1. 먼저 CD(230)의 애플리케이션(231)(이하, CD 애플리케이션)은 다음과 <표 1>과 같은 특정 ST(Search Target) 헤더 정보를 포함한 SSDP 프로토콜을 사용하여 네트워크 내에 가용한 PD의 검색을 요청한다.
표 1
Figure PCTKR2016003433-appb-T000001
2. SSDP 요청을 수신한 PD(210)는 다음 <표 2>와 같이 LOCATION 헤더를 포함한 HTTP/1.1 응답을 전송한다. 이때 LOCATION 헤더에는 PD(210)의 Device Description 파일을 요청할 수 있는 정보가 포함될 수 있다.
표 2
Figure PCTKR2016003433-appb-T000002
3. 가용한 PD(210)로부터 응답을 수신한 CD 애플리케이션은 상기 2번 과정에서 수신한 LOCATION 정보로 아래 <표 3>과 같이 PD의 Device description 파일을 요청하는 요청을 보낸다.
표 3
GET <path component of the LOCATION URL> HTTP/1.1
4. PD(210)는 Device description 파일과 함께 다음 <표 4>와 같은 Application-URL 헤더를 응답으로 보낸다.
표 4
Figure PCTKR2016003433-appb-T000003
5. CD 애플리케이션은 상기 4번 과정에서 수신한 Application-URL 정보로 서비스 종단점 정보를 다음 <표 5>와 같이 요청한다. 여기서 Application-URL의 마지막에 붙은 'HbbTV(Hybrid broadcast broadband TV)'는 하나의 실시 예로 본 발명에 따른 구현에 따라 변형될 수 있다.
표 5
GET /apps/HbbTV HTTP/1.1
6. PD(210)는 HTTP/1.1 OK 헤더와 함께 다음 <표 6>의 정보를 body로 응답한다. 본 발명에서는 XML(Extensible Markup Language)로 구성하는 예를 제시하였으나, 이 역시 구현에 따라 JSON(JavaScript Object Notation) 등 HTTP 응답의 Body 로 실어 보낼 수 있는 텍스트 기반의 어떠한 포맷도 사용 가능하다. 아래 <표 6>의 예에서 <X_HbbTV_App2AppURL>은 웹소켓(WS) 서버의 서비스 종단점을 제공하기 위해 사용되었으며, 나머지 <X_HbbTV_InterDevSyncURL>과 <X_HbbTV_UserAgent> 정보는 구현에 따라 사용하지 않을 수도 있다. 본 발명의 실시 예에서는 두 개 정보(즉 <X_HbbTV_InterDevSyncURL>, <X_HbbTV_UserAgent>)는 사용하지 않는다. 마찬가지로 구현 방식에 따라 추가적인 정보 제공이 필요한 경우 필드를 새로 정의하여 사용할 수 있다.
표 6
Figure PCTKR2016003433-appb-T000004
상기한 실시 예에서 설명한 PD의 탐색 및 서비스 종단점 정보 제공 방법에 의해, 상기 4번 과정에서 HTTP GET 요청을 보낼 수 있는 Web 서버의 종단점 정보를, 상기 6번 과정에서 WebSocket 서버의 종단점 정보를 획득할 수 있다.
한편 상기 도 3의 307 단계에서 PD 상태 정보 요청에 대해 자세히 설명한다. 상기 PD 상태 정보(즉 PD의 서비스 및/또는 콘텐츠와 관련된 정보)는 아래 <표 7>의 예시된 정보들 중 적어도 하나를 포함할 수 있다.
표 7
상태 정보 상태정보 ID 요청 빈도 양방향성 추천 방법
서비스 및 콘텐츠 ID 정보 cid 낮음 불필요 HTTP
ESG 정보 esg 낮음 불필요 HTTP
미디어 데이터 data 낮음 불필요 HTTP
미디어 타임라인 정보 timeline 높음 필요 WebSocket
미디어 재생 정보 playback 낮음 필요 WebSocket
Emergency Alert 정보 eam 낮음 필요 WebSocket
상기 PD 상태 정보에 포함될 수 있는 각각의 정보는 정보가 요청되는 빈도 및 통신 방식(예컨대, 양방향성 (불)필요)에 따라 HTTP GET이나 Web Socket 프로토콜을 사용한 두 가지 방식으로 나누어 요청할 수 있다. <표 1>에서는 이 두 가지 방식에 따라 예시를 하였으나, 다른 방식을 이용하는 것도 가능하다.
먼저, HTTP GET에 의한 PD 상태 정보 요청 방법을 설명한다.
HTTP 요청을 보낼 서비스 종단점은 상기 <표 4>에서 획득한 Application-URL 을 사용할 수 있다. 이때 원하는 PD의 상태정보를 구분하기 위해 Application-URL에 상기 <표 7>에서 예시한 상태 정보 ID를 붙여서 보낼 수 있다. 예를 들어, 서비스 및 콘텐츠 ID 정보를 요청하기 위한 HTTP GET 요청의 예는 다음 <표 8>과 같다.
표 8
GET /apps/cid HTTP/1.1
이에 대한 PD의 응답은 HTTP 상태코드와 Body에 포함되어 보내질 수 있다.
그 응답의 예는 아래 <표 9> 내지 <표 12>와 같으며, HTTP 요청에 대한 PD 상태 정보 응답의 일 구현 예를 나타낸 것이다. <표 9> 내지 <표 12>의 예는 XML로 구성하는 예를 제시하였으나, 이 역시 구현에 따라 JSON등 HTTP 응답의 Body 로 실어 보낼 수 있는 텍스트 기반의 어떠한 포맷도 사용 가능하다. 또한 포함되는 각각의 필드 역시 구현에 따라 달라질 수 있다.
표 9
Description Value
deviceID Device ID ofprimary device deviceID
serviceType The type of service contentID, esg, timeline, playback, eam
service The information of current service
esg The information of ESG
timeline The media timeline ofcurrent service UTC time
playbackState The playback state ofcurrent service
EAM Emergency Alert Message
표 10
Description
serviceName Description of service(text)
serviceID Identifier of current service
표 11
Description
MPstate PLAYING, PAUSED, STOPPED, FFOWARD, REWIND, BUFFERING, UNKNOWN
MPSpeed Current speed of media state
MediaURL The URL of content providing from the PD
표 12
Description
EAMID Identifier of the emergency alert message
SentTimeStamp Timestamp when the EAM generated
ExpiredTimeStamp Timestamp of EAM is valid
Urgency Urgency of EAM
Geo-loc Geographical location for EAM is applicable
EAMContent EAM content
RichEAMURL URL provides additional information about this EAM
상기 <표 10>은 상기 <표 9>에서 "service" 필드에 포함되는 정보의 일 구성 예를 나타낸 것이고, 상기 <표 11>는 상기 <표 9>에서 "playbackState" 필드에 포함되는 정보의 일 구성 예를 나타낸 것이다. 그리고 상기 <표 12>는 상기 <표 9>에서 "EAM" 필드에 포함되는 정보의 일 구성 예를 나타낸 것이다.
상기 <표 9>에서 각각의 필드의 의미는 다음과 같다.
<deviceID>: PD 상태 정보를 전송한 PD의 device ID를 기술한다.
<seviceType>: PD 상태 정보의 종류를 나타낸다. PD 상태 정보에 포함될 수 있는 값으로는 contentID, esg, timeLine, playbackState, EAM 등이 있다.
<service>:현재 PD에서 제공 중인(구동 중인) 서비스의 정보를 포함한다. <service> 의 하위 필드의 구성은 <표 10>과 같다.
<esg>: ESG(Electronic Service Guide) 정보를 나타낸다.
<timeline>: 현재 제공 중인 서비스의 미디어 타임 라인 정보를 포함한다. 상기 타임 라인(timeline) 정보는 UTC(Coordinated Universal Time) Time(즉 국제표준시)으로 기술된다. 이 타임라인 정보는 동일 디바이스 내에서 복수의 서비스 또는, 복수의 디바이스들 간의 서비스 사이에서의 동기화를 위해 사용된다.
<playbackState>: 현재 제공 중인 서비스의 재생상태 정보를 포함한다. <playbackState>의 하위 필드의 구성은 <표 11>와 같다.
<EAM>: Emergency Alert Message를 포함한다. 상기 EAM의 경우, <표 8>이나 <표10>의 CD 애플리케이션에서 PD로의 요청 과정 없이도 PD로부터 CD 애플리케이션으로의 전송이 가능하다. 상기 <EAM>의 하위 필드의 구성은 <표 12>와 같다.
상기 <표 10>에 포함되는 필드들의 의미는 다음과 같다.
<serviceName>: PD에서 제공 중인 서비스의 이름 (텍스트)을 포함한다.
<serviceID>: PD에서 제공 중인 서비스의 ID를 포함한다.
상기 <표 11>에 포함되는 필드들의 의미는 다음과 같다.
<MPState>: 제공 중인 서비스의 재생상태 정보를 나타낸다. PLAYING, PAUSED, STOPPED, FFOWARD, REWIND, BUFFERING, UNKNOWN의 값을 가질 수 있다.
<MPSpeed>: 제공 중인 서비스의 재생속도를 나타낸다. 정상적인 속도로 재생중일 때는 상수 1을 가지며, FFWOWRD(fast-forward), REWIND 등의 재생 상태일 때는 각각 양의 배수와 음의 배수 값을 취할 수 있다.
<MediaURL>: 제공 중인 서비스(또는 콘텐츠)의 다른 디바이스로의 재전송을 허용할 시, 그 서비스(또는 콘텐츠)가 재전송되는 URL을 기술한다. 상기 MediaURL은 예컨대, PD로부터 CD로 또는 CD로부터 PD로 재전송되는 서비스(또는 콘텐츠)에 접속하기 위한 네트워크 주소로 이해될 수 있다.
그리고 상기 <표 12>에 포함되는 필드들의 의미는 다음과 같다.
<EAMID>: Emergency Alert Mesasge의 ID를 나타낸다.
<setnTimeStamp>: EAM이 생성된 시간정보를 포함한다.
<expiredTimeStamp>:EAM이 유효한 시간정보를 포함한다.
<urgency>: EAM의 중요도를 표시한다.
<Geo-loc>: EAM이 적용되는 특정 지역정보가 포함될 경우 이를 나타낸다.
<EAMContent>: EAM 메시지(텍스트)를 포함한다.
<RichEAMURL>: 텍스트 이외의 이미지, 동영상, 음성 등 부가 정보가 제공될 때 이를 접근할 수 있는 URL 정보를 기술한다.
다음으로, WebSocket 프로토콜을 이용한 요청 방법을 설명한다.
WebSocket 요청을 보낼 서비스 종단점의 정보는 상기 <표 6>에서 획득한 <X_HbbTV_App2AppURL>을 사용할 수 있다. 상기 WebSocket은 양방향 통신을 지원하며, 어떠한 이의 payload format으로 어떠한 형식도 허용하기 때문에, 본 발명의 실시 예에서는 다음과 같은 XML payload 형태를 제안한다. 하지만, 앞서 설명한 것처럼 구현에 따라 XML 뿐 아니라 JSON등 WebSocket 프로토콜이 지원하는 어떠한 형태도 사용 가능하며, 필드 역시 필요에 따라 얼마든지 추가나 삭제가 가능하다. 아래 <표 13>은 웹소켓에 의한 서비스 및 콘텐츠 ID 정보 요청의 일 예를 나타낸 것이다.
표 13
Figure PCTKR2016003433-appb-T000005
상기 <표 13>에서 <statusID>필드는 특정 정보를 요청하기 위한 용도로 사용되었으며, 상기 예의 경우 구체적으로 서비스 및 콘텐츠 ID 정보를 요청하기 위한 방법을 예시하였다. 해당 필드가 생략되면, 모든 상태 정보의 업데이트를 요청하는 것으로 처리되어 PD에서 상태정보의 변화가 있을 때마다 CD에 제공하는 것도 가능하다.
상기 <표 13>에서 command 필드는 해당 정보의 요청 및/또는 취소를 나타낸 것이다. CD 애플리케이션은 PD에게 PD 상태 정보(즉 PD의 서비스 및/또는 콘텐츠와 관련된 정보)(예컨대, <statusID>로 기술된 정보)에 업데이트가 있을 경우, 그 업데이트된 정보의 전송을 PD에게 요청할 수 있다. 이러한 요청은 command 필드에서 아래 <표 14>와 같이 subscribe에 기술되고, 기존 요청을 갱신하고 싶을 때는 renew를, 취소하고 싶을 때는 cancel을 기술한다. 각각의 의미는 아래 <표 14>의 예시와 같다. 본 실시 예에서는 업데이트된 정보의 요청과 관련하여 아래 <표 14>와 같이 subscribe, renew, cancel의 명령을 통해 기술하였으나, 이는 일 예를 나타낸 것이고, 업데이트 시는 물론 상기 서비스 및/또는 콘텐츠와 관련된 정보의 업데이트가 없더라도 그 전송 요청의 subscribe, renew, cancel은 동일한 방식으로 적용될 수 있다. 상기 command 필드는 상기 서비스 및/또는 콘텐츠와 관련된 정보의 전송 요청/갱신/취소와 관련된 가입 관련 명령(또는 메시지)로 이해될 수 있다.
표 14
Command 값 의미
subscribe PD에 <statusID>로 기술된 정보에 업데이트가 있을 경우, 그 업데이트된 정보의 전송을 PD에게 요청한다. 디폴트 값으로 값이 지정되어 있지 않을때는 subscribe로 판단한다.
renew 업데이트 요청을 갱신한다.
cancel 업데이트 요청을 취소한다.
상기 <표 13>에서 duration 필드는 해당 정보의 요청이 지속되는 시간을 나타낸다. PD는 상기 duration 필드에 기술되어 있는 시간 동안만 해당 정보의 업데이트를 보내준다. CD 애플리케이션에서 취소 요청을 보낼 때까지 정보를 계속 받고자 할 때는 infinite(또는 -1)을 보내주면 된다. 상기 duration 필드가 기술되어 있지 않을 때 역시 infinite로 판단할 수 있다.
그리고 PD는 상기 WebSocket 프로토콜을 이용한 CD 애플리케이션의 PD 상태 정보 업데이트 요청을 수신하면, 상기 PD 상태 정보 업데이트 요청에 대한 처리 결과를 CD 애플리케이션에 알려줄 수 있다. 여기서 상기 PD 상태 정보 업데이트 요청은 PD에서 업데이트된 PD 상태 정보가 있을 경우, PD에게 업데이트된 PD 상태 정보의 전송을 요청하는 것으로 이해될 수 있다.
그리고 만약 PD가 CD로부터 PD 상태 정보 업데이트 요청을 수신한 시점에 업데이트된 PD 상태 정보가 없을 경우, 상기 PD 상태 정보 업데이트 요청에 대한 상기 처리 결과는 PD가 상기 PD 상태 정보 업데이트 요청을 수신하였음을 CD에게 알리는 일종의 확인 응답으로 이해될 수 있다.
아래 <표 15>는 PD가 웹 소켓에 의한 서비스 및 콘텐츠 ID 정보 요청을 수신한 경우, CD 애플리케이션에게 전송하는 처리 결과의 일 예를 나타낸 것이다. 상기 처리 결과는 상기 <표 7>에서 예시한 PD 상태 정보(즉 PD의 서비스 및/또는 콘텐츠와 관련된 정보) 중 적어도 하나에 대해 전송될 수 있다.
표 15
Figure PCTKR2016003433-appb-T000006
상기 <표 15>에서 <statusID> 필드는 상기 <표 13>에서 웹소켓에 의한 서비스 및 콘테츠 ID 정보 요청에 대한 처리 결과의 일 예를 나타낸 것이다.
상기 <표 15>에서 <responseCode>는 상기 <표 13>에서 서비스 및 콘테츠 ID 정보 요청에 대한 결과를 나타낸다. 상기 <responseCode>는 일반적인 HTTP에서 Status code와 동일한 의미를 사용될 수 있으며, 상기 <표 15>의 예에서는 "200", 즉 상기 서비스 및 콘테츠 ID 정보 요청이 성공적으로 처리되었음을 나타낸다. 만약 상기 서비스 및 콘테츠 ID 정보 요청이 어떠한 이유로 거부된 경우, 예컨대, 400 번대 Status code를 전송할 수 있다.
상기 <표 15>에서 <ack>는 상기 <표 13>에서 어떤 요청에 대한 ACK인지를 나타낸다. 예에서는 subscribe 요청에 대한 ACK임을 나타내며, 각각의 의미는 아래 <표 16>의 예시와 같다.
상기 <표 15>에서 duration 필드는 상기 <표 13>에서 서비스 및 콘테츠 ID 정보 요청에 따라 PD에서 해당 정보(또는 업데이트된 정보)를 전송할 수 있는 지속 시간(즉 가입 기간)을 CD 애플리케이션에 알려준다. 즉, 예에서 CD 애플리케이션은 업데이트의 지속시간을 예컨대, infinite로 요청하였으나 PD는 이에 대해 그 업데이트의 지속시간을 예컨대, 1000초로 결정하여 전송할 수 있다. 일 동작 예로 상기 업데이트의 지속시간 내에 상기 서비스 및 콘테츠 ID 정보의 업데이트가 있는 경우, PD는 CD에게 업데이트된 서비스 및 콘테츠 ID 정보를 전송할 수 있다.
표 16
ack 의미
subscribeAck 업데이트 요청에 대한 처리 결과임을 나타낸다.
renewAck 갱신 요청에 대한 처리 결과임을 나타낸다.
cancelAck 취소 요청에 대한 처리 결과임을 나타낸다.
상기 <표 16>에서 ack는 상기 <표 14>의 command 값과 1:1로 매핑된다. 따라서 경우에 따라서는 별도의 <ack> 필드를 사용하는 대신 <표 14>의 command 필드를 공동으로 사용하고 이의 값만 상기 <표 16>에서 정의한 값을 사용할 수도 있다.
상기 WebSocket 프로토콜을 이용한 PD 상태 정보 요청에 대한 PD의 상태 정보 업데이트 역시 상기한 <표 9> 내지 <표 16>에 기술한 포맷에 의해 기술할 수 있다.
도 5는 본 발명의 실시 예에 따라 WebSocket 프로토콜을 이용한 요청에 대한 PD의 응답을 처리하는 절차를 설명하기 위한 도면으로서, 도 5의 절차는 PD에서 이벤트(예를 들어 PD 상태 정보의 업데이트)가 발생했을 때, 수행될 수 있다.
도 5를 참조하면, 501 단계에서 PD는 먼저 CD 애플리케이션으로부터 WebSocket 프로토콜을 통해 PD 상태 정보의 요청을 수신한다. 이때 수신하는 값은 위에서 설명한 상기 <표 13>의 예와 같다.
다음으로 503 단계에서, PD는 상기 수신한 WebSocket 프로토콜을 이용한 요청의 <command> 필드를 분석하여, 이 <command> 필드 값이 subscribe이면, 505 단계에서 PD에서 발생한 이벤트가 있을 시 이 WebSocket 연결에 이벤트를 전송할 수 있도록 가입(등록)한다. 그리고 상기 503 단계에서 <command> 필드 값이 cancel이면 PD는 해당 이벤트에 대한 가입을 취소하는 요청인 것으로 판단하여 507 단계에서 상기 가입을 취소하고 응답 절차를 종료한다.
상기 505 단계에서 PD는 요청한 이벤트를 등록하고, 509 단계에서 등록이 성공하면(받아들여지면), 513 단계에서 이에 대한 처리 결과를 CD 애플리케이션으로 전송한다. 한편 상기 509 단계에서 어떠한 이유에서 등록이 실패하였을 경우에도 마찬가지로 511 단계에서 이에 대한 처리결과를 CD 애플리케이션으로 전송하고, 응답 절차를 종료한다. 한편 상기 505 단계에서 요청한 이벤트 등록이 완료된 후, 515 단계에서 PD의 상태 정보의 업데이트(이벤트)가 발생하면, 517 단계에서 PD는 상기 501 단계에서 상기 수신한 요청의 <statusID> 필드를 분석하여 해당 PD 상태 정보의 요청이 수신되었는지 판단한다. 만약 해당 PD 상태 정보의 요청이 수신되지 않았다면 CD 애플리케이션으로 해당 이벤트를 전송할 필요가 없으므로 523 단계에서 이 이벤트는 무시되고 응답 절차는 종료된다.
한편 상기 517 단계에서 판단 결과 상기 <statusID> 필드에 해당 PD 상태 정보의 요청이 포함되어 있을 경우, 519 단계로 이동하여 <duration> 필드에 기술된 요청 시간이 유효한지 판단한다. 만약 상기 <duration> 필드에 기술된 시간이 경과되어 그 PD 상태 정보의 요청이 유효하지 않다면 마찬가지로 해당 이벤트를 CD 애플리케이션으로 전송할 필요가 없기 때문에 523 단계로 진행하여 해당 이벤트는 무시되고 응답 절차는 종료된다. 그리고 상기 519 단계에서 <duration> 필드에 기술된 요청 시간이 유효하다면 521 단계로 진행하여 PD는 웹 소켓을 이용하여 해당 이벤트를 CD 애플리케이션으로 전송한다.
도 4는 본 발명의 실시 예에 따라 PD 상태 정보를 요청하는 방법을 선택하는 절차를 설명하기 위한 도면이다.
도 4를 참조하면, 401 단계에서 먼저 PD 상태 정보가 요청 빈도가 높은지 여부를 판단한다. PD 상태 정보의 요청 빈도가 낮은 경우 비교적 요청에 대한 비용이 적게 드는 HTTP를 사용하는 것이 좋으며, 요청이 빈번할 경우 요청이 발생할 때 마다 HTTP 요청을 하는 것보다는 한번 연결이 수행되면 해당 채널을 계속해서 유지하고 이를 통해 데이터를 전송할 수 있는 웹소켓을 사용하는 것이 비용측면에서 유리하다. 따라서 요청이 빈번할 때는 웹소켓을 사용하는 것이 좋다. 또한 상기 웹소켓은 비동기 통신을 용이하게 제공할 수 있다.
다음으로 403 단계에서 양방향성이 필요한지 판단한다. 양방향성이란, CD 애플리케이션에서 일방적으로 PD로 정보요청을 요청하는 것인지, PD에서 상태의 변화가 발생했을 때 CD 애플리케이션의 요청없이도 CD 애플리케이션으로 정보를 보낼 수 있는지를 말한다. 웹소켓은 양방향 통신을 지원하기 때문에 양방향 통신이 필요할 경우는 웹소켓을 사용하는 것이 좋다.
마지막으로 405 단계에서 바이너리 데이터의 전송이 필요한지를 판단한다. HTTP도 바이너리를 전송할 수 있지만, 웹소켓의 경우 양방향으로 전송되는 데이터에 제한이 없기 때문에 바이너리 전송에 보다 적합하다.
그리고 상기한 401 단계 내지 405 단계의 판단에 따라 407 단계에서 HTTP를 사용하여 PD 상태 정보를 요청하거나, 409 단계에서 웹 소켓을 사용하여 PD 상태 정보를 요청할 수 있다.
상기한 도 4의 방법을 사용하는 PD 상태 정보의 전송 방법을 판단해 보면 다음과 같다.
서비스 및 콘텐츠 ID 정보의 경우, 일반적으로 CD 애플리케이션이 최초 구동될 때 요청하는 것으로 충분하다. 따라서 요청 빈도가 낮다고 판단할 수 있고, 정보 또한 최초 CD 애플리케이션의 요청시 보내주는 것으로 충분하기 때문에 양방향성이 필요없다. 또한 서비스 정보는 일반적으로 XML이나 JSON같은 텍스트 정보로 기술 할 수 있기 때문에 도 4의 흐름도에 적용해 보면 HTTP를 사용하는 것으로 충분하다.
다음으로 미디어 타임라인 정보의 경우, PD에서의 미디어 재생이 진행될 때마다 정보의 업데이트가 빈번하기 때문에 웹소켓을 사용하는 것이 좋다.
미디어 재생 정보의 경우, 현재 PD에서 재생중인 미디어의 상태(재생 중인지, 중단되었는지, FF 중인지 등)를 나타내는데 위의 미디어 타임라인 정보에 비하면 요청 빈도가 상대적으로 낮다. 하지만, 미디어의 재생 상태가 변경되었을 때 (예를 들어, 재생에서 중단으로) 이를 CD 애플리케이션에 알려야 할 필요가 있기 때문에 양방향 통신이 필요하다. 따라서 이 경우 웹소켓을 사용하는 것이 좋다.
긴급 알람 정보의 경우에도 일반적으로 해당 정보가 발생할 가능성은 낮지만, PD가 해당 정보를 수신하는 경우, CD 애플리케이션에 반드시 정보를 전달해야 한다. 따라서 양방향성이 반드시 필요하며 이 경우 웹소켓 사용이 추천된다.
본 발명의 실시 예에 의하면, 도 6의 예와 같이 서비스 제공자(601, 603)로부터 방송망 또는 광대역 네트워크(61, 63)를 통해 복수의 디바이스들(611, 613)로 방송 서비스 또는 방송 콘텐츠가 제공되는 환경에서 멀티스크린 서비스를 이용하는 경우, CD 애플리케이션에서 PD 상태 정보를 요청(65)하고 수신(67)할 수 있는 방법을 제공함으로써, PD 애플리케이션이 없어도 CD 애플리케이션을 사용해 PD와 연동시킬 수 있다. 또한 기존의 컴페니온 스크린 구조와 프로토콜을 활용하여 PD의 상태 정보를 수신할 수 있는 방법을 제공함으로써 추가적인 구성과 비용이 발생하지 않는다.

Claims (15)

  1. 멀티미디어 시스템에서 디바이스들 간의 통신 방법에 있어서,
    제1 디바이스가 방송 서비스 또는 콘텐츠의 이용을 위한 제2 디바이스를 탐색하는 과정;
    상기 제1 디바이스가 상기 제2 디바이스로부터 상기 방송 서비스 또는 상기 콘텐트와 관련된 제1 정보를 수신하기 위한 적어도 하나의 서비스 종단점에 대한 제2 정보를 획득하는 과정;
    상기 제1 디바이스가 상기 제2 정보를 이용하여 상기 방송 서비스 또는 상기 콘텐츠와 관련된 상기 제1 정보의 전송을 요청하는 과정; 및
    상기 요청에 대한 응답으로, 상기 제1 디바이스가 상기 제2 디바이스로부터 상기 제1 정보를 수신하는 과정을 포함하는 통신 방법.
  2. 제 1 항에 있어서,
    상기 제1 정보는 상기 요청 시 이용된 상기 제2 디바이스의 서비스 종단점에 상응하는 통신 프로토콜을 이용하여 수신되며,
    상기 통신 프로토콜은 HTTP(Hypertext Transfer Protocol) 프로토콜과 웹 소켓 프로토콜 중 적어도 하나를 포함하는 통신 방법.
  3. 제 1 항에 있어서,
    상기 제2 디바이스는 웹 서버와 웹 소켓 서버 중 적어도 하나를 포함하며,
    상기 제2 정보는 상기 웹 서버의 서비스 종단점 정보와 상기 웹 소켓 서버의 서비스 종단점 정보 중 적어도 하나를 포함하는 통신 방법.
  4. 제 1 항에 있어서,
    상기 제1 디바이스는 상기 제2 디바이스와 애플리케이션간 통신을 이용하지 않고, 상기 제2 디바이스로부터 상기 제1 정보를 수신하는 통신 방법.
  5. 제 1 항에 있어서,
    상기 제1 정보는 상기 제2 디바이스로부터 상기 제1 디바이스로 상기 방송 서비스 또는 상기 콘텐츠를 전송할 경우, 상기 방송 서비스 또는 상기 콘텐츠의 접속을 위한 주소 정보를 포함하는 통신 방법.
  6. 제 1 항에 있어서,
    상기 제1 정보의 전송 요청은 상기 제1 및 제2 디바이스 간의 메시지 교환을 통해 가입, 갱신, 또는 취소될 수 있는 통신 방법.
  7. 제 1 항에 있어서,
    상기 제1 디바이스가 상기 제1 정보의 전송 요청에 대한 결과를 나타내는 코드 정보를 수신하는 과정을 더 포함하는 통신 방법.
  8. 제 1 항에 있어서,
    상기 제1 정보의 전송 요청은 상기 제1 및 제2 디바이스 간의 메시지 교환을 통해 정해진 기간 동안 수행될 수 있는 통신 방법.
  9. 멀티미디어 시스템에서 디바이스들 간의 통신을 수행하는 제1 디바이스에 있어서,
    방송 서비스 또는 콘텐츠의 이용을 위한 제2 디바이스와 통신을 위한 통신 인터페이스; 및
    상기 통신 인터페이스를 통해 상기 제2 디바이스를 탐색하고, 상기 제2 디바이스로부터 상기 방송 서비스 또는 상기 콘텐트와 관련된 제1 정보를 수신하기 위한 적어도 하나의 서비스 종단점에 대한 제2 정보를 획득하며, 상기 제2 정보를 이용하여 상기 방송 서비스 또는 상기 콘텐츠와 관련된 상기 제1 정보의 전송을 요청하고, 상기 요청에 대한 응답으로, 상기 제2 디바이스로부터 상기 제1 정보를 수신하는 것을 제어하는 제어부를 포함하는 제1 디바이스.
  10. 제 9 항에 있어서,
    상기 제1 정보는 상기 요청 시 이용된 상기 제2 디바이스의 서비스 종단점에 상응하는 통신 프로토콜을 이용하여 수신되며,
    상기 통신 프로토콜은 HTTP(Hypertext Transfer Protocol) 프로토콜과 웹 소켓 프로토콜 중 적어도 하나를 포함하는 제1 디바이스.
  11. 제 9 항에 있어서,
    상기 제2 디바이스는 웹 서버와 웹 소켓 서버 중 적어도 하나를 포함하며,
    상기 제2 정보는 상기 웹 서버의 서비스 종단점 정보와 상기 웹 소켓 서버의 서비스 종단점 정보 중 적어도 하나를 포함하는 제1 디바이스.
  12. 제 9 항에 있어서,
    상기 제어부는 상기 제2 디바이스와 애플리케이션간 통신을 이용하지 않고, 상기 제2 디바이스로부터 상기 제1 정보를 수신하는 것을 제어하는 제1 디바이스.
  13. 제 9 항에 있어서,
    상기 제1 정보는 상기 제2 디바이스로부터 상기 제1 디바이스로 상기 방송 서비스 또는 상기 콘텐츠를 전송할 경우, 상기 방송 서비스 또는 상기 콘텐츠의 접속을 위한 주소 정보를 포함하는 제1 디바이스.
  14. 제 9 항에 있어서,
    상기 제1 정보의 전송 요청은 상기 제1 및 제2 디바이스 간의 메시지 교환을 통해 가입, 갱신, 또는 취소될 수 있는 제1 디바이스.
  15. 제 9 항에 있어서,
    상기 제어부는 상기 제1 디바이스가 상기 제1 정보의 전송 요청에 대한 결과를 나타내는 코드 정보를 수신하는 것을 더 제어하는 제1 디바이스.
PCT/KR2016/003433 2015-04-01 2016-04-01 멀티미디어 시스템에서 디바이스들 간에 통신 방법 및 장치 Ceased WO2016159727A1 (ko)

Priority Applications (7)

Application Number Priority Date Filing Date Title
CN202210172370.8A CN114501118B (zh) 2015-04-01 2016-04-01 用于在多媒体系统中使用广播服务或内容的设备
EP16773508.3A EP3280148B1 (en) 2015-04-01 2016-04-01 Method and device for communicating between devices in multimedia system
CN201680019429.2A CN107431843B (zh) 2015-04-01 2016-04-01 用于在多媒体系统中的设备之间通信的方法和设备
CN202210173221.3A CN114513696B (zh) 2015-04-01 2016-04-01 用于在多媒体系统中使用广播服务或内容的设备的方法
JP2017551303A JP6728218B2 (ja) 2015-04-01 2016-04-01 マルチメディアシステムにおけるデバイス間の通信方法及び装置
US15/562,296 US11159844B2 (en) 2015-04-01 2016-04-01 Method and device for communicating between devices in multimedia system
US17/509,557 US11606601B2 (en) 2015-04-01 2021-10-25 Method and device for communicating between devices in multimedia system

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
KR20150046455 2015-04-01
KR10-2015-0046455 2015-04-01
KR10-2015-0073340 2015-05-26
KR20150073340 2015-05-26
KR1020150080209A KR102335007B1 (ko) 2015-04-01 2015-06-05 방송 시스템에서 디바이스들 간에 정보를 송수신하는 방법 및 장치
KR10-2015-0080209 2015-06-05

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US15/562,296 A-371-Of-International US11159844B2 (en) 2015-04-01 2016-04-01 Method and device for communicating between devices in multimedia system
US17/509,557 Continuation US11606601B2 (en) 2015-04-01 2021-10-25 Method and device for communicating between devices in multimedia system

Publications (1)

Publication Number Publication Date
WO2016159727A1 true WO2016159727A1 (ko) 2016-10-06

Family

ID=57004629

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/003433 Ceased WO2016159727A1 (ko) 2015-04-01 2016-04-01 멀티미디어 시스템에서 디바이스들 간에 통신 방법 및 장치

Country Status (1)

Country Link
WO (1) WO2016159727A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110049360A (zh) * 2018-01-16 2019-07-23 中兴通讯股份有限公司 跨平台内容控制方法、装置、终端、服务器及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20100127162A (ko) * 2009-05-25 2010-12-03 엘지전자 주식회사 단말 내에서 브로드캐스트 서비스를 통해 관련된 콘텐츠를 검색하고 주문하는 방법 및 장치
KR20130053650A (ko) * 2011-11-15 2013-05-24 삼성전자주식회사 디바이스간 직접 통신 서비스 시스템에서 데이터 송신 방법 및 장치
KR101413246B1 (ko) * 2013-03-08 2014-08-06 주식회사 엘지유플러스 콘텐츠 가이드 송수신 방법, 이를 위한 장치 및 기록 매체
KR20140125686A (ko) * 2013-04-19 2014-10-29 삼성전자주식회사 방송 통신 시스템에서 부가 정보를 제공하는 방법 및 장치
WO2015041488A1 (ko) * 2013-09-23 2015-03-26 삼성전자 주식회사 기기 별 응용 프로그램간 통신을 위한 장치 및 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20100127162A (ko) * 2009-05-25 2010-12-03 엘지전자 주식회사 단말 내에서 브로드캐스트 서비스를 통해 관련된 콘텐츠를 검색하고 주문하는 방법 및 장치
KR20130053650A (ko) * 2011-11-15 2013-05-24 삼성전자주식회사 디바이스간 직접 통신 서비스 시스템에서 데이터 송신 방법 및 장치
KR101413246B1 (ko) * 2013-03-08 2014-08-06 주식회사 엘지유플러스 콘텐츠 가이드 송수신 방법, 이를 위한 장치 및 기록 매체
KR20140125686A (ko) * 2013-04-19 2014-10-29 삼성전자주식회사 방송 통신 시스템에서 부가 정보를 제공하는 방법 및 장치
WO2015041488A1 (ko) * 2013-09-23 2015-03-26 삼성전자 주식회사 기기 별 응용 프로그램간 통신을 위한 장치 및 방법

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3280148A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110049360A (zh) * 2018-01-16 2019-07-23 中兴通讯股份有限公司 跨平台内容控制方法、装置、终端、服务器及存储介质
WO2019141150A1 (zh) * 2018-01-16 2019-07-25 中兴通讯股份有限公司 跨平台内容控制方法、装置、终端、服务器及存储介质

Similar Documents

Publication Publication Date Title
WO2012102582A2 (en) Method and apparatus for remotely controlling consumer electronics device by using wireless personal area network
WO2012173444A2 (en) Apparatus and method for exchanging data between upnp based devices
WO2010098591A2 (en) Remote user interface system and method
WO2012105764A2 (en) Apparatus and method for providing application auto-install function in digital device
WO2011119012A2 (en) Method and apparatus for receiving non-real time content included in real time broadcasting signal
EP3295693A1 (en) Apparatus and method for emergency alert scheme in wirless network environment
WO2011028022A2 (en) Apparatus and method for remote control in a short-range network, and system supporting the same
WO2014021624A1 (en) Method and apparatus of providing broadcasting and communication convergence service
WO2014171803A1 (en) Method and apparatus for transmitting and receiving additional information in a broadcast communication system
EP3420731A1 (en) Multi-point content transmission method and apparatus
WO2015133819A1 (ko) 자동 스위칭 방법 및 장치
KR102505302B1 (ko) 방송 시스템에서 디바이스들 간에 정보를 송수신하는 방법 및 장치
WO2011136537A2 (en) Method and apparatus for transmitting content to plurality of devices
WO2022250351A1 (ko) 초저지연 실시간 영상 전송 플랫폼 시스템 및 방법
WO2016159727A1 (ko) 멀티미디어 시스템에서 디바이스들 간에 통신 방법 및 장치
WO2013055146A1 (ko) 방송 수신 장치에서 방송 서비스와 연동되어 부가 서비스를 제공하는 오브젝트를 처리하는 방법 및 이를 위한 장치
WO2014092463A1 (en) Launching second-screen application related to a non-triggered first-screen application
WO2019112346A1 (ko) 전자 서비스 가이드를 송수신하는 방법 및 그 장치
WO2013089528A1 (ko) 통신 장치 및 방법
WO2023106589A1 (ko) 미디어 컨텐츠를 제공하는 방법 및 장치
WO2021107166A1 (ko) 무선 오디오 서비스 자동 재설정 방법 및 무선 오디오 시스템
WO2018066920A1 (ko) 스트리밍 서비스를 지원하는 방법 및 장치
WO2018155730A1 (ko) 지상파 방송 신호 중계기의 수신 성능을 향상시키는 제어 장치 및 방법
WO2014208862A1 (ko) 디바이스들 간 자원 공유 방법 및 이를 실행하는 디바이스
WO2011132951A2 (ko) 사용자 위치 기반 멀티미디어 시스템 및 그 제공방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16773508

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15562296

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2017551303

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE