WO2015065149A1 - 전자 장치 및 전자 장치의 제어 방법 - Google Patents

전자 장치 및 전자 장치의 제어 방법 Download PDF

Info

Publication number
WO2015065149A1
WO2015065149A1 PCT/KR2014/010491 KR2014010491W WO2015065149A1 WO 2015065149 A1 WO2015065149 A1 WO 2015065149A1 KR 2014010491 W KR2014010491 W KR 2014010491W WO 2015065149 A1 WO2015065149 A1 WO 2015065149A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
companion device
client
processor
connection
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/KR2014/010491
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.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
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
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Priority to US15/026,552 priority Critical patent/US10367864B2/en
Priority to EP14857015.3A priority patent/EP3068139B1/en
Priority to CN201480059752.3A priority patent/CN105706455B/zh
Priority to JP2016526847A priority patent/JP6301464B2/ja
Priority to KR1020167007221A priority patent/KR101898492B1/ko
Publication of WO2015065149A1 publication Critical patent/WO2015065149A1/ko
Anticipated expiration legal-status Critical
Priority to US16/506,417 priority patent/US10819761B2/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/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4126—The peripheral being portable, e.g. PDAs or mobile phones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • 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/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
    • 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/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H04N21/4433—Implementing client middleware, e.g. Multimedia Home Platform [MHP]
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H04N21/8173—End-user applications, e.g. Web browser, game
    • 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/41—Structure of client; Structure of client peripherals
    • H04N21/4104—Peripherals receiving signals from specially adapted client devices
    • H04N21/4122—Peripherals receiving signals from specially adapted client devices additional display device, e.g. video projector

Definitions

  • the present disclosure relates to an electronic device and a control method of the electronic device.
  • An object of the present specification is to provide an electronic device and a method of controlling the electronic device that can communicate an application of one electronic device with an application of another electronic device.
  • an electronic device includes an application processor and a network processor, a control unit for connecting to a companion device, a communication unit for transmitting and receiving data with the companion device, and the application processor is a companion to the network processor.
  • the network processor may connect the connection requesting application processor with the companion device.
  • the network processor may be a web socket server.
  • the application processor may transmit host request header information indicating at least one information of an electronic device or a companion device operating in the network processor, to the network processor.
  • the network processor may generate a stream head of the application processor and include the stream head in the stream head group when the connection request is made by the application processor.
  • the network processor receives the connection request from the companion device, the network processor generates the stream head of the companion device. And a stream head of the application processor matched from the stream head group.
  • the network processor may remove at least one of the matched stream head of the application processor or the stream head of the companion device from the stream head group.
  • the application processor may transmit the IP address of the companion device to be connected to the network processor.
  • the network processor may connect the application processor and the companion device using the same port.
  • a method of controlling an electronic device includes connecting with a companion device and transmitting and receiving data with the companion device, wherein the connecting step includes the companion device and the companion device as a network processor.
  • the connection request of the network processor receives a connection request from the companion device, the connection requesting processor and the companion device may be connected.
  • the network processor may be a web socket server.
  • the control method of the electronic device may further include transmitting, by the application processor, host request header information indicating at least one information of an electronic device or a companion device operating in the network processor.
  • the control method of the electronic device may include generating, by the network processor, a stream head of the application processor in a stream head group when the connection request is made by the application processor, and receiving the connection request from the companion device.
  • the processor may further include generating a stream head of the companion device and connecting the stream head of the application processor matched from the stream head group.
  • the control method of the electronic device may further include removing, by the network processor, at least one of the matched stream head of the application processor or the stream head of the companion device from the stream head group.
  • the control method of the electronic device may further include transmitting an IP address of the companion device to which the application processor is to connect to the network processor.
  • the connecting may include connecting the application processor and the companion device using the same port.
  • an electronic device and a control method may perform communication between an application running in one electronic device and an application running in another electronic device.
  • the electronic device and the control method may interface using a websocket server for communication between one electronic device and another electronic device.
  • the electronic device and the control method may connect one electronic device to another electronic device 1: 1.
  • FIG. 1 is a block diagram of an electronic device according to an embodiment of the present disclosure.
  • FIG. 2 illustrates a connection of a first client according to an exemplary embodiment.
  • FIG 3 illustrates a connection of a second client according to an embodiment of the present disclosure.
  • FIG. 4 illustrates a connection between a first client and a second client according to an embodiment.
  • FIG. 5 is a diagram illustrating an additional connection request according to one embodiment.
  • FIG. 6 is a diagram illustrating a connection between clients when there is no IP address according to an embodiment.
  • FIG. 7 illustrates a standby connection for connection between applications according to an embodiment of the present disclosure.
  • FIG. 8 is a diagram illustrating a new connection request for connection with a second client according to one embodiment.
  • FIG. 9 is a diagram illustrating setting of a first client when including an IP address according to an embodiment.
  • FIG. 10 is a diagram illustrating setting of first and second clients when including an IP address according to an embodiment.
  • FIG. 11 illustrates an embodiment of connecting to a plurality of second clients when including an IP address.
  • FIG. 12 is a flowchart illustrating a control method of an electronic device according to an embodiment of the present disclosure.
  • FIG. 1 is a block diagram of an electronic device according to an embodiment of the present disclosure.
  • the electronic device 100 may include a control unit 110 and a communication unit 120.
  • the controller 110 may perform a communication connection with the companion device.
  • the communication unit 120 may transmit / receive data with the companion device.
  • the controller 110 may include a network processor 111 and an application processor 112.
  • the application processor 112 may request a connection with the companion device to the network processor 111.
  • the network processor 111 may put a connection request received from the application processor 112 in a standby state. This is because the network processor 111 is not yet connected with the companion device. Thereafter, the network processor 111 may receive a connection request from the companion device. The network processor 111 may search for a connection request of the matching application processor 112 based on the information received from the companion device. When the network processor 111 searches for a matching connection request, the network processor 111 may connect the companion device to the application processor 112.
  • the application processor 112 may be an application module or an application browser. Or, it may be an HbbTV application.
  • the network processor 111 may be implemented as a network module.
  • the network processor 111 may be a WebSocket Server.
  • the network processor 111 may connect the application processor 112 and the companion device.
  • the application processor 112 and the companion device may be regarded as one client.
  • the websocket server may connect the first client and the second client.
  • the first client and the second client may each be called a peer.
  • the websocket server may be implemented as a separate device outside the electronic device.
  • the application processor 112 may drive one application.
  • the companion device can also drive one application.
  • the application processor 112 may be connected to the companion device through the network processor 111.
  • the companion device may receive data from the application processor 112 and receive and drive an application in which the application processor 112 is driven.
  • the application processor 112 and the companion device may each drive an application.
  • the application processor 112 may be connected to the companion device to transmit and receive data with the companion device. In this case, it may be said that the electronic device 100 and the companion device perform communication between applications.
  • the websocket server can be used as a repeater and create a communication channel between applications.
  • the generated communication channel may enable communication between the electronic device 100 and the companion device.
  • the websocket server may connect channels between applications requesting the same information by using an application name id and an application origin id to communicate with each other in order to create a communication channel.
  • the above-described method may connect an application (client) and an application (client) without modifying the websocket API in HbbTV 2.0.
  • FIG. 2 is a diagram illustrating a connection of a first client according to an exemplary embodiment.
  • the electronic device 100a may include an application processor and a network processor.
  • the application processor may be an HbbTV application or a first client
  • the network processor may be an HbbTV websocket server.
  • the companion device 200a may include a companion device processor.
  • the companion device processor may be a companion application or a second client.
  • the WebSocket server may need to be changed in order to establish a connection between clients. The following describes the operation related to the change of the websocket server.
  • the modified websocket server can be run on an HbbTV 2.0 TV.
  • the WebSocket client can specify the relative URI for the desired service on that host in the initial GET request, along with the remote host and WebSocket connection upgrade header to which the connection will be made.
  • a peer eg, companion device
  • the connection request from the first client for the client-to-client connection needs to remain active until there is a connection request from the target peer.
  • the upgrade WebSocket protocol GET request may contain two fields that define a specific use.
  • the request-URI may have a predetermined format of a general prefix string. This field can be used to match corresponding communication peers.
  • the Host request-header field refers to a TV set running on a WebSocket server (if communication is established with any peer with a matching URI request) or to a specific companion device (specified device and matching URI request). Communication is established with the customer). That is, the application processor may send host request header information indicating electronic device information or companion device information that operates in the network processor to the network processor.
  • the format for a URI request can be according to the following ABNF syntax.
  • HbbTV-Request-URI "/ hbbtv /" org-id ".” app-id
  • the websocket server In response to the URI request, the websocket server must create a stream head, which may mean a half open connection associated with the URI request supported by the client in the upgrade GET request. Instead of responding immediately to the WebSocket protocol handshake response, the WebSocket server may keep the first client waiting while waiting for another peer to appear. If the websocket server wishes to shut down, the server may respond with a 504 Gateway Timeout response.
  • the client When requesting a client-to-client connection, the client may not use the Sec-WebSocket protocol header.
  • the server may ignore the Sec-WebSocket protocol header in the request for a client-to-client connection. If the host header field in the client-to-client connection request does not specify any device on the local subnetwork to which the server is attached, the server may respond with a 403 Forbidden response. All HbbTV 2.0 WebSocket clients can use methods to request client-to-client connections from an HbbTV 2.0 WebSocket server.
  • a WebSocket client would specify the remote host to which it wishes a connection to be established, and the relative URI for the desired service on that host in the initial GET request along with the WebSocket connection upgrade header.
  • the peer to which communications are to be established has contacted the WebSocket server yet.
  • a connection request from a client in the special client-to-client mode hence needs to be kept active until another, suitable peer arrives.
  • the Host request-header field shall either refer to the TV set running the WebSocket server (in which case communications with any peer with a matching Request-URI will be established), or to a specific companion device (in which case communications only with the designated device, and with a matching Request-URI will be established).
  • HbbTV-Request-URI "/ hbbtv /" org-id ".” app-id
  • an HbbTV WebSocket server shall create a stream head, that is a half open connection, which is associated with the Request-URI supplied in the upgrade GET request by the client.
  • the server shall not respond immediately with a WebSocket Protocol Handshake response, but instead wait for other peers to appear, and thereby keep the first client waiting.
  • the server wishes to implement a time-out, it shall respond with a 504 Gateway Timeout response.
  • Clients shall not use the Sec-WebSocket-Protocol header when requesting client-to-client connections. Servers may ignore the Sec-WebSocket-Protocol header in requests for client-to-client connections. Servers shall respond with a 403 Forbidden response if the Host header field in a client-to-client connection request does not specify a device on any of the local sub-networks that the server is attached to. All HbbTV 2.0 WebSocket clients shall use the method described in this section to request client-to-client connections from HbbTV 2.0 WebSocket servers.
  • FIG. 3 is a diagram illustrating a connection of a second client according to an exemplary embodiment.
  • the electronic device 100a may include an application processor and a network processor.
  • the network processor eg, websocket server
  • the network processor may receive a connection request from the HbbTV application and the companion application.
  • the server may create a stream head for a new request, as shown in FIG. After the new stream head is created, the server may retrieve the set of stream heads currently waiting for connection for URI requests and matching host header field values other than the newly generated stream head. If no match is found, the server can add the newly created stream head to the set of stream heads waiting for a connection and wait for additional client-to-client connection requests.
  • the server when another client requests a client-to-client connection using the method as above, the server shall also create a stream head for that new request as shown in Fig. 3.After a new stream head is created, the server shall search the collection of stream heads currently waiting to be connected, for Request-URI and Host header field values matching those of the newly created stream head. If no match is found, the server shall add the newly created stream head to the collection of stream heads currently waiting to be connected, and shall keep waiting for further client-to-client connection requests.
  • FIG. 4 is a diagram illustrating a connection between a first client and a second client according to an exemplary embodiment.
  • the electronic device 100a may include an application processor and a network processor.
  • the network processor eg, websocket server
  • the network processor may connect the HbbTV application and the companion application.
  • the websocket server will match the stream head from that set. Can be eliminated and a two-way communication channel can be established between the two stream heads.
  • the server When two stream heads are connected, the server immediately outputs all the data received from one stream head, and does not change each other stream head. By doing so, a transparent communications channel can be established between the two clients.
  • the server may transmit a close frame corresponding to the other client. If one of the two clients disconnects without sending the close frame, the server can generate the close frame and send it to the other client.
  • the network processor may generate a stream head of the application processor and include the stream head in the stream head group.
  • the network processor may generate a stream head of the companion device and search for the existence of a matching stream head. If there is a matching stream head, the network processor may connect the stream head of the matching application processor and the stream head of the companion device from the stream head group. In this case, the network processor may remove the stream head of the matched application processor or the stream head of the companion device from the stream head group.
  • the server shall remove the matching stream head from the collection , and shall establish a full-duplex communications channel between the two stream heads as shown in Fig. 4.
  • the server output all data received from one stream head immediately and unaltered to the respective other stream head. Thereby, a transparent communications channel is established between the two clients. If one of the two clients sends a Close frame, the server shall send a corresponding Close frame to the other client. If one of the two clients disconnects without sending a Close frame, the server shall generate a Close frame, and shall send it to the other client.
  • FIG. 5 is a diagram illustrating an additional connection request according to an embodiment.
  • the HbbTV application (client) is connected to the companion application (client) of the companion device 200a. And the HbbTV application can create different stream heads for different clients.
  • the HbbTV application can be further connected with other applications.
  • the connection between clients can be one-to-one because the stream heads are removed from the set of connectable stream heads before establishing the connection between the clients. If a client wants to communicate with one or more other clients, the client can send additional connection requests to the server until the maximum number of connections between the clients can be reached.
  • the websocket server does not allow more than one stream head for the same client with the same URI request and host on the set of stream heads waiting for the connection. If a client issues a connection request with another client with the same URI request and host before one successful connection or timeout, the server may respond with a 403 Forbidden response.
  • a client may have a connection request between clients of several different URI request / host combinations in a waiting state to be connected.
  • a client cannot attempt to request a connection with another client with the same URI request / host combination before one successfully connects or times out.
  • any stream head be removed from the collection of stream heads available for connecting, prior to establishing a client-to-client connection, such client-to-client connections are one-to-one only.
  • a client wishes to communicate to more than one other client, it shall issue further connection requests to the server until the maximum number of client-to-client connections it is able to process, has been reached.
  • Servers shall not allow more than one stream heads for the same client with the same Request-URI and Host to be on the collection of stream heads currently waiting to be connected. If a client issues another client-to-client connection request with the same Request-URI and Host, before the previous one has been successfully connected or has timed-out, the server shall respond with a 403 Forbidden response.
  • Clients may have several client-to-client connection requests with different Request-URI / Host combinations in the waiting to be connected state. Clients shall not attempt to request another client-to-client connection with the same Request-URI / Host combination, before the previous one was either successfully connected or has timed-out.
  • the /hbbtv/orgid.appid scheme for URI requests can be used as a specific device-to-device operation to perform with others, use standard WebSocket server functions, and avoid interference between them.
  • Matching URI requests and host header fields may allow for two approaches. First, if a particular device (client) is targeted by a host header, the client may wish to talk to that targeted particular client. It may be recognized for its presence via other means (eg SSDP as part of UPnP). Second, if the host header field targets the server, it may be the same for all clients targeting the same server. This indicates that only a URI request is a differentiator for selecting the appropriate communication peer. Effectively targeting the server in the host header field can use the same URI request and provide a wildcard that matches other clients targeting the server. A dedicated and opportunistic connection establishment strategy may be possible.
  • the HbbTV 2.0 WebSocket server does not perform any authentication, authorization, or verification, there may be no trust between the client-to-client connection or between the client and the websocket server.
  • a client wishing to exchange personal information or sensitive information via a websocket server may perform an end password that will ensure communication privacy.
  • the client may perform an encryption scheme that establishes the identity or authenticity of the peer to communicate with via the websocket server.
  • the HbbTV 2.0 WebSocket Server establishes a connection with the indicated client over the connected Internet, it may not be susceptible to a successful denial-of-service attack against other clients via the HbbTV WebSocket Server.
  • the attacking client may stop requesting the server to connect to another client.
  • Denial of service attacks may be attempted against the server itself because the server has been defined as rejecting concurrent connection attempts to URI connections / host combinations that are not yet connected. This can be done by repeatedly sending the same connection request so that an error response is generated, or by sending a random connection request as one attempt to consume the resources of the server by creating many open stream heads. Both techniques are generic strategies for HTTP servers and are not specific to using WebSocket or HbbTV. Some WebSocket server implementations may have appropriate mitigation structures. (E.g. by stopping sending a response or generating a stream head)
  • HbbTV 2.0 WebSocket server since the HbbTV 2.0 WebSocket server does not perform any authentication, authorization, or other verification, no trust can be associated with client-to-client connections, or between clients and WebSocket servers. Clients that wish to exchange private, or otherwise sensitive information through a WebSocket server should therefore employ end-to-end encryption to ensure the privacy of the communication. Likewise, such clients should employ cryptographic methods to establish the identity and authenticity of any communication peers to which they wish to communicate through a WebSocket server. Since an HbbTV 2.0 WebSocket server will establish connections only to clients who have indicated the intent of being connected, it is very unlikely that a successful denial-of-service attack could be staged against another client through an HbbTV WebSocket server. The client under attack can simply stop asking the server to be connected to other clients.
  • a denial-of-service attack might be attempted against the server itself. This could be done by repeatedly sending the same connection request to provoke error responses being generated, or by sending random connection requests in an attempt to exhaust the server ’s resources by creating many open stream heads. Both techniques are general strategies against HTTP servers, and are not specific to WebSocket or HbbTV use of it. We hence expect that any WebSocket server implementation (be it of the HbbTV flavor or not) will have suitable mitigation mechanisms (e.g. by stopping sending responses or creating stream heads).
  • FIG. 6 is a diagram illustrating a connection between clients when there is no IP address according to an embodiment.
  • the WebSocket server may enable applications to communicate by connecting applications having the same URI path (other than the host name, that is, the path).
  • the client-to-client communication may selectively perform an application-to-application communication by distinguishing an application (eg, a TV application) running in an electronic device from an application (CS application) running in a companion device.
  • a URI request may be configured without including an IP address.
  • the path of the URI may begin with a reserved word (“hbbtv”) that advertises HbbTV after the root ("/"), followed by an organization or company identifier (org-id) and an app identifier (app-id). have.
  • the websocket server network processor
  • each client requesting a connection can use the same port and different ports. If the clients use the same port, if the IP of the application calling the WebSocket API is the same, the websocket server may know that the calling application is an HbbTV application, and if the IP is different, it is a companion device application. When using the same port, the WebSocket server can simplify server execution and testing, and does not require discovery. (With most WebSocket libraries, need to start a different instance per port.Single port drastically simplifies server implementation and test.No discovery needed if app-2-app server listens on well-defined port on the TV.)
  • FIG. 7 is a diagram illustrating a standby connection for connection between applications according to an exemplary embodiment.
  • the TV application of the electronic device 100a may transmit a connection request to the web socket server. Since the TV application is included in the electronic device, the websocket server may recognize the TV application as a local application. In addition, since the companion application exists outside the electronic device, the web socket server may recognize the companion application as the original application. As an example, an application may use the following method when making a connection request.
  • the network processor may execute the W3C WebSocket API and support at least 200 concurrent WebSocket connections.
  • the network processor may provide two service endpoints that run on the server side of the WebSocket protocol specification.
  • the local endpoint is for connection to the network processor by the HbbTV application.
  • the remote endpoint may be connected to the home network by an application of another device and is intended to include a remote companion application or an HbbTV application running on another HbbTV device.
  • HbbTV applications can be connected to the local service endpoint of the network processor they operate on or to a remote service endpoint of another hybrid terminal on the same home network. It is preferable that the network processor not connect to the local service endpoint of another device in the home network. For example, this can be achieved by placing a local service endpoint of the local loopback interface of the network processor. If another service endpoint runs the server side of the WebSocket Protocol specification and the HbbTV application or companion application uses such a service endpoint, the hybrid terminal must not locate the service endpoint on the same host and port combination as another service endpoint. do.
  • the base URL for the inter-application service endpoint may be a websocket URL.
  • WebSocket URLs can define resource names for hosts, ports, security, and service endpoints.
  • the client must connect to the host and port specified by the WebSocket URL of the service endpoint.
  • the resource name used in the initial protocol request by the client follows the ABNF syntax.
  • resource-name base-url-resource-name app-endpoint
  • the base-url-resource-name is a resource name derived from the web socket URL of the service endpoint.
  • app-endpoint is an application specification. This can be used in the client's connection matching process from the client. The message of the corresponding client may be delivered via the web socket protocol.
  • the app-endpoint can be selected by the application developer to avoid collisions. Thus, the app-endpoint can start with an identifier formatted with a reverse DNS notation that is uniquely associated with the HbbTV application or companion application and its developer.
  • Hybrid terminals can support app-endpoints that contain at least 1000 characters in length and any characters allowed in the resource name by the WebSocket protocol specification.
  • the service endpoint can support at least 10 simultaneous TCP socket connections from the client.
  • the server may reject the request if the server cannot handle concurrent connections. Otherwise, the server can accept the TCP socket connection and initiate a WebSocket protocol handshake over the TCP socket connection.
  • the server receives the client request handshake but the server may not immediately respond with a handshake response. Instead, the server can wait until the connection is paired or until the client is disconnected. In this state, the connection can form a standby connection. If the server wants to execute a timeout, the server may respond with a 504 gateway timeout response.
  • the server may ignore any origin header of the request handshake sent by the client.
  • the client may not use the Sec-WebSocket-Protocol header when requesting a connection between clients.
  • the server may ignore the Sec-WebSocket-Protocol header in the request for a connection between clients.
  • the server may not approve client requests for protocol extensions using the Sec-WebSocket-Protocol header. If the client uses the Sec-WebSocket extension header, the server may not be able to connect in the manner defined in the WebSocket Protocol Specification.
  • an HbbTV application acting as a client may attempt to connect with a local service endpoint having an app-endpoint of "org.mychannel.myapp" and a base-url-resource-name of / hbbtv /. have.
  • the connection with the companion device may remain idle because the companion application has not yet connected to communication between applications using the same app-endpoint.
  • FIG. 8 is a diagram illustrating a new connection request for connection with a second client according to one embodiment.
  • the HbbTV application (client) is connected to the companion application (client) of the companion device 200a. And the HbbTV application can create different stream heads for different clients.
  • the server cannot allow more than one simultaneous standby connection from the same original IP address with the same app-endpoint. If a client with that IP address issues another connection request using the same app-endpoint before successfully connecting or terminating, the server can respond with a 403 Forbidden response.
  • Clients may wish to establish connections between multiple concurrent clients through the same service endpoint using different resource-name combinations.
  • the client cannot attempt to request another connection to the service endpoint before waiting for a connection to an existing service endpoint is successfully connected, timed out, or disconnected.
  • the behavior of these clients can be defined by the WebSocket Protocol Specification.
  • the client may wait until an existing standby connection is paired. At this time, an additional connection request may be issued to the server until the maximum number of connections between the clients that can be processed is reached.
  • the HbbTV application may generate a new standby connection request to allow establishment of inter-application communication.
  • the client may also include an IP address in the URI path.
  • FIG. 9 is a diagram illustrating setting of a first client when an IP address is included according to an embodiment.
  • the above-described URI path starts with a reserved word ("hbbtb") indicating HbbTV after the root ("/"), followed by an organization / company identifier (org-id) and an application identifier (app-). id).
  • hbbtb a reserved word
  • org-id organization / company identifier
  • app- application identifier
  • id application identifier
  • an application that wants to perform communication between applications may add an IP address of a device running the target application to a path of a URI.
  • the WebSocket server can connect the WebSocket API calls according to the IPs that the URI paths of the same application want to communicate with each other.
  • TV application A may be running at IP 1.1.1.1
  • companion application B may be running at IP 1.1.1.2 (first user terminal)
  • companion application C may be running at IP 1.1.1.3 (second user terminal). have.
  • the TV application A may try to communicate with the companion application C.
  • the TV application A may include the IP (1.1.1.3) in which the companion application C is running in the path of the URI included in the WebSocket request.
  • the companion application C may include the IP (1.1.1.1) of the TV application A in the path of the URI included in the web socket request.
  • the URI path may be the same as hbbtv / 192.0.2.7 / org.mychannel.myapp HTTP / 1/1.
  • 192.0.2.7 may be an IP address of the target application.
  • 192.0.2.110 may be its own IP address.
  • org.mychannel.myapp may be an application ID.
  • FIG. 10 is a diagram illustrating setting of first and second clients when including an IP address according to an exemplary embodiment.
  • the websocket server may receive the URI request described in FIG. 9 from each client.
  • a first client having an IP address of 192.0.2.110 and a second client having an IP address of 192.0.2.7.
  • the application ID may be org.mychannel.myapp.
  • the second client requests a connection to the first client, the From Host is 192.0.2.7, and the To Host is 192.0.2.110.
  • the application ID may be org.mychannel.myapp. That is, the source and destination addresses of the first client and the second client may be opposite to each other. However, the application IDs are the same.
  • the websocket server can connect matching clients to each other.
  • a URI path including a host IP address may be used.
  • the URI path is Syntax) GET “/” hbbtv ”/” host_address ”/” org-id ".” App-id,
  • Example 10 It can be used as GET /hbbtv/192.0.2.7/org.mychannel.myapp.
  • FIG. 11 illustrates an embodiment of connecting to a plurality of second clients when including an IP address.
  • HbbTV has a constant IP address and includes an application ID of org.mychannel.myapp.
  • the first companion application IP address is 192.0.2.7 and the second companion application IP address is 192.0.2.1.
  • Application IDs of the first and second companion applications are org.mychannel.myapp.
  • the web socket server may connect matching clients with each other. Therefore, in response to a request of each client, the websocket server may connect matching clients with each other.
  • both clients designate a connection target, thereby improving security, enabling client-to-client connection, and matching all information without additional effort.
  • each client may use the same port or different ports.
  • FIG. 12 is a flowchart of a control method of an electronic device, according to an embodiment of the present disclosure.
  • the electronic device may connect with the companion device (S1210).
  • the electronic device may include a network processor and an application processor.
  • the electronic device may request the application processor to connect with the companion device to the network processor.
  • the network processor may connect the application processor that requested the connection to the companion device.
  • the application processor may be an application module or an application browser. Or, it may be an HbbTV application.
  • the network processor may be implemented as a network module. Alternatively, the network processor may be a WebSocket Server.
  • the application processor and the companion device may be regarded as one client. Alternatively, the first client and the second client may each be called a peer.
  • the application processor may transmit host request header information indicating electronic device information or companion device information operating in the network processor, to the network processor.
  • the network processor may generate a stream head of the application processor and include the stream head in the stream head group.
  • the network processor may generate a stream head of the companion device and connect the stream head of the matching application processor from the stream head group.
  • the network processor may remove the stream head of the matched application processor or the stream head of the companion device from the stream head group.
  • the application processor may transmit the IP address of the companion device to be connected, and each application may use the same port.
  • the electronic device may transmit / receive data with the companion device in operation S1220. Through this process, the electronic device may connect with the companion device to perform communication.
  • the electronic device and the control method according to the present disclosure are not limited to the configuration and method of the above-described embodiments, but various modifications may be made by selectively combining all or some of the embodiments.
  • control method of the electronic device of the present specification may be implemented as software in a processor-readable recording medium provided in the electronic device.
  • the processor-readable recording medium includes all kinds of recording devices that store data that can be read by the processor. Examples of the processor-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like, and may also be implemented in the form of a carrier wave such as transmission over the Internet. .
  • the processor-readable recording medium can also be distributed over network coupled computer systems so that the processor-readable code is stored and executed in a distributed fashion.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer And Data Communications (AREA)
  • Library & Information Science (AREA)
  • Telephone Function (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

전자 장치 및 전자 장치의 제어 방법이 개시된다. 전자 장치는 어플리케이션 프로세서 및 네트워크 프로세서를 포함하고, 컴패니언 장치와 연결하는 제어부, 컴패니언 장치와 데이터를 송수신하는 통신부를 포함하며, 어플리케이션 프로세서는 네트워크 프로세서로 컴패니언 장치와의 연결을 요청하고, 네트워크 프로세서는 컴패니언 장치로부터 연결 요청을 받으면, 연결 요청한 어플리케이션 프로세서와 상기 컴패니언 장치를 연결한다.

Description

전자 장치 및 전자 장치의 제어 방법
본 명세서는 전자 장치 및 전자 장치의 제어 방법에 관한 것이다.
방송 및 통신 기술의 발전에 따라 다양한 방송 장치 및 방송 서비스에 대한 기술이 개발되고 있다. 최근 스마트 폰과 스마트 TV가 대중화되어 다양한 어플리케이션이 스마트 폰과 스마트 TV 상에서 실행될 수 있다. 하나의 어플리케이션이 스마트 폰에서 실행되고 있을 때, 사용자는 스마트 TV에서도 스마트 폰에서 실행 중인 어플리케이션을 실행하고자 하는 경우가 있다. 이 경우 일반적으로 사용자는 정해진 경로를 따라 스마트 TV를 조작하여 스마트 폰에서 실행 중인 어플리케이션을 실행시킬 수 있다. 최근 통신 환경에서, 자신이 사용 중인 어플리케이션을 다른 기기에서 실행 중인 어플리케이션과 통신을 하고자 하는 사용자의 요구가 증가하고 있다. 그러나, 상술한 바와 같이 별도로 스마트 TV를 조작하여 어플리케이션을 실행시키는 것은 불편함이 있다.
이러한 불편함을 해결하기 위해 한 기기의 어플리케이션에서 다른 기기의 어플리케이션으로 통신을 수행할 수 있는 기술에 대한 필요성이 있다.
본 명세서의 목적은 하나의 전자 장치의 어플리케이션을 다른 전자 장치의 어플리케이션과 통신을 할 수 있는 전자 장치 및 전자 장치의 제어 방법을 제공하는 것이다.
본 명세서의 일 실시 예에 따르면, 전자 장치는 어플리케이션 프로세서 및 네트워크 프로세서를 포함하고, 컴패니언 장치와 연결하는 제어부, 상기 컴패니언 장치와 데이터를 송수신하는 통신부를 포함하며, 상기 어플리케이션 프로세서는 상기 네트워크 프로세서로 컴패니언 장치와의 연결을 요청하고, 상기 네트워크 프로세서는 상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 연결 요청한 어플리케이션 프로세서와 상기 컴패니언 장치를 연결할 수 있다.
그리고, 상기 네트워크 프로세서는 웹소켓 서버일 수 있다.
또한, 상기 어플리케이션 프로세서는 상기 네트워크 프로세서에서 동작하는 전자 장치 또는 컴패니언 장치 중 적어도 하나의 정보를 나타내는 호스트 요청 헤더 정보를 상기 네트워크 프로세서로 전송할 수 있다.
또한, 상기 네트워크 프로세서는 상기 어플리케이션 프로세서의 연결 요청이 있을 때, 상기 어플리케이션 프로세서의 스트림 헤드를 생성하여 스트림 헤드 그룹에 포함시키고, 상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 컴패니언 장치의 스트림 헤드를 생성하고, 상기 스트림 헤드 그룹으로부터 매칭되는 상기 어플리케이션 프로세서의 스트림 헤드와 연결할 수 있다.
그리고, 상기 네트워크 프로세서는 매칭된 상기 어플리케이션 프로세서의 스트림 헤드 또는 상기 컴패니언 장치의 스트림 헤드 중 적어도 하나를 상기 스트림 헤드 그룹으로부터 제거할 수 있다.
그리고, 상기 어플리케이션 프로세서는 연결하려는 컴패니언 장치의 IP 어드레스를 상기 네트워크 프로세서로 전송할 수 있다.
또한, 상기 네트워크 프로세서는 상기 어플리케이션 프로세서와 상기 컴패니언 장치를 동일한 포트를 이용하여 연결할 수 있다.
본 명세서의 일 실시 예에 따르면, 전자 장치의 제어 방법은 컴패니언 장치와 연결하는 단계 및 상기 컴패니언 장치와 데이터를 송수신하는 단계를 포함하며, 상기 연결하는 단계는 상기 어플리케이션 프로세서가 네트워크 프로세서로 컴패니언 장치와의 연결을 요청하고, 상기 네트워크 프로세서는 상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 연결 요청한 어플리케이션 프로세서와 상기 컴패니언 장치를 연결할 수 있다.
그리고, 상기 네트워크 프로세서는 웹소켓 서버일 수 있다.
그리고, 전자 장치의 제어 방법은 상기 네트워크 프로세서에서 동작하는 전자 장치 또는 컴패니언 장치 중 적어도 하나의 정보를 나타내는 호스트 요청 헤더 정보를 상기 어플리케이션 프로세서가 상기 네트워크 프로세서로 전송하는 단계를 더 포함할 수 있다.
또한, 전자 장치의 제어 방법은 상기 어플리케이션 프로세서의 연결 요청이 있을 때, 상기 네트워크 프로세서가 상기 어플리케이션 프로세서의 스트림 헤드를 생성하여 스트림 헤드 그룹에 포함시키는 단계 및 상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 네트워크 프로세서가 상기 컴패니언 장치의 스트림 헤드를 생성하여 상기 스트림 헤드 그룹으로부터 매칭되는 상기 어플리케이션 프로세서의 스트림 헤드와 연결하는 단계를 더 포함할 수 있다.
또한, 전자 장치의 제어 방법은 상기 네트워크 프로세서가 매칭된 상기 어플리케이션 프로세서의 스트림 헤드 또는 상기 컴패니언 장치의 스트림 헤드 중 적어도 하나를 상기 스트림 헤드 그룹으로부터 제거하는 단계를 더 포함할 수 있다.
또한, 전자 장치의 제어 방법은 상기 어플리케이션 프로세서가 연결하려는 컴패니언 장치의 IP 어드레스를 상기 네트워크 프로세서로 전송하는 단계를 더 포함할 수 있다.
한편, 상기 연결하는 단계는 상기 어플리케이션 프로세서와 상기 컴패니언 장치를 동일한 포트를 이용하여 연결할 수 있다.
본 명세서의 다양한 실시 예에 따르면, 전자 장치 및 제어 방법은 하나의 전자 장치에서 실행 중인 어플리케이션과 다른 전자 장치에서 실행 중인 어플리케이션 간의 통신을 수행할 수 있다.
그리고, 전자 장치 및 제어 방법은 하나의 전자 장치와 다른 전자 장치 간의 통신을 위해 웹소켓 서버를 사용하여 인터페이싱할 수 있다.
또한, 전자 장치 및 제어 방법은 하나의 전자 장치와 다른 전자 장치를 1:1로 연결시켜 줄 수 있다.
도 1은 일 실시 예에 따른 전자 장치의 블록도.
도 2는 일 실시 예에 따른 제1 클라이언트의 연결을 설명하는 도면.
도 3은 일 실시 예에 따른 제2 클라이언트의 연결을 설명하는 도면.
도 4는 일 실시 예에 따른 제1 및 제2 클라이언트 간의 연결을 설명하는 도면.
도 5는 일 실시 예에 따른 추가 연결 요청을 설명하는 도면.
도 6은 일 실시 예에 따른 IP 어드레스가 없는 경우 클라이언트 간의 연결을 설명하는 도면.
도 7은 일 실시 예에 따른 어플리케이션 간의 연결을 위한 대기 연결을 설명하는 도면.
도 8은 일 실시 예에 따른 제2 클라이언트와 연결을 위한 새로운 연결 요청을 설명하는 도면.
도 9는 일 실시 예에 따른 IP 어드레스를 포함하는 경우 제1 클라이언트의 설정을 설명하는 도면.
도 10은 일 실시 예에 따른 IP 어드레스를 포함하는 경우 제1 및 제2 클라이언트의 설정을 설명하는 도면.
도 11은 IP 어드레스를 포함하는 경우 복수의 제2 클라이언트에 연결하는 일 실시 예를 설명하는 도면.
도 12는 일 실시 예에 따른 전자 장치의 제어 방법의 흐름도.
이하 상술한 목적을 구체적으로 실현할 수 있는 본 명세서의 바람직한 실시 예를 첨부한 도면을 참조하여 설명한다. 이때 도면에 도시되고 또 이것에 의해서 설명되는 본 명세서의 구성과 작용은 적어도 하나의 실시 예로서 설명되는 것이며, 이것에 의해서 본 명세서의 기술적 사상과 그 핵심 구성 및 작용이 제한되지는 않는다.
본 명세서에서 사용되는 용어는 본 명세서에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 이는 당해 기술 분야에 종사하는 기술자의 의도 또는 관례 또는 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 명세서의 설명 부분에서 상세히 그 의미를 기재할 것이다. 따라서 본 명세서에서 사용되는 용어는 단순한 용어의 명칭이 아닌 그 용어가 가지는 의미와 본 명세서의 전반에 걸친 내용을 토대로 정의되어야 함을 밝혀두고자 한다.
도 1은 일 실시 예에 따른 전자 장치의 블록도이다.
도 1을 참조하면, 전자 장치(100)는 제어부(110) 및 통신부(120)를 포함할 수 있다. 제어부(110)는 컴패니언 장치와 통신 연결을 수행할 수 있다. 그리고, 컴패니언 장치와 통신 연결이 되면 통신부(120)는 컴패니언 장치와 데이터를 송수신할 수 있다.
그리고, 제어부(110)는 네트워크 프로세서(111) 및 어플리케이션 프로세서(112)를 포함할 수 있다. 어플리케이션 프로세서(112)는 네트워크 프로세서(111)로 컴패니언 장치와 연결을 요청할 수 있다.
네트워크 프로세서(111)는 어플리케이션 프로세서(112)로 받은 연결 요청을 대기 상태로 둘 수 있다. 네트워크 프로세서(111)는 아직 컴패니언 장치와 연결이 되지 않았기 때문이다. 이후에 네트워크 프로세서(111)는 컴패니언 장치로부터 연결 요청을 수신할 수 있다. 네트워크 프로세서(111)는 컴패니언 장치로부터 수신한 정보를 기초로 매칭되는 어플리케이션 프로세서(112)의 연결 요청을 검색할 수 있다. 네트워크 프로세서(111)는 매칭되는 연결 요청을 검색하면 컴패니언 장치와 어플리케이션 프로세서(112)를 연결할 수 있다.
일 실시 예로서, 어플리케이션 프로세서(112)는 어플리케이션 모듈, 어플리케이션 브라우저일 수 있다. 또는, HbbTV 어플리케이션일 수 있다. 일 실시 예로서, 네트워크 프로세서(111)는 네트워크 모듈로 구현될 수 있다. 또는, 네트워크 프로세서(111)는 웹소켓 서버(WebSocket Server)일 수 있다. 네트워크 프로세서(111)는 어플리케이션 프로세서(112)와 컴패니언 장치를 연결해 줄 수 있다. 일 실시 예로서, 네트워크 프로세서(111)가 웹소켓 서버로 구현되는 경우, 어플리케이션 프로세서(112)와 컴패니언 장치는 각각 하나의 클라이언트라고 볼 수 있다. 다시 말해서, 웹소켓 서버가 제1 클라이언트와 제2 클라이언트를 연결해 줄 수 있다. 또는, 제1 클라이언트와 제2 클라이언트를 각각 피어(peer)라고 부를 수도 있다. 경우에 따라, 웹소켓 서버는 전자 장치 외부에 별도의 장치로서 구현될 수도 있다.
한편, 어플리케이션 프로세서(112)는 하나의 어플리케이션을 구동시킬 수 있다. 그리고, 컴패니언 장치도 하나의 어플리케이션을 구동시킬 수 있다. 어플리케이션 프로세서(112)는 네트워크 프로세서(111)를 통해 컴패니언 장치와 연결할 수 있다. 컴패니언 장치는 어플리케이션 프로세서(112)로부터 데이터를 수신하여 어플리케이션 프로세서(112)가 구동 중인 어플리케이션을 수신하여 구동시킬 수 있다. 또는, 어플리케이션 프로세서(112)와 컴패니언 장치는 각각 어플리케이션을 구동시킬 수 있다. 어플리케이션 프로세서(112)는 컴패니언 장치와 연결하여 컴패니언 장치와 데이터를 송수신할 수 있다. 이 경우, 전자 장치(100)와 컴패니언 장치는 어플리케이션 간 통신을 수행한다고 말할 수 있다.
웹소켓 서버는 중계기로 이용되고 어플리케이션 간의 통신 채널을 생성할 수 있다. 생성된 통신 채널은 전자 장치(100)와 컴패니언 장치 간 통신을 가능하게 할 수 있다. 웹소켓 서버는 통신 채널을 생성하기 위해 통신을 하고자 하는 어플리케이션 네임 아이디(application name id)와 어플리케이션 오리진 아이디(application origin id)를 이용하여 같은 정보를 요청하는 어플리케이션끼리 채널을 연결해 줄 수 있다. 일 실시 예로서, 상술한 방법은 HbbTV 2.0에서 웹소켓 API를 수정하지 않고 어플리케이션(클라이언트)와 어플리케이션(클라이언트)을 연결할 수 있다.
본 명세서에서는 각 용어를 혼용하여 사용하도록 한다.
도 2는 일 실시 예에 따른 제1 클라이언트의 연결을 설명하는 도면이다.
도 2를 참조하면, 전자 장치(100a)와 컴패니언 장치(200a)가 도시되어 있다. 전자 장치(100a)는 어플리케이션 프로세서와 네트워크 프로세서를 포함할 수 있다. 일 실시 예로서, 어플리케이션 프로세서는 HbbTV 어플리케이션 또는 제1 클라이언트일 수 있고, 네트워크 프로세서는 HbbTV 웹소켓 서버일 수 있다. 컴패니언 장치(200a)는 컴패니언 장치 프로세서를 포함할 수 있다. 일 실시 예로서, 컴패니언 장치 프로세서는 컴패니언 어플리케이션 또는 제2 클라이언트일 수 있다. 클라이언트 간의 연결을 수행하기 위해 웹소켓 서버는 변경이 필요할 수 있다. 아래에서는 웹소켓 서버의 변경과 관련된 동작을 설명한다. 변경된 웹소켓 서버는 HbbTV 2.0 TV에서 구동될 수 있다.
일반적으로 웹소켓 클라이언트는 연결을 하고자하는 원격 호스트 및 웹소켓 연결 업그레이드 헤더와 함께 초기 GET 요청시 그 호스트에서 원하는 서비스를 위한 상대적 URI를 지정할 수 있다. 그러나, HbbTV의 경우, 통신 연결을 위한 피어(peer)(예, 컴패니언 장치)가 아직 웹소켓 서버와 컨택되지 않을 수 있다. 따라서, 클라이언트 간 연결을 위한 제1 클라이언트로부터의 연결 요청은 대상 피어의 연결 요청이 있을 때까지 활성을 유지할 필요가 있다.
이러한 필요성 때문에 업그레이드 웹소켓 프로토콜 GET 요청은 특정 사용을 정의한 두 가지 필드를 포함할 수 있다. URI 요청(Request-URI)은 일반 접두사 스트링의 기 설정된 포맷을 가질 수 있다. 이 필드는 대응되는 통신 피어들을 매칭하는데 사용될 수 있다. 호스트 요청 헤더(Host request-header) 필드는 웹소켓 서버에서 동작하는 TV 셋을 언급(매칭 URI 요청을 가진 임의의 피어와 통신이 설립되는 경우)하거나 특정 컴패니언 장치를 언급(지정된 장치 및 매칭 URI 요청과 통신이 설립되는 경우)할 수 있다. 즉, 어플리케이션 프로세서는 네트워크 프로세서에서 동작하는 전자 장치 정보 또는 컴패니언 장치 정보를 나타내는 호스트 요청 헤더 정보를 네트워크 프로세서로 보낼 수 있다.
URI 요청을 위한 포맷은 아래의 ABNF 문법에 따를 수 있다.
HbbTV-Request-URI = "/hbbtv/" org-id "." app-id
org-id = 8HEX
app-id = 4HEX
URI 요청에 대응하여 웹소켓 서버는 스트림 헤드를 생성해야 하는데, 이것은 클라이언트에 의해 업그레이드 GET 요청에서 지원되는 URI 요청과 관련된 하프(half) 오픈 연결을 의미할 수 있다. 웹소켓 서버는 웹소켓 프로토콜 핸드쉐이크(handshake) 응답에 즉시 응답하는 대신, 다른 피어(peer)가 나타나길 기다리면서 제1 클라이언트의 대기 상태를 유지시킬 수 있다. 웹소켓 서버가 종료하길 희망하는 경우, 서버는 504 게이트웨이 타임아웃 응답(504 Gateway Timeout response)으로 반응할 수 있다.
클라이언트 간 연결을 요청할 때, 클라이언트는 Sec-웹소켓 프로토콜 헤더를 사용하지 않을 수 있다. 서버는 클라이언트 간 연결을 위한 요청 내의 Sec-웹소켓 프로토콜 헤더를 무시할 수도 있다. 클라이언트 간 연결 요청 내의 호스트 헤더 필드는 서버가 어태치(attached)되는 로컬 서브 네트워크 상의 어떤 장치도 지정하지 않으면, 서버는 403 금지 응답(403 Forbidden response)으로 반응할 수 있다. 모든 HbbTV 2.0 웹소켓 클라이언트는 HbbTV 2.0 웹소켓 서버로부터 클라이언트 간 연결을 요청하는 메소드를 사용할 수 있다.
In other words, usually, a WebSocket client would specify the remote host to which it wishes a connection to be established, and the relative URI for the desired service on that host in the initial GET request along with the WebSocket connection upgrade header. In the HbbTV case however, it can not be assumed that the peer to which communications are to be established, has contacted the WebSocket server yet. A connection request from a client in the special client-to-client mode, hence needs to be kept active until another, suitable peer arrives.
To achieve this, we define special uses for two fields of the WebSocket protocol upgrade GET request.
The Request-URI - which is part of the Request-Line - takes a predefined format with a common prefix string. This field is used to match corresponding communication peers.
The Host request-header field shall either refer to the TV set running the WebSocket server (in which case communications with any peer with a matching Request-URI will be established), or to a specific companion device (in which case communications only with the designated device, and with a matching Request-URI will be established).
The format for the Request-URI field shall be according to the following ABNF grammar:
HbbTV-Request-URI = "/hbbtv/" org-id "." app-id
org-id = 8HEX
app-id = 4HEX
These rules are illustrated in Fig. 2. In response to such a request, an HbbTV WebSocket server shall create a stream head, that is a half open connection, which is associated with the Request-URI supplied in the upgrade GET request by the client. The server shall not respond immediately with a WebSocket Protocol Handshake response, but instead wait for other peers to appear, and thereby keep the first client waiting. In case the server wishes to implement a time-out, it shall respond with a 504 Gateway Timeout response.
Clients shall not use the Sec-WebSocket-Protocol header when requesting client-to-client connections. Servers may ignore the Sec-WebSocket-Protocol header in requests for client-to-client connections. Servers shall respond with a 403 Forbidden response if the Host header field in a client-to-client connection request does not specify a device on any of the local sub-networks that the server is attached to. All HbbTV 2.0 WebSocket clients shall use the method described in this section to request client-to-client connections from HbbTV 2.0 WebSocket servers.
도 3은 일 실시 예에 따른 제2 클라이언트의 연결을 설명하는 도면이다.
도 3을 참조하면, 전자 장치(100a)와 컴패니언 장치(200a)가 도시되어 있다. 전자 장치(100a)는 어플리케이션 프로세서와 네트워크 프로세서를 포함할 수 있다. 네트워크 프로세서(예, 웹소켓 서버)는 HbbTV 어플리케이션 및 컴패니언 어플리케이션으로부터 연결 요청을 수신할 수 있다.
다른 클라이언트가 상술한 메소드를 이용하여 클라이언트 간 연결을 요청할 때, 서버는 도 3에서 보는 바와 같이 새로운 요청을 위한 스트림 헤드를 생성할 수 있다. 새로운 스트림 헤드가 생성된 후, 서버는 URI 요청 및 새로 생성된 스트림 헤드외 매칭되는 호스트 헤더 필드 값을 위해 현재 연결 대기 중인 스트림 헤드의 집합을 검색할 수 있다. 어떠한 매칭도 발견되지 않으면 서버는 새로 생성된 스트림 헤드를 연결을 위해 대기 중인 스트림 헤드의 집합에 추가하고, 추가적인 클라이언트 간 연결 요청을 기다릴 수 있다.
In other words, when another client requests a client-to-client connection using the method as above, the server shall also create a stream head for that new request as shown in Fig. 3. After a new stream head is created, the server shall search the collection of stream heads currently waiting to be connected, for Request-URI and Host header field values matching those of the newly created stream head. If no match is found, the server shall add the newly created stream head to the collection of stream heads currently waiting to be connected, and shall keep waiting for further client-to-client connection requests.
도 4는 일 실시 예에 따른 제1 및 제2 클라이언트 간의 연결을 설명하는 도면이다.
도 4를 참조하면, 전자 장치(100a)와 컴패니언 장치(200a)가 도시되어 있다. 전자 장치(100a)는 어플리케이션 프로세서와 네트워크 프로세서를 포함할 수 있다. 네트워크 프로세서(예, 웹소켓 서버)는 HbbTV 어플리케이션 및 컴패니언 어플리케이션을 연결할 수 있다.
새로 생성된 스트림 헤드가 현재 연결을 위해 대기하는 스트림 헤드의 집합 내의 스트림 헤드로서 동일한 호스트 헤더 필드 값 및 동일한 URI 요청(Request-URI)과 연관되어 있다면, 웹소켓 서버는 그 집합으로부터 매칭되는 스트림 헤드를 제거하고, 두 개의 스트림 헤드 사이의 양 방향 통신 채널을 설립할 수 있다.
두 개의 스트림 헤드가 연결되면, 서버는 즉시 하나의 스트림 헤드로부터 수신한 모든 데이터를 출력하고, 각각 다른 스트림 헤드로 변경하지 않는다. 이렇게 함으로써, 두 클라이언트 간의 투명한 통신 채널(a transparent communications channel)이 설립될 수 있다.
두 클라이언트 중 하나가 클로즈 프레임(Close frame)을 전송하면, 서버는 다른 클라이언트에게 대응되는 클로즈 프레임을 전송할 수 있다. 두 클라이언트 중 하나가 클로즈 프레임을 전송하지 않고 연결을 해제하면, 서버는 클로즈 프레임을 생성하고 다른 클라이언트에게 전송할 수 있다.
즉, 네트워크 프로세서는 어플리케이션 프로세서의 연결 요청이 있을 때, 어플리케이션 프로세서의 스트림 헤드를 생성하여 스트림 헤드 그룹에 포함시킬 수 있다. 그리고, 네트워크 프로세서는 컴패니언 장치로부터 연결 요청을 받으면, 컴패니언 장치의 스트림 헤드를 생성하여 매칭되는 스트림 헤드의 존재 여부를 검색할 수 있다. 매칭되는 스트림 헤드가 존재하면, 네트워크 프로세서는 스트림 헤드 그룹으로부터 매칭되는 어플리케이션 프로세서의 스트림 헤드와 컴패니언 장치의 스트림 헤드를 연결할 수 있다. 이때, 네트워크 프로세서는 매칭된 어플리케이션 프로세서의 스트림 헤드 또는 컴패니언 장치의 스트림 헤드를 스트림 헤드 그룹으로부터 제거할 수 있다.
In other words, if a newly created stream head is associated with the same Request-URI and Host header field values as a stream head in the collection of stream heads currently waiting to be connected, the server shall remove the matching stream head from the collection, and shall establish a full-duplex communications channel between the two stream heads as shown in Fig. 4. Once the two stream heads are connected, the server output all data received from one stream head immediately and unaltered to the respective other stream head. Thereby, a transparent communications channel is established between the two clients. If one of the two clients sends a Close frame, the server shall send a corresponding Close frame to the other client. If one of the two clients disconnects without sending a Close frame, the server shall generate a Close frame, and shall send it to the other client.
도 5는 일 실시 예에 따른 추가 연결 요청을 설명하는 도면이다.
도 5를 참조하면, HbbTV 어플리케이션(클라이언트)은 컴패니언 장치(200a)의 컴패니언 어플리케이션(클라이언트)과 연결되어 있다. 그리고, HbbTV 어플리케이션은 다른 클라이언트를 위한 다른 스트림 헤드를 생성할 수 있다. HbbTV 어플리케이션은 다른 어플리케이션과 추가로 연결될 수 있다. 스트림 헤드는 클라이언트 간의 연결을 설립 전에 연결 가능한 스트림 헤드 집합에서 제거되기 때문에 클라이언트 간의 연결은 일대일로 될 수 있다. 만일 클라이언트가 하나 이상의 다른 클라이언트와 통신을 원하면, 클라이언트는 처리 가능한 클라이언트 간의 연결 최대 갯수에 다다를 때까지 추가 연결 요청을 서버로 보낼 수 있다.
웹소켓 서버는 연결을 위해 대기하는 스트림 헤드 집합 상에서 동일한 URI 요청과 호스트를 가진 동일한 클라이언트를 위한 하나 이상의 스트림 헤드를 허락하지 않는다. 클라이언트가 하나의 성공적인 연결이나 타임 아웃 전에 동일한 URI 요청 및 호스트를 가진 다른 클라이언트와의 연결 요청을 발행하면, 서버는 403 금지 응답(403 Forbidden response)으로 반응할 수 있다.
클라이언트는 연결될 대기 상태에서 몇 가지 서로 다른 URI 요청/호스트 조합의 클라이언트 간의 연결 요청을 가질 수 있다. 클라이언트는 하나가 성공적으로 연결되거나 타임 아웃되기 전에 동일한 URI 요청/호스트 조합을 가지고 다른 클라이언트와의 연결을 요청하는 시도를 할 수 없다.
In other words, any stream head be removed from the collection of stream heads available for connecting, prior to establishing a client-to-client connection, such client-to-client connections are one-to-one only. If a client wishes to communicate to more than one other client, it shall issue further connection requests to the server until the maximum number of client-to-client connections it is able to process, has been reached. Servers shall not allow more than one stream heads for the same client with the same Request-URI and Host to be on the collection of stream heads currently waiting to be connected. If a client issues another client-to-client connection request with the same Request-URI and Host, before the previous one has been successfully connected or has timed-out, the server shall respond with a 403 Forbidden response. Clients may have several client-to-client connection requests with different Request-URI/Host combinations in the waiting to be connected state. Clients shall not attempt to request another client-to-client connection with the same Request-URI/Host combination, before the previous one was either successfully connected or has timed-out.
다른 것과 함께 수행되고 표준 웹소켓 서버 기능들을 사용하며 그들 간의 간섭이 없도록 하기 위해 특정 장치간 동작으로서 URI 요청을 위한 /hbbtv/orgid.appid 스킴(scheme)이 사용될 수 있다. URI 요청 및 호스트 헤더 필드의 매칭은 두 가지 접근 방법을 허용할 수 있다. 첫째, 특정 장치(클라이언트)가 호스트 헤더에 의해 타겟되면, 클라이언트는 그 타켓된 특정 클라이언트와 대화를 희망할 수 있다. 그것은 다른 수단(예, UPnP의 파트로서 SSDP)을 통해 그것의 존재에 대해 인식될 수 있다. 둘째, 호스트 헤더 필드가 서버를 타켓으로 한다면, 동일한 서버를 타켓팅하는 모든 클라이언트에게 동일할 수 있다. 이것은 URI 요청만이 적절한 통신 피어를 선택하기 위한 차별적인 요소임을 나타낸다. 이렇게 호스트 헤더 필드에서 효과적으로 서버를 타켓팅하는 것은 동일한 URI 요청을 사용하고 서버를 타켓팅하는 다른 클라이언트와 매칭되는 와일드카드를 제공할 수 있다. 전용적이고 기회적인 연결 설립 전략이 가능할 수 있다.
In other words, we chose the special “/hbbtv/orgid.appid” scheme for the Request-URI as an escape into the special server client-to-client behaviour in order to allow it to be implemented along with other, standard WebSocket server functionalities, and without interfering with them. The choice of matching the Request-URI and Host header field allows for two approaches: if a specific device is targeted by the Host header, the client only wishes to talk to that specific other client. It may have learnt about its existence through other means (e.g. SSDP as part of UPnP). Secondly, if the Host header field targets the server, it will be the same for all clients targeting the same server. This will result in only the Request-URI being the discriminating factor for choosing suitable communication peers. Hence, targeting the server in the Host header field effectively provides a wildcard match with any other client using the same Request-URI and also targeting the server. So both, dedicated and opportunistic connection establishment strategies are possible.
HbbTV 2.0 웹소켓 서버는 어떤 인증, 허가 또는 확인 과정을 수행하지 않기 때문에 클라이언트 간 연결이나 클라이언트와 웹 소켓 서버간의 신뢰성이 없을 수 있다. 개인 정보 또는 웹소켓 서버를 통한 민감한 정보를 교환하려는 클라이언트는 통신 프라이버시를 보증할 끝단 암호를 수행할 수 있다. 클라이언트는 웹소켓 서버를 통해 통신을 수행할 피어의 신원이나 진위를 설립할 암호화 방식을 수행할 수 있다. HbbTV 2.0 웹소켓 서버는 연결된 인터넷을 통해 표시된 클라이언트와 연결을 설립하기 때문에 HbbTV 웹소켓 서버를 통해 다른 클라이언트에 대한 성공적인 서비스 거부 공격(denial-of-service attack)을 받지 않을 수 있다. 공격받는 클라이언트는 서버에게 다른 클라이언트로 연결하라는 요청을 중지할 수 있다.
서버는 아직 연결되지 않은 URI 연결/호스트 컴비네이션에 동시 연결 시도를 거절하는 것으로 정의했기 때문에 서비스 거부 공격은 서버 자체에 대해 시도될 수도 있다. 이것은 에러 응답이 생성되도록 동일한 연결 요청을 반복적으로 전송하거나 많은 오픈 스트림 헤드를 생성하여 서버의 리소스를 소비하기 위한 하나의 시도로서 랜덤 연결 요청을 전송함으로써 행해질 수 있다. 두 기술은 HTTP 서버에 대한 일반적인 전략이고, 웹소켓이나 HbbTV 사용의 특정한 것은 아니다. 어떤 웹소켓 서버 실행은 적절한 경감 구조를 가질 수 있다. (예, 응답 전송이나 스트림 헤드의 생성을 중지시킴으로써)
In other words, since the HbbTV 2.0 WebSocket server does not perform any authentication, authorisation, or other verification, no trust can be associated with client-to-client connections, or between clients and WebSocket servers. Clients that wish to exchange private, or otherwise sensitive information through a WebSocket server should therefore employ end-to-end encryption to ensure the privacy of the communication. Likewise, such clients should employ cryptographic methods to establish the identity and authenticity of any communication peers to which they wish to communicate through a WebSocket server. Since an HbbTV 2.0 WebSocket server will establish connections only to clients who have indicated the intent of being connected, it is very unlikely that a successful denial-of-service attack could be staged against another client through an HbbTV WebSocket server. The client under attack can simply stop asking the server to be connected to other clients.
Since we defined that a server shall reject simultaneous connection attempts to a not yet connected Request-URI/Host combination, a denial-of-service attack might be attempted against the server itself. This could be done by repeatedly sending the same connection request to provoke error responses being generated, or by sending random connection requests in an attempt to exhaust the server’s resources by creating many open stream heads. Both techniques are general strategies against HTTP servers, and are not specific to WebSocket or HbbTV use of it. We hence expect that any WebSocket server implementation (be it of the HbbTV flavour or not) will have suitable mitigation mechanisms (e.g. by stopping sending responses or creating stream heads).
도 6은 일 실시 예에 따른 IP 어드레스가 없는 경우 클라이언트 간의 연결을 설명하는 도면이다.
도 6을 참조하면, 클러이언트 간 통신 연결을 수행하는 방법이 도시되어 있다. 상술한 웹소켓 기반 어플리케이션 간 통신 방법은 웹 소켓 서버가 URI의 경로(호스트 네임을 제외한 나머지 경로, 즉 path)가 같은 어플리케이션끼리 연결시켜 어플리케이션 간 통신을 가능하게 할 수 있다. 클라이언트 간 통신은 전자 장치에서 구동되는 어플리케이션(예, TV 어플리케이션)과 컴패니언 장치에서 구동되는 어플리케이션(CS 어플리케이션)을 구분하여 선택적으로 어플리케이션 간 통신을 수행할 수 있다.
일 실시 예로서, HbbTV에 있어서 URI 요청(Request-URI)은 IP 어드레스를 포함하지 않고 구성할 수 있다. URI의 경로(path)는 루트("/")뒤에 HbbTV를 알리는 예약어("hbbtv")로 시작하고, 그 뒤에 기관 또는 회사 구분자(org-id)와 앱 구분자(app-id)로 구성될 수 있다. 웹소켓 서버(네트워크 프로세서)는 웹소켓 API 콜의 URI 경로가 같은 어플리케이션끼리 연결시켜 줄 수 있다.
신택스) GET "/hbbtv/"org-id"."app-id
실시예) GET/hbbtv/org.mychannel.myapp
한편, 연결을 요청하는 각 클라이언트는 같은 포트(port)를 사용할 수 있고 다른 포트를 사용할 수 있다. 클라이언트들이 같은 포트를 사용하는 경우, 웹소켓 API를 호출하는 어플리케이션의 IP가 같은 경우, 웹소켓 서버는 호출하는 어플리케이션이 HbbTV 어플리케이션임을 알 수 있고, IP가 다른 경우 컴패니언 장치 어플리케이션임을 알 수 있다. 같은 포트를 사용하는 경우, 웹소켓 서버는 서버 실행과 테스트를 간소화할 수 있고, 디스커버리가 불필요한 장점이 있다. (With most WebSocket libraries, need to start a different instance per port. Single port drastically simplifies server implementation and test. No discovery needed if app-2-app server listens on well-defined port on the TV.)
다음으로 클라이언트들이 다른 포트를 사용하는 경우를 설명한다. 이 경우에는 TV에서 구동하는 어플리케이션과 컴패니언 장치에서 구동하는 어플리케이션이 같은 URI 경로를 사용하지만, 서로 다른 포트를 쓰는 경우를 의미한다. 일 실시 예로서, TV에서 구동하는 HbbTV 어플리케이션은 8900 포트를 사용하고, 컴패니언 장치에서 구동하는 어플리케이션은 8901 포트를 사용할 수 있다. 웹소켓 서버가 TV 어플리케이션/컴패니언 어플리케이션이 사용하는 포트를 알면 TV 어플리케이션/컴패니언 어플리케이션 간 통신, 컴패니언 어플리케이션/컴패니언 어플리케이션 간 통신을 구분할 수 있다. 다른 포트를 사용할 때, 서로 같은 호스트 요청-헤더를 사용하여 여러 개의 컴패니언 장치가 TV로 연결될 경우, 이를 구분하여 클라이언트 간을 용이하게 연결할 수 있다. TV와 컴패니언 장치 모두가 호스트 요청-헤더는 같지만 웹소켓 서버에 서로 다른 포트를 통해 접속하여 통신하기 때문에 어느 장치가 컴패니언 장치인지 TV인지 알 수 있다. 이에 따라, 보안 측면에서 보완할 수 있다.
도 7은 일 실시 예에 따른 어플리케이션 간의 연결을 위한 대기 연결을 설명하는 도면이다.
도 7을 참조하면, 전자 장치(100a)와 컴패니언 장치(200a)가 도시되어 있다. 전자 장치(100a)의 TV 어플리케이션은 웹 소켓 서버로 연결 요청을 전송할 수 있다. TV 어플리케이션은 전자 장치 내에 포함되어 있으므로 웹소켓 서버는 TV 어플리케이션을 로컬 어플리케이션으로 인식할 수 있다. 그리고, 컴패니언 어플리케이션은 전자 장치 외부에 존재하므로 웹소켓 서버는 컴패니언 어플리케이션을 원결 어플리케이션으로 인식할 수 있다. 일 실시 예로서, 어플리케이션은 연결 요청을 할 때 다음과 같은 메소드를 사용할 수 있다.
표 1
String getApp2AppLocalBaseURL()
Description Returns the base URL of the application to application communication service local end-point.
Arguments No arguments
표 2
String getApp2AppRemoteBaseURL()
Description Returns the base URL of the application to application communication service remote end-point.
Arguments No arguments
일 실시 예로서, 네트워크 프로세서는 W3C 웹소켓 API를 실행할 수 있고 최소 200개의 동시 웹소켓 연결을 지원할 수 있다.
네트워크 프로세서는 웹소켓 프로토콜 사양의 서버 측에서 실행하는 두 가지 서비스 엔드 포인트를 제공할 수 있다. 로컬 엔드 포인트는 HbbTV 어플리케이션에 의해 네트워크 프로세서로의 연결을 위한 것이다. 원격 엔드 포인트는 다른 장치의 어플리케이션에 의해 홈 네트워크에 연결될 수 있고, 다른 HbbTV 장치에서 구동하는 원격 컴패니언 어플리케이션 또는 HbbTV 어플리케이션을 포함하기 위한 것이다. HbbTV 어플리케이션은 그들이 동작하는 네트워크 프로세서의 로컬 서비스 엔드 포인트나 동일한 홈 네트워크 상의 다른 하이브리드 터미널의 원격 서비스 엔드 포인트에 연결될 수 있다. 네트워크 프로세서는 홈 네트워크 내의 다른 장치의 로컬 서비스 엔드 포인트에 연결하지 않는 편이 낫다. 예를 들어, 네트워크 프로세서의 로컬 루프백 인터페이스의 로컬 서비스 엔드 포인트를 위치시킴으로써 이룰 수 있다. 다른 서비스 엔드 포인트가 웹소켓 프로토콜 사양의 서버 측을 실행하고 HbbTV 어플리케이션이나 컴패니언 어플리케이션이 그러한 서비스 엔드 포인트를 사용하면 하이브리드 터미널은 다른 서비스 엔드 포인트로서 동일한 호스트 및 포트 조합에서 서비스 엔드 포인트를 위치시키서는 안 된다.
어플리케이션 간 서비스 엔드 포인트를 위한 기본 URL은 웹소켓 URL일 수 있다. 웹소켓 URL은 호스트, 포트, 보안 및 서비스 엔드 포인트의 리소스 네임을 정의할 수 있다. 클라이언트는 서비스 엔드 포인트의 웹소켓 URL에 의해 명시된 호스트와 포트에 연결해야 한다. 클라이언트에 의해 최초 프로토콜 요청에서 사용되는 리소스 네임은 ABNF 문법에 따른다.
resource-name = base-url-resource-name app-endpoint
base-url-resource-name은 서비스 엔드 포인트의 웹소켓 URL으로부터 도출된 리소스 네임이다. app-endpoint는 어플리케이션 사양이다. 이것은 클라이언트로부터 대응되는 클라이언트의 연결 매칭 프로세스에 사용될 수 있다. 대응되는 클라이언트의 메시지는 웹 소켓 프로토콜을 통해 전달될 수 있다. app-endpoint는 충돌을 피하기 위해 어플리케이션 디벨로퍼에 의해 선택될 수 있다. 따라서 app-endpoint는 HbbTV 어플리케이션 또는 컴패니언 어플리케이션 및 그것의 디벨로퍼와 독특하게 연관된 리버스 DNS 표기로 형식화된 식별자로 시작할 수 있다. 하이브리드 터미널은 최소 1000 문자의 길이와 웹 소켓 프로토콜 사양에 의해 리소스 네임에서 허용된 어떤 문자를 포함하는 app-endpoint를 지원할 수 있다.
서비스 엔드 포인트는 클라이언트로부터 최소 10개의 동시 TCP 소켓 연결을 지원할 수 있다. 클라이언트가 서버와 TCP 소켓 연결을 오픈하기 위해 노력할 때, 서버는 서버가 동시 연결을 다룰 수 없으면 요청을 거절할 수 있다. 그렇지 않으면, 서버는 TCP 소켓 연결을 승인하고, TCP 소켓 연결을 웹소켓 프로토콜 핸드쉐이크를 시작할 수 있다. 서버는 클라이언트 요청 핸드쉐이크를 수신하지만 서버는 핸드쉐이크 응답으로 즉시 응답하지 않을 수 있다. 대신 서버는 연결이 페어링될 때까지 또는 클라이언트의 연결이 해제될 때까지 기다릴 수 있다. 이 상태에서 연결은 대기 연결을 구성할 수 있다. 서버가 타임 아웃을 실행하려는 경우, 서버는 504 게이트웨이 타임아웃 응답으로 반응할 수 있다.
서버는 클라이언트에 의해 전송된 요청 핸드쉐이크의 어떤 오리진(origin) 헤더를 무시할 수 있다. 클라이언트는 클라이언트 간의 연결을 요청할 때 Sec-웹소켓-프로토콜 헤더를 사용하지 않을 수 있다. 서버는 클라이언트 간의 연결을 위한 요청에서 Sec-웹소켓-프로토콜 헤더를 무시할 수 있다. 서버는 Sec-웹소켓-프로토콜 헤더를 사용하는 프로토콜 확장을 위한 클라이언트 요청을 승인하지 않을 수 있다. 클라이언트가 Sec-웹소켓 확장 헤더를 사용하면 서버는 웹소켓 프로토콜 사양에서 정의된 방식으로 연결하지 못할 수 있다.
도 7에서 도시된 바와 같이, 클라이언트로 동작하는 HbbTV 어플리케이션이 "org.mychannel.myapp"의 app-endpoint와 /hbbtv/의 base-url-resource-name을 가지는 로컬 서비스 엔드 포인트와 연결을 시도할 수 있다. 컴패니언 장치와의 연결은 컴패니언 어플리케이션이 아직 동일한 app-endpoint를 사용하는 어플리케이션 간의 통신에 연결하지 못했기 때문에 대기 상태를 유지할 수 있다.
도 8은 일 실시 예에 따른 제2 클라이언트와 연결을 위한 새로운 연결 요청을 설명하는 도면이다.
도 8을 참조하면, HbbTV 어플리케이션(클라이언트)은 컴패니언 장치(200a)의 컴패니언 어플리케이션(클라이언트)과 연결되어 있다. 그리고, HbbTV 어플리케이션은 다른 클라이언트를 위한 다른 스트림 헤드를 생성할 수 있다.
서버는 동일한 app-endpoint를 가지는 동일한 본래 IP 어드레스로부터 하나 이상의 동시 대기 연결을 허락할 수 없다. 성공적으로 연결되거나 종료되기 전에 해당하는 IP 어드레스의 클라이언트가 동일한 app-endpoint를 사용하는 다른 연결 요청을 발행하면 서버는 403 금지 응답으로 반응할 수 있다.
클라이언트는 다른 리소스-네임 조합을 사용하는 동일한 서비스 엔드포인트를 통해 멀티플 동시 클라이언트 간의 연결을 설립하길 희망할 수 있다. 클라이언트는 존재하는 서비스 엔드포인트로의 연결 대기가 성공적으로 연결되거나 타임아웃되거나 연결 해제되기 전에 서비스 엔드포인트로 다른 연결의 요청을 시도할 수 없다. 이러한 클라이언트의 동작은 웹소켓 프로토콜 사양에 의해 정의될 수 있다.
도 8에 따르면, 만일 클라이언트가 하나 이상의 클라이언트와 통신하길 희망하면, 클라이언트는 존재하는 대기 연결이 페어링될 때가지 대기할 수 있다. 이때, 처리 가능한 클라이언트 간의 연결 최대 숫자에 다다를 때까지 추가 연결 요청을 서버로 발행될 수 있다. 즉, HbbTV 어플리케이션은 어플리케이션 간 통신의 설립을 허락하기 위한 새로운 대기 연결 요청을 생성할 수 있다.
한편, 클라이언트는 URI 경로에 IP 어드레스를 포함시킬 수도 있다.
도 9는 일 실시 예에 따른 IP 어드레스를 포함하는 경우 제1 클라이언트의 설정을 설명하는 도면이다.
일 실시 예로서, 상술한 URI 경로(path)는 루트("/") 뒤에 HbbTV를 알리는 예약어("hbbtb")로 시작하고, 그 뒤에 기관/회사 구분자(org-id)와 어플리케이션 구분자(app-id)로 구성될 수 있다. 어플리케이션 간의 통신을 수행하고자 하는 어플리케이션이 타겟 어플리케이션을 지정하기 위해 URI의 경로에 타겟 어플리케이션이 구동중인 장치의 IP 어드레스를 추가할 수 있다. 웹소켓 서버는 웹소켓 API 콜의 URI 경로가 같은 어플리케이션 중 서로 통신하고자 하는 IP에 따라 연결시켜 줄 수 있다.
신택스) GET "/hbbtv/" target IP "/" org-id "." app-id
실시예) GET /hbbtv/1.1.1.1/org.mychannel.myapp
일 실시 예로서, TV 어플리케이션 A가 IP 1.1.1.1에서 구동 중이고, 컴패니언 어플리케이션 B가 IP 1.1.1.2(제1 사용자 단말기), 컴패니언 어플리케이션 C가 IP 1.1.1.3(제2 사용자 단말기)에서 구동 중일 수 있다. 이때, TV 어플리케이션 A가 컴패니언 어플리케이션 C와 서로 통신하려고 할 수 있다. TV 어플리케이션 A는 WebSocket 요청에 포함되는 URI의 경로에 컴패니언 어플리케이션 C가 구동 중인 IP(1.1.1.3)를 포함시킬 수 있다. 그리고, 컴패니언 어플리케이션 C는 웹소켓 요청에 포함되는 URI의 경로에 TV 어플리케이션 A의 IP(1.1.1.1)을 포함시킬 수 있다.
도 9에 따르면, URI 경로는 hbbtv/192.0.2.7/org.mychannel.myapp HTTP/1/1과 같을 수 있다. 여기서 192.0.2.7은 타겟 어플리케이션의 IP 어드레스일 수 있다. 192.0.2.110은 자신의 IP 어드레스일 수 있다. 그리고, org.mychannel.myapp는 어플리케이션 ID일 수 있다.
도 10은 일 실시 예에 따른 IP 어드레스를 포함하는 경우 제1 및 제2 클라이언트의 설정을 설명하는 도면이다.
웹소켓 서버는 각각의 클라이언트로부터 도 9에서 설명한 URI 요청을 수신할 수 있다. 도 10을 참조하면, 192.0.2.110의 IP 어드레스를 가지는 제1 클라이언트와 192.0.2.7의 IP 어드레스를 가지는 제2 클라이언트가 있다. 제1 클라이언트가 제2 클라이언트로 연결을 요청하는 경우, 출발지(From Host)는 192.0.2.110이고, 도착지(To Host)는 192.0.2.7이 된다. 그리고, 어플리케이션 ID는 org.mychannel.myapp일 수 있다. 제2 클라이언트가 제1 클라이언트로 연결을 요청하는 경우, 출발지(From Host)는 192.0.2.7이고, 도착지(To Host)는 192.0.2.110이 된다. 그리고, 어플리케이션 ID는 org.mychannel.myapp일 수 있다. 즉, 제1 클라이언트와 제2 클라이언트의 출발지와 목적지 주소는 서로 반대될 수 있다. 그러나, 어플리케이션 ID는 동일하다. 웹소켓 서버는 매칭되는 클라이언트를 서로 연결시켜 줄 수 있다.
또한, 호스트 IP 어드레스를 포함하는 URI 경로가 사용될 수도 있다.
예를 들어, URI 경로는 Syntax) GET “/”hbbtv”/" host_address”/”org-id "." app-id,
실시예) GET /hbbtv/192.0.2.7/org.mychannel.myapp 와 같이 사용될 수 있다.
도 11은 IP 어드레스를 포함하는 경우 복수의 제2 클라이언트에 연결하는 일 실시 예를 설명하는 도면이다.
도 11을 참조하면, HbbTV는 일정한 IP 어드레스를 가지고, org.mychannel.myapp의 어플리케이션 ID를 포함하고 있다. 제1 컴패니언 어플리케이션 IP 어드레스는 192.0.2.7이고, 제2 컴패니언 어플리케이션 IP 어드레스는 192.0.2.1이다. 제1 및 제2 컴패니언 어플리케이션의 어플리케이션 ID는 org.mychannel.myapp이다. 도 10에서 설명한 바와 같이, 웹소켓 서버는 매칭되는 클라이언트를 서로 연결시켜 줄 수 있다. 따라서, 각 클라이언트들의 요청에 대응하여 웹소켓 서버는 매칭되는 클라이언트들을 서로 연결시켜 줄 수 있다.
이와 같이, URI 경로에 IP 어드레스를 사용하는 경우, 양 클라이언트는 연결 대상을 지정하기 때문에 보안성이 향상되고, 클라이언트 간 연결이 가능하며, 별도의 노력없이 모든 정보의 매칭이 가능하다는 장점이 있다. 한편, URI 경로에 IP 어드레스를 사용하는 경우에도 각 클라이언트는 동일한 포트를 사용할 수 있고, 서로 다른 포트를 사용할 수도 있다.
도 12는 일 실시 예에 따른 전자 장치의 제어 방법의 흐름도이다.
도 12에 따르면, 전자 장치는 컴패니언 장치와 연결할 수 있다(S1210). 전자 장치는 네트워크 프로세서와 어플리케이션 프로세서를 포함할 수 있다. 전자 장치는 어플리케이션 프로세서가 네트워크 프로세서로 컴패니언 장치와의 연결을 요청할 수 있다. 네트워크 프로세서는 컴패니언 장치로부터 연결 요청을 받으면, 연결 요청한 어플리케이션 프로세서와 컴패니언 장치를 연결할 수 있다.
상술한 바와 같이, 어플리케이션 프로세서는 어플리케이션 모듈, 어플리케이션 브라우저일 수 있다. 또는, HbbTV 어플리케이션일 수 있다. 네트워크 프로세서는 네트워크 모듈로 구현될 수 있다. 또는, 네트워크 프로세서는 웹소켓 서버(WebSocket Server)일 수 있다. 네트워크 프로세서가 웹소켓 서버로 구현되는 경우, 어플리케이션 프로세서와 컴패니언 장치는 각각 하나의 클라이언트라고 볼 수 있다. 또는, 제1 클라이언트와 제2 클라이언트를 각각 피어(peer)라고 부를 수도 있다.
어플리케이션 프로세서는 네트워크 프로세서에서 동작하는 전자 장치 정보 또는 컴패니언 장치 정보를 나타내는 호스트 요청 헤더 정보를 네트워크 프로세서로 전송할 수 있다. 그리고, 네트워크 프로세서는 어플리케이션 프로세서의 연결 요청이 있을 때, 어플리케이션 프로세서의 스트림 헤드를 생성하여 스트림 헤드 그룹에 포함시킬 수 있다. 네트워크 프로세서는 컴패니언 장치로부터 연결 요청을 받으면, 컴패니언 장치의 스트림 헤드를 생성하여 스트림 헤드 그룹으로부터 매칭되는 어플리케이션 프로세서의 스트림 헤드와 연결할 수 있다. 이때, 네트워크 프로세서는 매칭된 어플리케이션 프로세서의 스트림 헤드 또는 컴패니언 장치의 스트림 헤드를 스트림 헤드 그룹으로부터 제거할 수 있다. 한편, 어플리케이션 프로세서는 연결하려는 컴패니언 장치의 IP 어드레스를 전송할 수 있으며, 각각의 어플리케이션들은 동일한 포트를 이용할 수 있다.
전자 장치는 컴패니언 장치와 데이터를 송수신할 수 있다(S1220). 이와 같은 과정을 통해, 전자 장치는 컴패니언 장치와 연결하여 통신을 수행할 수 있다.
본 명세서에 따른 전자 장치 및 제어 방법은 상술한 실시 예들의 구성과 방법으로 한정되어 적용되는 것이 아니라, 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 다양한 변형이 이루어질 수 있다.
한편, 본 명세서의 전자 장치의 제어 방법은 전자 장치에서 구비된 프로세서가 읽을 수 있는 기록 매체에 소프트웨어로서 구현되는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
또한, 이상에서는 본 명세서의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 명세서는 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 명세서의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
-
전자 장치에서 사용 가능하고 반복 가능성이 있는 산업상 이용가능성이 있다.

Claims (14)

  1. 어플리케이션 프로세서 및 네트워크 프로세서를 포함하고, 컴패니언 장치와 연결하는 제어부;
    상기 컴패니언 장치와 데이터를 송수신하는 통신부;를 포함하며,
    상기 어플리케이션 프로세서는,
    상기 네트워크 프로세서로 컴패니언 장치와의 연결을 요청하고,
    상기 네트워크 프로세서는,
    상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 연결 요청한 어플리케이션 프로세서와 상기 컴패니언 장치를 연결하는, 전자 장치.
  2. 제1항에 있어서,
    상기 네트워크 프로세서는 웹소켓 서버인 것을 특징으로 하는 전자 장치.
  3. 제1항에 있어서,
    상기 어플리케이션 프로세서는,
    상기 네트워크 프로세서에서 동작하는 전자 장치 또는 컴패니언 장치 중 적어도 하나의 정보를 나타내는 호스트 요청 헤더 정보를 상기 네트워크 프로세서로 전송하는 것을 특징으로 하는 전자 장치.
  4. 제1항에 있어서,
    상기 네트워크 프로세서는,
    상기 어플리케이션 프로세서의 연결 요청이 있을 때, 상기 어플리케이션 프로세서의 스트림 헤드를 생성하여 스트림 헤드 그룹에 포함시키고, 상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 컴패니언 장치의 스트림 헤드를 생성하고, 상기 스트림 헤드 그룹으로부터 매칭되는 상기 어플리케이션 프로세서의 스트림 헤드와 연결하는 것을 특징으로 하는 전자 장치.
  5. 제4항에 있어서,
    상기 네트워크 프로세서는,
    매칭된 상기 어플리케이션 프로세서의 스트림 헤드 또는 상기 컴패니언 장치의 스트림 헤드 중 적어도 하나를 상기 스트림 헤드 그룹으로부터 제거하는 것을 특징으로 하는 전자 장치.
  6. 제1항에 있어서,
    상기 어플리케이션 프로세서는,
    연결하려는 컴패니언 장치의 IP 어드레스를 상기 네트워크 프로세서로 전송하는 것을 특징으로 하는 전자 장치.
  7. 제1항에 있어서,
    상기 네트워크 프로세서는,
    상기 어플리케이션 프로세서와 상기 컴패니언 장치를 동일한 포트를 이용하여 연결하는 것을 특징으로 하는 전자 장치.
  8. 전자 장치의 제어 방법에 있어서,
    컴패니언 장치와 연결하는 단계; 및
    상기 컴패니언 장치와 데이터를 송수신하는 단계;를 포함하며,
    상기 연결하는 단계는,
    상기 어플리케이션 프로세서가 네트워크 프로세서로 컴패니언 장치와의 연결을 요청하고, 상기 네트워크 프로세서는 상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 연결 요청한 어플리케이션 프로세서와 상기 컴패니언 장치를 연결하는, 전자 장치의 제어 방법.
  9. 제8항에 있어서,
    상기 네트워크 프로세서는 웹소켓 서버인 것을 특징으로 하는 전자 장치의 제어 방법.
  10. 제8항에 있어서,
    상기 네트워크 프로세서에서 동작하는 전자 장치 또는 컴패니언 장치 중 적어도 하나의 정보를 나타내는 호스트 요청 헤더 정보를 상기 어플리케이션 프로세서가 상기 네트워크 프로세서로 전송하는 단계;를 더 포함하는 전자 장치의 제어 방법.
  11. 제8항에 있어서,
    상기 어플리케이션 프로세서의 연결 요청이 있을 때, 상기 네트워크 프로세서가 상기 어플리케이션 프로세서의 스트림 헤드를 생성하여 스트림 헤드 그룹에 포함시키는 단계; 및
    상기 컴패니언 장치로부터 연결 요청을 받으면, 상기 네트워크 프로세서가 상기 컴패니언 장치의 스트림 헤드를 생성하여 상기 스트림 헤드 그룹으로부터 매칭되는 상기 어플리케이션 프로세서의 스트림 헤드와 연결하는 단계;를 더 포함하는 전자 장치의 제어 방법.
  12. 제11항에 있어서,
    상기 네트워크 프로세서가 매칭된 상기 어플리케이션 프로세서의 스트림 헤드 또는 상기 컴패니언 장치의 스트림 헤드 중 적어도 하나를 상기 스트림 헤드 그룹으로부터 제거하는 단계;를 더 포함하는 전자 장치의 제어 방법.
  13. 제8항에 있어서,
    상기 어플리케이션 프로세서가 연결하려는 컴패니언 장치의 IP 어드레스를 상기 네트워크 프로세서로 전송하는 단계;를 더 포함하는 것을 특징으로 하는 전자 장치의 제어 방법.
  14. 제8항에 있어서,
    상기 연결하는 단계는,
    상기 어플리케이션 프로세서와 상기 컴패니언 장치를 동일한 포트를 이용하여 연결하는 것을 특징으로 하는 전자 장치의 제어 방법.
PCT/KR2014/010491 2013-11-04 2014-11-04 전자 장치 및 전자 장치의 제어 방법 Ceased WO2015065149A1 (ko)

Priority Applications (6)

Application Number Priority Date Filing Date Title
US15/026,552 US10367864B2 (en) 2013-11-04 2014-11-04 Electronic device and method for controlling electronic device
EP14857015.3A EP3068139B1 (en) 2013-11-04 2014-11-04 Electronic device and method for controlling electronic device
CN201480059752.3A CN105706455B (zh) 2013-11-04 2014-11-04 电子设备和用于控制电子设备的方法
JP2016526847A JP6301464B2 (ja) 2013-11-04 2014-11-04 電子装置及び電子装置の制御方法
KR1020167007221A KR101898492B1 (ko) 2013-11-04 2014-11-04 전자 장치 및 전자 장치의 제어 방법
US16/506,417 US10819761B2 (en) 2013-11-04 2019-07-09 Electronic device and method for controlling electronic device

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201361899305P 2013-11-04 2013-11-04
US61/899,305 2013-11-04
US201361911983P 2013-12-04 2013-12-04
US61/911,983 2013-12-04

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US15/026,552 A-371-Of-International US10367864B2 (en) 2013-11-04 2014-11-04 Electronic device and method for controlling electronic device
US16/506,417 Continuation US10819761B2 (en) 2013-11-04 2019-07-09 Electronic device and method for controlling electronic device

Publications (1)

Publication Number Publication Date
WO2015065149A1 true WO2015065149A1 (ko) 2015-05-07

Family

ID=53004648

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2014/010491 Ceased WO2015065149A1 (ko) 2013-11-04 2014-11-04 전자 장치 및 전자 장치의 제어 방법

Country Status (6)

Country Link
US (2) US10367864B2 (ko)
EP (1) EP3068139B1 (ko)
JP (1) JP6301464B2 (ko)
KR (1) KR101898492B1 (ko)
CN (1) CN105706455B (ko)
WO (1) WO2015065149A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016190662A1 (ko) * 2015-05-26 2016-12-01 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10038721B2 (en) * 2015-02-16 2018-07-31 International Business Machines Corporation Enabling an on-premises resource to be exposed to a public cloud application securely and seamlessly
KR102335007B1 (ko) * 2015-04-01 2021-12-06 삼성전자주식회사 방송 시스템에서 디바이스들 간에 정보를 송수신하는 방법 및 장치
WO2019039748A1 (ko) * 2017-08-23 2019-02-28 삼성전자 주식회사 클라이언트 디바이스, 컴패니언 스크린 디바이스 및 그 동작방법
GB2565807B (en) 2017-08-23 2022-04-20 Samsung Electronics Co Ltd Method and apparatus for controlling 360 degree video
JP7300250B2 (ja) * 2017-10-04 2023-06-29 日本放送協会 受信装置およびプログラム
CN110290417A (zh) * 2019-07-30 2019-09-27 四川虹魔方网络科技有限公司 基于WebSocket的电视网络通信传输方法
EP3787299A1 (de) * 2019-09-02 2021-03-03 Institut für Rundfunktechnik GmbH Aufbau einer verbindung zwischen einer ersten anwendung auf einem ersten gerät und einer zweiten anwendung auf einem zweiten gerät
CN113179293A (zh) * 2021-03-03 2021-07-27 广州盛成妈妈网络科技股份有限公司 Web端远程批量操作客户端的方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120000142A (ko) * 2010-06-25 2012-01-02 이지성 스마트폰을 이용한 보드게임시스템
KR20120114877A (ko) * 2011-04-08 2012-10-17 (주)서원인텍 용이하게 홈 네트워크를 구축할 수 있는 인터폰과 이를 컨트롤 할 수 있는 스마트폰을 포함하여 이루어진 인터폰시스템.
KR20130058215A (ko) * 2011-11-25 2013-06-04 조현욱 스마트 티브이 기반의 홈네트워크 시스템
KR20130097831A (ko) * 2012-02-27 2013-09-04 한국산업기술대학교산학협력단 스마트 프리젠테이션 시스템
US20130291015A1 (en) * 2012-04-27 2013-10-31 Wistron Corp. Smart tv system and input operation method

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101019147A (zh) * 2004-08-19 2007-08-15 同步加株式会社 销售支持系统
KR20070073749A (ko) * 2007-03-16 2007-07-10 가부시끼가이샤 싱크 플러스 판매 지원 시스템
US8438294B2 (en) 2010-04-07 2013-05-07 Apple Inc. Application programming interface, system, and method for collaborative online applications
US9667713B2 (en) 2011-03-21 2017-05-30 Apple Inc. Apparatus and method for managing peer-to-peer connections between different service providers
WO2013031556A1 (ja) * 2011-08-26 2013-03-07 日本放送協会 受信機および受信方法
WO2013126507A1 (en) * 2012-02-21 2013-08-29 Brass Monkey, Inc. Mobile embedded servers systems and methods related thereto
KR102121472B1 (ko) * 2013-09-23 2020-06-17 삼성전자주식회사 기기 별 응용 프로그램간 통신을 위한 장치 및 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120000142A (ko) * 2010-06-25 2012-01-02 이지성 스마트폰을 이용한 보드게임시스템
KR20120114877A (ko) * 2011-04-08 2012-10-17 (주)서원인텍 용이하게 홈 네트워크를 구축할 수 있는 인터폰과 이를 컨트롤 할 수 있는 스마트폰을 포함하여 이루어진 인터폰시스템.
KR20130058215A (ko) * 2011-11-25 2013-06-04 조현욱 스마트 티브이 기반의 홈네트워크 시스템
KR20130097831A (ko) * 2012-02-27 2013-09-04 한국산업기술대학교산학협력단 스마트 프리젠테이션 시스템
US20130291015A1 (en) * 2012-04-27 2013-10-31 Wistron Corp. Smart tv system and input operation method

Non-Patent Citations (1)

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

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016190662A1 (ko) * 2015-05-26 2016-12-01 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
KR20180001559A (ko) * 2015-05-26 2018-01-04 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10362371B2 (en) 2015-05-26 2019-07-23 Lg Electronics Inc. Broadcasting signal transmitting apparatus, broadcasting signal receiving apparatus, broadcasting signal transmitting method, and broadcasting signal receiving method
US10674234B2 (en) 2015-05-26 2020-06-02 Lg Electronics Inc. Broadcasting signal transmitting apparatus, broadcasting signal receiving apparatus, broadcasting signal transmitting method, and broadcasting signal receiving method
US11095959B2 (en) 2015-05-26 2021-08-17 Lg Electronics Inc. Broadcasting signal transmitting apparatus, broadcasting signal receiving apparatus, broadcasting signal transmitting method, and broadcasting signal receiving method
KR102714483B1 (ko) * 2015-05-26 2024-10-10 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Also Published As

Publication number Publication date
EP3068139A1 (en) 2016-09-14
JP2017502373A (ja) 2017-01-19
US20190334966A1 (en) 2019-10-31
US10367864B2 (en) 2019-07-30
EP3068139B1 (en) 2020-09-23
KR20160051794A (ko) 2016-05-11
CN105706455A (zh) 2016-06-22
CN105706455B (zh) 2020-02-07
JP6301464B2 (ja) 2018-03-28
US20160241614A1 (en) 2016-08-18
EP3068139A4 (en) 2017-05-03
US10819761B2 (en) 2020-10-27
KR101898492B1 (ko) 2018-09-13

Similar Documents

Publication Publication Date Title
US8856290B2 (en) Method and apparatus for exchanging configuration information in a wireless local area network
KR101898492B1 (ko) 전자 장치 및 전자 장치의 제어 방법
EP1547344B1 (en) Server, device, and communication system connected to the internet
RU2270531C2 (ru) Система и способ использования ip-адреса как идентификатора беспроводного устройства
JP5662133B2 (ja) Ｉｐｓｅｃとｉｐｖ６近隣要請の競合解消方法及びそのシステム
WO2012115385A2 (en) Apparatus and method for providing universal plug and play service based on wi-fi direct connection in portable terminal
US9065684B2 (en) IP phone terminal, server, authenticating apparatus, communication system, communication method, and recording medium
JP2011501624A (ja) 仮想ｉｐアドレスを介してアクセス可能なアドレスを持たないネットワークデバイスにアクセスするための種々の方法および装置
WO2014148866A1 (en) Method of connecting networks using wi-fi direct in image forming apparatus, image forming apparatus supporting wi-fi direct, and image forming system
CA2419853A1 (en) Location-independent packet routing and secure access in a short-range wireless networking environment
JP5331655B2 (ja) 通信システム、制御サーバ
KR20050046755A (ko) 홈 네트워크에서 동적 네트워킹을 실현하는 장치의 대등연결방법
WO2010021502A2 (en) Method and apparatus for protecting personal information in a home network
WO2012008772A2 (en) Apparatus and method for configuring high-definition video telephony between computer devices
AU2015264883A1 (en) Access control method and system, and access point
US8000280B2 (en) Network communication apparatus, network communication method, and address management apparatus
WO2017206602A1 (zh) 数据处理方法及装置
JPWO2006120751A1 (ja) 発着呼を可能とするピア・ツー・ピア通信方法及びシステム
US7650417B2 (en) Method for setting up a communication between a device and a host application over an IP network
WO2019045424A1 (ko) 보안을 위한 보안 소켓 계층 복호화 방법
WO2013151376A1 (ko) 듀얼 ｏｓ를 이용한 보안 시스템 및 그 방법
KR101996588B1 (ko) Arp 프로토콜을 지원하는 분리망 연계장치 및 그 제어방법
JP2007519356A (ja) セキュリティを備えた遠隔制御ゲートウェイ管理
WO2020096162A1 (ko) 무선 통신 시스템에서의 보안 통신 방법 및 장치
WO2013028007A2 (en) Apparatus and method for setting up parallel call session based on 3-box architecture

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: 14857015

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20167007221

Country of ref document: KR

Kind code of ref document: A

REEP Request for entry into the european phase

Ref document number: 2014857015

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 15026552

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2016526847

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE