CTFR 18/686,859 CTFR 88053 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Response to Arguments Applicant’s arguments with respect to claims 1-30 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Claims 1, 6-9, 12, 17-17, 21, 27, 29, and 30 have been amended. The VISE and HUSSAIN’s references correctly do not teach claims 1, 21, 29-30 as now amended by Applicant, further consideration of the cited reference show alternate teachings and figures which do fully teach claim 1, as set forth in the new grounds of rejection. Inasmuch as the newly cited portions of the Sinha reference can be considered new grounds of rejection, such new grounds of rejection are necessitated by Applicant’s amendments to the claims. Claims 1-30 are still pending. 07-30-03-h AIA Claim Interpretation The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph: (A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function; (B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and (C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Regarding claim 29 , the claim limitations in this application that use the word “means” (or “step”): means for receiving each of a plurality of frames in a scene; means for converting a data format for each of the plurality of frames to one or more display stream compression (DSC) bit streams for each of the plurality of frames; means for storing the one or more DSC bit streams for each of the plurality of frames in a first memory or a first cache; means for reading the one or more DSC bit streams for each of the plurality of frames from the first memory or the first cache; and means for transmitting , to a display panel based on an instruction , the one or more DSC bit streams for each of the plurality of frames.”, in this claim with functional languages create a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function. Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. If applicant does not intend to have this/these limitations interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim Rejections - 35 USC § 101 Applicant’s arguments with respect to claim 30 has been considered but are moot because Applicant has been amended with A non-transitory computer-readable medium storing computer executable code for display processing, the code when executed by a processor causes the processor to:..”. Claim Rejections - 35 USC § 103 07-20-aia AIA The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. 07-21-aia AIA Claim s 1-8, 10-11, 21-22, 25 and 29-30 are rejected under 35 U.S.C. 103 as being unpatentable over VIDEO ELECTRONIC STANDARDS ASSOCIATION: VESA Display Stream Compression (DSC) Standard”, Version 1.2a, Not Know, No.VESA_1.2a, 18 January 2017 (hereinafter VESA) in view of HUSSAIN et al. (US 20210407456 A1) . Regarding claim 1 . VESA discloses an apparatus for display processing, comprising: memory; and at least one processor coupled to the memory and configured to: receive each of a plurality of frames in a scene (see page 26, The DSC bitstream consists of one or more pictures: a picture is either a frame (when coding progressive format video) or a field (when coding interfaced format video) ; convert a data format for each of the plurality of frames to one or more display stream compression (DSC) bit streams for each of the plurality of frames (see page 28, Figure 3-4 illustrates the DSC encoding process, which generates bitstreams that precisely conform to the independently specified bit rate. The bit rate is specified in units of bits per pixel time, and as such, the rate is specified algorithmically because units of pixel time are the same at the encoder’s input and output. The number of bits used to code each pixel group can vary considerably. The rate buffer converts the variable number of bits used to code each group into a constant bit rate. The encoding process includes a rate control (RC) to manage rate buffer fullness.) ; store the one or more DSC bit streams for each of the plurality of frames in a first memory or a first cache (see pages 26 and 29, Figure 3-4: The encoding process produces bitstreams that conform to the hypothetical reference decoder (HRD) constraints. The HRD is an idealized model of a decoder that comprises a rate buffer model that is required to neither overflow nor underflow. The HRD rate buffer model is closely related to the rate buffer of the encoding process.) ; read the one or more DSC bit streams for each of the plurality of frames from the first memory or the first cache (see Figure 3.4: Bitstream Output) ; and VESA dose not disclose transmit, to a display panel based on an instruction , the one or more DSC bit streams for each of the plurality of frames . However, HUSSAIN discloses: transmit, to a display panel based on an instruction , the one or more DSC bit streams for each of the plurality of frames ([0015] The memory 150 holds a frame of pixel data. In some embodiments, the pixel data stored at the memory 150 is compressed using a compression algorithm such as, for example, VESA Display Stream Compression (DSC). The display controller 155 reads the stored pixel data from the memory 150 at an interval based on the current programming of the panel refresh rate. [0016] In some embodiments, the display device 140 is implemented as a variable refresh rate (VRR) display that synchronizes refreshing the display panel 160 with the generation of frames at the GPU 115 such that the refresh rate of the display panel 160 is variable. For example, by adjusting a vertical blanking interval of the display panel 160 , the GPU 115 can ensure that the display panel 160 is refreshed only after a new frame is fully written to the back buffer and is ready for display at the display panel 160. [0017] As a general operational overview, the memory 120 stores one or more sets of executable software instructions to manipulate the CPU 110 and GPU 115 to render a video stream including a series of display frames such as display frame 130 and corresponding metadata and to transmit this video stream to the display device 140 via the display interfaces 125 , 145 and the interconnect 135 . At the display device 140 , the display controller 155 receives each display frame and corresponding metadata in turn and processes the display frame for display in sequence at the display panel 160 during a corresponding frame period. As will be appreciated by one skilled in the art, the display device 140 is generally configured to display the most recent frame generated by the GPU 115 by refreshing the display panel 160 using the pixel data that the display device 140 receives from the GPU 115 ) . Regarding claim 2 . VESA in view HUSSAIN discloses the apparatus of claim 1, VESA further discloses wherein the at least one processor is further configured to: encode the one or more DSC bit streams for each of the plurality of frames, wherein the one or more DSC bit streams are encoded after being converted from the data format (see Figure 3-4: Encoding Process and page 29, The DSC bitstream and decoding process are designed to facilitate decoding of 3 pixels/clock in practical hardware decoder implementations. Hardware encoder implementations are possible at 1 pixel/clock.). Regarding claim 3 . VESA in view HUSSAIN discloses the apparatus of claim 2 (as rejected above), and VESA in view HUSSAIN further discloses wherein the one or more DSC bit streams are encoded in a physical sub-pixel format, a red (R) green (G) blue (B) (RGB) format, or a luminance (Y) chrominance (UV) (YUV) format (Figure 3-4: Flatness Determination; see page 29, Color space conversion (in the case of RGB output) from reversible YCoCg (YCoCg-R) to RGB, which is bypassed for YCbCr output). Regarding claim 4 . VESA in view HUSSAIN discloses the apparatus of claim 1 (as rejected above), VESA in view HUSSAIN further discloses wherein the at least one processor is further configured to: pre-calibrate or preprocess one or more pixels for each of the plurality of frames, wherein the one or more pixels correspond to the data format for each of the plurality of frames (see Figure 3-4: Flatness Determination). Regarding claim 5 . VESA in view HUSSAIN discloses the apparatus of claim 4, VESA further discloses (as rejected above), VESA in view HUSSAIN further discloses wherein the one or more pixels are pre-calibrated or preprocessed with a system-on-chip (SoC) Demura block, with color processing, with scaling processing, with sharpness processing, or without Demura processing (Not Know, Figure 3-4; flatness determination, page 28: color space conversion). Regarding claim 6 . VESA in view HUSSAIN discloses the apparatus of claim 1 (as rejected above) , and VESA in view HUSSAIN further discloses wherein to receive each of the plurality of frames, the at least one processor is configured to receive (HUSSAIN, see at least par. [0017] As a general operational overview, the memory 120 stores one or more sets of executable software instructions to manipulate the CPU 110 and GPU 115 to render a video stream including a series of display frames such as display frame 130 and corresponding metadata and to transmit this video stream to the display device 140 via the display interfaces 125 , 145 and the interconnect 135 . At the display device 140 , the display controller 155 receives each display frame and corresponding metadata in turn and processes the display frame for display in sequence at the display panel 160 during a corresponding frame period.) each of the plurality of frames sequentially or receive the plurality of frames in a burst operation (common general knowledge, this is how data is typically transmitted). Regarding claim 7 . VESA in view HUSSAIN discloses the apparatus of claim 1 (as rejected above) , and VESA further discloses wherein to receive each of the plurality of frames (HUSSAIN, see at least par. [0017] As a general operational overview, the memory 120 stores one or more sets of executable software instructions to manipulate the CPU 110 and GPU 115 to render a video stream including a series of display frames such as display frame 130 and corresponding metadata and to transmit this video stream to the display device 140 via the display interfaces 125 , 145 and the interconnect 135 . At the display device 140 , the display controller 155 receives each display frame and corresponding metadata in turn and processes the display frame for display in sequence at the display panel 160 during a corresponding frame period.)) , the at least one processor is configured to each of the plurality of frames from at least one of a graphics processing unit (GPU), a central processing unit (CPU), or a host device (Figure 3-1: Image source). Regarding claim 8 . VESA in view HUSSAIN discloses the apparatus of claim 1 (as rejected above) , and VESA further discloses wherein to receive each of the plurality of frames (HUSSAIN, see at least par. [0017] As a general operational overview, the memory 120 stores one or more sets of executable software instructions to manipulate the CPU 110 and GPU 115 to render a video stream including a series of display frames such as display frame 130 and corresponding metadata and to transmit this video stream to the display device 140 via the display interfaces 125 , 145 and the interconnect 135 . At the display device 140 , the display controller 155 receives each display frame and corresponding metadata in turn and processes the display frame for display in sequence at the display panel 160 during a corresponding frame period.) , the at least one processor is configured to receive each of the plurality of frames is from a second memory or a second cache (common general knowledge). Regarding claim 10 . VESA in view HUSSAIN discloses the apparatus of claim 1 (as rejected above) , and VESA in view HUSSAIN further discloses wherein the data format for each of the plurality of frames is a pixel format (section 3.1: The encoder compress incoming pixels to form a bitstream). Regarding claim 11. VESA in view HUSSAIN discloses the apparatus of claim 1 (as rejected above) , and VESA further discloses wherein the first cache is a system-on-chip (SOC) cache, a last level cache (LLC), or a low power on-chip cache, and wherein the first memory is a system-on-chip (SOC) memory or a double data rate (DDR) memory (paragraph 152: LLC; paragraph 75 DDR). Regarding claim 21 . A method of display processing of claim 21 use the apparatus of claim 1 to process. Therefore, claim 21 performs same steps of claim 1. Therefore, claim 21 further rejected based on the same rationale as claim 1 set forth above and incorporated herein. Regarding claim 22. VESA in view HUSSAIN discloses the apparatus of claim 21 (as rejected above) , and VESA further discloses further comprising: encoding the one or more DSC bit streams for each of the plurality of frames, wherein the one or more DSC bit streams are encoded after being converted from the data format, wherein the one or more DSC bit streams are encoded in a physical sub-pixel format, a red (R) green (G) blue (B) (RGB) format, or a luminance (Y) chrominance (UV) (YUV) format (Figure 3-4: Flatness Determination). Regarding claim 25 . VESA in view HUSSAIN discloses the apparatus of claim 21 (as rejected above) , and VESA further discloses wherein each of the plurality of frames is received from a second memory or a second cache, wherein each of the plurality of frames is stored in the second memory or the second cache by at least one of a graphics processing unit (GPU), a central processing unit (CPU), or a host device, and wherein each of the plurality of frames is received from the second memory or the second cache after being stored in the second memory or the second cache (Figure 3-1: Image source). Regarding claim 29 . An apparatus for display processing perform same steps of claim 1. Therefore, the apparatus for display processing of claim 29 is further rejected based on the same rationale as claim 1 set forth above and incorporated herein. Regarding claim 30. A non-transitory computer-readable medium storing computer executable code for display processing, the code when executed by a processor causes the processor to perform same step of claim 1. Therefore, the computer-readable medium of claim 30 is further rejected based on the same rationale as claim 1 set forth above and incorporated herein . 07-21-aia AIA Claim s 9, 14-19, 23, 26-28 are rejected under 35 U.S.C. 103 as being unpatentable over VIDEO ELECTRONIC STANDARDS ASSOCIATION: VESA Display Stream Compression (DSC) Standard”, Version 1.2a, Not Know, No.VESA_1.2a, 18 January 2017 (hereinafter VESA) in view of HUSSAIN et al. (US 20210407456 A1), as applied claim 1 above, and further in view of AKIYAMA et al. (US 20210097640 A1) . Regarding claim 9. VESA in view HUSSAIN discloses the apparatus of claim 8 (as rejected above), VESA does not disclose wherein each of the plurality of frames is stored in the second memory or the second cache by at least one of a graphics processing unit (GPU), a central processing unit (CPU), or a host device , and wherein to receive each of the plurality of frames (HUSSAIN, see at least par. [0017] As a general operational overview, the memory 120 stores one or more sets of executable software instructions to manipulate the CPU 110 and GPU 115 to render a video stream including a series of display frames such as display frame 130 and corresponding metadata and to transmit this video stream to the display device 140 via the display interfaces 125 , 145 and the interconnect 135 . At the display device 140 , the display controller 155 receives each display frame and corresponding metadata in turn and processes the display frame for display in sequence at the display panel 160 during a corresponding frame period) , the at least one processor is configured to receive each of the plurality of frames is received from the second memory or the second cache after being stored in the second memory or the second cache. However, AKIYAMA discloses: wherein each of the plurality of frames is stored in the second memory or the second cache by at least one of a graphics processing unit (GPU), a central processing unit (CPU), or a host device , and wherein receive each of the plurality of frames, the at least one processor is configured to receive (AKIYAMA, see at least [0195] In a system that uses one or more integrated graphics devices, engines, processor, systems, one or more display engine devices, and one or more discrete graphics devices, engines, processor, or systems, various embodiments can divide a workload either using alternate frame rendering (AFR), tile-based distributed rendering, checkerboard rendering (or other schemes) and use interface supported messages to transport image data from a discrete graphics processor to an integrated graphics processor so that the integrated graphics processor forms a frame. The integrated graphics processor provides the frame to a display. Forming the frame can be on a per-scanline or per tile (checkerboard) basis. A sink display engine sends interface supported messages to the appropriate source graphic controller to request and receive content based on which device has rendered image content.) each of the plurality of frames is received from the second memory or the second cache after being stored in the second memory or the second cache (AKIYAMA, see at least par. [0034] In some embodiments, the processor 102 includes cache memory 104. Depending on the architecture, the processor 102 can have a single internal cache or multiple levels of internal cache. In some embodiments, the cache memory is shared among various components of the processor 102. In some embodiments, the processor 102 also uses an external cache (e.g., a Level-3 (L3) cache or Last Level Cache (LLC)) (not shown), which may be shared among processor cores 107 using known cache coherency techniques. A register file 106 can be additionally included in processor 102 and may include different types of registers for storing different types of data (e.g., integer registers, floating point registers, status registers, and an instruction pointer register). Some registers may be general-purpose registers, while other registers may be specific to the design of the processor 102.). Regarding claim 14 . VESA in view HUSSAIN discloses the apparatus of claim 1 (as rejected above), but VESA in view HUSSAIN does not disclose wherein the instruction is from at least one of: a low power controller, a digital signal processor (DSP), a central processing unit (CPU), a sensor hub, or a microcontroller unit (MCU). However, AKIYAMA discloses: wherein the one or more DSC bit streams are transmitted based on an instruction from at least one of: a low power controller, a digital signal processor (DSP), a central processing unit (CPU), a sensor hub, or a microcontroller unit (MCU) (AKIYAM, see at least par. [0063] Input/output (I/O) circuitry 250 couples the GPU 239 to one or more I/O devices 252 such as digital signal processors (DSPs), network controllers, or user input devices. An on-chip interconnect may be used to couple the I/O devices 252 to the GPU 239 and memory 249. One or more I/O memory management units (IOMMUs) 251 of the I/O circuitry 250 couple the I/O devices 252 directly to the system memory 249. In one embodiment, the IOMMU 251 manages multiple sets of page tables to map virtual addresses to physical addresses in system memory 249. In this embodiment, the I/O devices 252, CPU(s) 246, and GPU(s) 239 may share the same virtual address space.). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the method and apparatus of VESA, to have a low power controller, a digital signal processor (DSP), a central processing unit (CPU), a sensor hub, or a microcontroller unit (MCU) , as provided by , wherein the one or more DSC bit streams are transmitted via a low constant frames-per-second (FPS) or a variable FPS, as provided by AKIYAMA. The modification provide an improved system and method for rendering and displaying visual content, thereby to allow[ing] applications that require less graphics processing performance to execute on integrated graphics controller and allowing the discrete graphics to power down in order to save power. (AKIYAMA, see par. [0002]). Regarding claim 15 . VESA in view HUSSAIN, and in view of AKIYAMA discloses the apparatus of claim 14 (as rejected above), and VESA in view of AKIYAMA further discloses wherein the instruction corresponds to a periodic transmission of the one or more DSC bit streams from the first memory or the first cache to the display panel via a display serial interface (DSI) or a hardware interface (AKIYAMA, see at least par. [0037] In some embodiments a display device 111 can connect to the processor(s) 102. The display device 111 can be one or more of an internal display device, as in a mobile electronic device or a laptop device or an external display device attached via a display interface (e.g., DisplayPort, embedded DisplayPort, MIPI, HDMI, etc.). In one embodiment the display device 111 can be a head mounted display (HMD) such as a stereoscopic display device for use in virtual reality (VR) applications or augmented reality (AR) applications.) . Regarding claim 16 . VESA in view HUSSAIN, and in view of AKIYAMA in view of AKIYAMA discloses the apparatus of claim 15 (as rejected above), and VESA in view of AKIYAMA further discloses wherein the periodic transmission of the one or more DSC bit streams is associated with a direct memory access (DMA) engine (AKIYAMA, see at least par. [0083] FIG. 2D is a block diagram of general purpose graphics processing unit (GPGPU) 270 that can be configured as a graphics processor and/or compute accelerator, according to embodiments described herein. The GPGPU 270 can interconnect with host processors (e.g., one or more CPU(s) 246) and memory 271, 272 via one or more system and/or memory busses. In one embodiment the memory 271 is system memory that may be shared with the one or more CPU(s) 246, while memory 272 is device memory that is dedicated to the GPGPU 270. In one embodiment, components within the GPGPU 270 and device memory 272 may be mapped into memory addresses that are accessible to the one or more CPU(s) 246. Access to memory 271 and 272 may be facilitated via a memory controller 268. In one embodiment the memory controller 268 includes an internal direct memory access (DMA) controller 269 or can include logic to perform operations that would otherwise be performed by a DMA controller.) . Regarding claim 17 . VESA in view HUSSAIN discloses VESA in view HUSSAIN (as rejected above), and VESA in view HUSSAIN further discloses wherein to read the one or more DSC bit streams (HUSSAIN, see par. [0015] The memory 150 holds a frame of pixel data. In some embodiments, the pixel data stored at the memory 150 is compressed using a compression algorithm such as, for example, VESA Display Stream Compression (DSC). The display controller 155 reads the stored pixel data from the memory 150 at an interval based on the current programming of the panel refresh rate) , the at least one processor is configured to read (HUSSAIN, see at pars. [0015-0016]) the one or more DSC bit streams are read from a system-on-chip (SOC) cache, a last level cache (LLC), a low power on-chip cache, a SOC memory, or a double data rate (DDR) memory. However, VESA in view of HUSSAIN does not disclose wherein to read the one or more DSC bit streams, the at least one processor is configured to read the one or more DSC bit streams are read from a system-on-chip (SOC) cache, a last level cache (LLC), a low power on-chip cache, a SOC memory, or a double data rate (DDR) memory. However, AKIYAMA discloses: wherein to read the one or more DSC bit streams, the at least one processor is configured to read the one or more DSC bit streams are read from a system-on-chip (SOC) cache, a last level cache (LLC), a low power on-chip cache, a SOC memory, or a double data rate (DDR) memory (AKIYAMA, see at least par. [0034] In some embodiments, the processor 102 includes cache memory 104 . Depending on the architecture, the processor 102 can have a single internal cache or multiple levels of internal cache. In some embodiments, the cache memory is shared among various components of the processor 102 . In some embodiments, the processor 102 also uses an external cache (e.g., a Level-3 (L3) cache or Last Level Cache (LLC)) (not shown), which may be shared among processor cores 107 using known cache coherency techniques). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the method and apparatus of VESA, to have wherein to read the one or more DSC bit streams, the at least one processor is configured to read the one or more DSC bit streams are read from a system-on-chip (SOC) cache, a last level cache (LLC), a low power on-chip cache, a SOC memory, or a double data rate (DDR) memory , as provided by AKIYAMA , wherein the one or more DSC bit streams are transmitted via a low constant frames-per-second (FPS) or a variable FPS, as provided by AKIYAMA. The modification provide an improved system and method for rendering and displaying visual content, thereby to allow[ing] applications that require less graphics processing performance to execute on integrated graphics controller and allowing the discrete graphics to power down in order to save power. (AKIYAMA, see par. [0002]). Regarding claim 18 . VESA in view of AKIYAMA discloses the apparatus of claim 1, and VESA in view of AKIYAMA further discloses wherein to read the one or more DSC bit streams (HUSSAIN, see par. [0015] The memory 150 holds a frame of pixel data. In some embodiments, the pixel data stored at the memory 150 is compressed using a compression algorithm such as, for example, VESA Display Stream Compression (DSC). The display controller 155 reads the stored pixel data from the memory 150 at an interval based on the current programming of the panel refresh rate) , the at least one processor is configured to read the one or more DSC bit streams are read by a lower power controller including at least one of a digital signal processor (DSP), a central processing unit (CPU), a sensor hub, or microcontroller unit (MCU) (AKIYAMA, see at least par. [0055] The graphics microcontroller 233 can be configured to perform various scheduling and management tasks for the graphics processor core 219. In one embodiment the graphics microcontroller 233 can perform graphics and/or compute workload scheduling on the various graphics parallel engines within execution unit (EU) arrays 222A-222F, 224A-224F within the sub-cores 221A-221F. In this scheduling model, host software executing on a CPU core of an SoC including the graphics processor core 219 can submit workloads one of multiple graphic processor doorbells, which invokes a scheduling operation on the appropriate graphics engine. Scheduling operations include determining which workload to run next, submitting a workload to a command streamer, pre-empting existing workloads running on an engine, monitoring progress of a workload, and notifying host software when a workload is complete. In one embodiment the graphics microcontroller 233 can also facilitate low-power or idle states for the graphics processor core 219, providing the graphics processor core 219 with the ability to save and restore registers within the graphics processor core 219 across low-power state transitions independently from the operating system and/or graphics driver stream software on the system.) . Regarding claim 19. VESA in view of AKIYAMA discloses the apparatus of claim 1, and VESA in view of AKIYAMA further discloses wherein the one or more DSC bit streams correspond to one or more pixels for each of the plurality of frames ([0251] By copying the display stream data to the integrated display engine's DDI, the amount of transferred data is reduced as data moves in native display format (e.g., RGB8 (8-bits red (R), 8-bits green (G), 8-bits blue (B)), RGB10 (10-bits R, 10-bits G, 10-bits B), RGB12 (12-bits R, 12-bits G, 12-bits B)) rather than using an FP16 data type (16-bits R, 16-bits G, 16-bit B), while also eliminating the need to carry alpha. Alpha is a value indicating the blending ratio of the foreground to background and is carried in the rendered frame from applications (overlay data), but is no longer present once compositing is done since all blending is now complete. Accordingly, PCIe bandwidth used to transfer image data can be reduced using native display format. Additionally, image data can be compressed using VESA’s Display Stream Compression (DSC) standard since no further processing of the display data. DSC can further reduce the PCIe bandwidth use requirements. Lossless or lossy compression schemes can be used. In cases where the interface or attached display does not support VESA DSC compression, a compression engine can be added before the DDI interface in the discrete display engine and DSC decompression added after the DDI interface in the integrated display engine.) . Regarding claim 23 . VESA in view of in view HUSSAIN and further in view AKIYAMA discloses the apparatus of claim 21 (as rejected above), and VESA in view of in view HUSSAIN and further in view AKIYAMA further discloses further comprising: pre-calibrating or preprocessing one or more pixels for each of the plurality of frames, wherein the one or more pixels correspond to the data format for each of the plurality of frames, wherein the one or more pixels are pre-calibrated or preprocessed with a system-on-chip (SoC) Demura block, with color processing, with scaling processing, with sharpness processing, or without Demura processing (AKIYAMA, see at least [0054] In one embodiment the SoC interface 232 enables the graphics processor core 219 to communicate with general-purpose application processor cores (e.g., CPUs) and/or other components within an SoC, including memory hierarchy elements such as a shared last level cache memory, the system RAM, and/or embedded on-chip or on-package DRAM. The SoC interface 232 can also enable communication with fixed function devices within the SoC, such as camera imaging pipelines, and enables the use of and/or implements global memory atomics that may be shared between the graphics processor core 219 and CPUs within the SoC. The SoC interface 232 can also implement power management controls for the graphics processor core 219 and enable an interface between a clock domain of the graphic core 219 and other clock domains within the SoC.) . Regarding claim 26 . VESA in view of HUSSAIN, and further in view of AKIYAMA discloses the apparatus of claim 21, and VESA in view of HUSSAIN, and further in view of AKIYAMA further discloses wherein the data format for each of the plurality of frames is a pixel format, wherein the first cache is a system-on-chip (SOC) cache, a last level cache (LLC), or a low power on-chip cache, wherein the first memory is a system-on-chip (SOC) memory or a double data rate (DDR) memory, wherein the one or more DSC bit streams are transmitted via a low constant frames-per-second (FPS) or a variable FPS, or wherein storing the one or more DSC bit streams in the first memory or the first cache comprises: writing the one or more DSC bit streams in the first memory or the first cache (AKIYAMA, see at least par. [0062] One or more combined level 1 (L1) caches and shared memory units 247 store graphics data such as texture data, vertex data, pixel data, ray data, bounding volume data, etc., locally within each multi-core group 240A. One or more texture units 247 can also be used to perform texturing operations, such as texture mapping and sampling. A Level 2 (L2) cache 253 shared by all or a subset of the multi-core groups 240A-240N stores graphics data and/or instructions for multiple concurrent graphics threads. As illustrated, the L2 cache 253 may be shared across a plurality of multi-core groups 240A-240N. One or more memory controllers 248 couple the GPU 239 to a memory 249 which may be a system memory (e.g., DRAM) and/or a dedicated graphics memory (e.g., GDDR6 memory).). Regarding claim 27 . VESA in view of HUSSAIN, and further in view of AKIYAMA discloses the apparatus of claim 21 (as rejected above), and VESA in view of HUSSAIN, and further in view of AKIYAMA further discloses wherein the instruction from at least one of: a low power controller, a digital signal processor (DSP), a central processing unit (CPU), a sensor hub, or a microcontroller unit (MCU), wherein the instruction corresponds to a periodic transmission of the one or more DSC bit streams from the first memory or the first cache to the display panel via a display serial interface (DSI) or a hardware interface, wherein the periodic transmission of the one or more DSC bit streams is associated with a direct memory access (DMA) engine (AKIYAM, see at least par. [0063] Input/output (I/O) circuitry 250 couples the GPU 239 to one or more I/O devices 252 such as digital signal processors (DSPs), network controllers, or user input devices. An on-chip interconnect may be used to couple the I/O devices 252 to the GPU 239 and memory 249. One or more I/O memory management units (IOMMUs) 251 of the I/O circuitry 250 couple the I/O devices 252 directly to the system memory 249. In one embodiment, the IOMMU 251 manages multiple sets of page tables to map virtual addresses to physical addresses in system memory 249. In this embodiment, the I/O devices 252, CPU(s) 246, and GPU(s) 239 may share the same virtual address space.). Regarding claim 28 . The method of claim 28, performs same steps of claims 17, 18 or 19. Therefore, claim 28 is further rejected based on the same rationale as claim 17, 18 or 19, set forth above and incorporated herein . 07-21-aia AIA Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over VIDEO ELECTRONIC STANDARDS ASSOCIATION: VESA Display Stream Compression (DSC) Standard”, Version 1.2a, Not Know, No.VESA_1.2a, 18 January 2017 (hereinafter VESA) in view of HUSSAIN et al. (US 20210407456 A1), as applied claim 1 above, and further in view of Serger, JR. (US 20220410911 A1) . Regarding claim 12 . VESA in view HUSSAIN discloses the apparatus of claim 1 (as rejected above), VESA in view HUSSAIN disclose wherein to transmit the one or more DSC bit streams (HUSSAIN, [0017] As a general operational overview, the memory 120 stores one or more sets of executable software instructions to manipulate the CPU 110 and GPU 115 to render a video stream including a series of display frames such as display frame 130 and corresponding metadata and to transmit this video stream to the display device 140 via the display interfaces 125, 145 and the interconnect 135) , the at least one processor is configured to transmit (HUSSAIN, see pars. [0015-0017]) the one or more DSC bit streams are via a low constant frames-per-second (FPS) or a variable FPS, but VESA in view HUSSAIN VESA in view HUSSAIN does not disclose wherein to transmit the one or more DSC bit streams, the at least one processor is configured to transmit. However, Serger discloses: wherein to transmit the one or more DSC bit streams, the at least one processor is configured to transmit the one or more DSC bit streams are via a low constant frames-per-second (FPS) or a variable FPS (Serger, JR. see at least par. [0492], Using the two self-signals can help in defining which mutual touch signal is detected on a touch panel, such as keypad 4415 , by a unique user. In particular, this can leverage a high rate of data capture, such as 300 frames per second, with high signal to noise ratio (SNR) and low drive signals and the capability to simultaneously transmit and receive on the same channel, allows for higher proximity detection and signal encoding and decoding. [0493] Any TX electrode 305 described herein can optionally be implemented as an electrode of a DSC 117 operable to simultaneously transmit and receive instead of being implemented as an electrode of an ID circuit 114 and/or 118 , and can optionally be implemented as an external electrode that is adjacent to, spread apart from, and/or not overlapping with another external sensor or XY pattern of electrodes. Any RX and/or button electrode 405 and/or 505 described herein can optionally be implemented as an electrode of a DSC 117 operable to simultaneously transmit and receive instead of being implemented as an electrode of an ID circuit 114 and/or 118 ) . Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the method and apparatus of VESA, to have wherein to transmit the one or more DSC bit streams, the at least one processor is configured to transmit the one or more DSC bit streams are via a low constant frames-per-second (FPS) or a variable FPS , as provided by Serger. The modification provide an improved system and method for rendering and displaying visual content, thereby to provide the received sensor signals to one or more computing devices for processing. A computing device is known to communicate data, process data, and/or store data. The computing device may be a cellular phone, a laptop, a tablet, a personal computer (PC), a work station, a video game device, a server, and/or a data center that support millions of web searches, stock trades, or on-line purchases every hour. (Serger, SR. see par. [0009]) . 07-21-aia AIA Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over VIDEO ELECTRONIC STANDARDS ASSOCIATION: VESA Display Stream Compression (DSC) Standard”, Version 1.2a, Not Know, No.VESA_1.2a, 18 January 2017 (hereinafter VESA) in view of HUSSAIN et al. (US 20210407456 A1), as applied claim 1 above, and further in view of WU et al. (US 20230230521 A1) . Regarding claim 13 . VESA in view of HUSSAIN discloses the apparatus of claim 1 (as rejected above), VESA in view of HUSSAIN does not disclose wherein to store the one or more DSC bit streams in the first memory or the first cache, the at least one processor is configured to: write the one or more DSC bit streams in the first memory or the first cache . However, WU disclose: wherein to store the one or more DSC bit streams in the first memory or the first cache, the at least one processor is configured to: write the one or more DSC bit streams in the first memory or the first cache (WU, see pars. [0217] The compression encoder 152 may encode the display data generated by the display controller in a specific scheme (e.g., a display stream compression (DSC) scheme determined by VESA). Through this, the display data generated by the display controller 151 may be compressed and the size of the data may be reduced. For example, the size of the display data generated by the display controller 151 may be reduced to 1/n through the encoding by the compression encoder 152. According to various embodiments of the disclosure, the compression encoder 152 may be omitted. For example, the display data may be delivered to the display driving circuit 200 without any compression process. [0224] The memory controller 227 may write the display data received from the interface controller 223 in the first memory 226. For example, the memory controller 227 may write the corresponding display data in the first memory 226 according to a frame rate of the display data that are to be delivered by the processor 150.). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the method and apparatus of VESA, to have wherein to store the one or more DSC bit streams in the first memory or the first cache, the at least one processor is configured to: write the one or more DSC bit streams in the first memory or the first cache , as provided by WU. The modification provide an improved system and method for rendering and displaying visual content, thereby to improving a screen quality of the display data (WU, see par. [0232]) . 07-21-aia AIA Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over VIDEO ELECTRONIC STANDARDS ASSOCIATION: VESA Display Stream Compression (DSC) Standard”, Version 1.2a, Not Know, No.VESA_1.2a, 18 January 2017 (hereinafter VESA) in view of HUSSAIN et al. (US 20210407456 A1), as applied claim 1 above, and further in view of BAE et al. (US 20200294185 A1) . Regarding claim 20 . VESA in view of HUSSAIN discloses the apparatus of claim 1 (as rejected above), VESA in view of HUSSAIN does not disclose further comprising at least one of an antenna or a transceiver coupled to the at least one processor, wherein the one or more DSC bit streams are associated with a continuous animation for an always-on-display (AOD) feature of the display panel . However, BAE discloses: further comprising at least one of an antenna or a transceiver coupled to the at least one processor, wherein the one or more DSC bit streams are associated with a continuous animation for an always-on-display (AOD) feature of the display panel (BAE, see at least par. [0055] The display outputting method described above may be referred to as “AOD” in an aspect that useful information is always provided. In addition, the display outputting method may be referred to as a self-display in an aspect that the display is performed by the operation of the DDI itself without any participation of the processor. [0065] According to an embodiment, the DDI 100 (or the controller 120 thereof) may change at least one partial image data to be output to the specified area of the display panel 200 , depending on a preset sequence. That is, the DDI 100 (or the controller 120 thereof) may sequentially select one of pieces of partial image data stored in the GRAM 110 , depending on a specified sequence (or a random sequence) and may output the selected one to the specified area of the display panel 200 . Thereby, a specific animation effect may be achieved.). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the method and apparatus of VESA, to have further comprising at least one of an antenna or a transceiver coupled to the at least one processor, wherein the one or more DSC bit streams are associated with a continuous animation for an always-on-display (AOD) feature of the display panel , as provided by BAE. The modification provide an improved system and method for rendering and displaying visual content, thereby to visually provide a variety of content (e.g., an image, a video, and the like) to a user. The display includes a display panel and a display driver integrated circuit for driving the display panel. (BAE, see par. [0005]) . 07-21-aia AIA Claim 24 is rejected under 35 U.S.C. 103 as being unpatentable over VIDEO ELECTRONIC STANDARDS ASSOCIATION: VESA Display Stream Compression (DSC) Standard”, Version 1.2a, Not Know, No.VESA_1.2a, 18 January 2017 (hereinafter VESA) in view of HUSSAIN, et al. (US 20210407456 A1) as applied claim 21 above, and further in view of Petersen et al. (US 20180175726 A1) . Regarding claim 24 . VESA in view of HUSSAIN discloses the apparatus of claim 1 (as rejected above), but VESA in view of HUSSAIN does not disclose wherein each of the plurality of frames is received sequentially or the plurality of frames is received in a burst operation, wherein each of the plurality of frames is received from at least one of a graphics processing unit (GPU), a central processing unit (CPU), or a host device. However, Petersen discloses: wherein each of the plurality of frames is received sequentially or the plurality of frames is received in a burst operation, wherein each of the plurality of frames is received from at least one of a graphics processing unit (GPU), a central processing unit (CPU), or a host device (Petersen, see at least par. [0002] Over the last years battery powered applications (like smartphones, tablets and notebooks) increased their computing power, screen resolution and display frame rate and added connected standby modes. The increase of computing power was enabled by silicon technology in the sub-micron range approaching 10 nm and below. These ultra-narrow gate structures exhibit increased leakage current for each transistor. In view of the fact that CPUs (central processing units) and GPUs (graphical processing units) are composed from multiple hundred million transistors, the leakage current of a modern microprocessor is typically significant. To reduce battery consumption, the embedded computing cores are typically disconnected from the power supply as often as possible. As a result of this, the required computing power is provided within short bursts of operation at maximum speed.). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the method and apparatus of VESA, to have wherein each of the plurality of frames is received sequentially or the plurality of frames is received in a burst operation, wherein each of the plurality of frames is received from at least one of a graphics processing unit (GPU), a central processing unit (CPU), or a host device , as provided by Petersen. The modification provide an improved system and method for rendering and displaying visual content, thereby to increasing power efficiency for particular conversion ratios (e.g. in the range of 3:1) (Petersen, see par. [0031]). Conclusion 07-40 AIA Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL . See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to KIM THANH THI TRAN whose telephone number is (571)270-1408. The examiner can normally be reached Monday-Friday 8:00am-5:00pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, ALICIA HARRINGTON can be reached at 5712722330. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /KIM THANH T TRAN/Examiner, Art Unit 2615 /JAMES A THOMPSON/Primary Examiner, Art Unit 2615 Application/Control Number: 18/686,859 Page 2 Art Unit: 2615 Application/Control Number: 18/686,859 Page 3 Art Unit: 2615 Application/Control Number: 18/686,859 Page 4 Art Unit: 2615 Application/Control Number: 18/686,859 Page 5 Art Unit: 2615 Application/Control Number: 18/686,859 Page 6 Art Unit: 2615 Application/Control Number: 18/686,859 Page 7 Art Unit: 2615 Application/Control Number: 18/686,859 Page 8 Art Unit: 2615 Application/Control Number: 18/686,859 Page 9 Art Unit: 2615 Application/Control Number: 18/686,859 Page 10 Art Unit: 2615 Application/Control Number: 18/686,859 Page 11 Art Unit: 2615 Application/Control Number: 18/686,859 Page 12 Art Unit: 2615 Application/Control Number: 18/686,859 Page 13 Art Unit: 2615 Application/Control Number: 18/686,859 Page 14 Art Unit: 2615 Application/Control Number: 18/686,859 Page 15 Art Unit: 2615 Application/Control Number: 18/686,859 Page 16 Art Unit: 2615 Application/Control Number: 18/686,859 Page 17 Art Unit: 2615 Application/Control Number: 18/686,859 Page 18 Art Unit: 2615 Application/Control Number: 18/686,859 Page 19 Art Unit: 2615 Application/Control Number: 18/686,859 Page 20 Art Unit: 2615 Application/Control Number: 18/686,859 Page 21 Art Unit: 2615 Application/Control Number: 18/686,859 Page 22 Art Unit: 2615 Application/Control Number: 18/686,859 Page 23 Art Unit: 2615 Application/Control Number: 18/686,859 Page 24 Art Unit: 2615 Application/Control Number: 18/686,859 Page 25 Art Unit: 2615 Application/Control Number: 18/686,859 Page 26 Art Unit: 2615 Application/Control Number: 18/686,859 Page 27 Art Unit: 2615 Application/Control Number: 18/686,859 Page 28 Art Unit: 2615 Application/Control Number: 18/686,859 Page 29 Art Unit: 2615
Prosecution Insights