CTNF 18/154,237 CTNF 102043 DETAILED ACTION The instant application having application number 18/154,237 filled on 1/13/23 has a total of 20 claims pending for examination. There are 3 independent claims and 17 dependent claims, all of which are examined below. This application claims the benefit of U.S. Provisional Application No. 63/312,373, filed on February 21, 2022, which is hereby incorporated by reference in its entirety . 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. Information Disclosure Statement The Information Disclosure Statement (IDS) submitted on April 18, 2023, contains references that cannot be considered due to inconsistencies between the patent numbers provided and the associated reference information: US Patent 1,012,187 B2 is identified in the IDS as Wittenbrink, et al. (2018), but the cited patent number corresponds to Behr (1911). US Patent 11,630,773 B2 is identified in the IDS as Holmes (2020), but the cited patent number corresponds to SHATSKY (2023). Because of this, the examiner cannot accurately identify the intended references for consideration. If the applicant wished for these references to be formally considered, a corrected IDS must be submitted. Drawings The drawings were received on January 13, 2023. The drawings are objected to by the examiner for the following reasons: Figure 1 includes two identically labeled items, “PROCESSING UNIT(S),” corresponding to reference numbers 116 and 130. Correction is required to either differentiate the labels or use the same reference number for the same labeled item. Figure 1 includes three identically labeled items, “LATENCY COMPONENT,” corresponding to reference numbers 136, 138, and 140. Correction is required to either differentiate the labels, for example, “FIRST LATENCY COMPONENT” (136), “SECOND LATENCY COMPONENT” (138), and “THIRD LATENCY COMPONENT” (140), or use the same reference number for the same labeled item. Claim Objections 07-36 AIA The following is a quotation of 35 U.S.C. 112(d): (d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers. The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph: Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers. Claim 20 is objected to under 35 U.S.C. §112(d) as being an improper dependent claim because it fails to further limit the subject matter of claim 18 from which it depends. Claim 18 is directed to a system and does not recite a processor. Therefore, the processor limitations recited in claim 20 do not further limit claim 18. Claim Rejections - 35 USC § 112 07-30-02 AIA The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 07-34-01 Claim 3 and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 20 recites the term a ‘the processor’ however there is no mention of a processor in claim 18. Correction is required. Claim 3 is indefinite because it creates an inconsistency with claim 1. Claim 1 recites that the third time may correspond to either a present call or a frame buffer flip. Claim 3 then recites that the third time corresponds to the frame buffer flip and separately recites a fourth time corresponding to the present call. This creates an inconsistency because claim 3 appears to require the frame buffer flip to be the third time and the present call to be a later fourth time, even though a present call would ordinarily occur before the corresponding frame buffer flip. Therefore, it is unclear whether claim 3 requires chronological order or whether the terms ‘third time’ and ‘fourth time’ are only labels. For purposes of this examination, the claim terms are given their broadest reasonable interpretation consistent with the specification. The terms “third time” and “fourth time” in claim 3 are interpreted as labels used to distinguish different recited times and are not interpreted as requiring chronological order. Accordingly, claim 3 is interpreted as reciting a frame buffer flip time as the “third time” and a present call time as the “fourth time,” without requiring the frame buffer flip to occur before the present call. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claim 1-11 and 13-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Step 1, Statutory Category: Yes: Claims 1-9 are directed to a method. Step 2A Prong I, judicial Exception: The Examiner submits that the foregoing claim limitations constitute mental processes and mathematical concepts when given their broadest reasonable interpretation. Abstract ideas are bolded. Claim 1 recites the limitations: 1. A method comprising: determining a first time that an input event associated with a software application is sent; determining a second time associated with simulating a frame corresponding to the input event; computing a first latency based at least on the first time and the second time; determining a third time that at least one of a present call associated with the frame occurs or a frame buffer flip associated with the frame occurs; and computing a second latency based at least on the first latency and the third time. The limitations determining a first time that an input event associated with a software application is sent, determining a second time associated with simulating a frame corresponding to the input event, and determining a third time that at least one of a present call associated with the frame occurs or a frame buffer flip associated with the frame occurs are abstract ideas because they are directed to mental processes, including observations, evaluations, judgments, and opinions (See MPEP §2106.04(a)(2)(III)). The claim only recites determining when these events occur at a high level of generality and does not provide details of how the event is detected, how the timestamps are obtained, or any particular structure for making the determinations. Therefore, these limitations could be performed by a user observing that an event occurred, checking a clock or timestamp, evaluating system logs, and noting the time of the event. For example, a user could evaluate a log showing when an input event was sent, when a frame was simulated, and when a present call or frame buffer flip occurred, and then identify the corresponding times. The limitations computing a first latency based at least on the first time and the second time and computing a second latency based at least on the first latency and the third time are abstract ideas because they are directed to mathematical concepts (See MPEP §2106.04(a)(2)(I)). These limitations require calculating latency values using previously determined times and a previously calculated latency value. In other words, the latency values are determined by performing mathematical operations on numerical time values. This is confirmed by the disclosure, which explains that computing a latency may include calculating the difference between two associated times, taking an average of differences, or using “one or more additional and/or alternative techniques, such as the minimum of the differences, the median of the differences, the maximum of the differences, and/or the like” (Paragraphs 23 and 24). Step 2A Prong II, Integration into a Practical Application: Claim 1 does not recite any additional elements beyond the identified abstract ideas. Step 2B, Significantly More: Claim 1 does not recite additional elements that amount to significantly more than the identified judicial exceptions. As discussed above, the claim is directed to determining times associated with events and computing latency values based on those times, which correspond to mental processes and mathematical concepts. The claim does not add any further limitation that improves the operation of a computer, changes how the software application or graphics pipeline operates, or provides any other meaningful limitation beyond the judicial exceptions themselves. Therefore, whether considered individually or as an ordered combination, the limitations of claim 1 do not amount to significantly more than the abstract ideas. Claim 1 is not patent eligible. Regarding claim 2, the rejection of claim 1 is incorporated herein. Claim 2 recites the method of claim 1, wherein the computing the second latency comprises: computing a third latency based at least on the second time and the third time; and computing the second latency by adding the first latency to the third latency. These limitations further recite mathematical concepts because they require calculating another latency value from the second time and the third time, and then adding that calculated latency value to the first latency to obtain the second latency. Thus, claim 2 only provides more specific recitations of the abstract idea of computing latencies through mathematical calculations. Therefore, claim 2 does not integrate the judicial exception into a practical application or add significantly more than the judicial exception. Claim 2 is not patent eligible. Regarding claim 3, the rejection of claim 1 is incorporated herein. Claim 3 recites the method of claim 1, wherein the third time corresponds to a time the frame buffer flip associated with the frame occurs, and wherein the method further comprises: determining a fourth time that the present call associated with the frame occurs; computing a third latency based at least on the second time and the fourth time; and computing a fourth latency based at least on the fourth time and the third time, wherein the computing the second latency comprises computing the second latency based at least on the first latency, the third latency, and the fourth latency. These limitations do not remove or change the abstract ideas identified in claim 1. Instead, claim 3 further specifies that the third time is the frame buffer flip time, adds a fourth time corresponding to the present call, and then uses those times to calculate additional latency values. The added determining limitation is still directed to a mental process because it only requires determining when another event occurs through observation and evaluation. The added computing limitations are still directed to mathematical concepts because they require calculating additional latency values from determined times and previously calculated latency values. Therefore, claim 3 only provides more specific recitations of the abstract ideas identified in claim 1 and does not integrate the judicial exception into a practical application or add significantly more than the judicial exception. Claim 3 is not patent eligible. Regarding claim 4, the rejection of claim 1 is incorporated herein. Claim 4 recites the method of claim 1, further comprising: determining a fourth time that a second input event associated with the software application is sent; and determining a fifth time associated with simulating a second frame corresponding to the second input event, wherein the computing the first latency is further based at least on the fourth time and the fifth time. These limitations repeat the same determining and computing steps identified in claim 1, but apply them to a second input event and a second frame. As with claim 1, the determining limitations are directed to mental processes because they merely require observing when additional events occur and identifying the corresponding times. The computing limitation is directed to mathematical concepts because it requires using the fourth time and the fifth time as additional numerical inputs in the same latency calculation recited in claim 1. In other words, claim 4 does not change how the latency is computed, but only adds another pair of time values that are used to further calculate the first latency. Therefore, claim 4 only provides more specific recitations of the abstract ideas identified in claim 1 and does not integrate the judicial exception into a practical application or add significantly more than the judicial exception. Claim 4 is not patent eligible. Regarding claim 5, the rejection of claim 1 is incorporated herein. Claim 4 recites the method of claim 4, further comprising: computing a third latency based at least on the first time and the second time; and computing a fourth latency based at least on the fourth time and the fifth time, wherein the computing the first latency comprises computing the first latency based at least on an average of the third latency and the fourth latency. These limitations do not remove or change the abstract limitations identified in claims 1 and 4. Instead, claim 5 further specifies how the first latency is computed by calculating two latency values and then averaging those latency values. The added computing limitations are directed to mathematical concepts because they require calculating latency values from determined times and then performing an averaging calculation using those latency values. Therefore, claim 5 only provides more specific recitations of the abstract idea of computing latencies through mathematical calculations and does not integrate the judicial exception into a practical application or add significantly more than the judicial exception. Claim 5 is not patent eligible. Regarding claim 6, the rejection of claim 4 is incorporated herein. Claim 6 recites the method of claim 4, further comprising causing, based at least on a predetermined time period elapsing since the first time, the second input event to occur . Claim 6 does not remove or change the abstract limitations identified in claims 1 and 4. Rather, claim 6 only adds a timing rule for when the second input event occurs. Specifically, the second input event is caused after a predetermined amount of time has elapsed since the first time. This limitation is still part of the abstract timing and latency calculation process because it uses the passage of time to create another event for the same latency analysis. The added causing step does not provide a technical improvement because the claim does not recite a specific mechanism for generating the second input event, improving input processing, or improving the software application or graphics pipeline. Instead, the caused second input event merely supplies another event to be timed and used in the latency calculations already recited in claim 4. Therefore, the added limitation amounts to insignificant extra-solution activity and does not integrate the judicial exception into a practical application or add significantly more than the judicial exception (see MPEP 2106.05(g)). Claim 6 is not patent eligible. Regarding claim 7, the rejection of claim 1 is incorporated herein. Claim 7 recites the method of claim 1, further comprising: based at least on the input event occurring, generating first data representative of at least the first time; based at least on the frame corresponding to the input event being simulated, generating second data representative of at least the second time and an identifier associated with the frame; and based at least on a detection of the input event, generating third data that associates at least the input event with the identifier associated with the frame, wherein the computing the first latency is based at least on the first data, the second data, and the third data. Claim 7 does not remove or change the abstract limitations identified in claim 1. Instead, claim 7 further specifies the abstract computation of the first latency by identifying the data used to perform that computation. These limitations amount to mere data gathering and organization under MPEP 2106.05(g) because the generated data is only collected, associated with the frame, and then used to calculate the first latency. The claim does not recite improvements in how the data is generated or how the input event is detected. Therefore, claim 7 does not integrate the judicial exception into a practical application or add significantly more than the judicial exception. Claim 7 is not patent eligible. Regarding claim 8, the rejection of claim 1 is incorporated herein. Claim 8 recites the method of claim 1, further comprising: determining a fourth time that at least one of a second present call associated with a second frame occurs or a second frame buffer flip associated with the second frame occurs, wherein the second frame is generated based at least on the frame; computing a third latency based at least on the first latency and the fourth time; and computing a fourth latency based at least on the second latency and the third latency . Claim 8 does not remove or change the abstract limitations identified in claim 1. Therefore, the determining and computing limitations of claim 1 remain present and are rejected for the same reasons explained above. Claim 8 only adds another timing determination for a second frame and additional latency calculations using previously determined and calculated values. The added determining limitation is directed to a mental process because it merely requires determining when another present call or frame buffer flip occurs. The added computing limitations are directed to mathematical concepts because they require calculating additional latency values from the previously calculated first latency, the fourth time, the previously calculated second latency, and the third latency. Therefore, claim 8 only provides more specific recitations of the abstract ideas identified in claim 1 and does not integrate the judicial exception into a practical application or add significantly more than the judicial exception. Claim 8 is not patent eligible. Regarding claim 9, the rejection of claim 1 is incorporated herein. Claim 9 recites the method of claim 1, further comprising: computing a third latency associated with a peripheral device that receives one or more inputs associated with the software application; computing a fourth latency associated with a display device that presents at least the frame; and computing a fifth latency based at least on the second latency, the third latency, and the fourth latency . Claim 9 does not remove or change the abstract limitations identified in claim 1. Instead, claim 9 only adds more latency calculations for additional devices and then uses those calculated latency values to compute another latency value. These limitations are directed to mathematical concepts because they require calculating latencies associated with a peripheral device and a display device, and then using those latency values in another calculation. Claim 9 does not explain how the peripheral device or display device is improved, but only uses their associated latency values as inputs for another calculation. Therefore, claim 9 only provides more specific recitations of the abstract idea of computing latencies and does not integrate the judicial exception into a practical application or add significantly more than the judicial exception. Claim 9 is not patent eligible. Step 1, Statutory Category: Yes: Claims 10-18 are directed to a machine. Step 2A Prong I, judicial Exception: The Examiner submits that the foregoing claim limitations constitute mental processes and mathematical concepts when given their broadest reasonable interpretation. Abstract ideas are bolded. Claim 10 recites the limitations: 10. A system comprising: one or more processing units to: determine a first time that a frame associated with a software application is simulated ; determine a second time that a frame buffer flip associated with the frame occurs; and compute, based at least on the first time and the second time, a latency associated with the software application. The limitations determine a first time that a frame associated with a software application is simulated and determine a second time that a frame buffer flip associated with the frame occurs are abstract ideas because they are directed to mental processes, including observations, evaluations, judgments, and opinions (See MPEP §2106.04(a)(2)(III)). The claim only recites determining when these events occur at a high level of generality and does not provide details of how the events are detected, how the times are obtained, or any particular structure for making the determinations. Therefore, these limitations could be performed by a user observing that an event occurred, checking a clock or timestamp, evaluating system logs, and noting the time of the event. For example, a user could evaluate a log showing when a frame was simulated and when a frame buffer flip occurred, and then identify the corresponding times. Therefore, these limitations amount to observing and evaluating event timing information, which is a mental process. The limitation to compute, based at least on the first time and the second time, a latency associated with the software application is an abstract idea because it is directed to mathematical concepts (See MPEP §2106.04(a)(2)(I)). These limitations require performing mathematical operations on numerical time values. This is confirmed by the disclosure, which explains that computing a latency may include calculating the difference between two associated times, taking an average of differences, or using “one or more additional and/or alternative techniques, such as the minimum of the differences, the median of the differences, the maximum of the differences, and/or the like” (Paragraphs 23 and 24). Step 2A Prong II, Integration into a Practical Application: Claim 10 recites the following additional claim limitation outside the abstract idea which only present mere instructions to apply an exception: one or more processing units (mere instructions to apply an exception, see MPEP § 2106.05(f)). Step 2B, Significantly More: When considered individually or in combination, the additional limitations and elements of claim 10 do not amount to significantly more than the judicial exceptions. The claim only recites the processing units as performing the determining and computing limitations, and does not recite any particular structure, arrangement, or improvement to the processing units themselves. Therefore, the recited processing units do not integrate the abstract ideas into a practical application, but merely use generic computer components as a tool to apply the abstract timing determinations and latency calculation. Regarding claim 11, the rejection of claim 10 is incorporated herein. Claim 11 recites The system of claim 10, wherein the one or more processing units are further to: determine a third time that a present call associated with the frame occurs; compute, based least on the first time and the third time, a second latency; and compute, based at least on the third time and the second time, a third latency, wherein the latency associated with the software application is computed based at least on the second latency and the third latency. Claim 11 does not remove or change the abstract limitations identified in claim 10. Instead, claim 11 adds another timing determination for the present call and additional latency calculations using the determined times. The added determining limitation is directed to a mental process because it merely requires observing when another event occurs. The added computing limitations are directed to mathematical concepts because they require calculating additional latency values from the first time, second time, and third time, and then using those latency values to compute the latency associated with the software application. Performing these abstract ideas on the recited one or more processing units does not integrate the judicial exception into a practical application because the processing units are generic computer components used to apply the timing determinations and latency calculations. Therefore, claim 11 only provides more specific recitations of the abstract ideas identified in claim 10 and does not integrate the judicial exception into a practical application or add significantly more than the judicial exception. Claim 11 is not patent eligible. Regarding claim 12, the rejection of claim 10 is resolved. Claim 12 recites t he system of claim 10, wherein the one or more processing units are further to: based at least on a present call associated with the frame occurring, generate data representing at least an identifier associated with the frame; and determine, based at least on the data, that the frame buffer flip is associated with the frame, wherein the latency is further computed based at least on the determination that the frame buffer flip is associated with the frame . Claim 12 adds more than the general timing and latency calculations recited in claim 10 because it uses frame identifier data to make sure the frame buffer flip is matched to the correct frame. This is different from claim 7, which generates data representing times and associates an input event with a frame identifier for use in calculating latency. Claim 12 uses the identifier data in a more specific way because the identifier data is used to determine that the frame buffer flip corresponds to the same frame associated with the present call. This provides a practical application in the graphics pipeline because multiple frames may be processed at the same time, and the latency calculation depends on using the frame buffer flip for the correct frame. Accordingly, claim 12 does more than merely collect data for a calculation. It uses the identifier data to match the correct frame, present call, and frame buffer flip before latency is computed. Therefore, claim 12 integrates the abstract idea into a practical application and is not rejected under 35 U.S.C. 101. Regarding claim 13, the rejection of claim 10 is incorporated herein. Claim 13 recites the system of claim 10, wherein the one or more processing units are further to: determine a third time that an input event associated with the software application is sent, wherein the frame is associated with the input event, wherein the latency is further computed based at least on the third time. Claim 13 does not remove or change the abstract limitations identified in claim 10. Instead, claim 13 adds another timing determination for an input event and uses that determined time in computing the latency. The added determining limitation is directed to a mental process because it merely requires observing when another event occurs. The added computing limitation is directed to mathematical concepts because it requires using the third time as another numerical time value in the latency calculation. Performing these abstract ideas on the recited one or more processing units does not integrate the judicial exception into a practical application because the processing units are generic computer components used to apply the timing determinations and latency calculation. Therefore, claim 13 only provides more specific recitations of the abstract ideas identified in claim 10 and does not integrate the judicial exception into a practical application or add significantly more than the judicial exception. Claim 13 is not patent eligible. Regarding claim 14, the rejection of claim 13 is incorporated herein. Claim 14 recites the system of claim 13, wherein the one or more processing units are further to: compute, based at least on the third time and the first time, a second latency; and compute, based at least on the first time and the second time, a third latency, wherein the latency associated with the software application is computed based at least on the second latency and the third latency. Claim 14 does not remove or change the abstract limitations identified in claims 10 and 13. Instead, claim 14 further specifies how the latency is computed by requiring additional latency calculations using the determined times and calculated latency values. These added computing limitations are directed to mathematical concepts because they require calculating latency values from numerical time values and then using those latency values in another latency calculation. Performing these abstract ideas on the recited one or more processing units does not integrate the judicial exception into a practical application because the processing units are generic computer components used to apply the latency calculations. Therefore, claim 14 only provides more specific recitations of the abstract ideas identified in claims 10 and 13 and does not integrate the judicial exception into a practical application or add significantly more than the judicial exception. Claim 14 is not patent eligible. Regarding claim 15, the rejection of claim 14 is incorporated herein. Claim 14 recites the system of claim 14, wherein the one or more processing units are further to: determine a fourth time that a second input event associated with the software application is sent; determine a fifth time that a second frame associated with the second input event is simulated; determine, based at least on the fourth time and the fifth time, a fourth latency; and compute a fifth latency based at least on an average of the second latency and the fourth latency, wherein the latency associated with the software application is computed based at least on the fifth latency and the third latency. Claim 15 does not remove or change the abstract limitations identified in claims 10, 13, and 14. Instead, claim 15 repeats the same type of timing determinations and latency calculations for a second input event and second frame. The added determining limitations are directed to mental processes because they merely require determining when additional events occur. The added computing limitations are directed to mathematical concepts because they require calculating another latency value from determined times, averaging calculated latency values, and then using the averaged latency value to compute the latency associated with the software application. Performing these abstract ideas on the recited one or more processing units does not integrate the judicial exception into a practical application because the processing units are generic computer components used to apply the timing determinations and latency calculations. Therefore, claim 15 only provides more specific recitations of the abstract ideas identified in claims 10, 13, and 14 and does not integrate the judicial exception into a practical application or add significantly more than the judicial exception. Claim 15 is not patent eligible. Regarding claim 16, the rejection of claim 10 is incorporated herein. Claim 16 recites the system of claim 10, wherein the one or more processing units are further to: based at least on the frame associated with the software application being simulated, generate first data representative of at least the first time and an identifier associated with the frame; and based at least on the frame buffer flip associated with the frame occurring, generate second data representative of at least the second time, wherein the latency associated with the software application is computed based at least on the first data and the second data. Claim 16 does not remove or change the abstract limitations identified in claim 10. Instead, claim 16 further specifies the data used to compute the latency by reciting data representative of the first time, the frame identifier, and the second time. These limitations amount to mere data gathering and organization under MPEP § 2106.05(g) because the generated data is only collected and used as input for the latency calculation recited in claim 10. The claim does not recite how the data is generated in any technical way or how the frame simulation or frame buffer flip is detected in a way that improves the software application or graphics pipeline. Performing these steps on the recited one or more processing units also does not integrate the judicial exception into a practical application because the processing units are generic computer components used to apply the data gathering and latency calculation. Therefore, claim 16 does not integrate the judicial exception into a practical application or add significantly more than the judicial exception. Claim 16 is not patent eligible. Regarding claim 17, the rejection of claim 10 is incorporated herein. Claim 17 recites the system of claim 10, wherein the one or more processing units are further to: compute a second latency associated with a peripheral device that receives one or more inputs associated with the software application; compute a third latency associated with a display device that presents at least the frame; and compute a fourth latency based at least on the first latency, the second latency, and the third latency. Claim 17 does not remove or change the abstract limitations identified in claim 10. Instead, claim 17 only adds more latency calculations for additional devices and then uses those calculated latency values to compute another latency value. These limitations are directed to mathematical concepts because they require calculating latencies associated with a peripheral device and a display device, and then using those latency values in another calculation. Claim 17 does not explain how the peripheral device or display device is improved, but only uses their associated latency values as inputs for another calculation. Performing these abstract ideas on the recited one or more processing units does not integrate the judicial exception into a practical application because the processing units are generic computer components used to apply the latency calculations. Therefore, claim 17 only provides more specific recitations of the abstract idea of computing latencies and does not integrate the judicial exception into a practical application or add significantly more than the judicial exception. Claim 17 is not patent eligible. Regarding claim 18, the rejection of claim 10 is incorporated herein. Claim 18 recites The system of claim 10, wherein the system is comprised in at least one of: a control system for an autonomous or semi-autonomous machine; a perception system for an autonomous or semi-autonomous machine; a system for performing simulation operations; a system for performing digital twin operations; … a system incorporating one or more virtual machines (VMs); a system implemented at least partially in a data center; or a system implemented at least partially using cloud computing resources. Claim 18 does not remove or change the abstract limitations identified in claim 10. Instead, claim 18 only identifies different systems or environments in which the abstract timing determinations and latency calculation may be used. These limitations merely link the use of the judicial exception to particular technological environments or fields of use under MPEP § 2106.05(h). Claim 18 does not remove or change the abstract limitations identified in claim 10. Instead, claim 18 only identifies different systems or environments in which the abstract timing determinations and latency calculation may be used. These limitations merely link the use of the judicial exception to particular technological environments or fields of use under MPEP § 2106.05(h). Therefore, claim 18 does not integrate the judicial exception into a practical application or add significantly more than the judicial exception. Claim 18 is not patent eligible. Step 1, Statutory Category: Yes: Claims 19-20 are directed to a machine. Step 2A Prong I, judicial Exception: The Examiner submits that the foregoing claim limitations constitute mental processes and mathematical concepts when given their broadest reasonable interpretation. Abstract ideas are bolded. Claim 19 recites the limitations: 19. A processor comprising: one or more processing units to compute a latency associated with a computing device based at least on a first time that an input event associated with a software application occurs and a second time that a frame buffer flip associated with a frame of the software application occurs , wherein the frame is associated with sampling the input event. The limitation to compute a latency associated with a computing device based at least on a first time that an input event associated with a software application occurs and a second time that a frame buffer flip associated with a frame of the software application occurs is an abstract idea because it is directed to mathematical concepts (See MPEP §2106.04(a)(2)(I)). These limitations require performing mathematical operations on numerical time values. This is confirmed by the disclosure, which explains that computing a latency may include calculating the difference between two associated times, taking an average of differences, or using “one or more additional and/or alternative techniques, such as the minimum of the differences, the median of the differences, the maximum of the differences, and/or the like” (Paragraphs 23 and 24). Step 2A Prong II, Integration into a Practical Application: Claim 19 recites the following additional claim limitation outside the abstract idea which only present mere instructions to apply an exception: A processor comprising: one or more processing units (mere instructions to apply an exception, see MPEP § 2106.05(f)). Wherein the frame is associated with sampling the input event (field of use under MPEP § 2106.05(h)) Step 2B, Significantly More: When considered individually or in combination, the additional limitations and elements of claim 19 do not amount to significantly more than the judicial exception. The claim recites a processor comprising one or more processing units, but the processing units are only used to perform the abstract latency calculation and do not provide any particular structure, arrangement, or improvement to the processor or processing units themselves. The limitation “wherein the frame is associated with sampling the input event” also does not add significantly more because it merely limits the latency calculation to a particular context in which the frame is related to sampled input. Therefore, the additional limitations merely apply the mathematical latency calculation using generic computer components and limit the calculation to a particular field of use. Claim 19 is not patent eligible. Regarding claim 20, the rejection of claim 19 is incorporated herein. Claim 20 recites the processor of claim 18, wherein the processor is comprised in at least one of: a control system for an autonomous or semi-autonomous machine; a perception system for an autonomous or semi-autonomous machine; a system for performing simulation operations … a system implemented at least partially in a data center; or a system implemented at least partially using cloud computing resources . Claim 20 does not remove or change the abstract limitations identified in claim 19. Instead, claim 20 only identifies different systems or environments in which the abstract latency computation may be used. These limitations merely link the use of the judicial exception to particular technological environments or fields of use under MPEP § 2106.05(h). Therefore, claim 20 does not integrate the judicial exception into a practical application or add significantly more than the judicial exception. Claim 20 is not patent eligible. 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-23-aia AIA The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. 07-21-aia AIA Claims 1, 2, 4, 7, and 8 are r ejected under 35 U.S.C. § 103 as being unpatentable over S chluessler et al, U.S. Patent Application Publication No. 2022/0122566 A1 (hereinafter "Schluessler") in view of Wang et al. U.S. Patent Application Publication No. 2024/0269549 A1 (hereinafter "Wang"). R egarding Claim 1, Schluessler teaches a method comprising determining a second time associated with simulating a frame corresponding to the input event (“In embodiments, a system monitor tracks the simulation, creation, rendering and display time for each frame,” “Measuring times associated with the creation of each individual frame includes the frame’s simulation time, when the frame was submitted to the driver and GPU, and when the frame was presented on the display,” and “the frame pacer 58 attempts to achieve the lowest latency from input data to frame display time,” wherein Schluessler’s frame pacer uses frame timing information to reduce latency from input data to frame display time, and the frame’s simulation time is interpreted as the second time associated with simulating the frame corresponding to the input data.) Schluessler’s FIG. 4 further illustrates a 3D application and frame-pacer architecture for coordinating the frame pipeline, including application frame generation, simulation timing, rendering, and display timing, which further supports that Schluessler determines a simulation time for a frame as part of controlling frame pacing. (e.g., Schluessler, paragraphs [0039], [0042], and [0054], FIG. 4). determining a third time that at least one of a present call associated with the frame occurs or a frame buffer flip associated with the frame occurs . The examiner will be selecting a present call associated with the frame for this rejection. (“determining measured timing data in response to a presentation request (e.g., present call) from an application, wherein the measured timing data is associated with one or more previous frames and the presentation request is associated with one or more subsequent frames” and “the frame pacer updates records of measured timing data since the last present,” wherein Schluessler determines measured timing data in response to a present call and updates timing records based on the present call, which is interpreted as determining the third time that the present call associated with the frame occurs.) (e.g., Schluessler, paragraphs [0065] and [0069]). Schluessler does not appear to specifically teach determining a first time that an input event associated with a software application is sent; computing a first latency based at least on the first time and the second time; and computing a second latency based at least on the first latency and the third time . However, Wang teaches determining a first time that an input event associated with a software application is sent (“at step 101 one or more of the systems described herein may send, to a cloud gaming server, cloud gaming input information with an input creation timestamp that marks when the cloud gaming input information was created,” and “input sending unit 104 may... identify a timestamp that matches the corresponding user input such that the timestamp indicates the particular time at which the user input information was created in response to the actual manual input by the user,” wherein the cloud gaming input information/user input is interpreted as the input event, sending the cloud gaming input information to the cloud gaming server is interpreted as the input event being sent, and the timestamp matching the corresponding user input is interpreted as the first time associated with the sent input event.) (e.g., Wang, paragraphs [0023] and [0027]). computing a first latency based at least on the first time and the second time (“such metrics may include measurements of latency between specific events within an overall cloud gaming processing pipeline, including... creation of input information... [and] a frame creation event at which point a frame, which was triggered by such user input, is actually generated or rendered at the cloud gaming server,” wherein the latency between creation of the input information and the frame event triggered by the input is interpreted as the first latency.)(e.g., Wang, paragraph [0018]) computing a second latency based at least on the first latency and the third time (“calculating latency by subtracting the input creation timestamp from the frame render timestamp to measure lag between creation of the cloud gaming input information and rendering of the frame at the cloud gaming client device,” and “client control unit 110 may subtract the input creation timestamp from the frame render timestamp, thereby deriving a precise measurement of end-to-end latency between creation of the cloud gaming input information and client-side rendering of the frame” and “one or more other measurements of lag using any suitable permutation of the cloud gaming input instruction timestamp, the frame creation timestamp, the frame render timestamp, and/or a corresponding client-side frame display timestamp,” wherein calculating lag measurements using different combinations of input and frame timing timestamps is interpreted as computing latency values based on a previously computed first latency and later frame timing information, including a later frame render or display timestamp.) (e.g., Wang, paragraphs [0041]-[0042]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Schluessler and Wang before him or her, to modify Schluessler’s frame-pacing method to include Wang’s input timestamp and latency calculations. Schluessler and Wang are analogous art because both references are directed to measuring and reducing latency in graphics processing pipelines, including frame timing and display-related latency for interactive applications. The motivation for doing so would have been to make Schluessler’s latency-reduction technique more complete and accurate. In paragraph 54, Schluessler expressly teaches that, in eSports mode, “the frame pacer 58 attempts to achieve the lowest latency from input data to frame display time.” To achieve this goal, Schluessler measures frame-side timing events, including simulation time and present call timing, and uses those measurements to control frame pacing. However, because Schluessler does not expressly timestamp the input event itself, its system lacks a direct indication of when the sampling latency begins and therefore cannot fully measure the complete latency path from user input to displayed frame. Wang supplies this missing metric by timestamping user input and calculating latency between the input timestamp and subsequent frame events. A person of ordinary skill in the art would have recognized that incorporating Wang’s input timestamp and sampling latency calculation into Schluessler would allow Schluessler’s frame pacer to measure the full latency path from input through simulation and presentation, rather than only managing later frame-side events. This modification would predictably improve Schluessler’s latency evaluation and frame-pacing control by allowing the system to measure latency occurring both before and during the frame timing events that Schluessler already tracks. Regarding Claim 2, Schluessler teaches wherein the computing the second latency comprises: computing a third latency based at least on the second time and the third time (“In embodiments, a system monitor tracks the simulation, creation, rendering and display time for each frame,” and “Measuring times associated with the creation of each individual frame—this includes the frame’s simulation time, when the frame was submitted to the driver and GPU, and when the frame was presented on the display,” and “the frame pacer updates records of measured timing data since the last present,” wherein Schluessler identifies the frame’s simulation time as one timing point and the present call as another timing point in the same frame processing sequence, and therefore the interval between those timing points is interpreted as the third latency based at least on the second time and the third time.) (e.g., Schluessler, paragraphs [0039], [0042], and [0069]). Schluessler does not appear to specifically teach computing the second latency by adding the first latency to the third latency . However, Wang teaches computing the second latency by adding the first latency to the third latency (“such metrics may include measurements of latency between specific events within an overall cloud gaming processing pipeline,” and “calculating latency by subtracting the input creation timestamp from the frame render timestamp to measure lag between creation of the cloud gaming input information and rendering of the frame at the cloud gaming client device,” and “Client control unit 110 may also additionally, alternatively, or analogously calculate one or more other measurements of lag using any suitable permutation of the cloud gaming input instruction timestamp, the frame creation timestamp, the frame render timestamp, and/or a corresponding client-side frame display timestamp,” wherein Wang teaches calculating multiple latency values for different portions of the graphics pipeline using different timestamp pairs, and the use of multiple timestamp based latency measurements supports computing a cumulative latency from multiple latency segments, including computing the second latency by adding the first latency to the third latency.) (e.g., Wang, paragraphs [0018] and [0041]-[0042]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Schluessler and Wang before him or her, to modify Schluessler’s frame pacing method to compute the second latency by adding the first latency to the third latency. Schluessler and Wang are analogous art because both references are directed to measuring and reducing latency in graphics processing pipelines for interactive applications. Schluessler teaches measuring frame timing data, including simulation timing and presentation timing, and Schluessler paragraph 54 expressly seeks to achieve “the lowest latency from input data to frame display time.” Wang teaches calculating latency measurements from timestamped events in a graphics processing pipeline, including input creation timestamps and later frame timestamps. A person of ordinary skill in the art would have been motivated to add the input-to-simulation latency and the simulation-to-present latency in order to obtain both the game latency and the render latency when evaluating the lag path from input data to frame display time. This modification would have predictably allowed Schluessler’s frame pacer to account for latency occurring before and during the frame timing events that Schluessler already tracks, thereby better supporting Schluessler’s goal of reducing latency from input data to frame display time. Regarding Claim 4, the claim recites substantially similar limitations to claim 1, but this time for a subsequent set of input events and frame rendering processes. Schluessler supports the idea of subsequent frames, including frames n−1, n, and n+1 in FIG. 3, and further teaches determining timing information for each frame and scheduling subsequent frames based on measured timing data. Therefore, claim 4 is rejected under 35 U.S.C. § 103 for the same reasons set forth above with respect to claim 1. Regarding Claim 7, Wang teaches based at least on the input event occurring, generating first data representative of at least the first time (“at step 101 one or more of the systems described herein may send, to a cloud gaming server, cloud gaming input information with an input creation timestamp that marks when the cloud gaming input information was created,” and “input sending unit 104 may perform step 101 at least in part by monitoring for, detecting, and/or intercepting data indicating the creation of the cloud gaming input information,” wherein Wang teaches detecting the creation of cloud gaming input information and generating or sending cloud gaming input information with an input creation timestamp. The cloud gaming input information is interpreted as first data, and the input creation timestamp is interpreted as being representative of at least the first time.) (e.g., Wang, paragraphs [0023]-[0024] and FIG. 7). based at least on the frame corresponding to the input event being simulated, generating second data representative of at least the second time and an identifier associated with the frame (“receive, in response to sending the cloud gaming input information, a frame creation timestamp that marks when a frame was drawn for a virtual display at the cloud gaming server,” “a rendering engine or other application at the cloud gaming server may generate a particular frame... in specific response to the cloud gaming input information transmitted at step 101,” and “Server control unit 116 may also monitor, detect, and/or intercept frame creation events, which may correspond to events whereby a corresponding rendering engine renders sequential frames of cloud gaming video,” wherein Wang teaches generating a frame in response to the cloud gaming input information and generating or receiving a frame creation timestamp for that frame. The frame creation timestamp is interpreted as a second data representative of at least the second time, and the frame creation timestamp or matching information associated with the generated frame is interpreted as an identifier associated with the frame.) (e.g., Wang, paragraphs [0030], [0032], [0034], and FIG. 7). based at least on a detection of the input event, generating third data that associates at least the input event with the identifier associated with the frame (“FIG. 7 further shows … how server control unit 116 within the cloud gaming server may perform such a matching process to thereby generate a feedback message,” “the matching process [is] to match the specific created frame, as a response, to a particular item of cloud gaming input information,” and “feedback message 802 may include a corresponding table 804 that further includes cells 808-822, which together aggregate the matching information from table 704 and table 754,” wherein Wang teaches generating a feedback message that records matching information between a particular item of cloud gaming input information and the specific frame created in response to that cloud gaming input information. Because Wang’s feedback message aggregates the matching information between the cloud gaming input information and the frame creation timestamp for the specific created frame, the feedback message is interpreted as third data that associates the input event with the identifier associated with the frame.) (e.g., Wang, paragraphs [0032], [0033], and [0037]). wherein the computing the first latency is based at least on the first data, the second data, and the third data (“feedback receiving unit 106 may also optionally parse the feedback message to identify which input creation timestamp matches which frame creation timestamp,” and “client control unit 110 may also additionally, alternatively, or analogously calculate one or more other measurements of lag using any suitable permutation of the cloud gaming input instruction timestamp, the frame creation timestamp, the frame render timestamp, and/or a corresponding client-side frame display timestamp” ) (e.g., Wang, paragraphs [0037] and [0042]). Regarding Claim 8, Schluessler teaches how to determine a fourth time that at least one of a second present call associated with a second frame occurs or a second frame buffer flip associated with the second frame occurs, wherein the second frame is generated based at least on the frame . The examiner is selecting a second present call associated with a second frame for this rejection. (“These times from one or more previous frames are inputs to control technology that predicts the optimal simulation and display times for the next frames,” “Using the previous measured times and a new frame pacing scheduler to calculate when the next frame should be simulated, submitted, rendered, and displayed,” “determining measured timing data in response to a presentation request (e.g., present call) from an application, wherein the measured timing data is associated with one or more previous frames and the presentation request is associated with one or more subsequent frames,” and “appPresentRequested” may be the “OS Timestamp that app called present function,” wherein Schluessler teaches using timing data from one or more previous frames to calculate timing for subsequent frames, including when a subsequent frame should be simulated, rendered, and displayed. Thus, Schluessler’s subsequent frame is interpreted as the second frame generated based at least on the frame, and the OS timestamp of the present call for the subsequent frame is interpreted as the fourth time that the second present call associated with the second frame occurs.) (e.g., Schluessler, paragraphs [0039], [0043], [0061], and [0065]). Schluessler does not appear to specifically teach computing a third latency based at least on the first latency and the fourth time and computing a fourth latency based at least on the second latency and the third latency However, Wang teaches computing a third latency based at least on the first latency and the fourth time and computing a fourth latency based at least on the second latency and the third latency . (“such metrics may include measurements of latency between specific events within an overall cloud gaming processing pipeline…,” and “client control unit 110 may also additionally, alternatively, or analogously calculate one or more other measurements of lag using any suitable permutation of the cloud gaming input instruction timestamp, the frame creation timestamp, the frame render timestamp, and/or a corresponding client-side frame display timestamp,” wherein Wang teaches calculating multiple latency measurements using different combinations of timestamped pipeline events. In the Schluessler-Wang framework, the first latency, second latency, and third latency are latency measurements computed from timestamped input and frame related events, and Schluessler’s fourth time is the present call timestamp for the second frame. Thus, Wang’s teaching of calculating multiple latency measurements using different combinations of timestamped pipeline events is interpreted as teaching computing the third latency based at least on the first latency and the fourth time, and computing the fourth latency based at least on the second latency and the third latency.) (e.g., Wang, paragraphs [0018] and [0042]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Schluessler and Wang before him or her, to modify Schluessler’s frame pacing method to include Wang’s input timestamp and latency calculation teachings. Schluessler and Wang are analogous art because both references are directed to measuring or reducing latency in graphics processing pipelines for interactive applications. In paragraph 54, Schluessler expressly seeks to achieve “the lowest latency from input data to frame display time.” To achieve this goal, Schluessler measures frame-side timing events, including simulation timing, present call timing, rendering timing, and display timing, and uses those measurements to control frame pacing. Wang teaches timestamping input information and calculating latency measurements between the input timestamp and later frame related timestamps in a graphics processing pipeline. A person of ordinary skill in the art would have recognized that incorporating Wang’s input timestamp and latency calculation teachings into Schluessler would allow Schluessler’s frame pacer to measure the full latency path from input through simulation and presentation, rather than only managing later frame-side events. This would allow Schluessler’s latency evaluation and frame-pacing control to account for latency occurring both before and during the frame timing events that Schluessler already tracks . 07-22-aia AIA Claims 3, 10-14, 16, and 18 are r ejected under 35 U.S.C. 103 as being unpatentable over S chluessler et al, U.S. Patent Application Publication No. 2022/0122566 A1 (hereinafter "Schluessler") in view of Wang et al. U.S. Patent Application Publication No. 2024/0269549 A1 (hereinafter "Wang”), a s applied to claims 1, 2, 4, 7, and 8 a bove, and further in view of R odrigues De Araujo et al., U.S. Patent No. 9,971,443 B2 (hereinafter "Araujo”). R egarding Claim 3, Schluessler teaches determining a fourth time that the present call associated with the frame occurs (“determining measured timing data in response to a presentation request (e.g., present call)” and “the frame pacer updates records of measured timing data since the last present,” wherein the measured present call between frames is interpreted as the fourth time.) (e.g., Schluessler, paragraphs [0065] and [0069]). computing a third latency based at least on the second time and the fourth time (“a system monitor tracks the simulation...and display time for each frame,” and measuring times includes “the frame’s simulation time,” wherein the interval between Schluessler’s simulation time and present call time is interpreted as the third latency.) (e.g., Schluessler, paragraphs [0039] and [0042]). Schluessler does not appear to specifically teach that the third time corresponds to a time the frame buffer flip associated with the frame occurs , computing a fourth latency based at least on the fourth time and the third time, or computing the second latency based at least on the first latency, the third latency, and the fourth latency . However, Araujo teaches a frame buffer flip time (“the display ‘flips’ or ‘swaps’ between two buffers which are used for display and rendering,” and “the system flips/swaps the buffers so that B is now visible and A can be rendered into,” and “the system determines a point in time Tr at which the display system will be refreshed from the frame buffer,” wherein Araujo’s refresh time Tr, at which the display is refreshed from the frame buffer by flipping/swapping buffers, is interpreted as the third time corresponding to the frame buffer flip time.) (e.g., Araujo, Col 3 lines 21-27, Abstract, Figures 1 and 3-4 ). Schluessler in view of Araujo and Wang teaches computing a fourth latency based at least on the fourth time and the third time . Schluessler contributes the fourth time because Schluessler teaches timing data associated with a present call, including an OS timestamp recording when the application calls the present function. Araujo contributes the third time because Araujo teaches measuring when a frame reaches the buffer flip using the system’s vertical refresh cycle. In particular, Araujo teaches that the display “flips” or “swaps” between display buffers and that the system determines “a point in time Tr at which the display system will be refreshed from the frame buffer.” Thus, Araujo’s refresh time Tr is interpreted as the time when the frame reaches the buffer flip. Wang contributes the latency calculation teaching because Wang teaches “measurements of latency between specific events within an overall cloud gaming processing pipeline” and calculating “one or more other measurements of lag using any suitable permutation” of pipeline timestamps. Accordingly, when Schluessler’s present call time is combined with Araujo’s buffer-flip timing, Wang provides the teaching to compute a latency between those timestamped pipeline events. Therefore, the interval between the present call time and the buffer flip is interpreted as the fourth latency based at least on the fourth time and the third time. (e.g., Schluessler paragraphs [0061] and [0065], Araujo Col 3 lines 21-27, Araujo Abstract, Araujo Figures 1 and 3-4, and Wang paragraphs [0018] and [0042]). computing the second latency based at least on the first latency, the third latency, and the fourth latency (“such metrics may include measurements of latency between specific events within an overall cloud gaming processing pipeline,” and “Client control unit 110 may also additionally, alternatively, or analogously calculate one or more other measurements of lag using any suitable permutation of the cloud gaming input instruction timestamp, the frame creation timestamp, the frame render timestamp, and/or a corresponding client-side frame display timestamp,” wherein Wang teaches calculating latency measurements using different combinations of timestamped events in the graphics processing pipeline, and the first latency, third latency, and fourth latency correspond to latency measurements for different portions of the latency path from input, to simulation, to present call, to buffer flip.) (e.g., Wang, paragraphs [0018] and [0042]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Schluessler, Araujo, and Wang before him or her, to modify Schluessler’s frame pacing method to include Araujo’s buffer flip timing and Wang’s latency calculations. Schluessler, Araujo, and Wang are analogous art because each reference addresses the same problem of reducing or measuring latency in an input, rendering, frame timing, or display pipeline by using timing information associated with pipeline events. Schluessler teaches a frame pacing framework that uses measured timing data from prior frames to calculate when subsequent frames should be simulated, rendered, and displayed. Thus, Schluessler’s scheduler depends on accurate measurements of the frame pipeline in order to control later frame pacing. Araujo teaches reducing system latency by timing rendering and display refresh around the vertical refresh cycle, including determining when the display is refreshed from the frame buffer during the buffer flip. A person of ordinary skill in the art would have been motivated to incorporate Araujo’s buffer flip timing into Schluessler’s frame pacing framework because the buffer flip identifies the actual display endpoint of the frame pipeline, which Schluessler’s scheduler uses when calculating and aligning later frame timing. This modification would have predictably improved the Schluessler-Wang framework by allowing the system to use Araujo’s buffer flip timing as the display endpoint for the time based latency calculation, thereby providing a more complete measurement of latency after the present call and before the frame is refreshed from the frame buffer. Regarding Claim 10, Wang teaches a system comprising: one or more processing units to (“In some examples, the term “physical processor,” such as processor 130 in FIG. 2 , generally refers to any type or form of hardware-implemented processing unit capable of interpreting and/or executing computer-readable instructions”) (e.g., Wang, paragraph [0067]). Schluessler teaches determining a first time that a frame associated with a software application is simulated (“In embodiments, a system monitor tracks the simulation, creation, rendering and display time for each frame,” and “Measuring times associated with the creation of each individual frame—this includes the frame's simulation time, when the frame was submitted to the driver and GPU, and when the frame was presented on the display,” wherein Schluessler’s frame simulation time is interpreted as the first time that the frame associated with the software application is simulated.) (e.g., Schluessler, paragraphs [0039] and [0042]). Araujo teaches determining a second time that a frame buffer flip associated with the frame occurs (“the display ‘flips’ or ‘swaps’ between two buffers which are used for display and rendering,” “the system flips/swaps the buffers so that B is now visible and A can be rendered into,” and “the system determines a point in time Tr at which the display system will be refreshed from the frame buffer,” wherein Araujo’s refresh time Tr, at which the display is refreshed from the frame buffer by flipping or swapping buffers, is interpreted as the second time that the frame buffer flip associated with the frame occurs.) (e.g., Araujo, Col. 3 lines 21-27, Abstract, Figures 1 and 3-4). Wang teaches compute, based at least on the first time and the second time, a latency associated with the software application (“such metrics may include measurements of latency between specific events within an overall cloud gaming processing pipeline,” and “one or more other measurements of lag using any suitable permutation of the cloud gaming input instruction timestamp, the frame creation timestamp, the frame render timestamp, and/or a corresponding client-side frame display timestamp,” wherein Wang teaches computing latency measurements using timestamped events in a graphics processing pipeline. Thus, Wang’s timestamp based latency calculation is interpreted as computing the latency associated with the software application based at least on Schluessler’s frame simulation time and Araujo’s frame buffer flip time.) (e.g., Wang, paragraphs [0018] and [0042]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Schluessler, Araujo, and Wang before him or her, to modify Schluessler’s system to determine Araujo’s frame buffer flip time and to compute a latency based on Schluessler’s frame simulation time and Araujo’s frame buffer flip time. Schluessler, Araujo, and Wang are analogous art because each reference addresses timing or latency in a graphics rendering or display pipeline. Schluessler teaches tracking simulation, rendering, and display timing for frames and using those timing values to control frame pacing. Araujo teaches a concrete display endpoint for a rendered frame by determining when the display is refreshed from the frame buffer during a buffer flip. Wang teaches computing latency measurements between timestamped events in a graphics processing pipeline. A person of ordinary skill in the art would have been motivated to combine these teachings because Schluessler’s frame pacing system depends on knowing when frames are simulated and displayed, Araujo identifies the frame buffer flip as a specific display timing event, and Wang provides a known way to compute latency from such timestamped pipeline events. Incorporating Araujo’s frame buffer flip timing and Wang’s latency calculation into Schluessler would improve Schluessler’s frame pacing system by allowing the system to quantify the time from frame simulation to the frame buffer flip, thereby providing a more complete display related latency measurement for controlling and evaluating the graphics pipeline. Regarding Claim 11, Schluessler teaches wherein the one or more processing units are further to determine a third time that a present call associated with the frame occurs (“determining measured timing data in response to a presentation request (e.g., present call)” and “the frame pacer updates records of measured timing data since the last present,” and “FIG. 19 illustrates an exemplary graphics software architecture for a data processing system 1000 … at least one processor 1030. In some embodiments, processor 1030 includes a graphics processor 1032 and one or more general-purpose processor core(s)”, wherein the measured present call between frames is interpreted as the third time.) (e.g., Schluessler, paragraphs [0065], [0069], and [0219]). compute, based least on the first time and the third time, a second latency (“In embodiments, a system monitor tracks the simulation, creation, rendering and display time for each frame,” “Measuring times associated with the creation of each individual frame includes the frame’s simulation time,” and “appPresentRequested” may be the “OS Timestamp that app called present function,” wherein Schluessler teaches measuring the frame’s simulation time and the present call time. The interval between the simulation time and the present call time is interpreted as the second latency based at least on the first time and the third time.) (e.g., Schluessler, paragraphs [0039], [0042], and [0061]). Schluessler does not appear to specifically teach how to compute, based at least on the third time and the second time, a third latency, wherein the latency associated with the software application is computed based at least on the second latency and the third latency . However, Wang teaches compute, based at least on the third time and the second time, a third latency, wherein the latency associated with the software application is computed based at least on the second latency and the third latency. (“such metrics may include measurements of latency between specific events within an overall cloud gaming processing pipeline,” and “one or more other measurements of lag using any suitable permutation of the cloud gaming input instruction timestamp, the frame creation timestamp, the frame render timestamp, and/or a corresponding client-side frame display timestamp,” wherein Wang teaches computing latency measurements between timestamped pipeline events and computing overall lag measurements using different combinations of such timestamped events. In the Schluessler-Araujo-Wang framework, Schluessler’s present call time is interpreted as the third time, Araujo’s frame buffer flip time is interpreted as the second time, the simulation-to-present latency is interpreted as the second latency, and the present-to-buffer-flip latency is interpreted as the third latency. Thus, Wang’s latency calculation using timestamped pipeline events is interpreted as computing the third latency based at least on the third time and the second time, and computing the latency associated with the software application based at least on the second latency and the third latency.) (e.g., Wang, paragraphs [0018] and [0042]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Schluessler, Araujo, and Wang before him or her, to modify Schluessler’s system to compute latency values using Schluessler’s present call timing, Araujo’s frame buffer flip timing, and Wang’s timestamp based latency calculations. Schluessler, Araujo, and Wang are analogous art because each reference addresses timing or latency in a graphics rendering or display pipeline. Schluessler teaches a frame pacing system that tracks frame timing data and uses that timing data to control when frames are simulated, rendered, and displayed. Araujo teaches that the frame buffer flip identifies when the rendered frame becomes the frame used for display refresh. Wang teaches computing latency between timestamped events in a graphics processing pipeline. A person of ordinary skill in the art would have been motivated to combine these teachings because Schluessler’s frame pacing system already depends on measured timing points in the frame pipeline, Araujo provides a more specific display timing point for when the frame reaches the buffer flip, and Wang provides the known calculation technique for converting those timing points into latency values. Incorporating Araujo’s buffer flip timing and Wang’s latency calculation into Schluessler would have produced the predictable result of allowing the system to separately measure the simulation-to-present latency and the present-to-buffer-flip latency, which would provide a more granular representation of latency in the system and thereby improve identification of bottlenecks in the frame pipeline. Regarding Claim 12, Schluessler teaches one or more processing units are further to: based at least on a present call associated with the frame occurring (“determining measured timing data in response to a presentation request (e.g., present call)” and “the frame pacer updates records of measured timing data since the last present,” and “FIG. 19 illustrates an exemplary graphics software architecture for a data processing system 1000 … at least one processor 1030. In some embodiments, processor 1030 includes a graphics processor 1032 and one or more general-purpose processor core(s)”) (e.g., Schluessler, paragraphs [0065], [0069], and [0219]). Wang teaches generate data representing at least an identifier associated with the frame (“receive, in response to sending the cloud gaming input information, a frame creation timestamp that marks when a frame was drawn for a virtual display at the cloud gaming server,” “a rendering engine or other application at the cloud gaming server may generate a particular frame... in specific response to the cloud gaming input information transmitted at step 101,” and “feedback message 802 may include a corresponding table 804... which together aggregate the matching information from table 704 and table 754,” wherein Wang teaches generating data identifying a particular frame and matching that frame to corresponding pipeline information. The frame creation timestamp or matching information associated with the generated frame is interpreted as the identifier associated with the frame.) (e.g., Wang, paragraphs [0030], [0032], and [0037]). Schluessler and Wang do not appear to specifically teach to determine , based at least on the data, that the frame buffer flip is associated with the frame, wherein the latency is further computed based at least on the determination that the frame buffer flip is associated with the frame. However, Araujo teaches how to determine, based at least on the data, that the frame buffer flip is associated with the frame, wherein the latency is further computed based at least on the determination that the frame buffer flip is associated with the frame . (“the display “flips” or “swaps” between two buffers which are used for display and rendering,” “the system flips/swaps the buffers so that B is now visible and A can be rendered into,” and “the system determines a point in time Tr at which the display system will be refreshed from the frame buffer,” wherein Araujo teaches that a frame is rendered into a frame buffer and that, during the buffer flip, the buffer containing the frame becomes the visible buffer used for display refresh. Thus, when the data identifies the frame, Araujo’s buffer flip identifies when that same frame becomes visible on the display. Therefore, associating the identified frame with the buffer flip is interpreted as determining, based at least on the data, that the frame buffer flip is associated with the frame. Because Araujo’s refresh time Tr is the time when that identified frame is refreshed from the frame buffer, using Tr in the latency calculation is interpreted as computing the latency based at least on the determination that the frame buffer flip is associated with the frame.) (e.g., Araujo, Col. 3 lines 21-27, Abstract, Figures 1 and 3-4). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Schluessler, Araujo, and Wang before him or her, to modify Schluessler’s system to use Wang’s frame identifying data to associate the frame with Araujo’s frame buffer flip timing for Wang’s latency calculation. Schluessler, Araujo, and Wang are analogous art because each reference addresses timing or latency in a graphics rendering or display pipeline. A person of ordinary skill in the art would have been motivated to combine these teachings because Schluessler tracks timing data for frames, Wang teaches generating data identifying and matching frames with pipeline information, and Araujo teaches the buffer flip timing for the displayed frame. Incorporating Wang’s frame identifying data and Araujo’s buffer flip timing into Schluessler would have produced the predictable result of allowing the system to match the correct frame to its corresponding buffer flip timing, thereby improving accuracy of the latency measurement for that frame. Regarding Claim 13, Wang teaches wherein one or more processing units are further to: determine a third time that an input event associated with the software application is sent, wherein the frame is associated with the input event (“at step 101 one or more of the systems described herein may send, to a cloud gaming server, cloud gaming input information with an input creation timestamp that marks when the cloud gaming input information was created,” “input sending unit 104 may... identify a timestamp that matches the corresponding user input such that the timestamp indicates the particular time at which the user input information was created in response to the actual manual input by the user,” “a rendering engine or other application at the cloud gaming server may generate a particular frame... in specific response to the cloud gaming input information transmitted at step 101,” “the matching process [is] to match the specific created frame, as a response, to a particular item of cloud gaming input information,” and “In some examples, the term “physical processor,” such as processor 130 in FIG. 2 , generally refers to any type or form of hardware-implemented processing unit capable of interpreting and/or executing computer-readable instructions”, wherein the cloud gaming input information/user input is interpreted as the input event associated with the software application, sending the cloud gaming input information to the cloud gaming server is interpreted as the input event being sent, and the input creation timestamp is interpreted as the third time. Wang further teaches that the frame is generated in response to and matched to the cloud gaming input information, which is interpreted as the frame being associated with the input event.) (e.g., Wang, paragraphs [0023], [0027], [0032-0033], and [0067]). wherein the latency is further computed based at least on the third time (“client control unit 110 may subtract the input creation timestamp from the frame render timestamp, thereby deriving a precise measurement of end-to-end latency between creation of the cloud gaming input information and client-side rendering of the frame,” wherein Wang teaches computing latency using the input creation timestamp. Thus, Wang’s input creation timestamp is interpreted as the third time used in computing the latency.) (e.g., Wang, paragraph [0041]). Regarding Claim 14, the rejection of claims 10 and 13 is incorporated herein. As discussed above, Wang teaches determining the third time associated with the sent input event, Schluessler teaches determining the first time associated with simulating the frame, and Araujo teaches determining the second time associated with the frame buffer flip. Wang further teaches computing latency measurements between timestamped events in a graphics processing pipeline (“such metrics may include measurements of latency between specific events within an overall cloud gaming processing pipeline,” and “one or more other measurements of lag using any suitable permutation of the cloud gaming input instruction timestamp, the frame creation timestamp, the frame render timestamp, and/or a corresponding client-side frame display timestamp”). Therefore, computing a latency between Wang’s input event time and Schluessler’s frame simulation time is interpreted as computing the second latency based at least on the third time and the first time, and computing a latency between Schluessler’s frame simulation time and Araujo’s frame buffer flip time is interpreted as computing the third latency based at least on the first time and the second time. Wang’s teaching of computing latency measurements using timestamped pipeline events is further interpreted as computing the latency associated with the software application based at least on the second latency and the third latency. (e.g., Wang, paragraphs [0018] and [0042]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Schluessler, Araujo, and Wang before him or her, to modify the system of claim 13 to compute latency values for the input-to-simulation portion and the simulation-to-buffer-flip portion of the graphics pipeline. A person of ordinary skill in the art would have been motivated to do so because Wang teaches measuring latency between timestamped pipeline events, Schluessler provides the simulation timing for the frame, and Araujo provides the frame buffer flip timing for the frame. Incorporating these teachings would have produced the predictable result of allowing the system to separately measure input-to-simulation latency and simulation-to-buffer-flip latency, thereby providing a more granular representation of latency in the system and improving identification of bottlenecks in the frame pipeline. Regarding Claim 16, Schluessler and Wang teach, based at least on the frame associated with the software application being simulated, generate first data representative of at least the first time and an identifier associated with the frame . Schluessler teaches the first time because “In embodiments, a system monitor tracks the simulation, creation, rendering and display time for each frame,” and “Measuring times associated with the creation of each individual frame includes the frame’s simulation time.” Wang teaches the identifier associated with the frame because Wang teaches receiving “a frame creation timestamp that marks when a frame was drawn for a virtual display at the cloud gaming server,” and further teaches matching “the specific created frame, as a response, to a particular item of cloud gaming input information.” Thus, Schluessler’s frame simulation time is interpreted as the first time, and Wang’s frame creation timestamp or frame matching information is interpreted as the identifier associated with the frame. (e.g., Schluessler, paragraphs [0039] and [0042], and Wang, paragraphs [0030] and [0033]). Araujo teaches, based at least on the frame buffer flip associated with the frame occurring, generate second data representative of at least the second time (“the display ‘flips’ or ‘swaps’ between two buffers which are used for display and rendering,” and “the system determines a point in time Tr at which the display system will be refreshed from the frame buffer,” wherein Araujo teaches determining refresh time Tr for the frame buffer flip/display refresh. Araujo’s determined refresh time Tr is interpreted as the second data representative of the second time.) (e.g., Araujo, Col. 3 lines 21-27, Abstract, Figures 1 and 3-4). Wang teaches wherein the latency associated with the software application is computed based at least on the first data and the second data. (“such metrics may include measurements of latency between specific events within an overall cloud gaming processing pipeline,” and “one or more other measurements of lag using any suitable permutation of the cloud gaming input instruction timestamp, the frame creation timestamp, the frame render timestamp, and/or a corresponding client-side frame display timestamp,” wherein Wang teaches computing latency using timestamped pipeline events. Thus, computing latency using the first data including Schluessler’s simulation time and Wang’s frame identifier, together with Araujo’s refresh time Tr, is interpreted as computing the latency associated with the software application based at least on the first data and the second data.) (e.g., Wang, paragraphs [0018] and [0042]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine Schluessler, Araujo, and Wang because each reference addresses timing or latency in a graphics rendering or display pipeline. Schluessler teaches tracking frame simulation timing to control frame pacing, Wang provides frame identifying and matching data for associating a generated frame with corresponding pipeline information, and Araujo provides the frame buffer flip timing that identifies when the frame reaches the display refresh stage. A person of ordinary skill in the art would have been motivated to combine these teachings because graphics pipeline stages may operate on different frames in parallel, so frame identifying data would allow the system to match the correct simulated frame with its corresponding buffer flip timing. This would have produced the predictable result of allowing latency to be computed using timing data for the same identified frame, thereby improving the accuracy and reliability of the latency measurement. Regarding Claim 18, the examiner selects the limitation “ a system implemented at least partially using cloud computing resources ” for this rejection. Wang teaches a system implemented at least partially using cloud computing resources (“such metrics may include measurements of latency between specific events within an overall cloud gaming processing pipeline,” “one or more of the systems described herein may send, to a cloud gaming server, cloud gaming input information,” and “a rendering engine or other application at the cloud gaming server may generate a particular frame... in specific response to the cloud gaming input information transmitted at step 101,” wherein Wang teaches a cloud gaming system that performs input processing, frame generation, and latency measurement using a cloud gaming server.) (e.g., Wang, paragraphs [0018], [0023], and [0032]) . 07-22-aia AIA Claim s 6, 9, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Schluessler et al, U.S. Patent Application Publication No. 2022/0122566 A1 (hereinafter "Schluessler") in view of Wang et al. U.S. Patent Application Publication No. 2024/0269549 A1 (hereinafter "Wang”) , as applied to claim s 1, 2, 4, 7, and 8 above, and further in view of McAllen et al., U.S. Patent Application Publication No. 2020/0278758 A1 (hereinafter "McAllen”) . Regarding Claim 6, Schluessler and Wang do not appear to specifically teach causing, based at least on a predetermined time period elapsing since the first time, the second input event to occur . However, McAllen teaches causing, based at least on a predetermined time period elapsing since the first time, the second input event to occur (“the transfer offset comprises an indication in +/−microseconds informing gaming controller 301 to speed up or delay its next input state delivery... to ensure proper timing of receipt of user input state by game application 432 with regard to the recurrent system event” and “Adjustment system 442 can compute two values, a number of microseconds until a next input state should be sent from an input device, and an interval in microseconds at which subsequent user input state traffic should be sent from the device,” wherein McAllen teaches determining timing values that cause an input device to send a next user input state and subsequent user input state traffic at specified microsecond intervals. McAllen’s user input state sent from input device for delivery to the game application is interpreted as the input event, the time of a first user input state delivery is interpreted as the first time, the number of microseconds until the next input state should be sent is interpreted as the predetermined time period, and the next user input state delivery is interpreted as the second input event caused to occur based at least on the predetermined time period elapsing since the first time.) (e.g., McAllen, paragraph [0077]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Schluessler, Wang, and McAllen before him or her, to modify the Schluessler-Wang framework to cause the second input event to occur based at least on a predetermined time period elapsing since the first time. Schluessler, Wang, and McAllen are analogous art because each reference addresses the same problem of reducing or measuring latency using event timestamps. Schluessler teaches a frame pacing framework that uses measured timing data from one or more previous frames to control when later frames are simulated, rendered, and displayed. Wang teaches calculating latency measurements between input events and frame related events using event timestamps. McAllen teaches reducing input latency by controlling when user input state is delivered from an input device to an application, including determining microsecond timing values for when a next input state and subsequent input state traffic should be sent. A person of ordinary skill in the art would have been motivated to apply McAllen’s timed user input delivery technique to the Schluessler-Wang framework because, as McAllen paragraphs 10-11 and 70-71 explain, game applications desire to associate changes in user input state with particular frames on which user initiated actions occur, and McAllen provides the application with fresher user input state by triggering delivery of the user input state based on recurrent system events such as graphics rendering or display refresh timing. Applying this teaching to the Schluessler-Wang framework would cause the second input event to be delivered according to a known timing interval and in coordination with the frame processing timing, rather than allowing the second input event to occur according to an uncontrolled input device cadence. This would better align the second input event with the corresponding second frame used in the latency calculation and would improve the accuracy of the second input-to-frame latency measurement. Regarding Claim 9, McAllen teaches computing a third latency associated with a peripheral device that receives one or more inputs associated with the software application (“input device 110 is shown as an exemplary input device comprising a game controller 101, mouse 102, or keyboard 103,” “Adjustment system 442 can comprise link lag or latency determination units which determine a link lag between a user input device and an application,” and “Adjustment system 442 determines a difference in time... to determine a transfer lag or latency between transmission of the user input state by game controller 301 and receipt by game application 432,” wherein McAllen teaches user input devices, including a game controller, mouse, or keyboard, that receive user input for an application and further teaches determining transfer lag or latency associated with transmission of user input state from the user input device to the game application. McAllen’s user input device is interpreted as the peripheral device that receives one or more inputs associated with the software application, and McAllen’s transfer lag or latency between transmission of the user input state by the user input device and receipt by the game application is interpreted as the third latency associated with the peripheral device.) (e.g., McAllen, paragraphs [0027], [0064], and [0074]). McAllen does not appear to specifically teach computing a fourth latency associated with a display device that presents at least the frame and computing a fifth latency based at least on the second latency, the third latency, and the fourth latency. However, Schluessler teaches computing a fourth latency associated with a display device that presents at least the frame (“In embodiments, a system monitor tracks the simulation, creation, rendering and display time for each frame,” “These times from one or more previous frames are inputs to control technology that predicts the optimal simulation and display times for the next frames,” and “Measuring times associated with the creation of each individual frame... includes the frame’s simulation time, when the frame was submitted to the driver and GPU, and when the frame was presented on the display”.) (e.g., Schluessler, paragraphs [0039] and [0042]). McAllen does not appear to specifically teach computing a fifth latency based at least on the second latency, the third latency, and the fourth latency . However, Wang teaches computing a fifth latency based at least on the second latency, the third latency, and the fourth latency (“such metrics may include measurements of latency between specific events within an overall cloud gaming processing pipeline,” “client control unit 110 may subtract the input creation timestamp from the frame render timestamp, thereby deriving a precise measurement of end-to-end latency between creation of the cloud gaming input information and client-side rendering of the frame,” and “client control unit 110 may also additionally, alternatively, or analogously calculate one or more other measurements of lag using any suitable permutation of the cloud gaming input instruction timestamp, the frame creation timestamp, the frame render timestamp, and/or a corresponding client-side frame display timestamp,” wherein Wang teaches computing latency measurements for an overall graphics processing pipeline and computing end-to-end latency using timestamped input and frame related events)(e.g., Wang, paragraphs [0018] and [0041]-[0042]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Schluessler, Wang, and McAllen before him or her, to modify the Schluessler-Wang framework to compute a third latency associated with the peripheral device and to compute a fifth latency based at least on the second latency, the third latency, and the fourth latency. Schluessler, Wang, and McAllen are analogous art because each reference is directed to measuring or reducing latency in an interactive graphics or gaming pipeline. In paragraph 54, Schluessler expressly seeks to achieve “the lowest latency from input data to frame display time.” Schluessler measures frame and display timing, while McAllen provides an additional technique for determining transfer lag between a user input device and a game application. Wang further teaches computing latency measurements using input timestamps and later frame timestamps. A person of ordinary skill in the art would have been motivated to combine these teachings because McAllen’s transfer lag, Schluessler’s display timing, and Wang’s timestamp based latency calculations each relate to a different portion of the same input to display path. Incorporating these teachings would improve Schluessler’s frame pacing system by allowing it to measure a more complete latency path from user input, through frame processing, and to display presentation, thereby better supporting Schluessler’s goal of reducing latency from input data to frame display time. Regarding Claim 17, the claim recites substantially similar limitations to claim 9, but in system form and with the latency values renumbered. In particular, claim 17 recites computing a latency associated with a peripheral device that receives inputs, computing a latency associated with a display device that presents the frame, and computing another latency based on those latency values and the latency recited in claim 10. These limitations correspond to the peripheral-device latency, display-device latency, and combined latency limitations addressed above with respect to claim 9. Therefore, claim 17 is rejected under 35 U.S.C. § 103 for the same reasons set forth above with respect to claim 9 . 07-22-aia AIA Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Schluessler et al, U.S. Patent Application Publication No. 2022/0122566 A1 (hereinafter "Schluessler") in view of Wang et al. U.S. Patent Application Publication No. 2024/0269549 A1 (hereinafter "Wang”) , as applied to claim s 1, 2, 4, 7, and 8 above, and further in view of Formby et al., U.S. Patent Application Publication No. 2014/0006610 A1 (hereinafter "Formby”) . Regarding Claim 5, Wang teaches computing a third latency based at least on the first time and the second time (“such metrics may include measurements of latency between specific events within an overall cloud gaming processing pipeline, including... creation of input information... [and] a frame creation event at which point a frame, which was triggered by such user input, is actually generated or rendered at the cloud gaming server,” wherein the latency between creation of the input information and the frame creation event triggered by the input is interpreted as the third latency based at least on the first time and the second time.) (e.g., Wang, paragraph [0018]). computing a fourth latency based at least on the fourth time and the fifth time (“such metrics may include measurements of latency between specific events within an overall cloud gaming processing pipeline,” and “one or more other measurements of lag using any suitable permutation of the cloud gaming input instruction timestamp, the frame creation timestamp, the frame render timestamp, and/or a corresponding client-side frame display timestamp,” wherein Wang teaches calculating latency measurements using different combinations of timestamped input and frame events, and the latency between a second input event timestamp and a second frame creation time is interpreted as the fourth latency based at least on the fourth time and the fifth time.) (e.g., Wang, paragraphs [0018] and [0042]). Schluessler and Wang do not appear to specifically teach wherein the computing the first latency comprises computing the first latency based at least on an average of the third latency and the fourth latency . However, Formby teaches computing an average latency based on first and second latency values (“to calculate a first difference between the first data packet’s arrival time with the first data packet’s predetermined time,” and “to calculate a second difference between the second data packet’s arrival time to the second data packet’s predetermined time and to average the first difference and the second difference, resulting in a first average latency,” wherein Formby teaches averaging first and second latency values to obtain an average latency value. Thus, Formby supports computing the claimed first latency based at least on an average of the third latency and the fourth latency because Formby teaches that separate latency values calculated from separate timestamped events can be combined by averaging to produce an average latency value.) (e.g., Formby, paragraphs [0012] and [0018]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Schluessler, Wang, and Formby before him or her, to modify the Schluessler-Wang framework to compute the first latency based at least on an average of the third latency and the fourth latency. Schluessler, Wang, and Formby are analogous art because each reference addresses the same problem of reducing or measuring latency using event timestamps. Wang teaches calculating latency measurements between input events and frame events. Schluessler teaches that timing data from one or more previous frames is used to predict later frame timing. Formby teaches averaging multiple latency measurements to obtain an average latency. A person of ordinary skill in the art would have been motivated to average the latency for the first input and frame with the latency for the second input and second frame because Schluessler’s frame pacing method relies on timing information from multiple frames rather than a single frame. Using Formby’s averaging technique on latency values from multiple input-to-frame measurements would have reduced the effect of variation in any one individual latency measurement. This is because a single frame measurement may be higher or lower than the surrounding frame measurements, while an average better represents the latency trend used by the frame pacing process. This modification would have predictably improved the Schluessler-Wang framework by allowing the system to average multiple input-to-frame latency samples, thereby reducing statistical variation among individual latency data points when computing the first latency . 07-22-aia AIA Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Schluessler et al, U.S. Patent Application Publication No. 2022/0122566 A1 (hereinafter "Schluessler") in view of Wang et al. U.S. Patent Application Publication No. 2024/0269549 A1 (hereinafter "Wang”) , as applied to claim s 1, 2, 4, 7, and 8 above, and further in view of Formby et al., U.S. Patent Application Publication No. 2014/0006610 A1 (hereinafter "Formby”) in view of Rodrigues De Araujo et al., U.S. Patent No. 9,971,443 B2 (hereinafter "Araujo”) . Regarding Claim 15, Wang teaches wherein the one or more processing units are further to: determine a fourth time that a second input event associated with the software application is sent (“at step 101 one or more of the systems described herein may send, to a cloud gaming server, cloud gaming input information with an input creation timestamp that marks when the cloud gaming input information was created,” “input sending unit 104 may... identify a timestamp that matches the corresponding user input such that the timestamp indicates the particular time at which the user input information was created in response to the actual manual input by the user,” and “In some examples, the term “physical processor,” such as processor 130 in FIG. 2 , generally refers to any type or form of hardware-implemented processing unit capable of interpreting and/or executing computer-readable instructions,” wherein a subsequent item of cloud gaming input information/user input is interpreted as the second input event associated with the software application, and its input creation timestamp is interpreted as the fourth time that the second input event is sent.) (e.g., Wang, paragraphs [0023], [0027], and [0067]). determine, based at least on the fourth time and the fifth time, a fourth latency (“such metrics may include measurements of latency between specific events within an overall cloud gaming processing pipeline, including... creation of input information... [and] a frame creation event at which point a frame, which was triggered by such user input, is actually generated or rendered at the cloud gaming server,” wherein Wang teaches computing latency between the input creation time and the frame event triggered by the input. In the Schluessler-Wang framework, the subsequent input creation timestamp is interpreted as the fourth time, the subsequent frame simulation time is interpreted as the fifth time, and the latency between those times is interpreted as the fourth latency.) (e.g., Wang, paragraph [0018]). wherein the latency associated with the software application is computed based at least on the fifth latency and the third latency (“such metrics may include measurements of latency between specific events within an overall cloud gaming processing pipeline,” and “one or more other measurements of lag using any suitable permutation of the cloud gaming input instruction timestamp, the frame creation timestamp, the frame render timestamp, and/or a corresponding client-side frame display timestamp,” wherein Wang teaches computing latency measurements using different timestamped events in an overall graphics processing pipeline. In the Schluessler-Araujo-Wang-Formby framework, the fifth latency represents an average input-to-simulation latency, and the third latency represents the simulation-to-buffer-flip latency. Computing the software application latency based on those values is interpreted as computing the latency associated with the software application based at least on the fifth latency and the third latency.) (e.g., Wang, paragraphs [0018] and [0042]). Wang does not appear to specifically teach how to determine a fifth time that a second frame associated with the second input event is simulated and compute a fifth latency based at least on an average of the second latency and the fourth latency . However, Schluessler in view of Wang teaches how to determine a fifth time that a second frame associated with the second input event is simulated (“In embodiments, a system monitor tracks the simulation, creation, rendering and display time for each frame,” “These times from one or more previous frames are inputs to control technology that predicts the optimal simulation and display times for the next frames,” and “a rendering engine or other application at the cloud gaming server may generate a particular frame... in specific response to the cloud gaming input information transmitted at step 101,” wherein Schluessler teaches determining simulation timing for each frame and Wang teaches that a frame is generated in response to input information. Thus, Schluessler’s simulation time for a subsequent frame generated in response to Wang’s subsequent input information is interpreted as the fifth time that the second frame associated with the second input event is simulated.) (e.g., Schluessler, paragraphs [0039] and [0042], and Wang, paragraph [0032]). Schluessler in view of Wang does not appear to specifically teach how to compute a fifth latency based at least on an average of the second latency and the fourth latency . However, Formby teaches how to compute a fifth latency based at least on an average of the second latency and the fourth latency (“to calculate a first difference between the first data packet’s arrival time with the first data packet’s predetermined time,” and “to calculate a second difference between the second data packet’s arrival time to the second data packet’s predetermined time and to average the first difference and the second difference, resulting in a first average latency,” wherein Formby teaches averaging first and second latency values to obtain an average latency value. Thus, Formby’s average latency is interpreted as the fifth latency based at least on an average of the second latency and the fourth latency.) (e.g., Formby, paragraphs [0012] and [0018]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Schluessler, Araujo, Wang, and Formby before him or her, to modify the system of claim 14 to compute an average input-to-simulation latency using multiple input-to-frame latency samples. Schluessler, Araujo, Wang, and Formby are analogous art because each reference addresses timing or latency in a graphics rendering, display, or data processing pipeline. A person of ordinary skill in the art would have been motivated to combine these teachings because Wang teaches measuring latency between input events and frame events, Schluessler provides simulation timing for multiple frames, Araujo provides the frame buffer flip timing, and Formby provides a known technique for averaging multiple latency values. Incorporating Formby’s averaging technique to the system in claim 14 would have produced the predictable result of reducing variation from any one input-to-simulation latency sample, thereby providing a more stable latency value that can be combined with the simulation-to-buffer-flip latency to evaluate latency in the frame pipeline . 07-21-aia AIA Claim s 19 and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over Wang et al. U.S. Patent Application Publication No. 2024/0269549 A1 (hereinafter "Wang") in view of Rodrigues De Araujo et al., U.S. Patent No. 9,971,443 B2 (hereinafter "Araujo”) . Regarding Claim 19, Wang teaches a processor comprising: one or more processing units (“the term “physical processor,” such as processor 130 in FIG. 2, generally refers to any type or form of hardware-implemented processing unit capable of interpreting and/or executing computer-readable instructions.”) (e.g., Wang, paragraph [0067]). to compute a latency associated with a computing device based at least on a first time that an input event associated with a software application occurs (“at step 101 one or more of the systems described herein may send, to a cloud gaming server, cloud gaming input information with an input creation timestamp that marks when the cloud gaming input information was created,” and “input sending unit 104 may... identify a timestamp that matches the corresponding user input such that the timestamp indicates the particular time at which the user input information was created in response to the actual manual input by the user,” wherein Wang’s user input/cloud gaming input information is interpreted as the input event associated with the software application, and the input creation timestamp is interpreted as the first time that the input event occurs.) (e.g., Wang, paragraphs [0023] and [0027]). Wang does not appear to specifically teach a second time that a frame buffer flip associated with a frame of the software application occurs, wherein the frame is associated with sampling the input event . However, Araujo teaches a second time that a frame buffer flip associated with a frame of the software application occurs, wherein the frame is associated with sampling the input event (“the display ‘flips’ or ‘swaps’ between two buffers which are used for display and rendering,” “the system determines a point in time Tr at which the display system will be refreshed from the frame buffer,” “sampling of the touch sensing system is initiated to obtain sampled touch data,” and “a frame that reflects the touch event data is rendered to the frame buffer prior to the time Tr,” wherein Araujo teaches sampling touch input, computing touch event data from the sampled touch data, rendering a frame reflecting the touch event data to the frame buffer, and refreshing the display system from the frame buffer at time Tr. Thus, Araujo’s sampled touch data is interpreted as the sampled input event, Araujo’s frame reflecting the touch event data is interpreted as the frame associated with sampling the input event, and Araujo’s refresh time Tr is interpreted as the second time that the frame buffer flip associated with the frame occurs. Araujo’s Figure 4 further confirms this interpretation because it illustrates initiating touch sampling for touch m, rendering a frame that reflects the corresponding touch event data to the frame buffer before refresh time Tr, and then flipping or swapping the frame buffer so the frame is displayed.) (e.g., Araujo, Abstract, Col. 3 lines 21-27, and Figures 1 and 3-4). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine Wang and Araujo, since both references address latency in interactive systems where user input causes a graphical response to be displayed. Wang teaches measuring latency and providing feedback to improve the cloud gaming experience when latency is too high. Araujo teaches a known way to reduce that type of latency by coordinating when touch input is sampled, when the responsive frame is rendered, and when the display is refreshed from the frame buffer. A person of ordinary skill in the art would have been motivated to use Araujo’s touch sensing and display refresh timing with Wang’s latency measurement system because Wang’s feedback would identify when latency is excessive, and Araujo provides a known timing technique for reducing the delay between the input and the displayed responsive frame. The combination would have produced the predictable result of allowing Wang’s system not only to measure input latency, but also to evaluate whether coordinating input sampling, rendering, and frame buffer refresh reduces the latency actually seen by the user. Regarding Claim 20, the claim recites substantially similar limitations to claim 18, but applies the selected implementation to the processor rather than the system. Therefore, claim 20 is rejected under 35 U.S.C. § 103 for the same reasons set forth above with respect to claim 18. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to AREEBAH FATIMA whose telephone number is (571)270-0294. The examiner can normally be reached 9am - 5pm. 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, Rehana Perveen can be reached at (571) 272-3676. 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. /AREEBAH FATIMA/Examiner, Art Unit 2189 /REHANA PERVEEN/Supervisory Patent Examiner, Art Unit 2189 Application/Control Number: 18/154,237 Page 2 Art Unit: 2189 Application/Control Number: 18/154,237 Page 3 Art Unit: 2189 Application/Control Number: 18/154,237 Page 4 Art Unit: 2189 Application/Control Number: 18/154,237 Page 5 Art Unit: 2189 Application/Control Number: 18/154,237 Page 6 Art Unit: 2189 Application/Control Number: 18/154,237 Page 7 Art Unit: 2189 Application/Control Number: 18/154,237 Page 8 Art Unit: 2189 Application/Control Number: 18/154,237 Page 9 Art Unit: 2189 Application/Control Number: 18/154,237 Page 10 Art Unit: 2189 Application/Control Number: 18/154,237 Page 11 Art Unit: 2189 Application/Control Number: 18/154,237 Page 12 Art Unit: 2189 Application/Control Number: 18/154,237 Page 13 Art Unit: 2189 Application/Control Number: 18/154,237 Page 14 Art Unit: 2189 Application/Control Number: 18/154,237 Page 15 Art Unit: 2189 Application/Control Number: 18/154,237 Page 16 Art Unit: 2189 Application/Control Number: 18/154,237 Page 17 Art Unit: 2189 Application/Control Number: 18/154,237 Page 18 Art Unit: 2189 Application/Control Number: 18/154,237 Page 19 Art Unit: 2189 Application/Control Number: 18/154,237 Page 20 Art Unit: 2189 Application/Control Number: 18/154,237 Page 21 Art Unit: 2189 Application/Control Number: 18/154,237 Page 22 Art Unit: 2189 Application/Control Number: 18/154,237 Page 23 Art Unit: 2189 Application/Control Number: 18/154,237 Page 24 Art Unit: 2189 Application/Control Number: 18/154,237 Page 25 Art Unit: 2189 Application/Control Number: 18/154,237 Page 26 Art Unit: 2189 Application/Control Number: 18/154,237 Page 27 Art Unit: 2189 Application/Control Number: 18/154,237 Page 28 Art Unit: 2189 Application/Control Number: 18/154,237 Page 29 Art Unit: 2189 Application/Control Number: 18/154,237 Page 30 Art Unit: 2189 Application/Control Number: 18/154,237 Page 31 Art Unit: 2189 Application/Control Number: 18/154,237 Page 32 Art Unit: 2189 Application/Control Number: 18/154,237 Page 33 Art Unit: 2189 Application/Control Number: 18/154,237 Page 34 Art Unit: 2189 Application/Control Number: 18/154,237 Page 35 Art Unit: 2189 Application/Control Number: 18/154,237 Page 36 Art Unit: 2189 Application/Control Number: 18/154,237 Page 37 Art Unit: 2189 Application/Control Number: 18/154,237 Page 38 Art Unit: 2189 Application/Control Number: 18/154,237 Page 39 Art Unit: 2189 Application/Control Number: 18/154,237 Page 40 Art Unit: 2189 Application/Control Number: 18/154,237 Page 41 Art Unit: 2189 Application/Control Number: 18/154,237 Page 42 Art Unit: 2189 Application/Control Number: 18/154,237 Page 43 Art Unit: 2189 Application/Control Number: 18/154,237 Page 44 Art Unit: 2189 Application/Control Number: 18/154,237 Page 45 Art Unit: 2189 Application/Control Number: 18/154,237 Page 46 Art Unit: 2189 Application/Control Number: 18/154,237 Page 47 Art Unit: 2189 Application/Control Number: 18/154,237 Page 48 Art Unit: 2189 Application/Control Number: 18/154,237 Page 49 Art Unit: 2189 Application/Control Number: 18/154,237 Page 50 Art Unit: 2189 Application/Control Number: 18/154,237 Page 51 Art Unit: 2189 Application/Control Number: 18/154,237 Page 52 Art Unit: 2189 Application/Control Number: 18/154,237 Page 53 Art Unit: 2189 Application/Control Number: 18/154,237 Page 54 Art Unit: 2189 Application/Control Number: 18/154,237 Page 55 Art Unit: 2189 Application/Control Number: 18/154,237 Page 56 Art Unit: 2189
Prosecution Insights