Reverse channel of user input for wireless display

Ukraine ₍₁₉₎ id (her) 109928 (s) C2

(51) IPC

H04M28 / 16 (2009.01)

H04b 29/06 (2006.01)

STATE SERVICE INTELLECTUAL OPPORTUNITY OF UKRAINE

(12) DESCRIPTION TO A patent for an invention

<tr><td><p>(21) Application number:</p></td><td><p>and 2013 10238</p></td></tr><tr><td><p>(22) Date of application:</p></td><td><p>January 20, 2012</p></td></tr><tr><td><p>(24) Date from which it is valid</p></td><td><p>10/26/2015</p></td></tr><tr><td><p>rights to invention:</p></td></tr><tr><td><p>(31) The number of the previous one</p></td><td><p>61 / 435,194,</p></td></tr><tr><td><p>applications according to</p></td><td><p>61 / 447,592,</p></td></tr><tr><td><p>Paris Convention:</p></td><td><p>61 / 448,312,</p></td></tr><tr><td><p>(32) Date of submission</p></td><td><p>61 / 450,101,</p><p>61 / 467,535,</p><p>61 / 467,543,</p><p>61 / 514,863,</p><p>61 / 544,445,</p><p>13 / 344,291</p><p>Jan 21, 2011</p></td></tr><tr><td><p>previous application</p></td><td><p>Feb 28, 2011</p></td></tr><tr><td><p>according to</p></td><td><p>03/02/2011</p></td></tr><tr><td><p>Paris Convention:</p></td><td><p>03/07/2011</p></td></tr><tr><td><p>(33) Code of the State Party</p></td><td><p>March 25, 2011,</p><p>March 25, 2011,</p><p>08/03/2011</p><p>10/07/2011</p><p>01/05/2012</p><p>υδ,</p></td></tr><tr><td><p>The Paris Convention</p></td><td><p>from</p></td></tr><tr><td><p>to which is filed</p></td><td><p>υδ,</p></td></tr><tr><td><p>preliminary application:</p></td><td><p>from</p></td></tr><tr><td><p>(41) Publication of information</p></td><td><p>υδ,</p><p>υδ,</p><p>υδ,</p><p>υδ,</p><p>υδ</p><p>Nov 25, 2013, No. 22</p></td></tr><tr><td><p>about the application:</p></td></tr><tr><td><p>(46) Publication of information</p></td><td><p>10/25/2015, bulletin No. 20</p></td></tr><tr><td><p>about the issuance of a patent:</p></td></tr><tr><td><p>(86) Number and date</p></td><td><p>Ρ ^ / υδ2012 / 022106,</p></td></tr><tr><td><p>international representation</p></td><td><p>January 20, 2012</p></td></tr>

applications filed in accordance with the PCT Agreement

(72) The inventor (s):

Ravindran Vijayalakshmi R. (υδ), Huang Xiaolong (υδ),

Wang Xiaodong (υδ),

Shaukat Fawad (υδ)

(73) Owner (s):

QUALCOM INCORPORATEID,

IPEgypaIIiPaI RI ActiPiIiOp, 5775MoGeIoIeE ^^ iNe, SalIdE, Saiiyogpia92121, ipIeS Ziaiee oi Ategis (iZ)

(74) Representative:

Moshynska Nina Nikolaevna, registry number 115

(56) List of documents taken into account by examination:

OTO 2010003347 A1, January 14, 2010TOT 2004071048 A1, 19.08.2004ER 1248431 A1, 09.10.2002 and I 2004196852 A1.07.10.2004

iA 109928 C2

(54) REVERSE USER CHANNEL FOR FREE DISPLAYS

(57) Summary:

As part of a communication session, a wireless source device can transmit audio and video data to a wireless receiver, and the wireless receiver unit can transmit user inputs received in the wireless receiver device back to the wireless source device. Thus, the user of the wireless device can control the receiver

iA 109928 C2

a wireless source device and control the content that is transmitted from the wireless source device to the wireless receiver. As part of the installation of the communication session, the non-wireless receiver and the wireless source device can perform the harmonization of characteristics.

iA 109928 C2

This application claims priority:

Preliminary US Patent Application Ser. No. 61 / 435,194 filed January 21, 2011; Preliminary Patent Application (US) 61/447592 filed Feb. 28, 2011; Preliminary Patent Application (US) 61/448312 filed March 2, 2011 Preliminary Patent Application (US) 61/450101 filed March 7, 2011; Preliminary Patent Application (US) 61/467535 filed March 25, 2011; Preliminary Patent Application (US) 61/467543 filed March 25 2011; Preliminary Patent Application (US) 61/514863 filed Aug. 3, 2011; and a Preliminary Patent Application (US) 61/544445 filed on October 7, 2011, the contents of each of which are fully incorporated herein by reference.

THE FIELD OF TECHNOLOGY TO WHICH THE INVENTION IS REQUIRED

This disclosure relates to the technology for data transmission between a wireless device-source and a wireless device-receiver.

TECHNICAL LEVEL

Wireless display (SHO) or Shi-Gi-reflection (SHGO) systems include a non-wireless source device and one or more wireless receiver devices. The source device and each of the receiver devices may be mobile devices or wired devices with wireless support. One or more source devices and receiver devices may include, for example, mobile phones, portablecomputers with wireless cards, personal digital devices (PDAs), portable multimedia players or other such wireless communication devices, Includes so-called smartphones and intelligent touch panels or tablet computers or any type of wireless display, videogame devices or other types of wireless devices.

The source device sends multimedia data, such as audio-video (AU) data, to the same number of receiver devices that participate in a particular multimedia sharing session. Multimedia data can be played both on the local display device of the source, and on each of the displays of receiver devices. More specifically, each of the participating receivers engages in rendering received multimedia data on its screen and audio equipment.

HOW TO FIND

This disclosure of the substance, in general, describes a system in which a wireless device-receiver can exchange data with a wireless device-receiver. As part of a communication session, a non-wireless source device can transmit audio and video data to a wireless receiver, and the wireless receiver unit can transmit custom inputs received to the wireless receiver devices, back to the wireless source device. Thus, the user of the wireless receiver device can control the wireless source device to control the content that is transmitted from the wireless source device to the wireless device receiver.

In one example, a method for matching characteristics between a wireless receiver and a wireless source device includes sending a message to a non-originating source device, with the message identifying a list of supported input categories, and a plurality of supported types of lists, with each of the supported categories of input from the list of supported categories the input has an associated list of supported types.

In another example, the wireless device-receiver is made to match the characteristics with a wireless source device. The wireless receiver includes a storage device that holds instructions, and one or more processors executed with the ability to follow the instructions. When executing instructions, one or more processors instruct the transmission of messages to a wireless source device, with the message identifies a list of supported input categories, and a set of supported types of lists, with each of the supported input categories from the list of supported categories has an associated list of supported types.

In another example, a machine-readable storage medium stores instructions that when using one or more processors instruct one or more processors to perform a way to reconcile the characteristics between the wireless receiver and the wireless source device. The method includes sending a message to a wireless source device, with the message identifying a list of supported

1

iA 109928 C2

categories of input, and a set of supported types of lists, and each of the supported categories of input from the list of supported categories of input has an associated list of supported types.

In another example, the wireless device-receiver is made to match the characteristics with a wireless source device. The wireless device receiver includes a means for transmitting messages to a wireless source device, with this message identifying a list of supported input categories, and a set of lists of supported types, with each of the supported input categories from the list of supported input categories having an associated list of supported types.

In another example, a method for matching characteristics between a wireless receiver and a wireless source device includes receiving a non-wireless receiver message, with the message identifying a list of supported input categories, and a plurality of supported types of lists, with each of the supported categories of input from the list of supported categories the input has an associated list of supported types.

In another example, a wireless source device is designed to match the characteristics of the wireless receiver. The cordless source device includes a stored storage device and one or more processors executed with the ability to execute instructions, while performing instructions one or more processors instruct the reception of messages from the wireless receiver device, when this message identifies a list of supported categories input, and a plurality of lists of supported types, with each of the supported categories of input from the list of supported input categories has an associated list of support emyh types.

In another example, a machine-readable storage medium stores instructions that when using one or more processors instruct one or more processors to perform a way to reconcile the characteristics between the wireless receiver and the wireless source device. The method involves receiving a non-wireless receiver message, with the message identifying a list of supportedcategories of input, and a set of supported types, with each of the supported input categories from the list of supported input categories has an associated list of supported types.

In another example, a wireless source device is designed to match the characteristics of the wireless receiver. A wireless source device includes a means for receiving messages from a wireless receiver device, while the message identifies a list of supported input categories and a set of lists of supported types, with each of the supported input categories from the list of supported input categories having an associated list of supported types.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram illustrating an example of a source / receiver system that can implement the technologies of this disclosure.

FIG. 1B is a block diagram illustrating an example of a source / receiver system with two receiver devices.

FIG. 2 shows an example of a source device that can implement the technologies of this disclosure of the essence.

FIG. 3 shows an example of a receiver device that can implement the technologies of this disclosure of the essence.

FIG. 4 shows a block diagram of the system of the transmitting device and the receiving device system, which can implement the technologies of this disclosure of the essence.

FIG. 5A and 5B show exemplary sequence of message transmissions to perform the matching of characteristics according to the technologies of this disclosure.

FIG. 6 shows an exemplary data packet that can be used to deliver user-entered data received in the receiver device to the source device.

FIG. 7A and 7B are flow diagrams of a method operation, illustrating the techniques of this disclosure, which can be used to reconcile characteristics between the device-source and the receiving device.

FIG. 8A and 8B are flowchart flow diagrams illustrating the techniques of this disclosure, which can be used to transmit and receive packets of data provided by the user input.

2

iA 109928 C2

FIG. 9A and 9B are flowchart flow diagrams illustrating the techniques of this disclosure, which can be used to transmit and receive packets of data provided by user input.

FIG. 10A and 10B are flow diagrams of a method sequence that illustrate the techniques of this disclosure, which can be used to transmit and receive packets of data with timestamp information and user input data.

FIG. 11A and 11B are flow diagram flow diagrams illustrating the techniques of this disclosure, which can be used to transmit and receive packets of data with timestamp information and user input data.

FIG. 12A and 12B are flowchart flow diagrams illustrating the techniques of this disclosure, which can be used for the transmission and receipt of data packets, which include speech commands.

FIG. 13A and 13B are flowchart flow diagrams illustrating the techniques of this disclosure, which can be used for transmitting and receiving data packets with multisensory user input commands.

FIG. 14A and 14B are flowchart flow diagrams illustrating the techniques of this disclosure, which can be used to transmit and receive packets of data provided by user input redirected from a third-party device.

FIG. 15A and 15B are flowchart flow diagrams illustrating the techniques of this disclosure that can be used to transmit and receive packets of data.

REFERENCE DESCRIPTION OF THE INVENTION

This disclosure of the substance, in general, describes a system in which a wireless device-receiver can exchange data with a wireless device-receiver. As part of a communication session, a non-wireless source device can transmit audio and video data to a wireless receiver, and the wireless receiver unit can transmit user inputs received to the wireless receiver devices, back to the wireless source device. Thus, the user of the wireless receiver device can control the wireless source device to control the content that is transmitted from the wireless source device to the wireless device receiver.

FIG. 1A is a block diagram illustrating exemplary source / receiver system 100 that can implement one or more technologies of this disclosure. As shown in FIG. 1A, system 100 includes a source device 120 that communicates with the receiver device 160 through the communication channel 150. The source device 120 may include a storage device that stores audio-video (A / V-) data 121, a display 122, a speaker 123, an audio video coder 124 (also referred to as an encoder 124), an audio video control module 125 and the transceiver unit 126 (TX / PX). The device receiver 160 may include a display 162, a speaker 163, an audio video decoder 164 (also referred to as a decoder 164), a transmitter unit 166, a user input device 167, and a custom input processing module 168. The illustrated components are only one example configuration for the 100 sources / receivers system. Other configurations may include fewer components than illustrated components, or may include additional components in comparison with illustrated components.

In the example of FIG. 1A, the source device 120 may display a portion of the audio video video 121 on the display 122 and may output part of the audio audio video 121 to the speaker 122. Audio video data 121 can be stored locally on source device 120 available from an external storage medium such as a file server, a hard disk, an external storage device, a DVD, a drive, or other physical storage device, or may be transmitted by the stream to the source device 120 via a network connection, for example, the Internet. In some cases, audio video 121 may be captured in real time through the camera and microphone of the source device 120. Audio-video data 121 may include multimedia content such as movies, television shows or music, but can also include real-time content, formed by the source device 120. Such real-time content, for example, may be formed using attachments operating on source device 120, or captured video data, for example, as part of a video telephony session. As described in more detail, such content in real time can in some cases include a video frame with user input items available for user selection. In some cases, audio video 121 may include video frames, which are a combination of different types of content, such as a video frame of a movie or a program that has custom input points overlayed on a video frame. as part of a video telephony session. As described in more detail, such content in real time can in some cases include a video frame with user input items available for user selection. In some cases, audio video 121 may include video frames, which are a combination of different types of content, such as a video frame of a movie or a program that has custom input points overlayed on a video frame. as part of a video telephony session. As described in more detail, such content in real time can in some cases include a video frame with user input items available for user selection. In some cases, audio video 121 may include video frames, which are a combination of different types of content, such as a video frame of a movie or a program that has custom input points overlayed on a video frame.

3

iA 109928 C2

In addition to rendering audio video 121 locally via the display 122 and the speaker 123, the audio video coder 124 of the source device 120 can encode the audio video 121, and the receiving and transmitting unit 126 can transmit the coded data through the communication channel 150 to the device receiver 160 The receiving device 166 receives the coded data and the audio decoder 164 decodes the encoded data and outputs the decoded data through the display 162 and the speaker 163. Thus, the audio and video data rendered by the display 122 and the di Amica 123 can be simultaneously prepared withthrough rendering via display 162 and speaker 163. The audio and video mozhutrozmischuvatysya staffing and sound frame can be synchronized with the time when implementation of video rendering.

An audio video encoder 124 and an audio video decoder 164 can implement any number of audio and video compression standards, for example, the 1Ti-T H.264 standard, which is alternatively called IRC-4, part 10, enhanced video encoding (AUC), or a new standard, high-performance encoding Video (NEUS), which is being developed, which is sometimes called the standard H.265. A plurality of other types of own or standardized compression technologies can also be used. Generally speaking, the audio video decoder 164 is made with the ability to perform mutually inverse encoding of the audio video encoder 124. Although shown in FIG. 1A, in some aspects, the A / W encoder 124 and the A / C decoder 164 may be integrated with an audio encoder and decoder and may include the appropriate blocks of the multiplexer-demultiplexer or other hardware and software for,

As described in more detail below, the A / B encoder 124 may also perform other encoding functions additionally to implement the compression standard of the video, as described above. For example, the A / B encoder 124 may add different types of metadata to the A / D data 121 to transmit the A / D data 121 to the receiver device 160. In some cases, A / D data 121 may be stored or received in the device- sources 120 in the encoded form and, therefore, do not require additional compression using the A / W encoder 124.

Although FIG. 1A shows a communication channel 150 that transmits work audio data and working video data separately, it should be understood that in some cases, work video data and working audio data may be part of a common data stream. If applicable, the blocks of the multiplexer-demultiplexer may match the protocol of the multiplexer ITI H.223 or other protocols, such as the user's datagram protocol (UDP). An audio video encoder 124 and an audio video decoder 164 can be implemented as one or more microprocessors, digital signal processors (IδP), specialized integrated circuits (ABISs), programmable gate matrix users (ERAS), discrete logic, software, hardware, firmware, or any other Which combinations of the above. Each audio video encoder 124 and an audio video decoder 164 may be included in one or more encoders or decoders, any of which may be integrated as part of a comodecode encoder / decoder (codec). Thus, each source device 120 and receiver device 160 may include specialized machines designed to carry out one or more of these disclosure techniques.

The display 122 and the display 162 may include any plurality of video output devices such as an electron beam tube (CPT) display, a liquid crystal display (SDL), a plasma display, a light-emitting diode (LED) display, an LED light emitting diode (OIE) display, or another type of display device. In these or other examples, displays 122 and 162 may be emissive displays or permeable displays. Display 122 and display 162 may also be touch screens, so that they simultaneously represent both input devices and display devices. Such touchscreens may be a capacitive, resistive or other type of touch panel that gives the user the opportunity to provide custom inputs to the device.

The speaker 123 may include any plurality of audio output devices such as headphones, a one-speaker system, a multi-speaker system, or a surround sound system. Additionally, although the display 122 and the speaker 123 are shown as part of the source device 120, the display 162 and the speaker 163 is shown as part of the receiver device 160, the source device 120 and the receiver device 160 can in fact be a system of devices. As one example, the display 162 may be a television receiver, the speaker 163 may be a surround sound system, the codec 164 may be part of an external prefix, connected, wired or wireless, to the display 162 and the speaker 163. In other cases, the receiver device 160 may be One device, such as a tablet PC or smartphone. At yet another

4

iA 109928 C2

in other cases, the device-source 120 and device-receiver 160 are similar devices, for example, both are smartphones, tablet PCs, and the like. In this case, one device can work as a source, and the other can operate as a receiver. These roles may even change to the opposite in subsequent communication sessions. In other cases, the source device may include a mobile device, such as a smartphone, portable or tablet computer, and the receiver device may contain a more stationary device (for example, an AC power cord), in which case the source device may deliver audio and video data for mass presentation through the receiver device.

The transmitter unit 126 and the transmitter device 166 may include various mixers, filters, amplifiers, and other components designed to modulate the signals, as well as one or more antennas and other components designed for transmitting and receiving data. The communication channel 150, in general, represents any suitable communication medium or a collection of different communication media for transmitting the video data from the device-source 120 to the receiver device 160. The communication channel 150 is, of course, a channel relative to the near-communications , similar to OTi-Gi, ViEiOiI technology, etc. However, the communication channel 150 is necessarily limited in this respect and may contain any wireless or dial-up communications medium, for example radio frequency (WG) spectrum or one or more physical transmission lines or any combination of wireless and wired environments. In other examples, the communication channel 150 may even be part of a packet switched network, such as a wireless or wireless local area network, a global computer network, or a global network, such as the Internet. Additionally, the communication channel 150 may be used by the source device 120 and the receiver device 160 in order to create a link between equal nodes. Device-source 120 and device-receiver160 can transmit on communication channel 150 using such communication protocol as standard from the family of standards IEEE 802.11. Device-source 120 and device-receiver 160, for example, can exchange data according to the OTi-Gi IZigesi standard, so that the source device 120 and the receiver device 160 exchange data with each other without the use of intermediaries, such as wireless access point or so-called public access point. Device-source 120 and device-receiver 160 can also implement the tunnel-based direct link (TC8) to prevent or reduce network overload. The technologies of this disclosure of nature can sometimes be described in relation to OTi-Gi, but it is assumed that aspects of these technologies can also be compatible with other protocols of communication. As an example and not a limitation, a wireless connection between the source device 120 and the receiving device can use the orthogonal frequency division multiplexing techniques (VoO). Also, a plurality of other wireless communication technologies can be used, including, but not limited to, plural access with time division of channels (TIMA), multiple frequency channel access (THM), multiple access code division channels (ORY), or any combination of THIRD, THORM, THUMB, and / or WOMAN. OTiGi Yuigesi and T0b8 are designed to establish a meeting on the near-communications. A relatively short distance in this context may mean, for example, less than 70 meters, although in a noisy or crowded environment the distance between devices may be even lower, for example, less than 35 meters. bunch A relatively short distance in this context may mean, for example, less than 70 meters, although in a noisy or crowded environment the distance between devices may be even lower, for example, less than 35 meters. bunch A relatively short distance in this context may mean, for example, less than 70 meters, although in a noisy or crowded environment the distance between devices may be even lower, for example, less than 35 meters.

In addition to decoding and rendering data received from the source device 120, the receiver 160 may also receive user inputs from the user input device 167. The user input device 167, for example, may be a keyboard, a mouse, a ball point manipulator or a touch panel, a touch screen, a language command recognition module, or any other such user device. âÀÌÌ 168 formats user input commands taken with the help of the user input device 167 into the data packet structure, the interpretation of which the source-source device 120 permits. Such data packets are transmitted using the transmitter / transmitter 166 to the source device 120 via the communication channel 150. Recorder-transmitter unit 126 receives data packets, and the 125 A / W control module parsingly analyzes the data packets in order to interpret the custom input command received by the user input device 167. Based on the commands received in the data packet, the 125 A / U control module can modify both encoded and transmitted content. Thus, the user of the receiver device 160 can control the work audio data and working video data transmitted using the source device 120 remotely and without direct interaction with the source device 120. The examples of commands that the user of the receiver device 160 can transmit to the source device 120, include commands for accelerated rewind, accelerated Based on the commands received in the data packet, the 125 A / U control module can modify both encoded and transmitted content. Thus, the user of the receiver device 160 can control the work audio data and working video data transmitted using the source device 120 remotely and without direct interaction with the source device 120. The examples of commands that the user of the receiver device 160 can transmit to the source device 120, include commands for accelerated rewind, accelerated Based on the commands received in the data packet, the 125 A / U control module can modify both encoded and transmitted content. Thus, the user of the receiver device 160 can control the work audio data and working video data transmitted using the source device 120 remotely and without direct interaction with the source device 120. The examples of commands that the user of the receiver device 160 can transmit to the source device 120, include commands for accelerated rewind, accelerated

5

iA 109928 C2

rewind, stop, and play audio and video data, as well as commands for zooming, rotation, scrolling, and more. Users can also choose, for example, from the menu items and pass the selection back to the source device 120.

Additionally, users of the receiver 160 may have the ability to run and control applications on the source device 120. For example, the user of the receiver device 160 may have the ability to run an application for editing photos stored in the source 120 and use the application to edit a photo, which is stored locally on the source device 120. The device receiver 160 can provide the user with such features as it seems that the photo is locally edited in the receiver 160, while in fact the photograph is edited on the source device 120. With the use of such a configuration, the user of the device may be able to use the characteristics of one device for use with several devices. For example, the source device 120 may be a smartphone with a large amount of smell ' the device and the high performance characteristics of the processing. The user of the device-source 120 can use the smartphone in all environments and situations where typical smartphones are used. However, while watching a movie, a user may want to watch a movie in a pattern with a large screen, and in this case, the receiver 160 may be a tablet computer or even a larger display device or television receiver. If you wish to send or reply to a message, the user may want to use a keyboard device, in which case the receiver device 160 may be a portable computer. In both cases, the processing volume at the same time can be executed using the device-source 120 (a smartphone in this example), even if the user interacts with the receiver. In this particular context of the operation, in the context of the processing performed by the source device 120, the receiver device 160 may be a less expensive device with less resources than when the device-receiver 110 needs to perform processing performed using the source device 120. As a device Both the source and the receiver device can allow user input (for example, touch screen commands) in some examples, and the technologies of this disclosure can simplify the two-way interaction by matching and / or identyfikatsiyiharakterystyk devices in any given session.

In some configurations, the A / W control module 125 may be an operating system process performed by the operating system of the source device 125. However, in other configurations, the A / U control module 125 may be an application program process that operates on a source device 120 In this configuration, the user input command can be interpreted using the software process, so that the user of the device receiver 160 interacts directly with the application, working on the source device 120, and not with the operating system working on Troy-source 120. Through interaction directly zdodatkom, not running, the user device receiver 160 can have accessto library of commands that are not their own operating system source device 120.Dodatkovo,

The source device 120 may correspond to the user inputs that are used in the wireless receiver device 160. In such an environment of the interactive application, the user input used in the wireless receiver 160 may be sent back to the wireless source of display through the communication channel 150. In one example, the backhaul architecture, also called the "back-end user interface (IIS) channel", can be implemented in order to enable the receiver device 160 to transmit the user inputs used in the receiver 160 to the source device 120 . The back channel architecture may include an upper level message for the transport of user inputs and a lower level frame for matching the user interface characteristics in the receiver device 160 and source device 120. The ipI can be permanently located above the transport layer based on the Internet Protocol (IP) between the device- the receiver 160 and the source device 120. Thus, iiVS may be higher than the transport layer in the communication model based on the open system interaction standard (OZI). In one example, an OI-link includes seven levels (1 physical, 2-channel, 3-intranet, 4-transport, 5-session, 6-presentation and 7-application). In this example, finding a higher transport level means levels 5, 6 and 7. To facilitate reliable transmission and delivery of the sequence of data packets,

6

iA 109928 C2

custom datagram protocol (υΡ). υΡ and TCP can work in parallel with the ΟδΙ-level architecture. The TCP / IP can enable the receiver 160 and the source device 120 to implement retransmission technologies in the event of loss of packets.

In some cases, there may be inconsistencies between the user input interfaces located in the source device I20 and receiver 160. To solve potential problems created by such inconsistency and to facilitate the improvement of the user's work in this case, the coordination of the characteristics of the user interface interface can be between a source device 120, and a receiver 160, to establish a communication session or repeatedly during a communication session. As part of this reconciliation process, the source device 120 and the receiver 160 can negotiate a coherent screen distinction. When the receiver unit 160 transmits coordinate data associated with a user input, the receiver device 160 can scale the coordinate data received from the display 162, so that they coincide with the agreed differentiation of the crane. In one example, if the device receiver 160 has a resolution of 1280x720, and the source device 120 has a resolution of 1600x900, devices, for example, can use 1280x720 as a coherent distinction. A coherent distinction can be chosen based on the distinction between the receiver device 160, although the distinction between source device 120 or some other distinction can also be used. In an example using a 1280x720 receiver, the receiver 160 can scale the received coordinates X to the cofferent 1600/1280 before transmitting the coordinates to the source device 120, and similarly, the receiver unit 160 can scale the obtained Y coordinates to 900/720 before the transfer of coordinates to device-source 120. In other configurations, device-source 120 can scale the received coordinates to a coherent distinction. Zooming can increase or decrease the range of coordinates based on whether the device-receiver 160 displays a higher resolution than the source device 120, or vice versa.

Additionally, in some cases, the distinction in the receiver 160 may vary during the communication session, potentially creating an inconsistency between the display 122 and the display 162. To improve user capabilities and provide proper functionality, the source / receiver system 100 may implement technologies for reducing or preventing inconsistency of user interaction through the implementation of technologies for the normalization of the screen. The display 122 of the source device 120 and the display 162 of the receiver device 160 may have different distinctions and / or different aspect ratios. Additionally, in some environments, the user of the receiver device 160 may have the ability to resize the display windows for video data received from the source device 120 so that the rendering of the video data received from the source device 120 is executed in the window, which does not fully cover the display unit 162 of the receiver 160. In another exemplary environment, the user of the receiver 160 may have a content view option in landscape mode or in book mode, each of which has unique coordinates and different aspect ratios. In such cases, the coordinates associated with the user input received in the receiver unit 160, such as the coordinate of the location where the mouse click or the sensor operation occurs, may not be able to be processed using the source 120, without modifying the coordinates. Accordingly, the technologies of this disclosure essentially may include the transformation of the user input coordinates received in the receiver device 160 into the coordinates associated with the source device 120. This transformation is also referred to as the regularization in this document, and,

Custom inputs taken with the receiver device 160 may be adopted using the i-module 167, for example, at the level of the drivers and transmitted to the operating system of the receiver device 160. The operating system on the receiver device 160 may receive coordinates ^ δΙΝΚ, α51YK), associate with a place on the surface of the display, in which there was a user input. In this example, ^ δΙΝΚ, δINΚ) represent the coordinates of the display 162, in which the event of a mouse click or touch occurred. The display display, whose rendering is performed on display 162, may have a length at coordinate X (WOT) and a width (HOUSE) at coordinate Y, which describe the size of the display window. The window display can also have the coordinate (aUOT, LUOT) of the upper left corner, which describes the location of the display window. Based on I_YUOT, The OUTO and the upper left coordinates (aUOT, LUOT) can be defined part of the display 162 that is covered by the display window. For example, the right upper corner of the display window may be in coordinates (AUOT + WOT, LUOT), the lower left corner of the display window may be in coordinates (aUOT, YOOTO + OTUOT), and the lower right corner of the display window may be in

7

iA 109928 C2

coordinates (AUOT + SHOT, LUOT + OTUOTO). The device receiver 160 can handle the input of an input signal if the input is received in coordinates within the display window. In other words, the input with associated coordinates (χδΙΝΚ, γΒΝΝΚ) can be processed as iiVS-input if the following conditions are satisfied:

aOOT &lt;х5 ^ К &lt;аЮОТ + ШОТ (1)

LUOT &lt;U5 ^ K &lt;LOOT + OTO0OT (2)

After determining that the user input is iiVS-input, the coordinates associated with the input can be normalized by means of ipI-168 before transmitting to device-source 120. Inputs that are defined as being outside the display window can be processed locally for using the device receiver 160 as non-iiVS-input.

As mentioned above, the normalization of input coordinates can be performed either at the base of the source or on the basis of the receiver. With the implementation of the receiver-based normalization, the source device 120 may send a display (SPDV, OT8RS) of the display for the supported display 122, with video data or irrespective of video data, to the receiver device 160. The resolution of the supported display, for example, may be transmitted as part of a session of matching characteristics or may be transmitted at another time during a communication session. Device-receiver 160 can detect the difference φδΙΝΚ, Μ8ΙΝΚ) display for the display162, the distinction (SHOT, OTUOTO) of the display window for displaying the content of the window that is taken from the source device 120, and the coordinate (aUOT, LUOT) of the upper left corner for the display window. As described above, when the coordinate (χδΙΝΚ, y8 ^^,

x8PC = (x81YC-a0OP) * (b8PC / b0OT) (3) y8PC = (y81YK-BYuOT) * (OT8RS / OTO0OT) (4)

Thus, when transmitting a coordinate corresponding to the user input that is received, the receiver device 160 can transmit the coordinate (χδΡ ^ уδΡС) for the user input, which is received in (χδΙΝΚ, δINΚ). As described in more detail below, the coordinate (χδΡ ^ уδΡСС), for example, may be transmitted as part of a data packet that is used to transmit a user input received in the receiver device 160 to the LAN device 120. In all other parts of this disclosure, the essence in which the input co-ordinates are described as included in the data packet, these coordinates can be converted to the source coordinate, as described above in cases where the source / receiver system 100 implements the receiver-based normalization.

When the source / receiver system 100 implements a source-based normalization for user inputs defined by inputs instead of local inputs (that is, within the display window, and not outside the display window), the above calculations can be performed in the source device 120 instead of the receiver device 160. In order to simplify such calculations, the receiver 160 can transmit to the SELECTOR source 120 the values ​​for the SHOT, OTUOT and location information for the display window (for example, aUOT, LUOT), as well as coordinates for (χδΙΝΚ , δINΚ). Using these transmitting values, source device 120 can determine values ​​for (χδΡ ^ уδΡС) in accordance with the above equations 3 and 4.

In other implementations of the normalization based on the receiver, the device-receiver 160 can transmit the coordinates (χώ, uYUOT) for user input, which describes in which places within the window of display there is a custom input event, in contrast to what place on display 162 there is a custom event. introduction. In this implementation, the coordinates (χώ, ωω) can be transmitted to the source device 120 together with the values ​​for (SHOT, OTUOT). Based on these received values, the source-source 120 can determine (χδΡ ^ уδΡС) according to the following transformation functions:

x8PC = x0OT * (b8PC / b0OT) (5) y5PC = yOOT * (OT5RS / OTS&gt; FROM) (6)

The device receiver 160 can define x ^ OT and uYOTOT based on the following functions: xOOT = x81YIK-aYuOT (7) yUOOT = u81YK-bOOT (8)

When this disclosure essentially describes the transmission coordinates associated with the user input in the data packet, for example, the transmission of these coordinates may include sinkormalization on a source or receiver basis as described above and / or may include

8

iA 109928 C2

in itself any additional information necessary to perform normalization on the basis of the source or on the basis of the receiver.

ИИВС can be designed with the ability to transport different types of data of user input, which include cross-platform data user-driven input. For example, the source device 120 may operate under the operating system of the iOZ®, while the receiver 160 operates under the control of another operating system such as Apbogio® or OTipBase®. Regardless of the platform, the iRi 168 can encapsulate the user input that is received in a form that is understandable for the 125A / ν control module. A number of different types of custom input formats can be supported with iIOS, in order to allow the plurality of different types of source devices and receivers to use the protocol, regardless of whether the source and receiver devices work on different platforms. Multipurpose input formats can be specified,

In the example of FIG. 1A, the source device 120 may comprise a smartphone, a tablet computer, a laptop, a desktop computer, an OTiRi-enabled television receiver, or any other device capable of transmitting audio and video data. The device receiver160 can also contain a smartphone, tablet PC, laptop, desktop computer, OTi-G TV receiver or any other device that allows reception of audio and video data and receive user-entered data. In some cases, the receiver device 160 may include a system of devices, so that the display 162, the speaker 163, the i-device 167 and the Α / ν-encoder 164 are parts of the individual but interacting devices. Device-source 120 can similarly be a system of devices, and not one device.

In this disclosure, the term "source device" in general is used as meaning that a device that transmits audio-video data is used, and the term "receiver-device" is generally used as being a device that receives audio-video data from the source device. In many cases, device-source 120 and device-receiver 160 can be analogous or identical devices, with the fact that one device works as a source, and the other works as a receiver. In addition, these roles may vary in the opposite in different sessions of communication. Thus, the receiver device in one communication session may become a source device in a subsequent communication session or vice versa.

FIG. 1B is a block diagram illustrating exemplary source / receiver system 101 that can implement the technologies of this disclosure. The source / receiver system 101 includes a device-source 120 and a receiver device 160, each of which can operate and operate with the means described above for FIG. 1A. The source / receiver system 101 additionally includes the receiver 180. Like the receiver device 160 described above, the receiver 180 can receive audio and video data from the source device 120 and transmit the user command to the source device 120 via the set input device. In some configurations, the receiver device 160 and the receiver 180 can operate independently of each other, and output audio and video data in the source device 120 can simultaneously be output in the receiver device 160 and receiver devices 180. In alternative configurations, the receiver device 160 may be a primary receiver, and the receiver 180 may be a secondary receiver. In such an exemplary configuration, the receiver device 160 and the receiver 180 can be connected, and the receiver unit 160 can display video data, while the receiver 180 outputs the corresponding audio data. Additionally, in some configurations, the receiver unit 160 can output only transmitted video data, while the receiver device 180 outputs only audio data transmitted.

FIG. 2 is a block diagram illustrating one example of a source device 220. The source device 220 can be a device similar to the source device 120 of FIG. 1A, and may work identically to the source device 120. The source 220 includes a local display 222, a loudspeaker 223, processors 231, a storage device 232, a transport unit 333, and a wireless modem 234. As shown in FIG. 2, the source device 220 may include one or more processors (i.e. processor 231) encoding and / or decoding A / V-data for transport, storage and display. The Α / ν data, for example, may be stored in memory device 232. The memory 232 can store the entire Α / ν-file or may contain a smaller buffer that simply stores the part of the Α / ν file, for example, which is transmitted by the stream from other device or source. The transport unit 233 can handle the coded A / V data for network transport. For example, coded Α / ν-data can

9

iA 109928 C2

processed using processor 231 and encapsulated by means of transport block 233 in the network access level unit (NID) for communication over the network. One-to-one can be sent by wireless modem 234 to a wireless device-receiver via a network connection. A wireless modem 234, for example, may be a Wi-Fi modem, executed with the ability to implement one of the family of standards IEEE 802.11.

The source device 220 can also process and display Α / ν data locally. In particular, the display processor 235 can process the video data that should be displayed on the landing display 222, the audio processor 236 can handle audio data for output on dynamics 223.

As described above with respect to the source device 120 of FIG. 1A, the source device 220 may also receive user input commands from the receiver device. Thus, the wireless modem 234 of the source device 220 receives the encapsulated data packets, for example, the NIA-unit and sends the encapsulated data units to the transport unit 233 for decapsulation. For example, the transport unit 233 may take data packets from the NIAI units, and the processor 231 can syntactically analyze the data packets in order to extract the user input commands. Based on user input commands, the processor 231 can control the encoded Α / ν data transmitted using the source device 220 in the receiver device. Thus, the functionality described above with respect to the A / V control module 125 of FIG. 1A may be implemented, either in whole or in part,

Processor 231 of FIG. 2, in general, represents any of a plurality of processors that include, but only one or more digital signal processors (δδ), general-purpose microprocessors, specialized integrated circuits (ASIS), user-programmed gate arrays (ERCAs), and other equivalent integrated or discrete logic circuits or some combination of the above. The memorizing device 232 of FIG. 2 may include any of a plurality of energy-dependent or non-energy-dependent storage devices, including, but not limited to, an operational storage device (RAM), for example, a synchronous dynamic operational memory (ZYURAM), a permanent storage device (ROM), non-volatile operational storage device (NVRAM), electrically erased programmed memory (EERRO), flash memory, etc. The memory device 232 may include a machine readable storage medium for preserving audio video data as well as other types of data. The memory device 232 can optionally store instructions and code that are executed using the processor231 as part of the implementation of the various technologies described in this disclosure.

FIG. 3 shows an example of the receiver 360. The device receiver 360 may be a device similar to the receiver device 160 in FIG. 1A and may operate identically to the receiver device 160. The device receiver 360 includes one or more processors (i.e., processor 331), a storage device 332, a transport unit 333, a wireless modem 334, a display processor 335, a local display 362, an audio processor 336, speaker 363, and custom input interface 376. The device-receiver 360 receives in the wireless modem 334 encapsulated units of data sent from the source device. A wireless modem334, for example, may be a N-and-E-modem, executed with the ability to implement one or more standards from the family of standards IEEE 802.11. The transport unit 333 may encapsulate the encapsulated units of data. Example, the transport unit 333 may extract the encoded video data from the encapsulated data units and send the encoded Α / ν-dan processor 331 for decoding and executing the rendering for output. The display processor 335 can process the decoded video data that should be displayed on the local display 362, and the audio processor 336 can process the decoded audio data for output on dynamics 363.

In addition to rendering audio and video data, the wireless device receiver 360 may also receive user input data via the user input interface 376. The user input interface 376 can represent any number of user input devices, including, but not limited to, a touch screen interface, a keyboard , a mouse, a language command module, a gesture capture device (for example, with camera-based input capture characteristics), or any other device user tskoho input. The custom input received from the user input interface 376 can be processed using a processor 331. This processing may include the formation of data packets that include a user input command that is received in accordance with the technologies described herein.

10

iA 109928 C2

disclosure of the essence. After the formation, the transport unit 333 can process data packets fornetransportation into a wireless device-source by iiVS.

Processor 331 of FIG. 3 may include one or more of a wide range of processors, such as one or more digital signal processors (δδ), general purpose microprocessors, specialized integrated circuits (A5IS), user programmable matrices (ERCAs), other equivalent integrated or discrete logic circuits, and some combination of the above . Recording device 332 of FIG. 3 may include any of a plurality of energy-dependent or non-volatile storage devices including, but not limited to, an operational storage device (RAM), for example, a synchronous dynamic memory storage device (50RAM), a permanent memory device ( ROM), non-volatile operational storage device (ΝνΡΑΜ), electrically erased programmable constant memory ' battery (EERRO), flash memory, etc. The memory device 232 may comprise a machine-readable storage medium for storing audio data as well as other types of data. The memory 332 can further store instructions and code that are executed using processor 331 as part of the execution of various technologies described in this disclosure of the essence .

FIG. 4 shows a block diagram of a exemplary transmitting system 410 and a receiving device system 450 that can be used with the transmitter and transceiver 126 and the transmitter / transmitter 166 of FIG. 1A for data exchange on the communication channel 150. In the transmitter system 410, data traffic for data stream streams is provided from a data source 412 to a data transfer processor (TX) 414. Each data stream can be transmitted over a corresponding transmit antenna. The 414TX data processor format, encode, and interleave traffic data for each data stream based on the specific encoding scheme selected for this data stream.

Coded data for each data stream can be multiplexed with pilot data using multiplexing techniques with orthogonal frequency division of the moon (OEM). Also, a plurality of other wireless communication technologies may be used, including, but not limited to, multiple channel time-division access (TOM), multiple-frequency channel access (EMA), multiple-access, code-split (COMA), or any combination of OEM, EMA, TOMA and / or SOMA.

According to FIG. 4, pilot data is typically a known data template that is processed by a known means and can be used in the receiving device system in order to evaluate the channel trick. Multiplexed pilot signal and coded data for each data stream are then modulated (for example, symbolically converted) based on a specific schema modulation (eg, two-position phase manipulation (BP5K), quadrature phase manipulation (OR5K), M-R5K or M-OAM (quadrature amplitude modulation), where M may be a two step) selected for this data stream to provide modulation symbols. The speed of data transmission, coding and modulation for each data stream can be determined by using instructions executed using a processor 430 that can be connected to a memory device 432.

Modulation symbols for all data streams are then provided in the TX MIMO processor 420, which can additionally handle modulation symbols (for example, for OEM). The THM MIMO processor can provide N_τ flows of symbols of modulation into N_τ transmitting devices (TMTP) 422a-4221. In certain aspects, the TX MIMO-processor 420 applies weighting factors for the formation of the directional diode to the data stream symbols and to the antenna from which the symbol is transmitted.

Each transmitter 422 can receive and process corresponding postings to provide one or more analog signals and additionally results in the necessary parameters (for example, amplifies, filters and converts at a frequency) analog signals to provide a modulated signal suitable for transmission over the MIMO- the channel. Ν_τ Modulated signals from transmission units 422a-4221 are then transmitted from N_τantennas 424a-4241, respectively.

In the system 450 of the receiving device, the modulated transmitted signals are received with N_ρ antennas 452a-452g, and the received signal from each antenna 452 is provided to the appropriate receiving device (P ^ P) 454a-454g. Receiving device 454 leads to the necessary parameters (for example, filters, amplifies and reduces frequency), the received signal digitizes the parameters necessary for the signal to provide sampling, and further processes the sampling to provide the corresponding "accepted" postmixings.

11

iA 109928 C2

The receiving data processor 460 then receives and processes N_π flows of symbols taken from N_π receiving devices 454 based on a specific processing technique of the receiving device to provide N_τ "Detected" thread streams. The 460 KH processor then demodulates, reverse, and decode each detected post-code to restore traffic data to the data stream. Processing by the processor460 of the PC data is complementary processing performed by the TX MIMO processor 420 and the TX data processor 414 in the transmitter system 410.

The processor 470, which can be connected to the storage device 472, periodically determines which pre-coding matrix is ​​to be used. A backlink telegram may contain various types of information relating to the communication line and / or the received data stream. The backlink message is then processed using the TX data processor 438, which also receives traffic data for a predetermined number of data streams from the data source 436, is modulated using a modulator 480, is given to the necessary parameters by transmitting devices 454a-454g and transmitted back to system 410 transmitting device.

In the transmitter system 410, the modulated signals from the receiver device system 450 are received using antennas 424, are brought to the required parameters by means of receiving devices 422, demodulated using a demodulator 440, and processed by the CPU 442 of the KH data to extract the message back to the transmission line using the receiver system 450. Processor 430 then determines which matrix of the previous coding to use to determine the weighting coefficients of the formation of the directional diagram, and then processes the elongated message.

FIG. 5A is a block diagram illustrating an exemplary sequence of messages transmitted between the device 520 and the receiver 560 as part of the matching session of the character set. Harmonization of characteristics can be performed as part of a larger process of establishing a communication session between the source device 520 and the receiver 560. This session, for example, can be set using the OTiRi Yuigesi or Tujda as the basicstandard of connection. After setting the OTiRi YUIGIOS or TOZ session, the receiver 560 can initiate a TCP connection with the source device 520. As part of the TCP connection setup, the real-time streaming control (PTT) control port (PT5P) can be set to control the communication session between the source device 520 and the receiver 560.

The source device 520 may generally work in the manner described above for the source device 120 of FIG. 1A, and the receiver device 560 may generally work in the manner described above for the receiver device 160 of FIG. 1A. After the device-source 520 and device-receiver 560 establish a connection, the source-device 520 and the receiver-receiver 560 may define a set of parameters that should be used for the subsequent communication session, as part of the exchange of data from the harmonization of characteristics.

Device-source 520 and device-receiver 560 can match the characteristics through the sequence of messages. Messages, for example, may be messages in the real-time streaming protocol (PTT5). At any stage of the agreement, the recipient of the message with the PT-5P request may correspond to the PT-5R-response, which includes a PTC-state code other than PT-5P OK, in which case the message exchange maybe repetitive with another set of parameters, or the matching session maybe completed.

The source device 520 may send a first message (a message requesting PT5R ORTIONNδ) to the receiver 560 to determine a set of PTT methods that the device receiver 560 supports. When receiving the first message from the source device 520, the receiver device 560 may correspond to a second message (a message with the response PT5R ORTION5) that lists the Pt5P methods supported by the receiver560. The second message may also include the status code PT5P OK.

After sending the second message to the source device 520, the receiver 560 can send a third message (a message requesting PT5R ORTION5) to determine the selection of PTT methods that support the source device 520. When receiving the third message from the receiver unit 560, the source device 520 may correspond to the fourth message (a message with the response PT5R ORTION5) that lists the PTLP methods supported by the source device 520. The fourth message may also include a PTTL status code OK.

12

iA 109928 C2

After sending the fourth message, the source device 520 may send a fifth message (a message requesting PT5P SET_RAMAMETER) to indicate a list of characteristics that are of interest to the source device 520. The device receiver 560 may correspond to the sixth message (a message with the response RT5RCET_RAMAMETER). The sixth message may contain the PT5R status code. If the PT5R-OK state code, then the sixth message may also include the response parameters for the parameter specified in the fifth message that is supported by the receiver device 560. The device receiver 560 may ignore those parameters in the fifth message which receiver 560 does not support.

Based on the sixth message, the source 520 may determine an optimal set of parameters to be used for the communication session and may send a seventh message (a message requesting PT5P 5ET_RAMETER) to the receiver device 560. The seventh message may include a set of parameters to be used in the time of communication between the source device 520 and the receiver 560. The seventh message may include a myrib-rgezepialio-igi that describes the universal resource identifier (IRI) that should be used request to establish RT5R to vstanovlyuvatyseans connection. # 1b-rgezep1a1iop-иг1 indicates the IR, which device receiver 560 can use for further messages during the exchange of messages to set up a session. The values ​​of the myBIU and the myB iGy, which are specified in this parameter, may correspond to the values ​​of the Horn-Rohr and the mountain rug in the May-Sieep-Giron-Rogis in the seventh message. RTR in this case, in general, means a real-time protocol that can work on top of the device.

When receiving the seventh message, the receiver 560 can match the eighth message with the status code RT5R, indicating whether the task has been completed or failed successfully, as indicated in the seventh message. As mentioned above, the role of the source device and the receiver device may vary in reverse or vary in different sessions. The order of messages that establish a communication session, in some cases, can specify a device that works as a source, and set the device that works as a receiver.

FIG. 5B is a block diagram illustrating another example between the message transmission sequence of the device-source 560 and the receiver 520 as part of the session of coordination of the characteristics. The sequence of message transmissions according to FIG. 5B is intended to provide a more detailed view of the sequence of transmission described above for FIG. 5A. In FIG. 5B, the message "1b. SET-RARAMETER REVIEW 5E "displays an example message that identifies the supported list of input categories (for example, universal and NUUs) with a subset of the supported input type lists. Each of the supported input categories in the list of supported input categories has an associated list of supported types, (e.g., depegis_sar_i5i and iibs_sar_ii5i). In FIG. 5B, message "2a. 5ET_RARAMETERREOIEZT "is an example of a second message, which identifies the second list of input categories (for example, universal and NUS), supported, and a set of other lists of supported types. Each of the supported input categories from the second list of supportedcategories of input has an associated second type list (for example, depegis_sar_i5 and iibs_sar_ii5i) supported. Message "1b. SET RARAMETER REVIEW 5E "identifies the input categories and input types supported by the receiver device 560. Message" 2a. 5ET_RAMMETER ReOiEZt "identifies the typewriter and input types supported by the source device 520, but it may not be a comprehensive list of all input categories and input types supported by the source device 520. Instead, the message" 2a. 5ET_MAARIMETERREOYEZT "can only identify the input categories and types of input identified in the message" 1b. SET-RARAMETER REVIEW 5E "as being supported by the device-receiver 560. Thus, the input categories and types of input identified in the message" 2a. 5ET_RARAMETER REOiEZT ", can be a subset of input categories and input types identified in the message" 1b. SETRARAMETER REVIEW 5E ».

FIG. 6 is a conceptual diagram illustrating one example of a data packet, which can beformed with the receiver device and transmitted to the source device. Aspect packet 600 data is explained with reference to FIG. 1A, but the explained technologies may be applicable to additional types of source / receiver systems. Data packet 600 may include a data packet header 610, followed by work data 650. The work data 650 may additionally include one or more work data headers (e.g., work data header 630). The data packet 600, for example, may be transmitted from the receiver 160 to the device. 1A to the source device 120 so that the user of the receiver device 160 can control the audio video data transmitted using the source device 120. In this case,

13

iA 109928 C2

the working data 650 may include user input data received in the receiver device 160. The work data 650, for example, can identify one or more user commands. The receiver device 160 may receive one or more user commands and may, based on received instructions, form the data packet header 610 and data processing 650. Based on the content of the data packet header 610 for the data packet 600, the source device 120 can syntax the data 650 to identify the user input data received in the receiver device 160. Based on the user input data contained in the data processing 650, the source device 120 may modify some of the audio and video data transmitted from the device -sources 120 to the receiver unit 160.

When used in this disclosure of the essence, the terms "syntactically analyze" and "syntactic analysis" generally mean the process of analyzing the stream of bits to extract data from the stream of bits. After extraction, the data can be processed, for example, with the device-source 120. Exhaust data, for example, may include an identification of how formatted information in the stream of bits. As described in more detail below, the data packet header 610 may provide a standardized format known to both the source device 120 and the device receiver 160. However, work data 650 may be formatted as one of a plurality of possible methods. With the parsing analysis of the data packet header 610, the source device 120 can determine how the working data 650 is formatted, and thus, the source device 120 can syntactically analyze the data 650, to extract one or more custom input commands from work data650. This allows for flexibility from the perspective of different types of working data that can be supported by the source / receiver communication. As detailed below, the 650 working data can also include one or more job data headers, for example, the header 630 of working data. In such cases, the source device 120 can syntactically analyze the data packet header 610 in order to define the format for the job data header 630 and then syntactically analyze the job data header 630 in order to determine the format for the remaining 650 work data. As described in more detail below, the working data 650 may also include one or more job data headers, e.g., a work data header 630. In such cases, the source device 120 can syntactically analyze the data packet header 610 in order to define the format for the job data header 630 and then syntactically analyze the job data header 630 in order to determine the format for the remaining 650 work data. As described in more detail below, the working data 650 may also include one or more job data headers, e.g., a work data header 630. In such cases, the source device 120 can syntactically analyze the data packet header 610 in order to define the format for the job data header 630 and then syntactically analyze the job data header 630 in order to determine the format for the remaining 650 work data.

Scheme 620 is a conceptual illustration of how a data packet header 610 can be formatted. Numbers 0-15 in line 615 are intended to identify the location of bits in the data packet header 610 and are not intended to actually represent the information contained in the data packet header 610. The packet header 610 includes a field 621 version, a time stamp flag 622, a reserved field 623, an input category 624, a length field 625, and an optional time stamp field 626.

In the example of FIG. 6, the 621 version of the version is a 3-bit field that may indicate the version of the specific communication protocol implemented by the receiver device 160. The value in the field 621 of the version can tell the source device 120 how to syntactively analyze the remainder of the data packet header 610, as well as how to syntactically analyze working data 650. In the example of FIG. 6, field 621 version is a trivial field, which should provide a unique identifier for eight different versions. In other examples, the larger or smaller number of bits may be allocated to field 621 version.

In the example of FIG. 6, timestamp flag 622 (T) is a 1-bit field indicating that there is no timestamp field 626 in the data packet header 610. The time stamp field 626 is a 16-bit field containing a timestamp based on multimedia data generated using the device-source 120 and transmitted to the device receiver 160. The timestamp, for example, may be a sequential value assigned to video frames using the device- the source 120 to transmit frames to the receiver device 160. The timestamp flag 622, for example, may include a "1" to indicate that the timestamp field 626 is present and may include "0" to indicate that the field 626 Time stamp is not present. When parsing the header 610 of the data packet and determining that the timestamp field 626 is present, the source device 120 can process a timestamp, included in timestamp field 626. In the parsing analysis of the data packet header 610 and determining that the timestamp field 626 is not present, the source device 120 may start a parsing analysis of the data 650 after the parsing of the 625 length field, since the time tag field is not present in the data packet header 610.

If present, the timestamp field 626 may include a timestamp to identify the frame of the video data displayed on the wireless receiver device 160 when the user input data for the working data 650 is received. The timestamp may, for example, be added to the video frame using the device. -sources 120 to transmitting a device-source 120 video to a device-receiver 160. Accordingly, the source device 120 can form a video frame and embed video in the frame as metadata, for example, a timestamp. Device-source 120 can transmit from eocadrome with timestamp in device-receiver 160, and

14

iA 109928 C2

the receiver unit 160 may display a video frame. Although the video frame is displayed with the aid of the receiver device 160, the receiver unit 160 may receive a custom command from a user. When the receiver unit 160 forms a data packet in order to transmit a custom command to the source device 120, the receiver 160 may include in the timestamp field 626 a timestamp of the frame that is displayed with the device receiver 160 when the user command is received.

When receiving the data packet 600 with the time stamp field 626 present in the header, the wireless source source 120 may identify the video frame displayed in the device receiver 160 at the time when the user input data of the working data 650 is received and to process user-input data based on content of a frame identified by a time stamp. For example, if user-input data is provided by the touch-sensitive command applied to the touch screen or by pressing the pointer, the source device 120 can determine the frame content that is displayed when the user applies the touch command to the display or clicks with the mouse. In some cases, the frame content may be necessary in order to properly process the working data. For example, user input based on user touches or mouse clicks may depend on what is shown on the display when tapping or tapping. Tapping or pressing may correspond, for example, to a badge or a menu item. In cases where the content display changes, the timestamp present in the timestamp field 626 may be used by the source device 120 to match the touch or cursor with the correct icon or menu item.

The source device 120 may, in addition or alternatively, compare the timestamp in the timestamp field field626 with the timestamp applied to the current video frame that is prepared using rendering. By comparing the timestamp from the field of the 626 hour label with the current timestamp device-source 120 can determine the transmission time and acceptance confirmation. The transmission time and acknowledgment of reception generally corresponds to the amount of time that passes from the moment when the frame is transmitted using the source device 120, when the user input on the basis of this frame is taken backward in the source device 120 from the receiver device 160. The transmission time and acknowledgment of receipt can provide device-source 120 indicator of system time delay, and if the transmission time and confirmation of reception exceeds the threshold value, the source device 120 may ignore the user input data contained in the job data 650 according to the assumption that the input command is applied to an irrelevant frame to be displayed. When the transmission time and acknowledgment reception are lower than the threshold value, the source device 120 can process user input data and adjust the audio-video content transmitted in response to user input data. Thresholds can be programmed, and different types of devices (or different combinations of sources / receivers) may be performed with the ability to set different thresholds for transmission times and confirmation of reception, which are acceptable. When the transmission time and acknowledgment reception are lower than the threshold, the source device 120 can process user input data and adjust the audio-video content transmitted in response to user input data. Thresholds can be programmed, and different types of devices (or different combinations of sources / receivers) may be performed with the ability to set different thresholds for transmission times and confirmation of reception, which are acceptable. When the transmission time and acknowledgment reception are lower than the threshold, the source device 120 can process user input data and adjust the audio-video content transmitted in response to user input data. Thresholds can be programmed, and different types of devices (or different combinations of sources / receivers) may be performed with the ability to set different thresholds for transmission times and confirmation of reception, which are acceptable.

In the example of FIG. 6, the reserved field 623 is an 8-bit field, which does not include the information used by source 120 when parsing the header 610 of the data packet and working data 650. However, future versions of a specific protocol (identified in the field 621 version) may use a reserved field 623, and in this case, the source device 120 may use the information in the reserved field 623 for the parsing analysis of the data packet header 610 and / or for the syntactic analysis of the work data 650. The reserved field 623 in conjunction with field 621 version potentially provides the opportunity to expand and add features to the format of data packets without fundamental changes to the already used format and features.

In the example of FIG. 6, the input category 624 is a 4-bit field in order to identify the input category for the user input data contained in the working data 650. The device receiver 160 can classify the user input data to determine the input category. Categorization of user input data, for example, may be based on the device from which the command is taken, or based on the properties of the team itself. The input category field 624, possibly combined with another data packet header information 610, identifies for the source device 120 how the working data 650 is formatted. Based on this formatting, the source device 120 can in-parsed the working data 650 to determine the user input that adopted in receiver devices 160.

Since the input category 624, in the example of FIG. 6, is 4 bits, sixteen different types of input may possibly be identified. One such category of input can

15

iA 109928 C2

to be a universal input format to indicate that the user input data work data 650 is formatted using the universal information items specified in the protocol, which is executed using both the source device 120 and the receiver device 160. The universal input format, as described in more detail below, may use the universal information elements that enable the user device-receiver 160 to interact with the device-source 120 at the application level.

Another such input category may be a Human Machine Interface Device (NIUS) command format to indicate that the user input data for work data 650 is formatted based on the type of input device used to receive the input data. Examples of device types include a keyboard, a mouse, a touch sensor device, a joystick, a camera, a gesture capture device (for example, an input device on the basis of the camera), and a remote control. Other types of input categories that may be identified in the input category field 624 include an input format that is redirected to indicate that the user data in the data processing data 650 is not output to the specific receiver 160 or the operating system format, and the formatting command to indicate what

The field 625 of length can contain a 16-bit field to indicate the length of the data packet 600. The length, for example, may be specified in units of 8 bits. Since the data packet 600 is parsed by source-device 120 in words of 16 bits, the data package 600 can be supplemented by an integer of 16 bits. Based on the length contained in the length field 625, the source device 120 can identify the end of the working data 650 (i.e., the end of the data packet 600) and the start of a new, subsequent data packet.

The different sizes of the fields provided in the example of FIG. 6, intended simply for explanation, implying that the fields can be implemented using other distinct numbers of bits in comparison with those shown in FIG. 6. Additionally, it is also assumed that the data packet header 610 may not include all the fields explained above, or may use additional fields not explained above. In fact, the technologies of this disclosure can be essentially flexible in terms of the actual format used for different fields of data packets.

After parsing the data packet header 610 in order to determine the formatting of the working data 650, the source device 120 can syntactically analyze the working data 650 in order to determine the user input command contained in the work data 650. The work data 650 may have its own work data header ( the header 630 of work data) indicating the content of the working data 650. Thus, the source device 120 can syntactically analyze the header 630 of the working data based on the parsing analysis of the data packet header 610, and then the syntax to analyze the remaining 650 working data, based on parsing the 630 header data.

If, for example, the input category 624 of the data packet header 610 indicates that the universal input is present in the working data 650, then the data 650 may have a format for universal input. Thus, the source device 120 can syntactically analyze the data 650 according to the universal input format. As part of the universal input format, the working data 650 may include a sequence of one or more input events, with each input event having its own entry of the event header. The table 1 below identifies the fields that can be included in the header of the input.

Table 1

<tr><td><p>Field</p></td><td><p>Size (octet)</p></td><td><p>Value</p></td></tr><tr><td><p>Universal ID</p><p>IE</p></td><td><p>1</p></td><td><p>See table 2</p></td></tr><tr><td><p>Length</p></td><td><p>2</p></td><td><p>The length of the following fields in octets</p></td></tr><tr><td><p>Description</p></td><td><p>Variable</p></td><td><p>Details of user introduction. tables</p></td></tr>

The ID field (Y) universal input (IE) identifies the identification data of the universal input events to identify the type of input. The field of the identifier of the universal IE, for example, may have a length of one octet and may include the identification data selected from the table 2 below. If, like this example, the field of the Universal ID identifier is 8 bits, then 256 different types of entries (identified by 0-255) can be identified, although not all 256 identifiers

16

iA 109928 C2

an associate type of input is required. Some of the 256 may be reserved for future use with future versions of any protocol that is implemented with the help of the receiver device 160 and the source device 120. In Table 2, for example, universal IE identifiers 9-255 do not have associated typing types, but they can

5 types of impose in the future.

The length field in the entry event header identifies the length of the description field, while the field

The description includes information elements that describe the user input. The formatting of the description field may depend on the type of input identified in the universal IDE. Thus, the source device 120 can be syntactically

10 analyze the content of the description field based on the type of input identified in the Universal ID identifier. Based on the length field of the input event header, device-source 120 can determine the end of one input event in the working data 650 and the beginning of a new input event. As explained in more detail below, one custom command may be described in work data 650 as one or more input events.

15 Table 2 provides an example of input types, each of which has a corresponding identifier

a universal IE that can be used to identify the type of input.

Table 2

<tr><td><p>Universal Identifier ID</p></td><td><p>Type of input</p></td></tr><tr><td><p>0</p></td><td><p>Left click / touch and hold</p></td></tr><tr><td><p>1</p></td><td><p>Release the left mouse button / tap and release</p></td></tr><tr><td><p>2</p></td><td><p>Move the mouse / touch with the move</p></td></tr><tr><td><p>3</p></td><td><p>Key press</p></td></tr><tr><td><p>4</p></td><td><p>Releasing the key</p></td></tr><tr><td><p>5</p></td><td><p>Changing the scale</p></td></tr><tr><td><p>6</p></td><td><p>Vertical scrolling</p></td></tr><tr><td><p>7</p></td><td><p>Horizontal scrolling</p></td></tr><tr><td><p>8</p></td><td><p>Turn</p></td></tr><tr><td><p>9-255</p></td><td><p>Reserved</p></td></tr>

Description fields associated with each input type may have a different format. Description Fields 20 Left Click / Left Click / Left Click Events, Left Button Events / Tapping and Release Events, and Mouse / Touch Move Events, for example, may include the information items identified in the following table 3,

although other formats can also be used in other examples.

Table 3

<tr><td><p>Field</p></td><td><p>Size</p><p>(octet)</p></td><td><p>Notes</p></td></tr><tr><td><p>Numeric</p><p>pointers (N)</p></td><td><p>1</p></td><td><p>The number of pointers of the multisensory input event. When equal to 1, this indicates the event of the traditional touch input.</p></td></tr><tr><td><p>For t = 1: N {</p></td><td><p></p></td><td><p></p></td></tr><tr><td><p>Id</p><p>pointer</p></td><td><p>1</p></td><td><p>Identification number of this pointer. The value is in [0, 1,. ..]</p></td></tr><tr><td><p>Coordinate X</p></td><td><p>2</p></td><td><p>Coordinate X for the event is normalized with respect to the agreed definition of the video stream between the receiving device and the source device.</p></td></tr><tr><td><p>Coordinate Y</p></td><td><p>2</p></td><td><p>The coordinate Υ for the event is normalized with respect to the agreed separation of the video stream between the receiving device and the source device.</p></td></tr>

25

The number of pointers can identify the number of touches or mouse clicks associated with the input. Each pointer may have a unique pointer identifier. If, for example, the multisensitive input event involves touching three fingers, then the event can have three pointers, each of which has a unique pointer identifier.

17

iA 109928 C2

Each index (that is, every finger touch) may have the corresponding X coordinate and the coordinate Y, corresponding to the point in which the contact occurred.

One custom command can be described as a sequence of input events. For example, if holding a three-fingered command is a command to close an application,

5 is holding three fingers can be described as operational data 650 as a touch event iutrymannya three pointers, touch events with a displacement of three pointers and podiyitorkannya and releasing three pointers. The three pointers of the touch and hold events may have identical pointers identifiers as three pointers of the touch event with the movement and the touch and release event. Device-source 120 can interpret a combination of these three

10 input events as holding with three fingers.

For example, a description of the events of a key press or key release event is possible

Include the information elements identified in the table below 4.

Table 4

<tr><td><p>Field</p></td><td><p>Size</p><p>(octet)</p></td><td><p>Notes</p></td></tr><tr><td><p>Reserved</p></td><td><p>1</p></td><td><p>Reserved</p></td></tr><tr><td><p>Key Code 1 (AZSII)</p></td><td><p>2</p></td><td><p>Key Code for the first push or release key. The base / extended ΑδΟΙΙ-code uses a younger one byte. The older one byte is reserved for the future AFID-compatible key code.</p></td></tr><tr><td><p>Code Key 2 (AZCII)</p></td><td><p>2</p></td><td><p>Key Code for the second push or release key event. The Basic / Extended ΑδΟΙΙ-code uses a younger one byte. The older one byte is reserved for the future AFID-compatible key code.</p></td></tr>

15 The scale change event description field, for example, may include information items,

identified in the following table 5.

Table 5

<tr><td><p>Field</p></td><td><p>Size</p><p>(octet)</p></td><td><p>Notes</p></td></tr><tr><td><p>X</p></td><td><p>2</p></td><td><p>The reference coordinate X for the zoom operation is normalized with respect to the agreed definition of the video stream between the receiver and the source device.</p></td></tr><tr><td><p>Υ</p></td><td><p>2</p></td><td><p>The reference coordinate Υ for the scale-shift operation is normalized with respect to the coherent distinction between the video stream and the device-receiver and source device.</p></td></tr><tr><td><p>The whole part of the changeable scale of the scale</p></td><td><p>1</p></td><td><p>Part of the whole number without a zigzag coefficient sign</p></td></tr><tr><td><p>Fractional part of the changeable scale</p></td><td><p>1</p></td><td><p>Fractional part of the scale factor</p></td></tr>

For example, a description of a horizontal scroll event or vertical scrolling event, for example, may include the information elements identified in the following

table 6

Table 6

<tr><td><p>Field</p></td><td><p>Size</p><p>(octet)</p></td><td><p>Notes</p></td></tr><tr><td><p>Size</p><p>scrolling</p></td><td><p>2</p></td><td><p>The number of pixels for scrolling is normalized relative to the agreed separation of the video stream between the receiving device and the source device. A negative number may indicate scrolling to the right, and a positive number may indicate scrolling to the left</p></td></tr>

18

iA 109928 C2

The examples above show some exemplary methods that can be formatted work data for the category of universal input. If the input data field 624 of the data packet header 610 indicates a different input category, for example, a pre-assigned user input, then the data 650 may have a different input format. With the redirected user input, the receiver 160 may receive data from the user's input from a third party device and direct the input data to the source device 120 without the interpretation of the user input data. Thus, the source device 120 can syntactically analyze the data 650 according to the user input format that is redirected. For example, the header 630 of working data for working data 650 may include a field to identify a third-party device, from which the received user input. The field, for example, may include an address by the third-party device's Internet Protocol (IP), an MAC address, a domain name, or some other such identifier. The source-120 device can syntactically analyze the remainder of the work data based on the third-party device identifier.

The device receiver 160 can match characteristics with a third-party device through a sequence of messages. The receiver 160 can then transmit the unique identifier of the third party device to the source device 120 as part of the session setup with the source device 120 as part of the matching process. Alternatively, the receiver unit 160 can transmit information describing a third device to a source device 120, and based on information, device-source 120 can determine the unique identifier for a third-party device. Information that describes a third-party device, for example, may include information for identifying a third-party device and / or information in order to identify third-party device features. Regardless of how

If the input category 624 of the data entry header 610 indicates another category of input, such as a speech command, then the data input 650 may have one more input format. For the language command, the data processing data 650 may include coded audio. A codec for encoding and decoding audio from a speech command can be arranged between the device 120 and the receiver 160 via a message sequence. For transmissions of the language command field 626 timestamp may include the meaning of the timing of the speech sampling. In this case, the timestamp flag 622 may be set so that it specifies that the timestamp is present, but instead of the timestamp, as described above, the timestamp field 626 may include the meaning of the language discretization time for coded audio work data 650.

In some examples, the language command can be transmitted as a universal command, as described above, and in this case, the input category 624 can be set so that it identifies the format of universal commands, and one of the reserved identifiers of the universal IE can be assigned to speech commands. If the language command is transmitted to a universal command, the sampling frequency of the speech may be present in the field 626 of the time label of the data packet header 610, or may be present in the working data 650.

For captured data of language commands, language data can be encapsulated in several ways. For example, the language command data can be encapsulated using RTR, so that it can provide a type of working data in order to identify the codec and timestamp, and the timestamp is used to identify the sampling rate. RTR data can be encapsulated using the universal user guide format described above, with or without an optional time stamp. The receiver 160 can transmit universal input data that transmits the speech command data to the source device 120 using TRS / IR.

As explained above, when coordinates are included as part of a data packet, for example, a data packet 600 in working data 650, for example, the coordinates may correspond to co-ordinates scaled on the basis of a coherent resolution, coordinate of the display window, normalized coordinates or coordinates associated with the receiver display. In some cases , additional information may be included in the data packet or transmitted separately for use with the source device to normalize the coordinates taken in the data packet.

19

iA 109928 C2

Regardless of the input category for a particular data packet, the data packet header maybe a header of the application layer packet, and the data packet can be transmitted over the TCP / IP. The TCP / IP can enable the receiving device 160 and the source device 120 to implement the retransmission technology in the event of packet loss . The data packet may be sent from the device receiver 160 to the source device 120 in order to control the audio data or the data of the source device 120, or for other purposes, for example, in order to control an application operating on the source device 120.

FIG. 7A is a block diagram of a sequence of operations of an exemplary method for coordinating the characteristics between a receiver device and a source device. The illustrated exemplary method may be implemented using a receiver device 160 (FIG. 1A) or 360 (FIG. 3). In some examples, a machine-readable storage medium (e.g., a storage device 332) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 331) to perform one or more illustrated steps on one or more flowcharacters of the sequence operations of the method described in this document.

The method of FIG. 7A includes receiving using the receiver device 160 from the first message device source 120 (701). A message, for example, may contain a request for the receipt of parameters. In response to the first message, the receiver 160 can send a second message to the source device 120 (703). The second message, for example, may include a parameter response that identifies the first list of supported input categories and the set of first lists of supported types, with each of the supported input categories from the first list of supported input categories having an associated first list of supported types. Supported input categories, for example, can match the identical categories used for the input field 624 of the FIG. 6 The above table 2 represents one example of supported types for a particular input category (universal input in this example). The device receiver 160 may receive a third message (705) from the source device 120. The third message, for example, may contain a request for parameter assignments, while the request for parameter assignments identifies the communication port, the second list of supported categories of input, and a set of other lists of supported types, and each of the supported input categories from the second list of supported input categories has an associated second list of supported types, and each of the supported types from other lists includes the typing of types from the first lists. The device receiver 160 may transmit a fourth message (707) to the source device 120. Fourth message, for example may contain an answer to the parameter query to confirm that the types of other lists are activated. The device receiver 160 may receive a fifth message from the source device 120 (709). The fifth message, for example, may contain a second parameter request request, indicating that the communication channel between the source device 120 and the receiver 160 is activated. A channel connection, for example, may contain a reverse user input channel (IIS). The device receiver 160 may transmit a sixth message to the source device 120 (711). The sixth message, for example, may contain a second response from a parameter job, which confirms receipt of the second request for parameter assignments using the receiver device 160. The device receiver 160 may receive a fifth message from the source device 120 (709). The fifth message, for example, may contain a second parameter request request, indicating that the communication channel between the source device 120 and the receiver 160 is activated. A channel connection, for example, may contain a reverse user input channel (IIS). The device receiver 160 may transmit a sixth message to the source device 120 (711). The sixth message, for example, may contain a second response from a parameter job, which confirms receipt of the second request for parameter assignments using the receiver device 160. The device receiver 160 may receive a fifth message from the source device 120 (709). The fifth message, for example, may contain a second parameter request request, indicating that the communication channel between the source device 120 and the receiver 160 is activated. A channel connection, for example, may contain a reverse user input channel (IIS). The device receiver 160 may transmit a sixth message to the source device 120 (711). The sixth message, for example, may contain a second response from a parameter job, which confirms receipt of the second request for parameter assignments using the receiver device 160. The connection between the source device 120 and the receiver 160 is activated. A channel connection, for example, may contain a reverse user input channel (IIS). The device receiver 160 may transmit a sixth message to the source device 120 (711). The sixth message, for example, may contain a second response from a parameter job, which confirms receipt of the second request for parameter assignments using the receiver device 160. The connection between the source device 120 and the receiver 160 is activated. A channel connection, for example, may contain a reverse user input channel (IIS). The device receiver 160 may transmit a sixth message to the source device 120 (711). The sixth message, for example, may contain a second response from a parameter job, which confirms receipt of the second request for parameter assignments using the receiver device 160.

FIG. 7B is a block diagram of a sequence of operations of an exemplary method for matching characteristics between a receiver device and a source device. The illustrated exemplary method may be performed using a source-120 (Figure 1A) or 220 (FIG. 2) device. In some examples, a machine-readable storage medium (e.g., a storage device 232) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 231) to perform one or more illustrated steps in the flowchart of the operation sequence of the method.

The method of FIG. 7B includes a transmission using the source device 120 in the first receiver device 160 (702). The first message, for example, may contain the requested parameter reception. Device-source 120 can receive a second message from device-receiver 160 (704). The second message, for example, may contain a parameter hold reply that identifies the first list of supported input categories, the first list of supported types, and each of the supported categories from the first list of supported categories of categories has an associated first list of supported types. The device-source 120 can transmit to the device-receiver 160that message (706). The third message, for example, may contain a request for a job parameters that identifies the port for communication,

20

iA 109928 C2

Supported types, and each of the types supported, from other lists includes the typing of types from the first lists. The source device 120 may receive a fourth message (708) from the receiver device 160. A fourth message, for example, may contain an answer to the parameter statement to confirm that the types of other lists are activated. The source device 120 may transmit a fifth message (710) to the receiver device 160. The fifth message, for example, may contain a second parameter request request, indicating that the communication channel between the source device 120 and the receiver 160 is activated. A channel connection, for example, may contain a reverse user input channel (IIS). The source device 120 may receive a sixth message from the receiver device 160 (712). Sixth message, for example

FIG. 8A is a block diagram of a sequence of operations of a exemplary method for transmitting data from a user input from a wireless receiver to a wireless source device in accordance with this disclosure. The illustrated exemplary method can be performed using the receiver device 160 (FIG. 1A) or 360 (FIG. 3). In some examples, a machine-readable storage medium (e.g., storage device 332) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 331) to perform one or more illustrated steps in the process sequence flowcharacter.

The method of FIG. 8A includes receiving user input data in a wireless receiver device such as a wireless receiver device 160 (801). The user input data can be obtained through the user input component of the non-wireless receiver 160, such as, for example, the user input interface 376 shown with respect to the wireless receiver unit 360. Additionally, the receiver unit 160 can classify user input data, for example, as universal, such as redirected, or specific for the operating system. The receiver device 160 then can form a data packet header based on user input (803). The header of the data packet may be the header of the application layer packet. The header of the packet may contain, among other fields, a field for to identify the input category corresponding to the data of the user input. The input category may include, for example, a universal input format or a device command with a human-machine interface. The device-receiver 160 may additionally form a data packet (805), while the data packet contains a preformed header of the data packet and working data. In one example, the working data can include accepted user input data and can identify one or more custom commands. The device receiver 160 can then transmit the generated data packet (807) to a wireless source device (e.g., source device 120 according to FIG. 1A or 220 of FIG. 2). The device receiver 160 may include components that enable the transmission of data packets including, for example, a transport unit 333 and a wireless modem 334, as shown in FIG. 3. The receiver device 160 can transmit packet data via TCP / IP.

FIG. 8B is a block diagram of a sequence of operations of exemplary method for receiving data from a user input from a wireless device to a receiver in a wireless source device in accordance with this disclosure. The illustrated exemplary method may be performed using a source-120 (Figure 1A) or 220 (FIG. 2) device. In some examples, a machine-readable storage medium (e.g., a storage device 232) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 231) to perform one or more illustrated steps in the flowchart of the operation sequence of the method.

The method of FIG. 8B includes the reception of a data packet (802), while the data packet can be provided, among other things, the header of the data packet and working data. Working data may include everything, for example, user-input data. The source device 120 may include communication components that enable the transmission of data packets including, for example, a transport unit 233 and a wireless modem 234 as shown in relation to FIG. 2. The source device 120 can then parse the data packet header (804) included in the data packet in order to determine the input category associated with the user input that is contained in the work data. Device-source 120 can process work data based on a defined input category (806). The data packets described with reference to FIG. 8A and 8B, in general, can take the form of data packets described with reference to FIG. 6, and can be used to control audio video data and accessories in the source device.

21

iA 109928 C2

FIG. 9A is a block diagram of a sequence of operations of exemplary method for transmitting data from a user input from a wireless receiver to a wireless source device in accordance with this disclosure. The illustrated exemplary method can be performed using the receiver device 160 (FIG. 1A) or 360 (FIG. 3). In some examples, a machine-readable storage medium (e.g., storage device 332) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 331) to perform one or more illustrated steps in the process sequence flowcharacter.

The method of FIG. 9A includes receiving custom input data in a wireless receiver device such as a wireless receiver device 160 (901). The user input data can be obtained via the user input component of the non-wireless device receiver 160, such as, for example, the user interface interface 376 shown with reference to FIG. 3. Device receiver 160 then can generate work data (903), with the working data can describe the data of user input. In the water case, the working data may include accepted user input data and can identify one or more user commands. The receiver device 160 can additionally form a data packet (905), with the data packet containing the packet header data and the generated working data. The receiver 160 can then transmit the generated data packet (907) to a wireless source device (e.g., source device 120 of FIG. 1A or 220 of FIG. The device receiver 160 may include, for example, components that enable the transmission of data packets such as the transport unit 333 and the wireless modem 334. The data packet can be transmitted to a wireless source device via the TCP / IP.

FIG. 9B is a block diagram of a sequence of operations of exemplary method for receiving data from a user input from a wireless device to a receiver in a wireless source device in accordance with this disclosure. The illustrated exemplary method may be performed using a source-120 (Figure 1A) or 220 (FIG. 2) device. In some examples, a machine-readable storage medium (e.g., a storage device 232) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 231) to perform one or more illustrated steps in the flowchart of the operation sequence of the method.

The method of FIG. 9B includes receiving a data packet from the receiver unit 360 (902), wherein the data packet may include, inter alia, the data packet header and the work data. In one example, the work data may include, for example, data describing the details of the user's input, for example, the value of the input type. Device-source 120 may include components of communication that enable the transmission of data packets including, for example, a transport unit 233 and a wireless modem 234, as shown with reference to FIG. 2. Device-source 120 can then syntactically analyze the data packet (904) to determine the input type type in the input type field in the working data. Device-source 120 can process data describing the details of the user input, based on a certain value of the type of input (906). Data packets described with reference to FIG. 9A and 9B, in general, may take the form of data packets described with reference to FIG. 6

FIG. 10A is a block diagram of a sequence of operations of exemplary mode for transmitting data from a user input from a wireless receiver to a wireless source device in accordance with this disclosure. The illustrated exemplary method can be performed using the receiver device 160 (FIG. 1A) or 360 (FIG. 3). In some examples, a machine-readable storage medium (e.g., storage device 332) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 331) to perform one or more illustrated steps in the process sequence flowcharacter.

The method of FIG. 10A includes receiving custom input data in a wireless receiver device such as a wireless receiver device 160 (1001). The user input data can be obtained via the user input component of the non-wireless device receiver 160, such as, for example, the user interface interface 376, as shown with reference to FIG. 3. Device-receiver 160 can then form the header of a data packet based on user input (1003). The header of the data packet may contain, among other fields, a time stamp flag (for example, a 1-bit field) to indicate if the timestamp field is present in the header of the data packet. A timestamp flag, for example, may include "1" to indicate that the time-tag field is present, and may include "0" to indicate that the time-tag field is not present.

22

iA 109928 C2

using the source device 120 and is attached to the video data prior to transmission. The receiver device160 can additionally form a data packet (1005), while the data packet comprises a generated data packet header and working data. In one example, the working data may include accepted user input data and can identify one or more custom commands. The receiver 160 can then transmit the generated data packet (1007) to a wireless source device (for example, source device 120 of FIG. 1A or 220 of FIG. 2). The device receiver 160 may include components that provide the possibility of transmitting data packets including, for example, a transport unit 333 and a wireless modem 334, as shown with respect to FIG. 3. The data packet can be transmitted to a non-originating device-source via TCP / IP.

FIG. 10B is a block diagram of a sequence of operations of exemplary method for receiving data from a user input from a wireless device to a receiver in a wireless source device in accordance with this disclosure. The illustrated exemplary method may be performed using a source-120 (Figure 1A) or 220 (FIG. 2) device. In some examples, a machine-readable storage medium (e.g., a storage device 232) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 231) to perform one or more illustrated steps in the flowchart of the operation sequence of the method.

The method of FIG. 10B includes receiving a data packet from a wireless device-receiver160 (1002), while the data packet may include, among other things, the header of the data packet and working data. Working data may include, for example, user input data. The source device 120 may include communication components that provide the ability to transmit packet data including, for example, a transport unit 233 and a wireless modem 234 as shown in relation to FIG. 2. The source device 120 can then parse the header of the data packet (1004) included in the data packet. The source device 120 can determine whether the timestamp field is present in the data packet header (1006). In one example, source device 120 can perform definitions based on the value of the time stamp flag included in the header of the data packet. If the data packet header includes a weather timestamp, the source device 120 can process the work data based on the timestamp, which is in the timestamp field (1008). The data packets described with reference to FIG. 10A and 10B, in general, may take the form of data packets described with reference to FIG. 6, and may be used to control audio-video data in the source device.

FIG. 11A is a block diagram of a sequence of operations of exemplary mode for transmitting data from a user input from a wireless receiver to a wireless source device in accordance with this disclosure. The illustrated exemplary method can be performed using the receiver device 160 (FIG. 1A) or 360 (FIG. 3). In some examples, a machine-readable storage medium (e.g., storage device 332) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 331) to perform one or more illustrated steps in the process sequence flowcharacter.

The method of FIG. 11A includes receiving custom input data in a wireless receiver device such as a wireless receiver device 160 (1101). The user input data can be obtained via the user input component of the wireless device-receiver 160, such as, for example, the user-interface interface 376 shown with respect to FIG. 3. Device receiver 160 then can form a header of a data packet based on user input (1103). The header of the data packet may contain, among other fields, the time stamp field. A timestamp field may include, for example, a 16-bit field containing a timestamp based on multimedia data generated by means of a non-originating source device 120 and transmitted to the wireless device receiver 160. A timestamp may have added to the frame of video data using a wireless source device 120 before being transmitted to the wireless device receiver. The timestamp field, for example, can identify the timestamp associated with the video frame displayed on the wireless device receiver 160 when the user input data is captured. The device receiver 160 may additionally form a data packet (1105), with the data packet containing the generated header data packet and work data. In one example, the working data can include accepted user input data and can identify one or more custom commands. The receiver 160 can then transmit the formed data packet (1107) to a wireless source device (e.g., source device 120 of FIG. 1A or 220 of FIG. The device receiver 160 may contain components,

23

iA 109928 C2

a transport unit 333 and a wireless modem 334, as shown in relation to FIG. 3. The data packet can be transmitted to a wireless source device via TCP / IP.

FIG. 11B is a block diagram of a sequence of operations of exemplary method for receiving data from a user input from a wireless device to a receiver in a wireless source device in accordance with this disclosure. The illustrated exemplary method may be performed using a source-120 (Figure 1A) or 220 (FIG. 2) device. In some examples, a machine-readable storage medium (e.g., a storage device 232) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 231) to perform one or more illustrated steps in the flowchart of the operation sequence of the method.

The method of FIG. 11B includes receiving a data packet from a wireless receiver device such as a wireless device-receiver 160 (1102), wherein the data packet may include, calculate the other, the data packet header, and the work data. Working data may include, for example, user input data. The source device 120 may include components for providing data packets including, for example, a transport unit 233 and a wireless modem 234, as shown in relation to FIG. 2. The source device 120 can then identify the timestamp field in the data packet header (1104). The source-source device 120 can process the work data based on the timestamp located in the field of the timestamp (1106). As part of the processing of working data based on the timestamp, the source device 120 can identify the frame of the video data, which is displayed in the wirelessdevice receiver at the moment when the user input data is received, and interpretprocess data based on the content of the frame. As part of the processing of work data based on a timestamp, device-source 120 can compare the timestamp with the current timestamp for the video stream transmitted using the source device 120, and can execute the user input command described in the working data, in response to the difference between times between the timestamp and the current timestamp, less than the threshold value, or not execute the user input command described in the working data, in response to the difference between the time between the timestamp and the current timestamp that is yschuye porohoveznachennya. The data packets described with reference to FIG. 11A and 11B, in general, may receive the form of data packets described with reference to FIG. 6

FIG. 12A is a block diagram of a sequence of operations of exemplary mode for transmitting data from a user input from a wireless receiver to a wireless source device in accordance with this disclosure. The illustrated exemplary method can be performed using the receiver device 160 (FIG. 1A) or 360 (FIG. 3). In some examples, a machine-readable storage medium (e.g., storage device 332) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 331) to perform one or more illustrated steps in the process sequence flowcharacter.

The method of FIG. 12A includes receiving custom input data in a wireless receiver device such as a wireless receiver 160 (1201). In one example, the user input data may be data of speech commands that may be received through the user input component of the wireless device receiver 160, such as, for example, the language command recognition module included in the user input interface 376 of FIG. 3. Device receiver 160 may form a header of packet data based on user input (1203). The device receiver 160 may also generate working data (1205), with the working data may contain data of speech commands. In an aqueous example, the working data may also include accepted user guide data and can identify one or more user commands. The device receiver160 can additionally form a data packet (1207), while the data packet comprises a generated data packet header and working data. The device receiver 160 may then transmit the generated data packet (1209) to a wireless source device (e.g., source device 120 of FIG. 1A or 220 of FIG. The device receiver 160 may comprise components that provide the ability to transmit data packets including, for example, a transport unit 333 and a wireless modem 334, as shown in relation to FIG. 3. Data packet can be transmitted to a wireless source device via TCP / IP. 1A or 220 for FIG. 2). The device receiver 160 may comprise components that provide the ability to transmit data packets including, for example, a transport unit 333 and a wireless modem 334, as shown in relation to FIG. 3. Data packet can be transmitted to a wireless source device via TCP / IP. 1A or 220 for FIG. 2). The device receiver 160 may comprise components that provide the ability to transmit data packets including, for example, a transport unit 333 and a wireless modem 334, as shown in relation to FIG. 3. Data packet can be transmitted to a wireless source device via TCP / IP.

FIG. 12B is a block diagram of a sequence of operations of an exemplary method for receiving data from a user input from a wireless device to a receiver in a wireless source device in accordance with this disclosure. The illustrated exemplary method may be performed using a source-120 (Figure 1A) or 220 (FIG. 2) device. In some examples,

24

iA 109928 C2

a machine readable storage medium (e.g., a storage device 232) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 231) to perform one or more illustrated steps in the flowchart of the operation sequence of the method.

The method of FIG. 12B includes the reception of a data packet (1202), while the data packet can be provided, among other things, the header of the data packet and working data. Working data may include all of you, for example, user-input data, such as language command data. The source device 120 may include communication components that enable the transmission of data packets including, for example, a transport unit 233 and a wireless modem 234, as shown in relation to FIG. 2. The source-device 120 can then parse the working data (1204) included in the data packet to determine whether they contain working data or no data of speech commands. The data packets described with reference to FIG. 12A and 12B, in general, may receive the form of data packets described with reference to FIG. 6, and can be used to

FIG. 13A is a block diagram of a sequence of operations of exemplary mode for transmitting data from a user input from a wireless receiver to a wireless source device in accordance with this disclosure. The illustrated exemplary method can be performed using the receiver device 160 (FIG. 1A) or 360 (FIG. 3). In some examples, a machine-readable storage medium (e.g., storage device 332) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 331) to perform one or more illustrated steps in the process sequence flowcharacter.

The method of FIG. 13A includes receiving custom input data in a wireless receiver device such as a wireless receiver 160 (1301). In one example, the user input data can be a multisensor gesture that can be obtained through the user-input component of the wireless device-receiver160, such as, for example, ii 167 or the user input interface 376 of FIG. 3. In an aqueous example, a multisensor gesture may contain a first sensory input and a bi-sensory input. The device receiver 160 may generate a header of the data packet based on the user input (1303). The receiver 160 may also generate working data (1305), the work data can associate the user input for the first touch input event with the first pointer identifier and the user input for the second touch input event with the second pointer identifier. The device receiver 160 may additionally form a data packet (1307), while the data packet comprises a formed data packet header and working data. The receiver device 160 may then transmit the generated data packet (1309) to a wireless source device (e.g., source device 120 of FIG. 1A or 220 of FIG. 2). The device receiver 160 may comprise components that provide the ability to transmit data packets including, for example, a transport unit 333 and a wireless modem 334, as shown in relation to FIG. 3. Data packet can be transmitted to a wireless source device via TCP / IP.

FIG. 13B is a block diagram of a sequence of operations of exemplary mode for receiving data from a user input from a wireless device to a receiver in a wireless source device in accordance with this disclosure. The illustrated exemplary method may be performed using a source device 120 (FIG. 1A) or 220 (FIG. 2). In some examples, a machine-readable storage medium (e.g., a storage device 232) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 231) to perform one or more illustrated steps in the flowchart of the operation sequence of the method.

The method of FIG. 13B includes the reception of a data packet (1302), while the data packet can be provided, among other things, the header of the data packet and working data. Working data may include everything, for example, user-input data such as multi-sensory gesture. The source device 120 may include communication components that provide the ability to transmit packet data including, for example, a transport unit 233 and a wireless modem 234, as shown in FIG. 2. The source device 120 can then parse the working data (1304) included in the data packet in order to identify the user input data included in the working data. In one example, the identifiable data may include the data of the user input for the first sensory input event with the identifier of the first index and the data of the user input for the second event of the sensory input with the identifier of the second index. The device-source 120 can then interpret user input data for the first touch input event and user data

25

iA 109928 C2

input for the second sensory input event as a multisensor gesture (1306). The data packets described with reference to FIG. 13A and 13B, in general, may take the form of data packets described with reference to FIG. 6, and can be used to control audio-video data in the source device.

FIG. 14A is a block diagram of a sequence of operations of exemplary mode for transmitting data from a user input from a wireless receiver to a wireless source device in accordance with this disclosure. The illustrated exemplary method can be performed using the receiver device 160 (FIG. 1A) or 360 (FIG. 3). In some examples, a machine-readable storage medium (e.g., storage device 332) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 331) to perform one or more illustrated steps in the process sequence flowcharacter.

The method of FIG. 14A includes receiving user input data in a wireless device-receiver 360 from an external device (1401). In one example, the external device may be a third party device connected to the receiver device. Device-receiver 160 may form a data packet header based on a user-generated output (1403). In one example, the data packet header may identify the data of the user's input as the redirected user input. The device receiver 160 may also generate working data (1405), with the working data may contain a user input. The receiver 160 may additionally form a data packet (1407), while the data packet may comprise a preformed header of the data packet and work data. The receiver device 160 can then transmit the generated data packet (1409) to a wireless source device (e.g., source device 120 of FIG. 1A or 220 of FIG. 2). The device receiver 160 may include components that enable the transmission of data packets including, for example, a transport unit 333 and a wireless modem 334, as shown with reference to FIG. 3. The data packet can be transmitted to the wireless device / source of the POP / IP.

FIG. 14B is a block diagram of a sequence of operations of exemplary mode for receiving data from a user input from a wireless device to a receiver in a wireless source device in accordance with this disclosure. The illustrated exemplary method may be performed using a source device 120 (FIG. 1A) or 220 (FIG. 2). In some examples, a machine-readable storage medium (e.g., a storage device 232) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 231) to perform one or more illustrated steps in the flowchart of the operation sequence of the method.

The method of FIG. 14B includes receiving a data packet (1402), while a data packet can be provided, among other things, the header of the data packet and working data. Working data may include all of you, for example, user-input data, such as a forward-directed user-directed command that specifies that user-input data is redirected to a non-spam device. The source device 120 may include communication components that enable the transmission of data packets including, for example, a transport unit 233 and a wireless modem 234, as shown in relation to FIG. 2. The source device 120 can then parse the data packet header syntactically and may determine that the working data contains a redirecting custom input (1404) command. The source 120 then can syntactically analyze the working data (1406), included in the packets, in order to identify the identification data associated with a third-party device that corresponds to the redirecting custom input command. The source device 120 can then process the work data based on the identification data of the sidestream device (1408). The data packets described with reference to FIG. 14A and 14B, in general, may take the form of data packets described with reference to FIG. 6, and may be used to control audio-video data in the source device. described with reference to FIG. 14A and 14B, in general, may take the form of data packets described with reference to FIG. 6, and may be used to control audio-video data in the source device. described with reference to FIG. 14A and 14B, in general, may take the form of data packets described with reference to FIG. 6, and may be used to control audio-video data in the source device.

FIG. 15A is a block diagram of a sequence of operations of exemplary mode of transferring user data from a wireless receiver to a wireless source device in accordance with this disclosure of the essence. The illustrated exemplary method can be performed using device-receiver 160 (FIG. 1A) or 360 (FIG. 3). In some examples, a machine-readable storage medium (e.g., storage device 332) can store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 331) to perform one or more illustrated steps on a flowchart of the operation sequence of a method.

26

iA 109928 C2

The method of FIG. 15A includes receiving user input data in a wireless receiver device (1501). Custom input data may have associate coordinate data. The associated coordinate data, for example, may correspond to the position of the mouse click event or the location of the touch input event. The device receiver 160 can then normalize the associated coordinate data to form the normalized coordinate data (1503). The receiver 160 then can form packet data, which includes normalized coordinate data (1505). Normalization of coordinate data may include scaling of associated coordinate data based on the aspect ratio of the display window differentiation and the resolution of the source display, for example, the display 22 of the source device 120. The separation of the display window can be determined by the receiver device 160, and the source resolution display differentiation may be taken from the source device 120. The receiver 160 can then transmit the data packet with the normalized coordinates to the wireless source device 120 (1507). As part of the method of FIG. 15A, receiver 160 may also determine whether or not associate coordinate data within the display window for content received by a non-originating source device and, for example, processing user input locally if the associated coordinate data is outside the display window, or in the other case, normalize the coordinates as described, if the input is within the display window. The device receiver 160 can then transmit the data packet to the normalized coordinates in the wireless source device 120 (1507). As part of the method of FIG. 15A, receiver 160 may also determine whether or not associate coordinate data within the display window for content received by a non-originating source device and, for example, processing user input locally if the associated coordinate data is outside the display window, or in the other case, normalize the coordinates as described, if the input is within the display window. The device receiver 160 can then transmit the data packet to the normalized coordinates in the wireless source device 120 (1507). As part of the method of FIG. 15A, receiver 160 may also determine whether or not associate coordinate data within the display window for content received by a non-originating source device and, for example, processing user input locally if the associated coordinate data is outside the display window, or in the other case, normalize the coordinates as described, if the input is within the display window.

FIG. 15B is a block diagram of a sequence of operations of exemplary method for receiving data from a user input from a wireless device to a receiver in a wireless source device in accordance with this disclosure. The illustrated exemplary method may be performed using a source-120 (Figure 1A) or 220 (FIG. 2) device. In some examples, a machine-readable storage medium (e.g., a storage device 232) may store instructions, modules, or algorithms that, when executed, instruct one or more processors (e.g., processor 231) to perform one or more illustrated steps in the flowchart of the operation sequence of the method.

The method of FIG. 15B includes receiving a data packet in a wireless source device, with the data packet containing user input data with associated coordinate data (1502). The associated coordinate data, for example, may correspond to the location of the mouse click or the location of the touch input event in the receiver device. The source-120 device can then normalize the associated coordinate data to form the coordinated coordinate data (1504). Device-source 120 can normalize the coordinate data by scaling the associated coordinate data based on the ratio of the differentiation of the display window and the differentiation of the source display. Device-source 120 can define a distinction between the display of the source device and may receive the resolution of the window displayed from the wireless receiver device. The device-source can then process a data packet based on normalized coordinate data (1506). The data packets described with reference to FIG. 15A and 15B, in general, may take the form of data packets described with reference to FIG. 6, and can be used to control the audio-video data in the device source.

For ease of explanation, aspects of this disclosure are described in detail with reference to FIGS. 7-15. However, it is assumed that these various aspects can be combined and used in conjunction with each other, rather than simply separate. In general, the functionality and / or modules described in the given document can be implemented in one or both of the wireless source device and the wireless receiver device. Thus, the characteristics of the user interface described in the current example, can be used interchangeably between the wireless source device and the wireless device receiver.

The technologies of this disclosure essentially can be implemented in a wide range of devices or devices, including a wireless portable telephone and an integrated circuit (IC) or a set of ICs (that is, the set of chips). All of the components, modules, or blocks described are intended to emphasize the functional aspects, and do not necessarily require implementation with the help of various hardware blocks.

The technologies described herein may be implemented in hardware, software, firmware, or in any combination thereof. In hardware implementations, any features described as modules, blocks, or components can be implemented together in an integrated logical device or separately as discrete but interactive logical devices. When implemented in software, technologies can be implemented at least partially using a machine readable media containing instructions that, when executed in the processor, carry out one or more of the methods described above.

27

iA 109928 C2

Machine-readable media may contain material and non-volatile machine readable storage media and may be part of a computer software product that may include packaging. Machine readable storage media may include an operating memory device (RAM), such as a synchronous dynamic operational memory device (5YURAM), a permanent storage device (ROM), a non-volatile memory storage device (NVRAM), an electrically erased programmed constant smell ' the device (EERRO), flash memory, magnetic or optical storage media, etc. Additionally or alternatively, technologies can be implemented at least partially by means of a machine-readable communication medium, which transmits or transmits code in the form of instructions or data structures,

The code can be executed using one or more processors, such as one or more digital signal processors (δδ), general purpose microprocessors, specialized integrated circuits (ALIs), user-programmable gate arrays (ERCAs), or other equivalent integral or discrete logic circuits. Accordingly, the term "processor", when used in this document, may mean any of the foregoing structures or other structure suitable for the implementation of the technologies described in this document. In addition, in some aspects, the functionality described in this document may be provided within the framework of specialized software modules or hardware modules executed with the capability of encoding or decoding or embedded in a combined video codec. In addition,

Various aspects of disclosure are described. These and other aspects are within the scope of the scope of the appended claims.

Reference positions

100, 101 source / receiver system

120, 220 source device

121 audio-video (AM-) data

122, 162 display

123, 163 speaker

124 audio video codec

125 audio video control module

126, 166 block of the transmitting device

150 communication channel

160, 180 receiver device

164 audio video decoder

167 user input device

168 custom input processing module

222, 362 local display

223 local speaker

232, 332 storage device

231, 235 processor

233, 333 transport block

234, 334 wireless modem

335 display processor

236, 336 audio processor

360 device receiver

376 user input interface

410 transmission system

412 data source

414 data transfer processor

420 THM MIMO processor

422 transmitter

424 antennas

430 processor

436 data source

438 TX data processor

440 demodulator

442 RX data processor

430 processor

450 receiver system

28

iA 109928 C2

452 receiving antenna

454 receiving device460 processor receiving data470 processor

472 storage device

480 modulator

520 device source

560 receiver device

600 package

610 header of data packet615 line

621 version field

622 flag timestamp

623 reserved field

624 input category field

625 field length

626 optional timestamp field630 job data header

650 working data

FORMULA INSTRUCTIONS

A method for reconciling characteristics between a wireless receiver device and a wireless source device, the method comprising the step of:

transmit messages to a wireless source device, with this message identifies:

a list of supported input categories, and the list of supported input categories identifies the user input data formats supported by the wireless receiver;

a set of supported types of lists, with each of the supported categories of inputting an abbreviation of supported input categories has an associated list of supported types.

2. The method of claim 1, wherein the message is a message with an answer RT8R OET_RARAMETER.

3. The method of claim 1, further comprising the step of:

the list of supported categories of input is the first list of supported categories, and the set of supported types is the first set of lists of supported types;

receive a second message from the wireless source device, while the second message identifies:

second list of supported input categories;

a set of other lists of supported types, with each of the supported categories entering from the second list of supported input categories has an associated second list of supported types.

4. The method of claim 3, wherein the second message further comprises a port for communication.

5. The method of claim 3, wherein the second message is a message requesting RT8R8ET_RAMAMETER.

6. The method of claim 3, wherein the supported types from other lists are a subset of types from the first plots.

7. The method of claim 3, further comprising the step of:

transmitting a third message to the wireless source device to confirm that the types from other lists are activated.

8. The method of claim 7, further comprising the step of:

receive a fourth message from the wireless source device, while the fourth message indicates that the communication channel between the wireless source device and the wireless receiver is activated.

9. The method of claim 8, further comprising the step of:

transmitting a fifth message to the wireless device-source, with the fifth message confirming the reception of the fourth message with the help of the wireless receiver device.

10. The method of claim 8, wherein the communication channel is a reverse user input channel (IIS).

29

iA 109928 C2

11. The method of claim 1, wherein supported input categories from the list of supported categories input are selected from a group consisting of a universal command and a device command with a human-machine interface (NU).

12. The method of claim 1, further comprising the step of:

receive from the wireless device the source of the message with the parameter request, while the message with the parameter request identifies the input path for the supported type of list of supported types.

13. The method of claim 1, wherein supported types of supported type lists are selected from the group consisting of a keyboard, a mouse, a traditional touch input, a multisensory output, a joystick, a camera, a gesture, and a remote control.

14. The method of claim 2, wherein supported types from other lists of supported types are selected from a group consisting of a keyboard, a mouse, a traditional touch input, a multisensory input, a joystick, a camera, gestures, and a remote control.

15. The method of claim 4, wherein the port for communication is a port on a transmission control protocol (TCP).

16. The method of claim 1, wherein the first message further identifies a zero entry for the supported input category to indicate that the input category is not supported by the wireless receiver device.

17. The method of claim 1, wherein the first message is a text message.

18. A wireless receiver device configured to match the characteristics of a non-originating source device, the wireless receiver comprising: a storage device storing instructions;

one or more processors executed with the ability to execute instructions, while instructing one or more processors to instruct:

transmit messages to a wireless source device, with the message identifying:

a list of supported input categories, and the list of supported categories of input identifies the user input data formats supported by the wireless device-receiver; and

a set of supported types of lists, with each of the supported categories of inputting an abbreviation of supported input categories has an associated list of supported types.

19. The apparatus of claim 18, wherein the message is a message with an RT-8RCET_RAMAMETER response.

20. The device of claim 18, wherein the list of supported categories of input is the first list of supported input categories, while the set of supported types is the first number of supported types of lists, and while executing instructions one or more processors are further instructed:

receive a second message from the wireless source device, while the second message identifies:

second list of supported input categories;

a set of other lists of supported types, with each of the supported categories entering from the second list of supported input categories has an associated second list of supported types.

21. The apparatus of claim 20, wherein the second message further comprises a port for communication.

22. The apparatus of claim 20, wherein the second message is a message requesting RT8R8ET_ARAMETER.

23. The apparatus of claim 20, wherein supported types from other lists are a subset of types from the first plots.

24. The apparatus of claim 20, wherein, when executing instructions, one or more processors are further instructed:

transmit the third message to the wireless source device to confirm that the types from other lists are activated.

25. The apparatus of claim 24, wherein, when executing instructions, one or more processors are further instructed:

receive a fourth message from the wireless source device, while the fourth message indicates that the communication channel between the wireless source device and the wireless device-receiver is activated.

26. The apparatus of claim 25, wherein, when executing the instructions, one or more processors are additionally instructed:

transmitting a fifth message to the wireless device-source, with the fifth message confirming the reception of the fourth message with the help of the wireless receiver device.

30

iA 109928 C2

27. The apparatus of claim 25, wherein the communication channel is a reverse user input channel (s).

28. The device of claim 18, wherein supported categories of input from the list of supported categories input are selected from a group consisting of a universal command and a device command with human-machine interface (NUU).

29. The apparatus of claim 18, wherein, when executing instructions, one or more processors are further instructed:

receive from the wireless device the source of the message with the parameter request, while the message with the parameter request identifies the input path for the supported type of list of supported types.

30. The apparatus of claim 18, wherein the supported types of supported types are selected from a group consisting of a keyboard, a mouse, a traditional touch input, a multisensory input, a joystick, a camera, a gesture, and a remote control.

31. The apparatus of claim 19, wherein supported types from other lists of supported types are selected from the group consisting of a keyboard, a mouse, a traditional touch input, a multisensory input, a joystick, a camera, gestures, and a remote control.

32. The apparatus of claim 21, wherein the port for communication is a port according to a transmission control protocol (TCP).

33. The apparatus of claim 18, wherein the first message further identifies a zero entry for the supported input category to indicate that the input category is not supported by the wireless receiver device.

34. The apparatus of claim 18, wherein the first message is a text message.

35. A machine-readable storage medium that stores instructions that, when executed with the help of one or more processors, give instructions to one or more processors to implement a method for reconciling the characteristics between the wireless receiver device and the wireless source device, the method comprising the step of:

transmit messages to a wireless source device, with this message identifies:

a list of supported input categories, and the list of supported input categories identifies the user input data formats supported by the wireless receiver;

a set of supported types of lists, with each of the supported categories of inputting an abbreviation of supported input categories has an associated list of supported types.

36. A wireless receiver device configured to match characteristics of a non-wireless source device, wherein the wireless receiver unit comprises:

a means for transmitting a message to a wireless source device, with this message identifies:

a list of supported input categories, and the list of supported categories of input identifies the user input data formats supported by the wireless device-receiver; and

a set of supported types of lists, with each of the supported categories of inputting an abbreviation of supported input categories has an associated list of supported types.

37. A method for reconciling characteristics between a wireless receiver and a wireless source device, the method comprising the step of:

Receive messages from the wireless device receiver, with the message identifies:

a list of supported input categories, and the list of supported categories of input identifies the user input data formats supported by the wireless device-receiver; and a plurality of supported types of lists, with each of the supported categories entering from the list of supported input categories has an associated list of supported types.

38. The method of claim 37, wherein the message is a message with an answer RT8PCET_RAMAMETER.

39. The method of claim 37, further comprising the step of:

the list of supported categories of input is the first list of supported categories, and the set of supported types is the first set of lists of supported types;

the second message is transmitted to the wireless device-receiver, while the second message identifies:

second list of supported input categories;

31

iA 109928 C2

a set of other lists of supported types, with each of the supported categories entering from the second list of supported input categories has an associated second list of supported types.

40. The method of claim 39, wherein the second message further comprises a port for communication.

41. The method of claim 39, wherein the second message is a message with the request РИ5Р5ετ_ραραμετερ.

42. The method of claim 39, wherein the supported types from other lists are a subset of types from the first plots.

43. The method of claim 39, further comprising the step of:

receive a third message from the wireless receiver device to confirm that the types from other lists are activated.

44. The method of claim 43, further comprising the step of:

the fourth message is transmitted to the wireless device-receiver, while the fourth message indicates that the communication channel between the wireless source device and the wireless receiver is activated.

45. The method of claim 44, further comprising the step of:

receive from the wireless receiver device the fifth message, while the fifth message confirms the reception of the fourth message with the help of a wireless device-receiver.

46. ​​The method of claim 44, wherein the communication channel is a reverse user input channel (s).

47. The method of claim 37, wherein supported categories of input from the list of supported categories input are selected from a group consisting of a universal command and a device command with a human-machine interface (NUU).

48. The method of claim 37, further comprising the step of:

sends the message to the wireless device receiver with the parameter request, while the message with the parameter request identifies the input path for the supported type of list of supported types.

49. The method of claim 37, wherein the supported types of supported type lists are selected from the group consisting of a keyboard, a mouse, a traditional touch input, a multisensory output, a joystick, a camera, gestures, and a remote control.

50. The method of claim 39, wherein the supported types from other lists of supported types are selected from the group consisting of a keyboard, a mouse, a traditional touch input, a multisensory input, a joystick, a camera, gestures, and a remote control.

51. The method of claim 40, wherein the port for communication is a port according to a transmission control protocol (RPMS).

52. The method of claim 37, wherein the first message further identifies the zero entry for the supported input category to indicate that the input category is not supported by the wireless receiver device.

53. The method of claim 37, wherein the first message is a text message.

54. A wireless source device configured to match the characteristics of a non-wireless receiver device, wherein the wireless source device comprises: a storage device storing instructions;

one or more processors executed with the ability to execute instructions, while instructing one or more processors to instruct:

receive messages from the wireless receiver device, with this message identifies:

a list of supported input categories, and the list of supported categories of input identifies the user input data formats supported by the wireless device-receiver; and

a set of supported types of lists, with each of the supported categories of inputting an abbreviation of supported input categories has an associated list of supported types.

55. The wireless source device according to claim 54, wherein the message is a message in response to the answer PI5P ΟΕτ_ΡΑΡΑΜΕΕΕΕΕ.

56. The wireless source device of claim 54, wherein the list of supported input categories is the first list of supported input categories, and the set of supported types is the first set of supported types of lists, and in doing so, instructions for one or more processors are further instructed:

transmitting a second message to the wireless device receiver, while the second message identifies:

32

iA 109928 C2

second list of supported input categories;

a set of other lists of supported types, with each of the supported categories entering from the second list of supported input categories has an associated second list of supported types.

57. The wireless source device according to claim 56, wherein the second message further comprises a communication port.

58. The wireless source device according to claim 56, wherein the second message is a message requesting RT5R 5ET_RAMAMETER.

59. The wireless source device according to claim 56, wherein the supported types of other lists are an abbreviation of types from the first lists.

60. A wireless source device according to claim 56, wherein, when executing instructions, one or more processors are further instructed:

Receive a third message from the wireless device receiver to confirm that the types from other lists are activated.

61. The wireless source device according to claim 60, wherein, when executing instructions, one or more processors are further instructed:

send a fourth message to the wireless device receiver, while the fourth message indicates that the communication channel between the wireless source device and the wireless receiver is activated.

62. The wireless source device according to claim 61, wherein, when executing instructions, one or more processors are further instructed:

accept the fifth message from the wireless device receiver, while the fifth message confirms the reception of the fourth message with the help of a wireless receiver device.

63. The wireless source device according to claim 61, wherein the communication channel is a reverse user input channel (IIS).

64. The wireless source device according to claim 54, wherein the supported input categories from the list of supported input categories are selected from the group consisting of a universal command and a machine-to-machine interface (NU) command.

65. A wireless source device according to claim 54, wherein, when executing instructions, one or more processors are further instructed:

transmitting a parameter request message to the wireless device, with the message requesting parameters identifying the input path for a supported type of type of list of supported types.

66. The wireless source device of claim 54, wherein the supported types of supported types of lists are selected from the group consisting of a keyboard, a mouse, a traditional touch sensor, a multisensory input, a joystick, a camera, a gesture, and a remote control.

67. The wireless source device according to claim 56, wherein supported types from other lists of supported types are selected from the group consisting of a keyboard, mouse, traditional sensory input, multisensory input, joystick, camera, gestures, and remote control.

68. The wireless source device of claim 58, wherein the port for communication is a port through the transferring control protocol (TCP).

69. The wireless source device of claim 54, wherein the first message further identifies the write entry for the supported input category to indicate that the input category is not supported by the wireless receiver device.

70. The wireless source device according to claim 54, wherein the first message is an in-text message.

71. A machine-readable storage medium that stores instructions that, when executed with the help of one or more processors, instruct one or more processors to implement a method for reconciling the characteristics between a wireless receiver device and a wireless source device, the method comprising the step of:

Receive messages from the wireless device receiver, with the message identifies:

a list of supported input categories, and the list of supported categories of input identifies the user input data formats supported by the wireless device-receiver; and

a set of supported types of lists, with each of the supported categories of inputting an abbreviation of supported input categories has an associated list of supported types.

33

iA 109928 C2

72. A wireless source device configured to match the characteristics of a non-wireless receiver device, wherein the wireless source device comprises: means for receiving a message from a wireless receiver device, wherein the message identifies:

5 list of supported input categories, and the list of supported input categories identifies the user input data formats supported by the wireless receiver;

a set of supported types of lists, with each of the supported categories of inputting an abbreviation of supported input categories has an associated list of supported types.

34

iA 109928 C2

35

iA 109928 C2

signal

Transmitter

Processor KH

Receiver

Transmitter

Receiver

Transmitter

Receiver

Receiver

Transmitter.

The first message

The third message

Fifth message

Sixth message

Eighth message

FIG. 5A

400

Fourth message

Seventh message

FIG. 4

Device-receiver

560

GIS

GIS

438

&lt;4

The second message

Device-source

520

424A

452A

460

454A

data

472

Memorably

424T

452K

knitting

device

Processor TX

Modulator

data

-480

422T

454P

412

410

Source

data

And idolotny

414

420

GC ΜΙΜΟ

Processor TX

processor

data

, 432

Memorably

flying

irisiry

Processor iHdani

^ 442 ± 440

Processor

Processor

Demodulator

Source

data

36

iA 109928 C2

Length 625

Time tag (optional) 626

FIG. 6

1b SET_RARAMETER^{The answer is}("МyиссaaІІІііu: іпри1_a1едогу_ІІ8І = ΟΕΝΕΡΙΟ; dvpegis_ar_Іi8І = Μοιιεβ, ЗіпДІеоТоісііі;

BisIs_sar_Ii8I = N1) 1.1; horns = N1) 1.1.) approx

(ipsi_iis_sara iiii: iprilasa (edogu_1iz) {= NUS; dvpegis_sar_1і5і = ΝΙΙίΕ

bie &lt;3c_sar Ii $ (= Moise / BT, KetoIeSopIgOi / IgGgawb; ροΓΐ = Νυιυ

2a 5ET_RARAMETER Request (\ 7M_iIs_SarAIIIIu: IpriI_a1oDo_Ii $ 1 = SEiERIdeDeGiIs_ARiIi8I = Moise, ZipDiTeIsi:

bibs_sar_ІІ8І = ΝΙΑΙ .; horns = 1000)

• - OR

("МІІссарсаІІіуу; Іприі_са1едогу_1із1 = НЮС; двпепс_араріІІ8І = ΝΙΑΙ .;

Kk1s_sar_Ii5I = Moise / BT, RhotoIoSiIiIiIghEsi; horns = 1000)

FIG. 5V

600

2b. 5ET_RARAMETER^{In |}D^sayD^ıOK

1a. SETRARAMETER^Request"1 &amp; lt; / RTI &amp; gt;

By. ZET_RARAMETER

imi_iis_ze11ipd: epaYe

Request

Z. ZET_RARAMETEROK

Answer

Title

Title

workers

Working data

package

data

650

630

610

615

Version

621

Input category

624

Reserved θ23

Device-receiver

560

Device-source

520

37

iA 109928 C2

38

iA 109928 C2

39

iA 109928 C2

40

iA 109928 C2

41

iA 109928 C2

42

iA 109928 C2

43

iA 109928 C2

Computer layout A. Krulewski

State Service of Intellectual Property of Ukraine, st. Vasyl Lipkivsky, 45, Kyiv, Ukraine, 03680, Ukraine

State Enterprise "Ukrainian Institute of Intellectual Property", st. Glazunova, 1, Kyiv - 42, 01601

44