Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
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.
Claims 6, 14, 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.
The above claims each recite the limitation "the graphical representation". There is insufficient antecedent basis for this limitation in these claims. There is reference to a display in the claims for which these depend, but it is unclear whether this is the same device.
Claim Rejections - 35 USC § 103
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.
Claim(s) is/are rejected under 35 U.S.C. 103 as being unpatentable over 20090157359 A1, MECHANISM FOR PROFILING PROGRAM SOFTWARE RUNNING ON A PROCESSOR, Chernoff; Anton (Chernoff hereafter), 2009-06-18. In view of 20190147402 A1, SYSTEMS AND METHODS PROVIDING COLLABORATING AMONG A PLURALITY OF USERS, Sitrick; David H. et all. (Strick hereafter) 2019-05-16.
Chernoff teaches the following substantially as claimed.
1. A computer-implemented method comprising:
collecting data relating to each event being executed at a specific time instance by a computing system, wherein each event is part of a thread of associated events;
[0028] The profiling mechanism 200 extends the processor architecture to allow user mode (CPL3) processes to gather performance data about themselves with very low overhead. For example, modules such as dynamic optimizers and managed runtime environments may be enabled to monitor the currently running program with high accuracy and resolution, thereby allowing them to report on performance problems and opportunities and fix them immediately. The architecture extensions may allow a program to gather performance data and examine it either by polling or by taking an occasional interrupt. It introduces minimal additional state to the CPU and to the process. It differs from conventional performance counters in that large quantities of data may be collected with no interrupts, considerably reducing the overhead of using performance feedback. More particularly, in one embodiment the profiling mechanism 200 described herein may be used with a polling scheme that requires no data collection interrupts at all. The profiling mechanism 200 may also allow a user mode program to control its data collection without calling a driver, which may be a software routine that interacts with data collection hardware or software. Finally, the profiling mechanism 200 may run within the context of a thread, so it may be used by multiple processes within a system at the same time.
[0030] In one embodiment, the profiling mechanism 200 may gather information associated with events such as instructions retired, branches (i.e., transfer of control) retired, and certain data cache misses. However, it is contemplated that in other embodiments other events such as CPU cycles, data TLB misses, instruction TLB misses, floating point operations, instruction cache (ICache) misses, and memory lock contention, for example, may also be monitored. The event information may be recorded in event records, examples of which are illustrated in FIG. 3A through FIG. 3C.
generating, for each thread, a ring buffer specifying each event being executed at the specific time instance;
[0033] The fourth address space within memory 14 illustrates an embodiment of a monitor thread designated P1T3. The address space for the monitor thread includes space for a number of ring buffers (e.g., 232A and 232B). As shown, the monitor code is user mode code. The monitor thread P1T3 may be used to monitor a number of processes that may be executing on any processor core. In the illustrated embodiment, there are two ring buffers and thus two processes are being monitored. However, any number of threads or processes may be monitored in other embodiments. For example, if the monitor thread P1T3 is monitoring threads in other processes, the ring buffers 232A and 232B may be in memory that is shared with the processes being monitored and the buffers may be read and written by both the monitor thread P1T3 and by the threads being monitored.
storing data relating to each event of the thread in the ring buffer;
[0029] In various embodiments, when enabled, the monitor logic 18 may be configured to monitor and count one or more events during the execution of user mode code and at predetermined intervals, to insert event records into a ring buffer (e.g., ring buffer 231A) in the address space of the running process within memory 14. Once a ring buffer is filled to a user-specified threshold, the monitor logic 18 may cause an interrupt to the OS, which the OS may use to signal a process to empty the buffer by moving the buffer contents to non-volatile storage (e.g., peripheral device 13A) or by using the buffer contents in some other way. With proper OS support, the interrupt may even be delivered to a separate process or thread. In some embodiments, the profiling mechanism 200 may allow the user program to manually insert information into an event record in the ring buffer, allowing the program to record software events that may affect the interpretation of the other data in the buffer.
retrieving stored data from one or more ring buffers;
[0029] Once a ring buffer is filled to a user-specified threshold, the monitor logic 18 may cause an interrupt to the OS, which the OS may use to signal a process to empty the buffer by moving the buffer contents to non-volatile storage (e.g., peripheral device 13A) or by using the buffer contents in some other way. With proper OS support, the interrupt may even be delivered to a separate process or thread.
Chernoff does not teach the following limitation:
generating an output representing the stored data from the ring buffer; and causing display of the output.
Sitrick does however.
[0442] The display generation logic, is responsive to the formatted presentation data, to generate a display output, and the display apparatus provides a corresponding presentation responsive to the display output. It would have been obvious to one of ordinary skill in the art at the time of this application’s filing to modify Chernoff’s design such that it allowed for event data to be displayed from the ring buffer as this would in turn provide insights on system performance that would be otherwise hidden from the end user.
Chernoff teaches the following substantially as claimed.
The reasoning cited for the rejection of claim 1 applies to its child, claim 2.
2. The computer-implemented method of claim 1,
wherein the ring buffer stores per thread events with a size that corresponds with a CPU L2 cache or a L1 cache.
[0047] As described above, when a monitored event overflows its event counter, the monitor logic 18 writes an event record into the appropriate event ring buffer. In various embodiments, and as shown in FIG. 3A through FIG. 3C, each event record in the ring buffer is 32 bytes long. However, it is contemplated that in other embodiments any number of bytes may be used as desired. The actual record size may be determined by using a CPUID command to characterize the profiling mechanism 200. It is noted that Reserved fields in event records may be set to zero when the profiling mechanism 200 writes an event record. However, other embodiments may provide other ways of characterizing the profiling mechanism. It is noted that the event records shown in FIG. 3A through FIG. 3C are exemplary records. In other embodiments, event records may include other fields, the fields may be arranged differently in the record, or the fields may have different sizes than the event records shown in FIG. 3A through FIG. 3C.
Chernoff teaches the following substantially as claimed.
The reasoning cited for the rejection of claim 2 applies to its child, claim 3.
3. The computer-implemented method of claim 2,
wherein the size of the event data is 64 bytes.
[0047] However, it is contemplated that in other embodiments any number of bytes may be used as desired.
Chernoff teaches the following substantially as claimed.
The reasoning cited for the rejection of claim 1 applies to its child, claim 4.
4. The computer-implemented method of claim 1,
wherein the data collected for each event includes any of: a time stamp, an event type, and one or more type-specific parameters.
[0048] Referring to FIG. 3A, an exemplary event record 305 for instructions retired is shown. In the first row, beginning from the right, byte 0 is the event ID field, which specifies the event record type. The event ID of one (1) represents the instructions retired event record. In one embodiment, valid identifiers are 1 to 255, and zero is an invalid event identifier. The next byte is the core identifier field. For multicore systems, this field identifies the core on which the profiling mechanism 200 is running. This field allows software to aggregate event records from multiple threads into a single buffer without losing CPU information. In one embodiment, for single core systems an ID of zero may be used. In some embodiments, the core identifier may be supplied from a machine specific register (MSR) or other value that is initialized by the operating system or other code. The next two bytes is an event-specific flags field and may include any number of flags dependent on the type of event record. In the present exemplary event record, the entire field is reserved. The next four bytes represent an event-specific data field. In the present exemplary event record, these bytes are reserved. The next row includes bytes 8:15, and represents the instruction address.
Chernoff teaches the following substantially as claimed.
The reasoning cited for the rejection of claim 1 applies to its child, claim 5.
5. The computer-implemented method of claim 1,
wherein a scope of each event is derived based on aggregating a timing of each event being executed.
[0048] This field allows software to aggregate event records from multiple threads into a single buffer without losing CPU information.
Chernoff teaches the following substantially as claimed.
7. A system comprising:
one or more processors;
[0007] Various embodiments of a mechanism for profiling software running on a processor are disclosed. In one embodiment, a processor having one or more processor cores includes execution logic that may execute instructions including one or more processes. Each process may include one or more execution threads. The processor also includes a profiling mechanism that includes monitor logic and a monitor process. The monitor logic may monitor the one or more processes and provide access to performance data associated with the one or more processes without interrupting a flow of control of the one or more processes being monitored. The monitor process may gather the performance data.
one or more non-transitory processor readable storage devices comprising instructions which, when executed by the one or more processors, cause the one or more processor to perform operations comprising:
[0016] Turning now to FIG. 1, a block diagram of one embodiment of a computer system 10 is shown. In the illustrated embodiment, the computer system 10 includes a processing node 12 coupled to memory 14 and to peripheral devices 13A-13B. The node 12 includes processor cores 15A-15B coupled to a node controller 20 which is further coupled to a memory controller 22, a plurality of HyperTransport.TM. (HT) interface circuits 24A-24C, and a shared level three (L3) cache memory 60. The HT circuit 24C is coupled to the peripheral device 16A, which is coupled to the peripheral device 16B in a daisy-chain configuration (using HT interfaces, in this embodiment). The remaining HT circuits 24A-B may be connected to other similar processing nodes (not shown) via other HT interfaces (not shown). The memory controller 22 is coupled to the memory 14. In one embodiment, node 12 may be a single integrated circuit chip comprising the circuitry shown therein in FIG. 1. That is, node 12 may be a chip multiprocessor (CMP). Any level of integration or discrete components may be used. It is noted that processing node 12 may include various other circuits that have been omitted for simplicity. It is noted that reference designators that include a number and a letter (e.g., processor core 15A) may be referred to by the number only where appropriate.
[0022] Generally, a processor core 15A-15B may include circuitry that is designed to execute instructions defined in a given instruction set architecture. That is, the processor core circuitry may be configured to fetch, decode, execute, and store results of the instructions defined in the instruction set architecture. For example, in one embodiment, processor cores 15A-15B may implement the x86 architecture. As such, the processor cores may be operated in one or more modes or protection levels, which are typically referred to as CPU protection levels (CPLs) or protection rings. In the x86 architecture, there are four levels, designated CPL0 through CPL3, although only two are commonly used. One of the commonly used levels is CPL0, which is typically referred to as kernel mode and is the most privileged level. The other commonly used level is CPL3, which is typically referred to as user mode and is the least privileged level.
collecting data relating to each event being executed at a specific time instance, wherein each event is part of a thread of associated events;
The above limitation corresponds to 1a and is therefore rejected for the same reason.
generating, for each thread, a buffer specifying each event being executed at the specific time instance;
The above limitation corresponds to 1b and is therefore rejected for the same reason.
generating an output representing the data from the buffer; and causing display of the output.
The above limitation corresponds to 1e and is therefore rejected for the same reason.
Chernoff teaches the following substantially as claimed.
The reasoning cited for the rejection of claim 7 applies to its child, claim 8.
8. The system of claim 7, wherein the operations further comprise:
storing data relating to each event of the thread in the buffer;
[0029] In some embodiments, the profiling mechanism 200 may allow the user program to manually insert information into an event record in the ring buffer
and retrieving stored data from the buffer,
[0029] Once a ring buffer is filled to a user-specified threshold, the monitor logic 18 may cause an interrupt to the OS, which the OS may use to signal a process to empty the buffer by moving the buffer contents to non-volatile storage (e.g., peripheral device 13A) or by using the buffer contents in some other way. With proper OS support, the interrupt may even be delivered to a separate process or thread.
Chernoff does not teach the following limitation:
wherein the output is generated based on the stored data of the buffer.
Sitrick does however.
[0442] The display generation logic, is responsive to the formatted presentation data, to generate a display output, and the display apparatus provides a corresponding presentation responsive to the display output. It would have been obvious to one of ordinary skill in the art at the time of this application’s filing to modify Chernoff’s design such that it allowed for event data to be displayed from the ring buffer as this would in turn provide insights on system performance that would be otherwise hidden from the end user.
Chernoff teaches the following substantially as claimed.
The reasoning cited for the rejection of claim 7 applies to its child, claim 9.
9. The system of claim 7,
wherein the buffer comprises a ring buffer.
[0029] In some embodiments, the profiling mechanism 200 may allow the user program to manually insert information into an event record in the ring buffer
Chernoff teaches the following substantially as claimed.
The reasoning cited for the rejection of claim 9 applies to its child, claim 10.
10. The system of claim 9,
wherein the ring buffer stores per thread events with a size that corresponds with a CPU L2 cache or a L1 cache.
The above limitation corresponds to 2a and is therefore rejected for the same reason.
Chernoff teaches the following substantially as claimed.
The reasoning cited for the rejection of claim 10 applies to its child, claim 11.
11. The system of claim 10,
wherein the size of the event data is 64 bytes.
The above limitation corresponds to 3a and is therefore rejected for the same reason.
Chernoff teaches the following substantially as claimed.
The reasoning cited for the rejection of claim 7 applies to its child, claim 12.
12. The system of claim 7,
wherein the data collected for each event includes any of: a time stamp, an event type, and one or more type-specific parameters.
The above limitation corresponds to 4a and is therefore rejected for the same reason.
Chernoff teaches the following substantially as claimed.
The reasoning cited for the rejection of claim 7 applies to its child, claim 13.
13. The system of claim 7,
wherein a scope of each event is derived based on aggregating a timing of each event being executed.
The above limitation corresponds to 5a and is therefore rejected for the same reason.
Chernoff teaches the following substantially as claimed.
15. One or more non-transitory computer-readable media comprising instructions which, when executed by one or more processors, cause the one or more processors to perform operations comprising:
collecting data relating to each event being executed at a specific time instance by a computing system, wherein each event is part of a thread of associated events;
The above limitation corresponds to 1a and is therefore rejected for the same reason.
generating, for each thread, a ring buffer specifying each event being executed at the specific time instance;
The above limitation corresponds to 1b and is therefore rejected for the same reason.
storing data relating to each event of the thread in the ring buffer;
The above limitation corresponds to 1c and is therefore rejected for the same reason.
retrieving stored data from one or more ring buffers;
The above limitation corresponds to 1d and is therefore rejected for the same reason.
generating an output representing the stored data from the ring buffer; and causing display of the output.
The above limitation corresponds to 1e and is therefore rejected for the same reason.
Chernoff teaches the following substantially as claimed.
The reasoning cited for the rejection of claim 15 applies to its child, claim 16.
16. The one or more non-transitory computer-readable media of claim 15,
wherein the ring buffer stores per thread events with a size that corresponds with a CPU L2 cache or a L1 cache.
The above limitation corresponds to 2a and is therefore rejected for the same reason.
Chernoff teaches the following substantially as claimed.
The reasoning cited for the rejection of claim 16 applies to its child, claim 17.
17. The one or more non-transitory computer-readable media of claim 16,
wherein the size of the event data is 64 bytes.
The above limitation corresponds to 3a and is therefore rejected for the same reason.
Chernoff teaches the following substantially as claimed.
The reasoning cited for the rejection of claim 15 applies to its child, claim 18.
18. The one or more non-transitory computer-readable media of claim 15,
wherein the data collected for each event includes any of: a time stamp, an event type, and one or more type-specific parameters.
The above limitation corresponds to 4a and is therefore rejected for the same reason.
Chernoff teaches the following substantially as claimed.
The reasoning cited for the rejection of claim 15 applies to its child, claim 19.
19. The one or more non-transitory computer-readable media of claim 15,
wherein a scope of each event is derived based on aggregating a timing of each event being executed.
The above limitation corresponds to 5a and is therefore rejected for the same reason.
Claim(s) 6,14,20 is/are rejected under 35 U.S.C. 103 as being unpatentable over 20090157359 A1, MECHANISM FOR PROFILING PROGRAM SOFTWARE RUNNING ON A PROCESSOR, Chernoff; Anton (Chernoff hereafter), 2009-06-18. In view of 20190147402 A1, SYSTEMS AND METHODS PROVIDING COLLABORATING AMONG A PLURALITY OF USERS, Sitrick; David H. et all. (Strick hereafter) 2019-05-16 as well as in further view of 20170266568 A1, SYNCHRONIZED VIDEO WITH IN GAME TELEMETRY, Lucas; Alexander Brian Marshall et all. (Lucas Hereafter), 2017-09-21.
Chernoff does not teach the following limitation:
The reasoning cited for the rejection of claim 1 applies to its child, claim 6.
6. The computer-implemented method of claim 1,
wherein the graphical representation comprises a heatmap.
Lucas does however.
[0088] In some embodiments, the data visualization system 132 may include one or more plug-ins for rendering game metric analyses in certain formats. For example, the data visualization system 132 may have a plug-in that can allow the data visualization system 132 to display game data using a heatmap. It would have been obvious to one of ordinary skill in the art at the time of this application’s filing to modify Chernoff’s design such that it allowed for event data from the ring buffer to be displayed in the form of a heatmap as this would provide a visual aid to help one to better understand system performance.
Chernoff does not teach the following limitation:
The reasoning cited for the rejection of claim 7 applies to its child, claim 14.
14. The system of claim 7,
wherein the graphical representation comprises a heatmap.
Lucas does however.
The above limitation corresponds to 6a and is therefore rejected for the same reason.
Chernoff does not teach the following limitation:
The reasoning cited for the rejection of claim 15 applies to its child, claim 20.
20. The one or more non-transitory computer-readable media of claim 15,
wherein the graphical representation comprises a heatmap.
Lucas does however.
The above limitation corresponds to 6a and is therefore rejected for the same reason.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Luke Absher whose telephone number is (571) 270-1057. The examiner can normally be reached M-F: 8:00 am - 4:00 pm.
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 US PTO Automated Interview Request (AIR) at http:/ /www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Kevin Young can be reached at 571-270-3180.
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.
/LUCAS DONALD ABSHER/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights