WO2016186352A1 - Procédé et dispositif de traitement de commande vocale par l'intermédiaire d'un uibc - Google Patents

Procédé et dispositif de traitement de commande vocale par l'intermédiaire d'un uibc Download PDF

Info

Publication number
WO2016186352A1
WO2016186352A1 PCT/KR2016/004700 KR2016004700W WO2016186352A1 WO 2016186352 A1 WO2016186352 A1 WO 2016186352A1 KR 2016004700 W KR2016004700 W KR 2016004700W WO 2016186352 A1 WO2016186352 A1 WO 2016186352A1
Authority
WO
WIPO (PCT)
Prior art keywords
wfd
rtsp
vcdc
wfd device
uibc
Prior art date
Application number
PCT/KR2016/004700
Other languages
English (en)
Korean (ko)
Inventor
박기원
이병주
김동철
박현희
임태성
Original Assignee
엘지전자 주식회사
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 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Priority to US15/575,713 priority Critical patent/US20180295414A1/en
Publication of WO2016186352A1 publication Critical patent/WO2016186352A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L15/00—Speech recognition
    • G10L15/22—Procedures used during a speech recognition process, e.g. man-machine dialogue
    • 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/441—Acquiring end-user identification, e.g. using personal code sent by the remote control or by inserting a card
    • H04N21/4415—Acquiring end-user identification, e.g. using personal code sent by the remote control or by inserting a card using biometric characteristics of the user, e.g. by voice recognition or fingerprint scanning
    • 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/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless

Definitions

  • the present invention relates to a wireless fidelity (WFD) display, and more particularly, to a method and apparatus for processing a voice command through a user input back channel (UIBC).
  • WFD wireless fidelity
  • UIBC user input back channel
  • Wireless display transmission technology can be largely divided into content transmission and mirroring (screen casting). Content delivery should be linked to the VOD (Video on Demand) service, rather than the mobile device screen.
  • Content transmission is a method of sending video signals
  • mirroring is a method of transmitting a content file to a remote device by streaming and showing it again on a large screen display such as a TV.
  • Mirroring is a way of showing images printed on a mobile device as if they were mirrored.
  • Mirroring projects your computer screen to the projector by making wired connections such as D-sub (D-Subminiature, RGB), Digital Visual Interface (DVI), and High-Definition Multimedia Interface (HDMI) when giving a presentation. It's similar to how you do it.
  • the mirroring method has the advantage of being able to wirelessly transmit pixel information of the original screen without being dependent on a specific service in real time.
  • Wi-Fi Miracast is being studied as a wireless display transmission technology using Wi-Fi.
  • Miracast is a wireless video transmission standard and wireless display transmission technology created by the WiFi alliance.
  • Miracast is a type of mirroring (screencasting) technology that compresses the screen and sound to a wireless LAN and sends it back to the dongle or integrated receiver.
  • An object of the present invention is to provide a voice command processing method through the UIBC.
  • Still another object of the present invention is to provide a voice command processing apparatus through UIBC.
  • a voice command processing method through a user input back channel (UIBC) in which a first WFD device is a second WFD device.
  • UIBC user input back channel
  • a first WFD device is a second WFD device.
  • Receiving, but the M3 response message includes input category information and VCDC capability information set to VCDC of the second WFD device, wherein the first WFD device initializes a real time streaming protocol (RTSP) with the second WFD device.
  • VCDC voice command device category
  • RTSP real time streaming protocol
  • the M4 request message includes input category information set to the VCDC and initial set VCDC capability information;
  • Receiving an M4 response message from the second WFD device in response to the M4 request message wherein the first WFD device is a device that supports the streaming of multimedia content, the second WFD device is the A device for receiving and rendering the multimedia content from the first WFD device via a peer-to-peer link with a first WFD device, wherein the VCDC capability information is received by the second WFD device by the first WFD device; And a plurality of voice-based motion control commands for controlling the multimedia content played in each of the device and the second WFD device.
  • a first WFD (WiFi Display) device for performing voice command processing through a user input back channel (UIBC) for communication with a second WFD device
  • UIBC user input back channel
  • a processor operatively connected to the communication unit and the communication unit, wherein the processor transmits an M3 request message for requesting information on a voice command device category (VCDC) capability of the second WFD device to the second WFD device.
  • VCDC voice command device category
  • the M4 request message is transmitted to the WFD device in an RTSP (real time streaming protocol) initialization state, but the M4 request message is set to the VCDC.
  • Information and initial VCDC capability information may be implemented to receive an M4 response message from the second WFD device in response to the M4 request message, wherein the first WFD device supports streaming of multimedia content.
  • the second WFD device is a device that receives and renders the multimedia content from the first WFD device via a peer-to-peer link with the first WFD device, and the VCDC capability information is determined by the first WFD device.
  • 2 may include information about a plurality of voice-based operation control commands for controlling the multimedia content played by each of the first WFD device and the second WFD device by the WFD device.
  • a user's voice command input through the WFD sink may be transmitted to the WFD source on the UIBC to drive an application for playing multimedia content on the WFD source.
  • WFDS Wi-Fi Direct Service
  • FIG. 2 is a conceptual diagram illustrating a WFD network.
  • FIG. 3 is a conceptual diagram illustrating a WFD session.
  • FIG. 4 is a conceptual diagram illustrating a method for establishing a WFD session.
  • FIG. 5 is a conceptual diagram illustrating a network between a WFD source and a WFD sink.
  • FIG. 6 is a conceptual diagram illustrating a WFD capability exchange and negotiation procedure.
  • FIG. 7 is a conceptual diagram illustrating a WFD session establishment procedure.
  • FIG. 8 is a flowchart illustrating UIBC capability negotiation between a WFD source and a WFD sink according to an embodiment of the present invention.
  • FIG. 9 is a flowchart illustrating UIBC capability negotiation between a WFD source and a WFD sink according to an embodiment of the present invention.
  • FIG. 10 is a flowchart illustrating UIBC capability negotiation between a WFD source and a WFD sink according to an embodiment of the present invention.
  • FIG. 11 is a flowchart illustrating UIBC capability negotiation between a WFD source and a WFD sink according to an embodiment of the present invention.
  • FIG. 12 is a flowchart illustrating UIBC capability negotiation between a WFD source and a WFD sink according to an embodiment of the present invention.
  • FIG. 13 is a conceptual diagram illustrating a method of transmitting an RTSP control message according to an embodiment of the present invention.
  • FIG. 14 is a conceptual diagram illustrating a UIBC input message format according to an embodiment of the present invention.
  • 15 is a flowchart illustrating a UIBC capability negotiation method according to an embodiment of the present invention.
  • 16 is a flowchart illustrating a UIBC capability negotiation method according to an embodiment of the present invention.
  • 17 is a flowchart illustrating a capability negotiation and a capability negotiation procedure of a RAC for delivery of a voice command according to an embodiment of the present invention.
  • FIG. 18 is a conceptual diagram illustrating a method for transmitting a voice command of a user through UIBC according to an embodiment of the present invention.
  • 19 is a conceptual diagram illustrating a method of transmitting a voice command of a user through UIBC according to an embodiment of the present invention.
  • 20 is a block diagram illustrating a wireless device to which an embodiment of the present invention can be applied.
  • the AP may be responsible for a physical layer support function for a wireless / wired connection, a routing function for devices on a network, a function of adding / removing a device to a network, and a service providing function. That is, in the existing WLAN system, devices in a network are connected through APs, but not directly connected to each other.
  • Wi-Fi Direct is a direct communication technology that allows devices (or STAs) to easily connect with each other without an access point basically required in a conventional WLAN system.
  • Wi-Fi Direct is used, a connection is established between devices without complicated setup process to provide various services to the user.
  • Wi-Fi Alliance provides Wi-Fi Direct services that support various services using the Wi-Fi Direct link (e.g. Send, Play, Display, Print, etc.) WFDS) is being studied.
  • WFDS Wi-Fi Direct services
  • an application may be controlled or managed by a service platform called an application service platform (ASP).
  • ASP application service platform
  • WFDS devices that support WFDS include devices that support WLAN systems such as display devices, printers, digital cameras, projectors, and smart phones.
  • the WFDS device may include a STA and an AP. WFDS devices in the WFDS network may be directly connected to each other.
  • WFDS Wi-Fi Direct Service
  • the WFDS framework may include a Wi-Fi Direct layer 100, an ASP 120, a service layer 140, and an application layer 160.
  • the Wi-Fi Direct layer 100 is a medium access control (MAC) layer defined in the Wi-Fi Direct standard. Under the Wi-Fi Direct layer 100, a wireless connection may be configured by a physical layer (not shown) compatible with the Wi-Fi PHY. An application service platform (ASP) 120 is defined above the Wi-Fi Direct layer 100.
  • MAC medium access control
  • ASP application service platform
  • the ASP 120 is a common shared platform, and manages sessions and processes commands between the upper application layer 160 and the lower Wi-Fi Direct layer 100. Perform ASP control and security functions.
  • the service layer 140 is defined above the ASP 120.
  • the service layer 140 may support four basic services, Send, Play, Display, Print, and services defined by third party applications.
  • the service layer 140 may support Wi-Fi Serial Bus (WSB), Wi-Fi Docking, or Neighbor Awareness Networking (NAN).
  • WB Wi-Fi Serial Bus
  • NAN Neighbor Awareness Networking
  • the application layer 160 may provide a user interface (UI), express information in a form that can be recognized by a person, and transmit user input to a lower layer.
  • UI user interface
  • Wi-Fi display (WFD) of WFDS is disclosed in more detail.
  • the WFD standard was defined to transfer audio / video (AV) data between devices while satisfying high quality and low latency.
  • WFD networks (WFD sessions) with the WFD standard allow Wi-Fi devices to be connected to each other in a peer-to-peer fashion without going through a home network, office network, or hot-spot network.
  • a device for transmitting and receiving data according to the WFD standard may be expressed by the term WFD device.
  • WFD devices in the WFD network may search for information about the WFD devices (for example, capability information), establish a WFD session, and render content through the WFD session.
  • a WFD session may be a network between a source device that provides content and a sink device that receives and renders the content.
  • the source device may also be expressed as a WFD source, and the sink device may be referred to as a WFD sink.
  • the WFD source may mirror data present on the display (or screen) of the WFD source to the display of the WFD sink.
  • the WFD source and the WFD sink may perform a device discovery and service discovery procedure by exchanging a first sequence message between each other. After the device discovery and service discovery procedure between the WFD source and the WFD sink is completed, an internet protocol (IP) address may be assigned to each of the WFD source and the WFD sink.
  • IP internet protocol
  • a transmission control protocol (TCP) connection is established between the WFD source and the WFD sink, followed by real time streaming protocol (RTSP) and real time protocol (RTP) for the WFD source and the WFD sink.
  • TCP transmission control protocol
  • RTSP real time streaming protocol
  • RTP real time protocol
  • the capability negotiation procedure between the WFD source and the WFD sink is performed via RTSP, and during the capability negotiation procedure, the WFD source and the WFD sink can exchange RTSP based messages (M (message) 1 to M4). Can be. The WFD source and the WFD sink may then exchange WFD session control messages. In addition, a data session via RTP may be established between the WFD source and the WFD sink.
  • RTSP RTSP based messages
  • FIG. 2 is a conceptual diagram illustrating a WFD network.
  • the WFD source 200 and the WFD sink 250 may be connected based on WiFi-P2P as a WFD device.
  • the WFD source 200 is a device that supports streaming of multimedia content through a WiFi peer to peer (P2P) link, and the WFD sink 250 receives the multimedia content from the WFD source 200 through a P2P link and displays an image. And / or a device that performs a procedure for generating sound.
  • the procedure for generating an image and / or sound may be expressed in terms of rendering.
  • the WFD sink 250 may be divided into a primary sink and a secondary sink.
  • the secondary sync can render only the audio payload when connected to the WFD source 200 independently.
  • FIG. 3 is a conceptual diagram illustrating a WFD session.
  • the top first of FIG. 3 is an audio only session.
  • the WFD source 300 may be connected to either the primary sink 305 or the secondary sink 310 through an audio only session.
  • the upper second of FIG. 3 is a video-only session.
  • the WFD source 320 may be connected to the primary sink 325.
  • the upper third of FIG. 3 is an audio and video session, such that a WFD source 340 may be connected to the primary sink 345 as well as a video-only session.
  • the upper fourth of FIG. 3 initiates a session connection in a coupled WFD Sink operation.
  • the primary sink 365 renders a video
  • the secondary sink 370 renders audio.
  • primary sync 365 may render both video and audio.
  • Such a WFD session may be established after performing a procedure as shown in FIG. 4 below.
  • FIG. 4 is a conceptual diagram illustrating a method for establishing a WFD session.
  • a WFD device discovery procedure (WFD Device Discovery, S401), a WFD service discovery procedure (WFD Service Discovery, S402), a WFD connection setup procedure (WFD Connection Setup, S403), capability exchange and negotiation procedure (Capability Exchange). and negotiation, S404) may be established after the WFD session.
  • the WFD source may find a peer device for the WFD, that is, a WFD sink, through the WFD device discovery procedure.
  • the beacon frame, probe request frame, and probe response frame transmitted by the WFD source and the WFD sink for the WFD device discovery may include a WFD Information Element (IE).
  • the WFD IE may be an information element including information related to the WFD, such as a device type and a device state.
  • the WFD source may transmit a probe request frame including the WFD IE to the WFD sink, and the WFD sink may transmit a probe response frame including the WFD IE in response to the probe request frame.
  • the probe request frame may include WFD IE and P2P information elements.
  • the probe response frame which is a response to the probe request frame, is transmitted through a channel through which the probe request frame is received, and may include both a P2P IE and a WFD IE.
  • the discovery of the service capability between the WFD source and the WFD sink that performed the WFD device discovery may be performed. For example, if a WFD source sends a service discovery request frame that contains information about WFD capabilities, the WFD sink sends a service discovery response frame that contains information about WFD capabilities in response to the service discovery request frame. Can be.
  • the WFD service discovery procedure may be an optional procedure.
  • the probe request frame and the probe response frame used in the WFD device discovery procedure for performing the WFD service discovery procedure may include information indicating whether the WFD device has the capability of supporting the service discovery procedure.
  • the WFD device performing the WFD device discovery procedure and optionally the WFD service discovery procedure may select the WFD device for the WFD connection setup.
  • a connection scheme of any one of Wi-Fi P2P and tunneled direct link service (TDLS) may be used for WFD connection.
  • the WFD devices may determine the connection method based on the preferred connectivity information and the associated basic service set identifier (BSSID) subelement carried with the WFD information element.
  • BSSID basic service set identifier
  • FIG. 5 is a conceptual diagram illustrating a network between a WFD source and a WFD sink.
  • connection between the WFD source 500 and the WFD sink 510 based on Wi-Fi P2P is started, and at the bottom of FIG. 5, the WFD source 550 and the WFD sink (based on the TDLS link) are disclosed.
  • the connection between 560 is disclosed.
  • the AP may be common to or different from the WFD source 500 and the WFD sink 510. Or the AP may not exist.
  • the WFD connection is performed using the TDLS link as shown in the lower part of FIG. 5, the WFD source 550 and the WFD sink 560 must maintain the connection with the same ⁇ .
  • the WFD capability exchange and negotiation procedure may be performed after the WFD connection setup procedure between WFD devices.
  • the WFD source and the WFD sink may exchange at least one or more of the codec, the profile information, the codec level information, and the resolution information supported by each other.
  • the WFD capability exchange and negotiation may be performed by exchanging a message using a Real Time Streaming Protocol (RTSP). It is also possible to determine a set of parameters that define the audio / video payload during the WFD session.
  • RTSP Real Time Streaming Protocol
  • the WFD capability exchange and negotiation procedure may be performed by exchange of RTSP M1 to RTSP M4 messages as shown in FIG. 6 to be described later.
  • the WFD session establishment procedure may be performed after the WFD exchange and negotiation procedure.
  • FIG. 6 is a conceptual diagram illustrating a WFD capability exchange and negotiation procedure.
  • the WFD source may transmit an RTSP M1 request message for initiating RSTP procedure and WFD capability negotiation (step S601).
  • the RTSP M1 request message may include an RTSP OPTIONS request for determining a set of RTSP methods supported by the WFD sink.
  • the WFD sink may transmit an RTSP M1 response message enumerating the RTSP methods supported by the WFD sink (step S602).
  • the WFD sink may transmit an RTSP M2 request message for determining a set of RTSP methods supported by the WFD source (step S603).
  • the WFD source may respond with an RTSP M2 response message enumerating the RTSP methods supported by the WFD source (step S604).
  • the WFD source may send an RTSP M3 request message (RTSP GET_PARAMETER request message) that specifies a list of WFD capabilities that it wants to know (step S605).
  • RTSP M3 request message RTSP GET_PARAMETER request message
  • the WFD sink may respond with an RTSP M3 response message (RTSP GET_PARAMETER response message) (step S606).
  • the WFD source may determine an optimal set of parameters to be used during the WFD session and send an RTSP M4 request message (RTSP SET_PARAMETER request message) containing the determined set of parameters to the WFD sink.
  • RTSP M4 request message RTSP SET_PARAMETER request message
  • the WFD sink may transmit an RTSP M4 response message (RTSP SET_PARAMETER response message) (step S607).
  • FIG. 7 is a conceptual diagram illustrating a WFD session establishment procedure.
  • WFD sources / WFD sinks that have performed WFD capability exchange and negotiation may establish a WFD session.
  • the WFD source may transmit an RTSP SET parameter request message (RTSP M5 Trigger SETUP request) to the WFD sink (S701).
  • RTSP M5 Trigger SETUP request RTSP M5 Trigger SETUP request
  • the WFD sink may transmit an RTSP M5 response message in response to the RTSP SET parameter request message (step S702).
  • the WFD sink may transmit the RTSP SETUP request message (RTSP M6 request) to the WFD source (step S703).
  • the WFD source may respond with an RTSP SETUP response message (RTSP M6 response) (step S704).
  • the establishment of the status code of the RTSP M6 response message may indicate the successful establishment of the RTSP session.
  • the WFD sink may send an RTSP PLAY request message to the source device to indicate that it is ready to receive the RTP stream (step S705), and the WFD source may send an RTSP PLAY response message. (RTSP M7 response message) (step S706).
  • Successful establishment of the WFD session may be indicated based on the status code of the RTSP PLAY response message.
  • the WFD source After the WFD session has been established, the WFD source will be assigned to the RTF M3 request message (RTSP GET_PARAMETER request message) to obtain the capability for at least one RTSP parameter supported by the WFD sink and the WFD to update the audio / video (AV) format.
  • RTF M3 request message RTSP GET_PARAMETER request message
  • RTSP M4 request message to set at least one RTSP parameter value corresponding to the WFD session for capability renegotiation between source and WFD sink
  • RTSP M5 to trigger the WFD sink to send RTSP PAUSE request message (RTSP M9 request message) Request message
  • RTSP M12 request message indicating that the WFD source enters WFD standby mode
  • RTSP M14 request message to select input type, input device and other parameters to be used in user input back channel (UIBC) or
  • UIBC user input back channel
  • An RTSP M15 request message for enabling or disabling a user input back channel (UIBC) may be transmitted to the WFD sink.
  • the WFD sink receiving the aforementioned RTSP request message from the WFD source may respond with an RTSP response message.
  • the WFD sink continues to run RTSP M7 request message (RTSP PLAY request message) to start (or resume) audio / video streaming, and RTSP M9 request message (RTSP) to suspend audio / video streaming from the WFD source to the WFD sink.
  • RTSP M7 request message RTSP PLAY request message
  • RTSP M9 request message RTSP
  • PAUSE request message RTSP M10 request message to request the WFD source to change the audio rendering device
  • RTSP M11 request message to instruct to change the active connector type
  • WFD sink has entered WFD standby mode.
  • RTSP M12 request message indicating, M13 request message requesting WFD source to refresh instantaneous decoding refresh (IDR), RTSP M14 request message to select input type to be used in UIBC, input device and other parameters or activation of UIBC (RTSP M15 request message for enable or disable can be sent to WFD source .
  • the WFD source receiving the above-listed RTSP request message from the WFD sink may respond with an RTSP response message.
  • the WFD source and the WFD sink may proceed with audio / video streaming using a codec commonly supported by both.
  • a codec commonly supported by the WFD source and the WFD sink By using a codec commonly supported by the WFD source and the WFD sink, interoperability between the two can be guaranteed.
  • WFD communication is based on the WFD IE
  • the format of the WFD IE can be defined as shown in Table 1 below.
  • the WFD subelement field has a format as shown in Table 2 below.
  • the sub element ID may be defined as shown in Table 3 below.
  • the subelement ID field of one octet may indicate what information the WFD subelement includes. Specifically, the values 0, 1,... Of the subelement ID field. 10 indicates that each subelement is a WFD Device Information subelement, Associated BSSID subelement, WFD Audio Formats subelement, WFD Video Formats subelement, WFD 3D Video Formats subelement, WFD Content Protection subelement, Coupled Sink Information subelement, WFD Extended Capability subelement, Local IP Address subelement, WFD Session Information subelement, or alternative MAC address subelement.
  • the WFD Device Information subelement may include information necessary to determine whether to attempt pairing with the WFD device and session creation.
  • the Associated BSSID subelement may be used to indicate the address of the currently associated AP.
  • Each of the WFD Audio Formats subelement, the WFD Video Formats subelement, and the WFD 3D Video Formats subelement may be used to indicate capabilities of a WFD device related to audio, video, and 3D video.
  • the WFD Content Protection subelement may transmit information related to the content protection method, and the Coupled Sink Information subelement may transmit information about the state of the coupled sink, the MAC address, and the like.
  • the WFD Extended Capability subelement is used to convey various capability information of other WFD devices, and the Local IP Address subelement may be used to deliver an IP address to the WFD peer during TDLS setup.
  • the WFD Session Information subelement may include information such as a list of WFD device information descriptors in the WFD group. If the WFD connection method requires an interface (eg, a MAC address) different from that used in device discovery, the Alternative MAC Address subelement may convey the relevant information.
  • the user input back channel may be a channel for delivering user input to a user interface present in a WFD sink to a WFD source.
  • UIBC user input delivered through UIBC may be packetized using a common packet header, and may be transmitted over a transmission control protocol (TCP) / internet protocol (IP).
  • TCP transmission control protocol
  • IP internet protocol
  • the user input category may include a generic category and a human interface device class (HIDC) category.
  • Generic categories or integration categories
  • Generic categories can be used for user input that is not device dependent at the application level.
  • Generic user input may have a format using a generic input body (or integrated input body).
  • Generic user input may include conceptual inputs such as zoom and scroll, as well as inputs such as mouse and keyboard events.
  • HIDC can be used for user input generated by a human input device (HID) such as a remote control and keyboard.
  • the HIDC user input may have a format using a HIDC input body.
  • the WFD sink may transmit a voice command of a user received through a user input device (for example, a voice command device) implemented in the WFD sink to the WFD source, and the WFD source may be transmitted from the WFD sink. It may be controlled according to the received voice command of the user.
  • a user input device for example, a voice command device
  • the WFD source can be controlled in a simple and fast manner, without the use of a hand.
  • the user voice command may be transmitted from the WFD sink to the WFD source through the UIBC data and control the screen of the WFD source.
  • UIBC data for delivering a voice command may be defined in a generic category and a human interface device class (HIDC) category, or in a separate category (eg, voice command device category (VCDC)).
  • HIDC human interface device class
  • VCDC voice command device category
  • the UIBC data may have a format using a VCDC input body as a VCDC user input.
  • the following voice command is input to the WFD sync, and then, the UI player is controlled through the UIBC data on the UIBC to control the video player being played.
  • Voice commands control Play, Stop, Forward, Rewind, Screen Rotation, Mute, Unmute, Full Screen, Maintain Original Size, or Set Screen to control the video player. And the like.
  • a voice command device category (VCDC) and a VCDC input body format may be defined to support voice command processing on the UIBC.
  • the VCDC input body format may include one or more VCDC input messages.
  • the VCDC body format may be defined as shown in Table 4 below.
  • VCD Voice Command Device
  • UIBC Application ID controlled via UIBC data passing (eg Gom player, Internet Explorer, etc) Length Length of the VC value in octets Voice Command (VC) value See Table 6
  • VCD Voice Command Device
  • the voice command device may mean a WFD sink or may be a separate user input device connected to the WFD sink.
  • a screen being mirrored from the WFD source to the WFD sink may be controlled by the WFD sink by including the user voice command input through the WFD sink in the UIBC data and transmitting the same to the WFD source.
  • a voice command key code (or voice command value, voice command action code) corresponding to the user voice command may be included in the VCDC input body and transmitted as UIBC data.
  • Table 7 shows specific voice command key codes (voice command values).
  • Voice command Key code Play-When the user sends a command "Play” by voice, the VCDC Input message contains a command key to play the Player (identified by the Application ID) running on the source device. “Play” To be determined (TBD) Stop-When the user delivers a "Stop” command by voice, the VCDC Input message contains a command key to stop playback of the Player (identified by the Application ID) running on the source device. “Stop” TBD Forward-When the user delivers the command "Forward” by voice, the VCDC Input message contains a command key to "Forward” the playback screen of the Player (identified by the Application ID) running on the source device.
  • the user can "Rotation” the playback screen in portrait type if the user sends the command "Screen Rotation” by voice.
  • the key is included in the VCDC Input message. “Screen Rotation” TBD Mute-When the user sends a command “Mute” by voice, the VCDC Input message contains a command key to “Mute” the sound of the Player (identified by the Application ID) running on the source device.
  • VCDC Input message contains an "Unmute” command key that allows the user to reactivate the sound of the Player (identified by the Application ID) running on the source device when the user delivers the command "Unmute” by voice. do. “Unmute” TBD Original Size-Command key to change the size of the mirrored screen to "Original Size” in the Player (divided by Application ID) running on the source device when the user delivers the command "Original Size” by voice. Is included in the VCDC Input message.
  • “Original Size” TBD Full Screen-Command key to change the size of the mirrored screen to "Full Screen” in the Player (divided by Application ID) running on the source device when the user sends the command "Full Screen” by voice. Is included in the VCDC Input message.
  • “Target Query Voice Commands” Convert and transmit “Target Query Voice Command” to ASCII. Search-When the user delivers the command “Search” by voice, the VCDC has a command key that allows the user to search for items corresponding to the “Target query voice command” instructed by the user through the Internet search application installed on the source device. It is included in the input message. “Search” TBD
  • VCDC input body or VCDC input message proposed by the present invention is a voice command for controlling various application applications.
  • VCDC input message may be transmitted to the WFD source through the UIBC data.
  • FIG. 8 is a flowchart illustrating UIBC capability negotiation between a WFD source and a WFD sink according to an embodiment of the present invention.
  • the WFD source may request a wfd2_uibc_capability parameter to the WFD sink through the RTSP M3 request message (step S800).
  • the wfd2_uibc_capability parameter may include information on the aforementioned voice command device category (VCDC) and voice command device type.
  • the WFD sink may transmit the RTSP M3 response message to the WFD source in response to the RTSP M3 request message (step S810).
  • the wfd2_uibc_capability parameter includes information about the input category (eg, VCDC), VCDC capability (eg, voice command device type (TV), supported voice command value information, etc.). can do.
  • VCDC input category
  • VCDC capability eg, voice command device type (TV), supported voice command value information, etc.
  • each of the WFD source and the WFD sink can obtain information about UIBC capabilities from each other.
  • the WFD source may send an RTSP M4 request message to the WFD sync for UIBC capability negotiation (step S820).
  • the RTSP M4 request message may also include a wfd2_uibc_capability parameter.
  • the wfd2_uibc_capability parameter may include information on an input category and information on the VCDC capability (for example, a voice command device type and information on supported voice command values).
  • the WFD sink may transmit an RTSP M4 / M14 response message to the WFD source for UIBC capability negotiation (step S830).
  • the RTSP M4 / M14 response message may be sent for consent to the values set by the RTSP M4 request message.
  • FIG. 9 is a flowchart illustrating UIBC capability negotiation between a WFD source and a WFD sink according to an embodiment of the present invention.
  • the WFD source may request the wfd2_uibc_capability parameter to the WFD sink through the RTSP M3 request message (step S900).
  • the WFD sink may transmit the RTSP M3 response message to the WFD source in response to the RTSP M3 request message (step S910).
  • the RTSP M3 response message may include a wfd2_uibc_capability parameter, and the wfd2_uibc_capability parameter may include information about the input category (eg, VCDC), information about the VCDC capability (eg, voice command device type (TV)). , Supported voice command value information).
  • VCDC input category
  • VCDC capability e.g, voice command device type (TV)
  • TV voice command device type
  • each of the WFD source and the WFD sink can obtain information about UIBC capabilities from each other.
  • the WFD source may send an RTSP M4 request message to the WFD sync for UIBC capability negotiation (step S920).
  • the RTSP M4 request message may include a wfd2_uibc_capability parameter.
  • the wfd2_uibc_capability parameter may include information on an input category and information on the VCDC capability (eg, voice command device type, supported voice command value).
  • the WFD sink may send an RTSP M4 response message to the WFD source for UIBC capability setting (step S930).
  • the WFD sink may send an RTSP M14 request message for renegotiation of UIBC capability to the WFD sink (step S940).
  • the WFD sink can perform renegotiation of UIBC capabilities for voice command support to the WFD source via M14 RTSP messages in RTSP playing state.
  • the RTSP M14 request message for UIBC capability renegotiation may include a wfd2_uibc_capability parameter.
  • the wfd2_uibc_capability parameter may include information on an input category and information on the VCDC capability (for example, a voice command device type and a supported voice command value).
  • the WFD source may send an RTSP M14 response message for renegotiation of UIBC capability to the WFD sync (step S950).
  • the RTSP M14 response message may be sent for consent to the values reset by the RTSP M14 request message.
  • Table 8 describes the wfd2-uibc-capability parameters for supporting voice commands via UIBC.
  • FIG. 10 is a flowchart illustrating UIBC capability negotiation between a WFD source and a WFD sink according to an embodiment of the present invention.
  • the UIBC capability negotiation procedure based on the RTSP M3 message / RTSP M4 message may be performed as shown in FIG. 9.
  • the picture of the WFD source may be mirrored to the WFD sink.
  • the WFD sink may transmit a UIBC input message to the WFD source.
  • the UIBC input message may include a key code of the voice command (operation code of the voice command) as illustrated in Table 7.
  • the present invention discloses a method in which the WFD sink controls the WFD source in such a manner that the WFD sink transmits a user's voice command to the WFD source through an RTSP control message.
  • the wfd2-uibc-ability parameter is set via RTSP M3 request / response messages, RTSP M4 request messages, and RTSP M14 request messages. Can be sent.
  • the wfd2-uibc-capability parameter may be defined as shown in Table 9 below.
  • FIG. 11 is a flowchart illustrating UIBC capability negotiation between a WFD source and a WFD sink according to an embodiment of the present invention.
  • the WFD source may request a wfd2_uibc_capability parameter to the WFD sink through the RTSP M3 request message (step S1100).
  • the WFD sink may transmit the RTSP M3 response message to the WFD source in response to the RTSP M3 request message (step S1110).
  • the RTSP M3 response message may include a wfd2_uibc_capability parameter, and the wfd2_uibc_capability parameter may contain information about the input category (eg, VCDC), information about the VCDC capability (eg, supported voice command information). It may include. Supported voice command information includes Play, Pause, Forward, Rewind, Previous, Next, Mute and Unmute. , Full screen, original size, screen rotate, and the like.
  • VCDC input category
  • Supported voice command information includes Play, Pause, Forward, Rewind, Previous, Next, Mute and Unmute. , Full screen, original size, screen rotate, and the like.
  • each of the WFD source and the WFD sink can obtain information about UIBC capabilities from each other.
  • the WFD source may send an RTSP M4 request message to the WFD sync for UIBC capability negotiation (step S1120).
  • the RTSP M4 request message may include a wfd2_uibc_capability parameter.
  • the wfd2_uibc_capability parameter may include information about an input category (eg, VCDC) and information about VCDC capability (eg, supported voice command information).
  • the WFD sink may send an RTSP M4 response message to the WFD source for UIBC capability setting (step S1130).
  • the capability negotiation for voice command support may be performed through the UIBC in the RTSP initiation state through the RTSP M4 message.
  • FIG. 12 is a flowchart illustrating UIBC capability negotiation between a WFD source and a WFD sink according to an embodiment of the present invention.
  • the WFD source may transmit an RTSP M14 request message for renegotiation (or reconfiguration) of UIBC capabilities to the WFD sync (step S1200).
  • the WFD source can perform renegotiation of UIBC capabilities for voice command support with WFD sync via M14 RTSP control messages in RTSP playing state.
  • the WFD sink may send an RTSP M14 response message to the WFD source for renegotiation of the UIBC capability (step S1210).
  • the RTSP M14 response message may be sent for consent to the values set by the RTSP M14 request message.
  • the WFD sink may transmit an RTSP M14 request message for renegotiating (or resetting) UIBC capability to the WFD source, and the WFD source may transmit an RTSP M14 response message for renegotiating UIBC capability to the WFD sink.
  • a wfd2-uibc-voice command (vc) -control ”RTSP parameter for controlling an AV streaming screen of a WFD source may be defined through a user voice command.
  • the wfd2-uibc-vc-control parameter is used for a specific operation to support user voice command through UIBC.
  • the portion marked “none” in the wfd2-uibc-voice command (vv) -control parameter may mean that the corresponding sub-parameter value is not supported.
  • Table 11 discloses lower parameters of the wfd2-uibc-voice command (vc) -control parameter included in M15 SET_PARAMETER.
  • the voice command illustrated in the present invention is only a part of various embodiments, and a voice command for controlling various application applications may be transmitted to the WFD source through the RTSP control message proposed by the present invention.
  • the lower parameters included in the proposed wfd2-uibc-voice command-control may be defined in a bitmap format.
  • Table 12 defines the parameters included in the proposed wfd2-uibc-voice command-control in bitmap format.
  • a lower parameter may correspond to each bit included in the bitmap, and each bit of the bitmap may be set to 0 or 1 to transmit a specific voice command received from the WFD sink.
  • FIG. 13 is a conceptual diagram illustrating a method of transmitting an RTSP control message according to an embodiment of the present invention.
  • the WFD source may perform AV streaming to the WFD sync.
  • the user may deliver a voice message called pause in WFD sync.
  • the WFD sink may generate an RTSP M15 request message (M15 req. RTSP SET_PARAMETER REQUEST) based on the received voice message (“stop”) and transmit it to the WFD source (step S1300).
  • the RTSP M15 request message may include a wfd2-uibc-vc-control parameter, and the wfd2-uibc-vc-control parameter may include a key code or bitmap corresponding to a pause.
  • the WFD source may transmit an RTSP M15 response message (M15 res. RTSP SET_PARAMETER RESPONSE) to the WFD sink (step S1310).
  • M15 res. RTSP SET_PARAMETER RESPONSE M15 res. RTSP SET_PARAMETER RESPONSE
  • the WFD source may stop the image being played according to the RTSP control message transmitted through the WFD sink.
  • the user can deliver a voice message "play" to the WFD sync.
  • the WFD sink may generate an RTSP M15 request message (M15 req. RTSP SET_PARAMETER REQUEST) based on the received voice message (“playback”) and transmit it to the WFD source (step S1320).
  • the RTSP M15 request message may include a wfd2-uibc-vc-control parameter, and the wfd2-uibc-vc-control parameter may include a key code or bitmap corresponding to a play.
  • the WFD source may transmit an RTSP M15 response message (M15 res. RTSP SET_PARAMETER RESPONSE) to the WFD sink (step S1330).
  • M15 res. RTSP SET_PARAMETER RESPONSE M15 res. RTSP SET_PARAMETER RESPONSE
  • the WFD source may play the paused video according to the RTSP control message transmitted through the WFD sink.
  • an embodiment of the present invention discloses a method in which a WFD sink includes a user's voice command in audio low data and transmits the audio low data to a WFD source through a UIBC input message to control the WFD source. do.
  • the user's voice command is encoded in one of the following audio file formats in the WFD sink, and the encoded audio file may be included in the UIBC input message and transmitted to the WFD source.
  • the audio file format may be 3gp, act, aiff, aac, amr, au, awb, dct, dss, dvf, mp3, m4a, ra, raw, wma, wav, and the like.
  • the WFD source may extract a user voice by decoding an audio file included in the UIBC input message.
  • the extracted user voice may be reinterpreted as a key code value of the UIBC voice command defined in the present invention and transferred to the upper layer, and the screen of the WFD source being streamed may be controlled according to the key code of the user voice command. .
  • FIG. 14 is a conceptual diagram illustrating a UIBC input message format according to an embodiment of the present invention.
  • the UIBC input message may include a frame header 1400 and UIBC input data 1410.
  • the UIBC input data 1410 may include an internet protocol (IP) header 1420, a TCP header 1430, and a UIBC input body 1440.
  • IP internet protocol
  • the UIBC input body 1440 can include audio raw data 1450.
  • the IP header 1420 / TCP header 1430 may include control information for transmission and interpretation of the UIBC input body 1440.
  • the UIBC input body 1440 may include an audio file format in which a voice of a user is encoded.
  • 15 is a flowchart illustrating a UIBC capability negotiation method according to an embodiment of the present invention.
  • the WFD source may transmit the RTSP M3 request message 1500 to the WFD sink.
  • the RTSP M3 request message 1500 may include a wfd2_uibc_capability parameter.
  • the wfd2_uibc_capability parameter may be used to negotiate the UIBC capability for exchanging voice commands through a UIBC input message including an audio file between the WFD source and the WFD sink.
  • information indicating the voice command device category included in the wfd2_uibc_ capability parameter and information on the capability (eg, voice command information) of the voice command device category may be included.
  • RTSP M3 request message 1500 / RTSP M3 response message 1510 After the exchange of the RTSP M3 request message 1500 / RTSP M3 response message 1510, through the RTSP M4 request message 1520 / RTSP M4 response message 1530, capability negotiation for voice command support using UIBC in the RTSP initialization state is performed. The procedure can be performed.
  • the WFD source or the WFD sink may re-perform the capability negotiation procedure for supporting voice commands using UIBC through the RTSP M14 request message 1540 and the RTSP M14 response message 1550.
  • the audio file including the voice command shown in Table 7 may be input from the WFD sink to the WFD source, and the screen being mirrored to the WFD sink by the WFD source may be controlled by the WFD sink.
  • An audio file including the voice command is transmitted through the UIBC input message, and the audio file may be reinterpreted in the WFD source and interpreted as a key code corresponding to the voice command correctly.
  • a voice command device category is newly defined to support voice command processing through UIBC, and a VCDC input type for user input of a voice command device category may be defined as shown in Table 13 below. have.
  • the voice command of the user input from the WFD sink may be included in the UIBC data and transmitted to the WFD source. Therefore, the screen mirrored from the WFD source to the WFD sink may be controlled by the WFD sink.
  • a Voice Command (VC) value (or voice command keycode) may be included in the VCDC input body.
  • the wfd2-uibc capability parameter may be defined as follows.
  • 16 is a flowchart illustrating a UIBC capability negotiation method according to an embodiment of the present invention.
  • a UIBC capability negotiation procedure may be performed based on an RTSP M3 request / response message and an RTSP M4 request message / RTSP M4 response message.
  • the screen of the WFD source may be mirrored to the WFD sink (step S1600).
  • a voice command may be input through the WFD sink (step S1610), and the WFD sink may transmit a UIBC input message including an audio raw file format to the WFD source (step S1620).
  • the WFD source may decode the audio row file to determine a key code corresponding to the voice command and then perform an operation corresponding to the key code.
  • the WFD sink may control the WFD source by transmitting a user's voice command to the WFD source through a reverse audio channel (RAC).
  • RAC reverse audio channel
  • user voice commands may be delivered to the WFD source via RAC as audio streaming.
  • Table 16 below discloses bits indicating whether RAC is supported.
  • a bit indicating whether RAC is supported may be added to an extended capabilities bitmap and used for negotiation between the WFD source and the WFD sink when performing capability negotiation.
  • wfd2-rac-audio-formats parameter may be defined as shown in Table 17 below.
  • wfd2-rac-audio-formats “wfd2_rac_audio_formats:”
  • SP rac-audio-cap CRLFrac-audio-cap “none” / rac-audio-list; “None” if not supported at the WFD
  • Sinkrac-audio-list audio-format SP modes SP latency * (“,” SP rca-audio-list)
  • the “wfd2-rac-control” RTSP control parameter may be used.
  • the wfd2-rac-control parameter proposed in the present invention is as follows.
  • CONV_VOICE may indicate a conversational voice requiring real-time or latency critical handling.
  • OTHER_VOICE is an audio signal transmitted to a microphone input and may be a voice used for speech recognition. OTHER_VOICE may be less latency compared to CON_VOICE.
  • ANY_AUDIO may be audio content that does not require real-time or latency importance.
  • a voice command of a user input from a WFD sink may be included in an audio stream through a RAC and transmitted to a WFD source. Therefore, the screen mirrored from the WFD source to the WFD sink may be controlled by the WFD sink.
  • a voice command as defined in Table 7 may be included in the audio stream via the RAC to be delivered to the WFD source, and the WFD source may be reinterpreted as a voice command by determining a key code corresponding to the voice command.
  • the voice command illustrated in Table 7 is only a part of various embodiments, and a voice command for controlling various application applications may be delivered to a WFD source through an audio stream through RAC proposed in the present invention. have.
  • the RAC RTSP parameter for voice command support may be defined as shown in Table 19 below.
  • Table 19 Parameter name Parameter description Method Usage wfd2-rac-audio-formats Audio format (s) supported by the WFD R2 Source or WFD R2 Sink for audio streaming in reverse audio channel.
  • the wfd2-rac-audio-formats parameter may include information on audio formats supported by the WFD source or the WFD sink for audio streaming in the RAC.
  • the wfd2-rac-audio-formats parameter can be passed via RTSP M3 message.
  • the wfd2-rac-control parameter can be defined to enable / disable RAC.
  • the wfd2-rac control parameter may be transmitted in the RTSP M4 / M17 request message and the RTSP M18 request message.
  • the RTSP M17 message may be used by the WFD R2 device (WFD Source / WFD Sink) to reset the RAC during the WFD session.
  • the RTSP M18 message may be used for activation / deactivation of the RAC at the WFD R2 device (WFD source / WFD sink) during the WFD session.
  • 17 is a flowchart illustrating a capability negotiation and a capability negotiation procedure of a RAC for delivery of a voice command according to an embodiment of the present invention.
  • the M3 request message / M3 response message and the M4 request message / M17 request message may be used for UIBC capability negotiation.
  • the WFD source and the WFD sink may set up a reverse audio channel (RAC) through RTSP capability negotiation (step S1700), and an audio stream may be delivered from the WFD sink to the WFD source according to the setting of the RAC. .
  • RAC reverse audio channel
  • RTSP capability negotiation step S1700
  • the voice command (“stop”) may be transmitted to the WFD source through the RAC.
  • the WFD source may determine a key code corresponding to the voice command defined in the present invention corresponding to the received voice and perform an operation corresponding to the key code (step S1720).
  • FIG. 18 is a conceptual diagram illustrating a method for transmitting a voice command of a user through UIBC according to an embodiment of the present invention.
  • the WFD source may mirror the AV stream with the WFD sync (step S1800).
  • the user may input a command called stop WFD sync (“pause”) (step S1810), and the command input through the WFD sync may include UIBC input data including an operation code (or key code) corresponding to the voice command of the user. It can be transmitted to the WFD source as (step S1820).
  • pause a command called stop WFD sync
  • UIBC input data including an operation code (or key code) corresponding to the voice command of the user. It can be transmitted to the WFD source as (step S1820).
  • the WFD source may stop the AV stream (step S1830).
  • Table 20 below defines voice commands as new input categories.
  • the voice command may be defined as a separate input category and defined and transmitted as a separate input body.
  • Table 21 below is the syntax of the wfd2-uibc capability parameter.
  • VC is defined as a separate input category in the syntax of the wfd2-uibc capability parameter.
  • a new RTSP parameter may be defined indicating which device has the ability to interpret a user's voice command.
  • the wfd2-vc-translation parameter may be defined, and the wfd2-vc-translation parameter may indicate whether there is an ability to interpret voice commands.
  • Table 22 below shows the wfd2-vc-translation parameter.
  • the wfd2-vc-translation parameter may indicate which of the WFD source and the WFD sink determines the key code corresponding to the voice command by interpreting the voice command.
  • the WFD source If the WFD source supports voice commands via UIBC, the WFD source sends the wfd2-vc-translation parameter via an RTSP M4 request message, allowing any device, either the WFD source or the WFD sink, to interpret voice commands. It may be indicated whether to determine a key code corresponding to.
  • the WFD sink may receive an RTSP M4 request message from a WFD source and transmit an RTSP M4 response message in response to the RTSP M4 request message.
  • the WFD sink interprets the audio input containing the voice command.
  • the key code (or translated value) corresponding to the voice command may be determined.
  • the WFD sink may send user input data including the corresponding key code (or translated value) to the WFD source.
  • the WFD source may receive user input data including a key code (or translated value) and process a user voice command based on the key code (or interpreted value).
  • the WFD sink includes the audio input containing the voice command.
  • User input data VCDC input body / VCDC input message
  • the WFD sink may transmit user input data including audio low data corresponding to a voice command of the user to the WFD source.
  • the WFD source may receive user input data including audio row data, interpret the audio row data, and determine a key code corresponding to the audio row data to process a user voice command.
  • Table 23 below shows a VC input body format for supporting UIBC voice commands.
  • wfd2-voicecommand-translation is set to “Sink”, the Operation Code (or key code) of User's Voice Command is included in VC Input Body. If the wfd2-voicecommand-translation is set to “Source”, the Audio Low Data of User's Voice Command is included in VC Input Body.
  • Table 24 below discloses operation codes according to voice commands.
  • 19 is a conceptual diagram illustrating a method of transmitting a voice command of a user through UIBC according to an embodiment of the present invention.
  • the WFD source may transmit an RTSP M3 request message to the WFD sink (step S1900).
  • the RTSP M3 request message may include a wfd2_uibc_capability parameter and a wfd2_vc_translation parameter.
  • the WFD sink may transmit an RTSP M3 response message to the WFD source (step S1910).
  • the RTSP M3 response message may include a wfd2_uibc_capability parameter and a wfd2_vc_translation parameter.
  • the wfd2_uibc_capability parameter may include information about an input category (eg, VCDC) and a port.
  • the wfd2_vc_translation parameter may include information about a translation capability of a voice command of a WFD source / WFD sink.
  • the WFD source may transmit an RTSP M4 request message to the WFD sink (step S1920).
  • the RTSP M4 request message can be used to set UIBC parameters for voice commands.
  • the RTSP M4 request message may include a wfd2_uibc_capability parameter, a wfd2_vc_interpretation parameter, and a wfd_uibc_setting parameter.
  • whether the WFD sink interprets the voice command or the WFD source interprets the voice command may be determined according to the wfd2_vc_interpretation parameter.
  • the WFD sink may transmit an RTSP M4 response message to the WFD source (step S1930).
  • the WFD source may transmit data to the WFD sink through AV streaming.
  • the WFD sink may interpret the voice command of the user and determine an operation code (key code) corresponding to the voice command of the user.
  • the WFD sink may include an operation code corresponding to the voice command of the user in the UIBC input message (or UIBC data) and transmit the same to the WFD source.
  • 20 is a block diagram illustrating a wireless device to which an embodiment of the present invention can be applied.
  • the wireless device may be a WFD source 2000 (or a first WFD device) and a WFD sink 2050 (or a second WFD device) capable of implementing the above-described embodiment.
  • the WFD source 2000 includes a processor 2010, a memory 2020, and a communication unit 2030.
  • the RF unit 2030 may be connected to the processor 2010 to transmit / receive a radio signal.
  • the processor 2010 may implement the functions, processes, and / or methods proposed in the present invention.
  • the processor 2010 may be implemented to perform the operation of the WFD source 2000 according to the above-described embodiment of the present invention.
  • the processor may perform an operation of the WFD source 2000 disclosed in the embodiment of FIGS. 1 to 19.
  • the processor 2010 transmits an RTSP M3 request message for requesting information on the voice command device category (VCDC) capability of the second WFD device to the second WFD device, and requests the RTSP M3 from the second WFD device.
  • VCDC voice command device category
  • response to the message may receive an RTSP M3 response message.
  • the RTSP M3 response message may include input category information and VCDC capability information set to VCDC of the second WFD device.
  • the processor 2010 transmits an RTSP M4 request message including input category information set to VCDC and initial set VCDC capability information to a second WFD device in a real time streaming protocol (RTSP) initialization state, and the RTSP M4 It may be implemented to receive the RTSP M4 response message from the second WFD device in response to the request message.
  • RTSP real time streaming protocol
  • the first WFD device is a device that supports streaming of multimedia content
  • the second WFD device is a device that receives and renders the multimedia content from the first WFD device through a peer-to-peer link with the first WFD device. Can be.
  • the VCDC capability information may include information on a plurality of voice-based motion control commands for controlling multimedia content played by the second WFD device in the first WFD device and the second WFD device.
  • the processor 2010 transmits an RTSP M14 request message for resetting initial configuration VCDC capability information to a second WFD device in an RTSP playing state, wherein the RTSP M14 request message is configured to input category information and initial information set to VCDC.
  • the RTSP M14 request message is configured to input category information and initial information set to VCDC.
  • includes reset VCDC capability information for resetting the configuration VCDC capability information and may be implemented to receive the RTSP M14 response message from the second WFD device in response to the RTSP M14 request message.
  • the processor 2010 may be implemented to receive UIBC data for voice commands from the second WFD device, wherein the UIBC data includes a VCDC input body, and the VCDC input body includes a VCDC command device type identifier field and an application identifier field. And a voice command value field, the VCDC command device type identifier field includes information on the device type of the second WFD device, and the application identifier field plays the multimedia content in the first WFD device controlled based on the UIBC data. Includes identifier information of the application driven for the, and the voice command value field may include at least one key code corresponding to at least one operation control command of the plurality of key codes corresponding to the plurality of operation control commands.
  • the RTSP M3 response message further includes information on whether a reverse audio channel (RAC) is supported, and UIBC data is transmitted through a RAC set between the first WFD device and the second WFD device. It can be classified according to the need for real time processing.
  • RAC reverse audio channel
  • the RTSP M4 request message further includes a translation capability parameter, wherein the translation capability parameter determines whether any of the first WFD device or the second WFD device determines at least one key code corresponding to the at least one operation control command. Can be indicated.
  • the WFD sink 2050 includes a processor 2060, a memory 2070, and a communication unit 2080.
  • the RF unit 2080 may be connected to the processor 2060 to transmit / receive a radio signal.
  • the processor 2060 may implement the functions, processes, and / or methods proposed in the present invention.
  • the processor 2060 may be implemented to perform the operation of the WFD sink 2050 according to the above-described embodiment of the present invention.
  • the processor may perform the operation of the WFD sink 2050 (or the second WFD device) in the embodiments of FIGS. 1 to 19.
  • the processor 2060 may transmit the RTSP M3 response message to the first WFD device in response to the RTSP M3 request message, and transmit the RTSP M4 response message to the first WFD device in response to the RTSP M4 request message. Can be implemented.
  • the processor 2060 receives an RTSP M14 request message for resetting initial configuration VCDC capability information in an RTSP playing state, and an RTSP M14 response message from the second WFD device in response to the RTSP M14 request message. It can be implemented to transmit.
  • the processors 2010 and 2060 may include application-specific integrated circuits (ASICs), other chipsets, logic circuits, data processing devices, and / or converters for interconverting baseband signals and wireless signals.
  • the memories 2020 and 2070 may include read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media and / or other storage devices.
  • the RF unit 2030 and 2080 may include one or more antennas for transmitting and / or receiving a radio signal.
  • Modules may be stored in memories 2020 and 2070 and executed by processors 2010 and 2060.
  • the memories 2020 and 2070 may be inside or outside the processors 2010 and 2060, and may be connected to the processors 2010 and 2060 by various well-known means.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Human Computer Interaction (AREA)
  • General Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Biomedical Technology (AREA)
  • Computational Linguistics (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Physics & Mathematics (AREA)
  • Acoustics & Sound (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

L'invention concerne un procédé de traitement d'une commande vocale par l'intermédiaire d'un UIBC, qui peut comprendre les étapes consistant à : envoyer, par un premier dispositif WFD, un message de requête M3, pour demander des informations sur la capacité VCDC d'un second dispositif WFD, au second dispositif WFC ; recevoir, par le premier dispositif WFC, un message de réponse M3 en provenance du second dispositif WFC en réponse au message de requête M3, le message de réponse M3 comprenant des informations de catégorie d'entrée et des informations de capacité VCDC configurées pour un VCDC du second dispositif WFD ; envoyer, par le premier dispositif WFC, un message de requête M4 au second dispositif WFD dans un état d'initialisation RTSP, le message de requête M4 comprenant les informations de catégorie d'entrée et des informations de capacité VCDC de configuration initiale configurées pour le VCDC ; et recevoir, par le premier dispositif WFD, un message de réponse M4 en provenance du second dispositif WFD en réponse au message de requête M4.
PCT/KR2016/004700 2015-05-21 2016-05-04 Procédé et dispositif de traitement de commande vocale par l'intermédiaire d'un uibc WO2016186352A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/575,713 US20180295414A1 (en) 2015-05-21 2016-05-04 Method and device for processing voice command through uibc

Applications Claiming Priority (14)

Application Number Priority Date Filing Date Title
US201562165139P 2015-05-21 2015-05-21
US62/165,139 2015-05-21
US201562166671P 2015-05-26 2015-05-26
US201562166672P 2015-05-26 2015-05-26
US201562166673P 2015-05-26 2015-05-26
US201562166669P 2015-05-26 2015-05-26
US62/166,671 2015-05-26
US62/166,673 2015-05-26
US62/166,669 2015-05-26
US62/166,672 2015-05-26
US201562170142P 2015-06-03 2015-06-03
US62/170,142 2015-06-03
US201562172036P 2015-06-06 2015-06-06
US62/172,036 2015-06-06

Publications (1)

Publication Number Publication Date
WO2016186352A1 true WO2016186352A1 (fr) 2016-11-24

Family

ID=57320638

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/004700 WO2016186352A1 (fr) 2015-05-21 2016-05-04 Procédé et dispositif de traitement de commande vocale par l'intermédiaire d'un uibc

Country Status (1)

Country Link
WO (1) WO2016186352A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019125012A1 (fr) * 2017-12-21 2019-06-27 엘지전자 주식회사 Procédé pour réaliser une communication sans fil sur la base de données vocales dans un système de réseau local sans fil, et appareil sans fil l'utilisant

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120082846A (ko) * 2011-01-14 2012-07-24 삼성전자주식회사 와이파이 다이렉트 통신 방식에서의 싱크 디바이스에서 소스 디바이스로 사용자의 입력을 송신하기 위한 방법 및 장치
KR20130126969A (ko) * 2011-01-21 2013-11-21 퀄컴 인코포레이티드 무선 디스플레이들을 위한 사용자 입력 백 채널
JP2014127213A (ja) * 2012-12-25 2014-07-07 Pioneer Electronic Corp 同期再生制御装置及び同期再生制御方法
US20140365611A1 (en) * 2013-06-07 2014-12-11 Qualcomm Incorporated Method and system for using wi-fi display transport mechanisms to accomplish voice and data communications
US20150036695A1 (en) * 2013-07-31 2015-02-05 Nvidia Corporation Real time network adaptive low latency transport stream muxing of audio/video streams for miracast

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120082846A (ko) * 2011-01-14 2012-07-24 삼성전자주식회사 와이파이 다이렉트 통신 방식에서의 싱크 디바이스에서 소스 디바이스로 사용자의 입력을 송신하기 위한 방법 및 장치
KR20130126969A (ko) * 2011-01-21 2013-11-21 퀄컴 인코포레이티드 무선 디스플레이들을 위한 사용자 입력 백 채널
JP2014127213A (ja) * 2012-12-25 2014-07-07 Pioneer Electronic Corp 同期再生制御装置及び同期再生制御方法
US20140365611A1 (en) * 2013-06-07 2014-12-11 Qualcomm Incorporated Method and system for using wi-fi display transport mechanisms to accomplish voice and data communications
US20150036695A1 (en) * 2013-07-31 2015-02-05 Nvidia Corporation Real time network adaptive low latency transport stream muxing of audio/video streams for miracast

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019125012A1 (fr) * 2017-12-21 2019-06-27 엘지전자 주식회사 Procédé pour réaliser une communication sans fil sur la base de données vocales dans un système de réseau local sans fil, et appareil sans fil l'utilisant

Similar Documents

Publication Publication Date Title
WO2020076110A1 (fr) Dispositif électronique pour déterminer un canal opérationnel p2p et procédé associé
WO2014189318A1 (fr) Schéma de communication à base de proxy dans une structure d'accueil
WO2018222024A1 (fr) Procédé et appareil permettant de connecter des dispositifs à l'aide de la technologie bluetooth à faible consommation d'énergie
WO2015069031A1 (fr) Procédé et appareil de formation d'une liaison de communications utilisant bluetooth
WO2017030232A1 (fr) Procédé pour transmettre et recevoir des données, et dispositif associé
WO2014051367A1 (fr) Appareil de terminal d'utilisateur, dispositif électronique, et procédé pour commander celui-ci
WO2016093623A1 (fr) Procédé et appareil pour délivrer un contenu supplémentaire à partir d'un wfd
WO2015182896A1 (fr) Procédé et appareil de connexion bluetooth
WO2014204272A1 (fr) Procédé et appareil pour reproduire des contenus multimédias à l'aide de bluetooth dans un système de communication sans fil
WO2015190877A1 (fr) Procédé et dispositif de transmission/réception de données par hdmi
WO2017043718A1 (fr) Procédé et dispositif permettant à un récepteur wfd de modifier l'orientation d'une image
WO2015133865A1 (fr) Procédé et système pour l'établissement d'une session de service entre un dispositif chercheur et un dispositif d'annonceur publicitaire
WO2016111562A1 (fr) Procédé et appareil pour rapport d'état de batterie dans un wfd
WO2021096257A1 (fr) Procédé de transmission de données audio à l'aide d'une communication de courte portée dans un système de communication sans fil, et dispositif associé
WO2020246768A1 (fr) Procédé, appareil et programme informatique pour service de découverte de diffusion dans un système de communication sans fil, et support d'enregistrement associé
WO2016167475A1 (fr) Procédé et appareil pour commuter un caractère d'entrée dans un wfd
WO2021091241A1 (fr) Procédé, appareil et programme informatique de définition de clé de chiffrement dans un système de communication sans fil, et support d'enregistrement associé
WO2021162413A1 (fr) Procédé de réception de données audio à l'aide d'une communication sans fil à courte portée dans un système de communication sans fil, et appareil associé
WO2016186352A1 (fr) Procédé et dispositif de traitement de commande vocale par l'intermédiaire d'un uibc
WO2020262926A1 (fr) Procédé, dispositif et programme informatique permettant de réguler et de gérer l'état d'un dispositif périphérique dans un système de communication sans fil et support d'enregistrement associé
WO2022019345A1 (fr) Procédé et dispositif pour le balayage et la connexion d'un dispositif bluetooth
WO2020246767A1 (fr) Procédé, dispositif et programme informatique pour commander des données audio dans un système de communication sans fil, et support d'enregistrement associé
WO2020256166A1 (fr) Dispositif de transmission de données et dispositif de réception de données dans un système audiovisuel sans fil
WO2021010496A1 (fr) Appareil et procédé de commande de puissance d'émission rf adaptative dans un système av sans fil
WO2019203580A1 (fr) Procédé et dispositif permettant de fournir un service de diffusion en continu audio à l'aide de la technologie bluetooth à faible énergie

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15575713

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16796679

Country of ref document: EP

Kind code of ref document: A1