Source: https://patents.google.com/patent/US9052902B2/en
Timestamp: 2018-08-21 04:43:07
Document Index: 604258132

Matched Legal Cases: ['Application No. 200910221453', 'Application No. 201180002742', 'Application No. 2013', 'Application No. 10', 'Application No. 10', 'Application No. 10', 'Application No. 10', 'Application No. 2013', 'Application No. 2013', 'Application No. 200910221453', 'Application No. 201180002742', 'Application No. 201180002742', 'Application No. 10', 'Application No. 2012', 'Application No. 10', 'Application No. 10', 'Application No. 98132686', 'Application No. 98132686']

US9052902B2 - Techniques to transmit commands to a target device to reduce power consumption - Google Patents
Techniques to transmit commands to a target device to reduce power consumption Download PDF
US9052902B2
US9052902B2 US12890217 US89021710A US9052902B2 US 9052902 B2 US9052902 B2 US 9052902B2 US 12890217 US12890217 US 12890217 US 89021710 A US89021710 A US 89021710A US 9052902 B2 US9052902 B2 US 9052902B2
US12890217
US20120079295A1 (en )
Todd M. Witter
This application is related to co-pending U.S. patent application Ser. No. 12/286,192, entitled “Protocol Extensions in a Display Port Compatible Interface,” inventors Kwa et al., filed Sep. 29, 2008.
The subject matter disclosed herein relates generally to techniques for regulating power consumption.
Multimedia operations in computer systems are very common. For example, personal computers are often used to process and display video. Power consumption by computers is a concern. It is desirable to regulate power consumption by personal computers.
FIG. 1A depicts a system in accordance with an embodiment.
FIG. 1B depicts an example of components of a host system whose power consumption can be controlled, in accordance with an embodiment.
FIG. 1C depicts a high level block diagram of a timing controller for a display device in accordance with an embodiment.
FIG. 2 depicts an example format of signals transmitted over multiple lanes of a DisplayPort interface.
FIG. 3 depicts an example manner of communication of secondary data packets over one and more lanes of a DisplayPort interface.
FIG. 4 depicts an example of a sequence of events for entry into main link standby mode.
FIG. 5 depicts an example of a sequence of events for exit from main link standby mode.
FIG. 1A depicts a system 100 in accordance with an embodiment. System 100 may include a source device such as a host system 102 and a target device 150. Host system 102 may include a processor 110 with one or more cores, host memory 112, storage 114, and graphics subsystem 115. Chipset 105 may communicatively couple devices in host system 102. Graphics subsystem 115 may process video and audio. System 100 can be implemented in a handheld personal computer, mobile telephone, set top box, or any computing device. Any type of user interface is available such as a keypad, mouse, and/or touch screen.
In accordance with various embodiments, processor 110 may execute a software driver (not depicted) that determines whether to (1) instruct target device 150 to capture an image and repeatedly display the captured image, (2) power down components of graphics subsystem 115, and (3) power down components of target device 150. The driver may determine whether to initiate actions (1), (2), or (3) based at least on: a change in the system timer period, triangle or polygon rendering, any processor core is not in low power mode, any mouse activity, vertical blanking interrupts are used, and/or overlay is enabled. For example, powering down components may involve reducing voltage regulators to the lowest operating voltage level. For example, when the processor 110 executes a Microsoft Windows compatible operating system, the driver may be a kernel mode driver.
For example, host system 102 may transmit commands to target device 150 using interface 145. In some embodiments, interface 145 may include a Main Link and an AUX channel, both described in Video Electronics Standards Association (VESA) DisplayPort Standard, Version 1, Revision 1a (2008) as well as revisions and variations thereof. In various embodiments, host system 102 (e.g., graphics subsystem 115) may form and transmit communications to target device 150 at least in a manner described with respect to co-pending U.S. patent application having Ser. No. 12/286,192, entitled “Protocol Extensions in a Display Port Compatible Interface,” inventors Kwa et al., filed Sep. 29, 2008.
Target device 150 may be a display device with capabilities to display visual content and/or render audio content. For example, target device 150 may include control logic such as a timing controller (TCON) that controls writing of pixels as well as a register that directs operation of target device 150. Target device 150 may have access to a memory or frame buffer from which to read frames for display.
Various embodiments include the capability to transmit secondary data packets over interface 145 to target device 150. Secondary data packets can be used to command target device 150.
FIG. 1B depicts an example of components of host system 102 whose power consumption can be controlled (e.g., power consumption decreased or increased), in accordance with an embodiment. The components can be in a chipset, processor, or graphics subsystem. For example, the display phase lock loop (PLL) 160, display plane 162, display pipe 164, and display interface 166 of host 102 can be powered down or up. PLL 160 may be a system clock for the display plane 162, display pipe 164, and/or display interface 166. For example, display plane 162 may include a data buffer and RGB color mapper, which transforms data from buffer to RGB. Display plane 162 may include an associated memory controller and memory input/output (IO) (not depicted) that could also be power managed. Pipe 164 may include a blender of multiple layers of images into a composite image, X, Y coordinate rasterizer, and interface protocol packetizer. The interface protocol packetizer may be compliant at least with Display Port or Low-voltage differential signaling (LVDS), available from ANSI/TIA/EIA-644-A (2001), as well as variations thereof. Display interface 166 may include a DisplayPort or LVDS compatible interface and a parallel-in-serial-out (PISO) interface.
FIG. 1C depicts a high level block diagram of a timing controller for a display device in accordance with an embodiment. Timing controller 180 has the capability to respond to instructions from a host device to enter a self refresh display (SRD) mode that may include powering down components and/or capturing an image and repeatedly outputting the captured image to a display. In response to signal SRD_ON from a host, SRD control block activates the frame buffer to capture a frame and the SRD control block controls the multiplexer (MUX) to transfer the captured frame to the output port. After the frame buffer captures a frame, the host may read a register in the panel that indicates that the capture has taken place and that the timing controller displays a captured image. After the signal SRD_ON is deactivated, SRD control block deactivates the frame buffer and associated logic and causes the MUX to transfer incoming video from the input port (RX in this case) to the output port (TX). Timing controller 180 may use less power because the frame buffer is turned off and the logic clock gated when the self refresh display mode is exited. In various embodiments, SRD_ON and SRD_STATUS can be signals or configured in a register.
FIG. 2 depicts an example format of signals transmitted over multiple lanes on a DisplayPort compatible interface. In particular, FIG. 2 reproduces FIG. 2-14 of the Video Electronics Standards Association (VESA) DisplayPort Standard, Version 1, Revision 1a (2008) (hereafter “DP1.1a specification”). However, embodiments of the present invention can be used in any version and variation of DisplayPort as well as other standards. DisplayPort specifies the availability of secondary data packets to transmit information at the vendor's discretion. Vendor-specific extension packets are a type of secondary data packet that can be used to control the display self refresh functionality over embedded DisplayPort (eDP). The basic structure of the header information for these secondary data packets is described in table 2-33 of section 2.2.5 of the DP1.1a specification, which is reproduced below in table 1.
Byte# Content
HB0 Secondary-data Packet ID
HB1 Secondary-data Packet type
HB2 Secondary-data-packet-specific header byte0
HB3 Secondary-data-packet-specific header byte1
FIG. 3 depicts an example manner of communication of secondary data packets over one and more lanes of a DisplayPort compatible interface. In particular, FIG. 3 reproduces FIG. 2-24 of the DP1.1a specification. As shown, secondary data packets can include header bytes, parity bytes, and data bytes.
In accordance with various embodiments, the following table provides an example of commands that can be transmitted in header bytes of secondary data packets, in accordance with various embodiments. Commands can be performed by a target device such as a display with capability to perform self refresh display.
Byte# Example of Contents
HB0 Specifies generation number of specification:
00h: Revision 0 (Haswell generation)
HB1 04h (extension packet type indicator as defined by DP1.1a
HB2 Bits 0-2 used for controls
Bits 7:3 = Reserved (all 0's)
HB3 Reserved (all 0's)
Various embodiments provide controls in bits 0-2 of header byte HB2. Table 3 describes example commands in bits 0, 1, and 2 in header byte HB2.
Control Field Bit Definition
B0: Frame Type B0 = 0 means current frame is identical to the one
B0 = 1 means current frame is different from the
previously sent frame.
B1: Source SRD Source SRD state control field indicates the source's
State display controller state, which is used as a command by
the target device to manage its local controller.
B1 = 0 means SRD_Off. Source state is such that
normal display processing occurs and the eDP link
B1 = 1 means SRD_On. Source state is such that
normal display processing may be disabled and the eDP
link may be placed in standby.
B2: Link Standby B2 = 0 means main link to remain in normal active state.
Enable B2 = 1 enables main link to enter standby state.
Bit B0 indicates whether a frame to be sent to a target device has not changed from a previous frame that was sent to the target device. Bit B0 indicates whether a target device is to store an incoming image in a buffer. The target device can be a display with capability to enter self refresh display mode and display an image from a buffer. Bit B0 can be used where an application is to update an image on a display. An update can be made to wakeup a panel and tell the panel that one or more modified frame(s) are to be transmitted to the display and to store the frames. After storing the frames, the display and display system can return to low power state and the display system can use the updated frame for self refresh display.
Bit B1 indicates whether the target device is to enter self refresh display mode or remain in normal operation. Bit B1 also indicates whether normal display processing occurs and the link between the source and target device remains in normal active state.
Bit B2 indicates whether to power down a main link. For example, the main link can be a differential pair wire having connectors, d+ and d−. The link can transmit RGB content or other types of content. The link can be powered down or enter lower power mode.
Standard Embedded DisplayPort implementations support two link states: (1) full on (“Normal Operation”) in which video data is transmitted to a panel and (2) full off (“ML Disabled”) in which a lid is closed on a laptop and the display interface is turned off because video is not required. The standard Embedded DP implementation also supports an intermediate set of training-related transitional states. SRD adds an additional state: “ML Standby.” State “ML Standby” enables a receiver to implement additional power management techniques for additional power reductions. For example, a receiver bias circuitry and PLLs can be turned-off. For example, components described with regard to FIG. 1B can enter lower power state or turn-off. State “ML Standby” can turn off a display interface and display link but use an image stored in panel for SRD.
FIG. 4 depicts an example of a sequence of events for entry into ML standby mode. A DisplayPort main link can be used to transmit signals X, Y, and Z. In some embodiments, header byte HB2 can be used to transmit signals X, Y, and Z. Signal X represents whether the current frame, that is to be transmitted after a VBI, is modified or unmodified relative to a previously transmitted frame. In this example, the value of signal X can indicate that the current frame is modified or unmodified relative to the previously transmitted frame. In this example, it does not matter whether frame is modified or unmodified. Signal Y indicates whether SRD is on or off. In this case, signal Y indicates that SRD state is ON. Signal Z indicates whether a link standby entry is to occur. In this case, signal Z indicates link standby is to be entered.
In some embodiments, header byte HB2 can be used to transmit signals X, Y, and Z. To transmit X, Y, and Z, the following scheme can be used: bit B0 represents X, bit B1 represents Y, and bit B2 represents Z.
Segment “Active” can include RGB color data for transmission to a display. Segment “BS” can indicate a start of a vertical blank interval in the system. Segment “BS to stdby” indicates a delay between a start of a vertical blank interval and a start of standby mode.
FIG. 5 depicts an example of a sequence of events for exit from ML standby mode. In particular, states of the main link and auxiliary channel are described. The main link state is in state “Standby.” The source initiates ML Standby exit using an AUX channel to transmit a write operation. Command WR can be used to write to register address location 00600h to wake up the target device and cause the target device to exit ML standby mode. Other register address locations can be used. The target device monitors location 00600h and wakes up on reading a wake up command in that location. After some delay, the target device transmits command ACK to the host using an AUX channel to indicate acknowledgement of receipt of the WR command. The length of the delay between receipt of WR and transmission of ACK can be defined by the DisplayPort Specification.
On detecting the write event, the target device power-ups the main link receiver and re-enters the training state to be ready for link training. Accordingly, as shown, the main link enters the state “Training.” Re-entering the training state after exiting standby mode without explicit command provides faster synchronization. After the source completes sending the write transaction, the source may initiate link training. The transmitter may initiate either full training or Fast Link Training as described in the DP specification. A target device could be turned off and lose awareness of need to train when it wakes up. Causing the target device to train immediately after exiting standby allows full power down of a DP receiver.
receiving, at a display controller, at least one command in a header byte of a secondary data packet, wherein the secondary data packet is in compliance with a DisplayPort specification and the at least one command comprises: an indication of whether a frame is unchanged from another frame sent prior to the frame and provides the same image data as that of the another frame or changed from the another frame and provides different image data as that of the another frame, a command to enter self refresh mode, and a command to reduce power of a link and wherein a single bit represents at least one command;
receiving, at the display controller, the frame associated with the at least one command; and
requesting, at the display controller, performance of an action based on the at least one command, wherein in response to enabled self refresh mode and an indication that a frame is changed from another frame, performance of an action based on the at least one command comprises:
storing the changed frame associated with the command into a buffer and maintaining self refresh mode while using the stored changed frame for self refresh.
2. The method of claim 1, wherein when the at least one command comprises an indication that a frame is changed from the another frame, performance an action based on of the at least one command comprises:
a display system exiting lower power mode prior to the storing the frame; and
the display system entering lower power mode after the storing the frame.
3. The method of claim 1, wherein when the at least one command comprises a command to reduce power of a link, performance of an action based on the at least one command comprises:
reducing power of a main link.
4. The method of claim 1, wherein each of the at least one command is stored in a different bit of header byte HB2 as defined in section 2.2.5 of the DisplayPort version 1.1a.
receiving the frame after a vertical blanking interval.
an interface, the interface to receive at least one command in a header byte of a secondary data packet, wherein the secondary data packet is in compliance with a DisplayPort specification, wherein the at least one command comprises: an indication of whether a frame is unchanged from another frame sent prior to the frame and is to provide the same image data as that of the another frame or whether the frame is changed from another frame and is to provide different image data than that of the another frame, a command to enter self refresh mode, and a command to reduce power of a link, and wherein a different bit is to represent each command and wherein the interface is to receive the frame associated with the at least one command; and
a controller of the display, the controller to perform an action based on the at least one command, wherein in response to enabled self refresh mode and an indication that a frame is changed from another frame, the controller is to store the changed frame associated with the command into a buffer and to maintain a self refresh mode with use of the stored changed frame for self refresh.
7. The system of claim 6, wherein when the at least one command comprises an indication that a frame is changed from the another frame, the controller is to request:
exit from lower power mode prior to storage of the frame into the buffer; and
enter lower power mode after storage of the frame into the buffer.
8. The system of claim 6, wherein when the at least one command comprises a command to reduce power of a link, the controller is to request:
reduction of power of a main link.
9. The system of claim 6, wherein each of the at least one command is stored in a bit of header byte HB2 as defined in section 2.2.5 of the DisplayPort version 1.1a.
10. The system of claim 6, wherein the interface is to receive the frame after a vertical blanking interval.
11. The system of claim 6, further comprising a host system to transmit the secondary data packet to the interface.
12. At least one non-transitory computer-readable medium comprising instructions stored thereon, which when executed by a computer, cause the computer to:
receive at least one command in a header byte of a secondary data packet, wherein the secondary data packet is in compliance with a DisplayPort specification and the at least one command comprises: an indication of whether a frame is unchanged from another frame sent prior to the frame and provides the same image data as that of the another frame or whether the frame is changed from the another frame and provides different image data than that of the another frame, a command to enter self refresh mode, and a command to reduce power of a link;
receive the frame associated with the at least one command; and
request performance of an action based on the at least one command, wherein in response to enabled self refresh mode and an indication that a frame is changed from another frame, the action comprises storage of the changed frame associated with the command into a buffer and maintain a self refresh mode with use of the stored changed frame for self refresh.
13. The medium of claim 12, wherein
when the at least one command comprises an indication that a frame is not unchanged from another frame, the at least one command requests:
exit from lower power mode,
storage of the frame associated with the command into a buffer, and
entrance into lower power mode; and
when the at least one command comprises a command to reduce power of a link, the at least one command requests reducing power of a main link.
14. The medium of claim 12, wherein each of the at least one command is stored in a bit of header byte HB2 as defined in section 2.2.5 of the DisplayPort version 1.1a.
US12890217 2010-09-24 2010-09-24 Techniques to transmit commands to a target device to reduce power consumption Active 2031-09-06 US9052902B2 (en)
US12890217 US9052902B2 (en) 2010-09-24 2010-09-24 Techniques to transmit commands to a target device to reduce power consumption
KR20137008235A KR101549819B1 (en) 2010-09-24 2011-09-26 Techniques to transmit commands to a target device
CN 201180002742 CN102741809B (en) 2010-09-24 2011-09-26 Techniques for sending commands to the target device
CN 201410724562 CN104484028A (en) 2010-09-24 2011-09-26 Techniques to transmit commands to a target device
KR20157028612A KR20150119974A (en) 2010-09-24 2011-09-26 Techniques to transmit commands to a target device
EP20110827711 EP2619653A4 (en) 2010-09-24 2011-09-26 Techniques to transmit commands to a target device
KR20147036634A KR101574047B1 (en) 2010-09-24 2011-09-26 Techniques to transmit commands to a target device
PCT/US2011/053237 WO2012040697A3 (en) 2010-09-24 2011-09-26 Techniques to transmit commands to a target device
EP20140192885 EP2857930A3 (en) 2010-09-24 2011-09-26 Techniques to transmit commands to a target device
JP2013530388A JP5636111B2 (en) 2010-09-24 2011-09-26 Technology to send a command to the target device
JP2014212429A JP2015008022A (en) 2010-09-24 2014-10-17 Technique to transmit command to target device
US14578999 US20150113308A1 (en) 2010-09-24 2014-12-22 Techniques to transmit commands to a target device
US14578999 Continuation US20150113308A1 (en) 2010-09-24 2014-12-22 Techniques to transmit commands to a target device
US20120079295A1 true US20120079295A1 (en) 2012-03-29
US9052902B2 true US9052902B2 (en) 2015-06-09
ID=45871902
US12890217 Active 2031-09-06 US9052902B2 (en) 2010-09-24 2010-09-24 Techniques to transmit commands to a target device to reduce power consumption
US14578999 Abandoned US20150113308A1 (en) 2010-09-24 2014-12-22 Techniques to transmit commands to a target device
US (2) US9052902B2 (en)
EP (2) EP2857930A3 (en)
JP (2) JP5636111B2 (en)
KR (3) KR101574047B1 (en)
CN (2) CN102741809B (en)
WO (1) WO2012040697A3 (en)
US20120207208A1 (en) * 2011-02-10 2012-08-16 David Wyatt Method and apparatus for controlling a self-refreshing display device coupled to a graphics controller
US9047085B2 (en) 2011-03-14 2015-06-02 Nvidia Corporation Method and apparatus for controlling sparse refresh of a self-refreshing display device using a communications path with an auxiliary communications channel for delivering data to the display
JP6176168B2 (en) * 2014-03-26 2017-08-09 ソニー株式会社 Transmission apparatus and transmission method, receiving apparatus and receiving method, a transmission system, and program
US20150379665A1 (en) * 2014-06-27 2015-12-31 Seh W. Kwa Power Optimization with Dynamic Frame Rate Support
KR20160033549A (en) * 2014-09-18 2016-03-28 삼성전자주식회사 Image Processing Device and Method including a plurality of image signal processors
US20170109859A1 (en) * 2015-10-20 2017-04-20 Nvidia Corporation Partial refresh of display devices
US20020024489A1 (en) * 1994-02-25 2002-02-28 Jun Koyama Active matrix type electro-optical device and method of driving the same
US20060082587A1 (en) 2004-10-18 2006-04-20 Genesis Microchip Inc. Virtual extended display information data (EDID) in a flat panel controller
US20060082570A1 (en) 2004-10-18 2006-04-20 Genesis Microchip Inc. Acquisition of extended display identification data (EDID) in a display controller in a power up mode from a power down mode
KR20070021799A (en) 2005-08-19 2007-02-23 삼성전자주식회사 Display apparatus and control mathod thereof
US20090204840A1 (en) * 2008-02-12 2009-08-13 Nec Lcd Technologies, Ltd. Browsing terminal, charging terminal, and communication system as well as transmitting/receiving system using the same
US20100080218A1 (en) * 2008-09-29 2010-04-01 Seh Kwa Protocol extensions in a display port compatible interface
US20100164968A1 (en) 2008-12-30 2010-07-01 Kwa Seh W Hybrid graphics display power management
US7966436B2 (en) * 2007-12-28 2011-06-21 Mtekvision Co., Ltd. Data transmitter having high and low speed transmission units
US8704839B2 (en) * 2010-05-26 2014-04-22 Stmicroelectronics, Inc. Video frame self-refresh in a sink device
JP2007067526A (en) * 2005-08-29 2007-03-15 Sharp Corp Image processor
CN101159128A (en) 2006-09-29 2008-04-09 英特尔公司 Graphics processor and method for controlling a display panel in self-refresh and low-response-time modes
CN101345039A (en) 2007-07-11 2009-01-14 创世纪微芯片公司 Dynamic resource re-allocation in a packet based video display interface
US20110196998A1 (en) * 2008-09-29 2011-08-11 Seh Kwa Protocol extensions in a display port compatible interface
JP2010156970A (en) 2008-12-30 2010-07-15 Intel Corp Hybrid graphics display power management
"Section 2.2.5.4 Extension Packet", VESA DisplayPort Standard, Video Electronics Standards Association, Version 1, Revision 1a, Jan. 11, 2008, pp. 1 and 81-83.
"VESA DisplayPort Standard", Video Electronics Standards Association (VESA), Version 1.1a, Jan. 11, 2008, 5 pages.
"VESA Embedded DisplayPort (eDP) Standard", VESA eDP Standard, Video Electronics Standards Association, Version 1.1, Oct. 23, 2009, pp. 1-32.
"VESA Embedded DisplayPort (eDP)", VESA eDP Standard, VESA eDP Standard, Video Electronics Standards Association, Version 1, Dec. 22, 2008, pp. 1-23.
"VESA Embedded DisplayPort Standard", eDP Standard, Video Electronics Standards Association, Version 1.2, May 5, 2010, pp. 1-53.
International Preliminary Report on Patentability for PCT Application No. PCT/US2011/053237, mailed on Apr. 4, 2013, 5 pages.
International Search Report & Written Opinion for PCT Application No. PCT/US2011/053237, mailed Apr. 24, 2012, 10 pages.
Non-Final Office Action received in U.S. Appl. No. 12/286,192, mailed Apr. 29, 2010, 6 pages.
Non-Final Office Action received in U.S. Appl. No. 13/089,731, mailed Jul. 22, 2011, 6 pages.
Non-Final Office Action received in U.S. Appl. No. 13/349,276, mailed Jul. 2, 2012, 6 pages.
Office Action received for Chinese Patent Application No. 200910221453.6, mailed Oct. 10, 2011, 8 pages, including 4 pages of English translation.
Office Action Received for Chinese Patent Application No. 201180002742.2, mailed on Jan. 21, 2015, 9 Pages of Chinese Office Action and 8 Page Of English Translation.
Office Action Received for Japanese Patent Application No. 2013-530388, mailed on Apr. 1, 2014, 3 Pages of Japanese Office Action and 3 Pages of English Translation.
Office Action received for Korean Patent Application No. 10-2009-0092283, mailed Feb. 12, 2011, 5 pages, including 2 pages of English translation.
Office Action received for Korean Patent Application No. 10-2009-0092283, mailed Oct. 27, 2011, 5 pages, including 2 pages of English translation.
Office Action received for Korean Patent Application No. 10-2009-111387, mailed Mar. 9, 2011, 9 pages, including 4 pages of English translation.
Office Action Received for Korean Patent Application No. 10-2014-7036634, mailed on Mar. 26,2015, 3 Pages of Korean Office Action and 1 Page of Enlgish transaltion.
Office Action Received for Korean Patent Application No. 2013-7008235, mailed on May 1, 2014, 1 Page of English Translation only.
Office Action Received for Korean Patent Application No. 2013-7008235, mailed on Nov. 27, 2014, 3 Pages of Korean Office Action and 1 Page Of English Translation.
Office Action received in Chinese Patent Application No. 200910221453.6, mailed Jul. 23, 2012, 5 pages of Office Action including 2 pages of English translation.
Office Action Received in Chinese Patent Application No. 201180002742.2, mailed on Dec. 20, 2013, 8 pages of English Translation and 7 pages of Office Action.
Office Action Received in Chinese Patent Application No. 201180002742.2, mailed on Jul. 15, 2014, 7 pages of English Translation and 7 pages of Office Action.
Office Action received in Japanese Patent Application No. 10-2009-222990, mailed on Aug. 2, 2011, 4 pages, including 2 pages of English translation.
Office Action Received in Japanese Patent Application No. 2012-031772, mailed on May 14, 2013, 2 pages of English Translation and 2 pages of Office Action.
Office Action received in Korean Patent Application No. 10-2009-92283, mailed Apr. 9, 2012, 8 pages, including 4 pages of English translation.
Office Action received in Korean Patent Application No. 10-2009-92283, mailed Oct. 31, 2012, 7 pages of Office Action including 4 pages of English translation.
Office Action Received in Taiwan Patent Application No. 98132686, mailed on Nov. 5, 2013, 1 page of English Translation and 5 pages of Office Action.
Search Report Received in Taiwan Patent Application No. 98132686, mailed Dec. 26, 2012, 19 pages of Taiwanese Office Action and 1 page of English Translation of Search Report and 6 pages of English Translation of Office Action.
VESA DisplayPort Standard Version 1, Revision 1a; Jan. 11, 2008. *
VESA DisplayPort Standard, Video Electronics Standards Association, Version 1, Revision 1a, Jan. 11, 2008, 238 pages.
Video Electronics Standards Association, VESA DisplayPort Standard, "Section 2.2.5 Secondary-data Packing Formats," Version 1, Revision 1a, Jan. 11, 2008, pp. 71-83.
KR20150119974A (en) 2015-10-26 application
WO2012040697A2 (en) 2012-03-29 application
KR20150008504A (en) 2015-01-22 application
JP2015008022A (en) 2015-01-15 application
EP2619653A2 (en) 2013-07-31 application
KR101574047B1 (en) 2015-12-02 grant
CN102741809B (en) 2016-01-27 grant
KR20130064798A (en) 2013-06-18 application
JP5636111B2 (en) 2014-12-03 grant
US20150113308A1 (en) 2015-04-23 application
CN102741809A (en) 2012-10-17 application
JP2013539123A (en) 2013-10-17 application
US20120079295A1 (en) 2012-03-29 application
KR101549819B1 (en) 2015-09-11 grant
EP2857930A3 (en) 2015-12-23 application
CN104484028A (en) 2015-04-01 application
EP2857930A2 (en) 2015-04-08 application
EP2619653A4 (en) 2015-12-23 application
WO2012040697A3 (en) 2012-06-14 application
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HAYEK, GEORGE R.;WITTER, TODD M.;KWA, SEH;AND OTHERS;SIGNING DATES FROM 20100916 TO 20100920;REEL/FRAME:027899/0597