DETAILED ACTION
Claims 1-20 are pending.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 03/01/2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 1-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 following claim language is unclear:
As to claim 1, line 3 recites “identifying a scenario in a configuration file” it is unclear from the context of the claim whether the configuration file is part of the trace file or if the configuration file is also obtained. For examination purposes, examiner interprets the limitation as a configuration file being obtained.
As to claim 1, lines 3-7 recite “identifying a log event in the trace file by iterating the state machine through the scenario based at least partially on values obtained from the trace file” If the scenario is obtained from the configuration file, which appears to be separate from the trace file, it is unclear how the state machine identifies a log event in the trace file. Furthermore, it is unclear what “partially” means in the context of the claim.
Claims 2-15 are dependent on claim 1 and fail to cure the deficiencies set forth above for claim 1. Therefore, it is rejected under the same rationale.
Claim 16 is a system type claim having similar deficiencies as claim 1 above. Therefore, it is rejected under the same rationale above.
Claims 17-18 are dependent on claim 16 and fail to cure the deficiencies set forth above for claim 16. Therefore, it is rejected under the same rationale.
Claim 19 is a system type claim having similar deficiencies as claim 16 above. Therefore, it is rejected under the same rationale above.
Claim 20 is dependent on claim 19 and fail to cure the deficiencies set forth above for claim 19. Therefore, it is rejected under the same rationale.
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.
Claims 1-6 and 13-20are rejected under 35 U.S.C. 103 as being unpatentable over Nicolson et al. (US 2009/0119515 A1) in view of O’Reilly Jr et al. (US 2022/0083371 A1) in further view of Geer et al. (US 6,212,667 B1).
Regarding claim 1, Nicolson teaches a method comprising:
obtaining a trace file ([0099] The original code execution unit 906a runs the executable, which is a runnable combination of the original code module 200 and the logging library 206, with the data sets 220 (S406). It should be noted that the data sets 220 are used as input to produce the trace output file 214.);
identifying a scenario in a configuration file ([0100] The obfuscation unit 910 creates a control record 412 for the obfuscation (S410). In other words, the obfuscation unit 910 creates a basic set of obfuscation control parameters, or the control record 412, using either values from user input or a set of predefined values. This control record 412 will play an important role in the feedback process, as will be described later.; [0117] Before the obfuscation in Step S416, there is a process for creating an initial obfuscation control record 412. This control record 412 contains a set of instructions on how to obfuscate. In the present embodiment, for zero or more fundamental blocks of code (as identified by the insertion of block identifiers (S402)) within the original code module 200 there will be an entry in the control record 412 to suggest at least the preferred obfuscation type or the preferred level of obfuscation for the block in question, as well as default values for the rest of the blocks of code.; Fig. 8 Before 200 and After 204 modified code with additional tasks);
implementing a state machine for the scenario ([0083] Therefore, with the obfuscation method of the present embodiment, the obfuscation process is performed based on dynamic analysis. In other words, by evaluating metrics used on the trace output file 218, which indicates the result of executing the obfuscated code module 204, it can be determined whether or not the obfuscated code module 204 has been obfuscated to the optimum degree. If it is determined that the obfuscated code module 204 has not been obfuscated to the optimum degree, the obfuscation process is caused to reflect the result of the aforementioned metrics evaluation, and is run again.; [0089]; Fig. 8; [0101] Next, the obfuscation unit 910 performs the obfuscation (S416). Here, the obfuscation unit 910 takes the inputted original code module 200, the control record 412, the result record 418 (if present), and the obfuscation record 420 (if present), and applies one or more obfuscation techniques to the original code 200.);
identifying a log event in the trace file by iterating the state machine through the scenario based at least partially on values obtained from the trace file ([0110] In the present invention, the determination whether or not to continue iterating may be based on one or more of the following factors: average score of specific metrics (such as execution speed, code size, path coverage, etc.), weighted as desired (including a weight of zero to effectively ignore certain metrics), pass a user-defined threshold (permissible range); specific metrics pass a user-defined threshold (permissible range); number of iterations performed exceed a limit (predetermined number of iterations); optimisation with feedback process execution time or memory requirements exceed a limit, and so on. Note that the determination to iterate may be made in the case where the average value of plural metrics does not fall within a permissible range without the above weighting being performed.); and
reporting a state machine result of the log event ([0173] Then, the obfuscator 1000 generates a metrics report 208b (208), that includes metrics for evaluating the patterns of the execution paths).
While Nicolson teaches taking a trace file and obfuscating it in an obfuscation module by adding a set of blocks of code to determine how to optimize it, Nicholson does not teach the obfuscation module being a state machine nor define these blocks (A0-A4) as a scenario.
However, O’Reilly teaches a state machine (Abstract: Techniques for processing a request may include: providing tasks to a state machine framework, wherein the tasks perform processing of a workflow for servicing the request; generating, by the state machine framework, a state machine for processing the request, wherein the state machine includes states associated with the tasks, wherein generating the state machine may include automatically determining a first state transition of the state machine between a first and a second of the states; receiving the request; and responsive to receiving the request, performing first processing using the state machine to service the request. The framework may automatically generate triggers that drive the state machine to determine subsequent states in accordance with defined state transitions.; [0004] The plurality of tasks may have sequential order denoting an order in which the plurality of tasks are executed when servicing the command).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of O’Reilly with the teachings of Nicolson to utilize state machines to perform iterative testing. The modification would have been motivated by the desire of being able to determine the state of each task and paths with the paths as taught by Nicolson.
Nicolson nor O’Reilly expressly teach blocks (A0-A4) as a scenario.
However, Geer teaches a scenario (Col. 11, lines 64-65: A scenario is usually in the form of "first X happened, then Y, and then Z", where X, Y and Z are events or sets of events.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Geer with the teachings of Nicolson and O’Reilly to further define obfuscation blocks in Fig 8 (A0-A4) as subtasks of a scenario as taught by Geer. The modification would have been motivated by the desire of combining known elements to yield predictable results.
Regarding claim 2, Nicolson teaches wherein the state machine includes a timeout status that reports a timeout result in response to the scenario exceeding a timeout value ([0110] In the present invention, the determination whether or not to continue iterating may be based on one or more of the following factors: average score of specific metrics (such as execution speed, code size, path coverage, etc.), weighted as desired (including a weight of zero to effectively ignore certain metrics), pass a user-defined threshold (permissible range); specific metrics pass a user-defined threshold (permissible range); number of iterations performed exceed a limit (predetermined number of iterations); optimisation with feedback process execution time or memory requirements exceed a limit, and so on. Note that the determination to iterate may be made in the case where the average value of plural metrics does not fall within a permissible range without the above weighting being performed.; [0173] Then, the obfuscator 1000 generates a metrics report 208b (208), that includes metrics for evaluating the patterns of the execution paths).
In addition, O’Reilly teaches a state machine (Abstract).
In addition, Geer teaches timeout status and result (Col. 7, lines 50-60).
Regarding claim 3, Nicolson teaches wherein the scenario includes a plurality of subtasks and iterating the state machine through the scenario includes iterating through the plurality of subtasks ([0110] In the present invention, the determination whether or not to continue iterating may be based on one or more of the following factors: average score of specific metrics (such as execution speed, code size, path coverage, etc.), weighted as desired (including a weight of zero to effectively ignore certain metrics), pass a user-defined threshold (permissible range); specific metrics pass a user-defined threshold (permissible range); number of iterations performed exceed a limit (predetermined number of iterations); optimisation with feedback process execution time or memory requirements exceed a limit, and so on. Note that the determination to iterate may be made in the case where the average value of plural metrics does not fall within a permissible range without the above weighting being performed.; Fig. 13 shows various iterations of the set of tasks A-D).
In addition, O’Reilly teaches a state machine (Abstract).
In addition, Geer teaches timeout status and result (Col. 7, lines 50-60).
Regarding claim 4, Nicolson teaches wherein the state machine includes a timeout status that reports a timeout result in response to a subtask exceeding a timeout value ([0110] In the present invention, the determination whether or not to continue iterating may be based on one or more of the following factors: average score of specific metrics (such as execution speed, code size, path coverage, etc.), weighted as desired (including a weight of zero to effectively ignore certain metrics), pass a user-defined threshold (permissible range); specific metrics pass a user-defined threshold (permissible range); number of iterations performed exceed a limit (predetermined number of iterations); optimisation with feedback process execution time or memory requirements exceed a limit, and so on.) .
In addition, O’Reilly teaches a state machine (Abstract).
In addition, Geer teaches timeout status and result (Col. 7, lines 50-60).
Regarding claim 5, the combination as cited teaches wherein a first timeout status is associated with a first subtask of the plurality of subtasks and a second timeout status is associated with a second subtask of the plurality of subtasks (Nicolson’s [0110] and Geer’s Col. 7, lines 50-60).
Regarding claim 6, the combination teaches wherein iterating through the plurality of subtasks includes comparing a result of a first subtask of the plurality of subtasks to a result of a second subtask of the plurality of subtasks (Nicolson’s [0038] The quality of an obfuscation is measured by metrics, and by examining these metrics in isolation, or by comparing these metrics with the corresponding metrics for the program before obfuscation, the effectiveness of an obfuscating transformation can be observed.; [0072]; [0081] The logging libraries 206 and 212 are libraries which output a code module execution log, and produce respective trace output files 214 and 218. The trace output files 214 and 218 are then taken as input and used by a comparator and metrics module 216; [0110] and Fig, 208a and 208b; Geer’s Col. 7, lines 50-60).
Regarding 13, O’Reilly teaches further comprising defining a list of active state machines based at least partially on the scenario ([0012] FIGS. 3, 5 and 6 are examples that include state machines (SMs) generated in an embodiment in accordance with the techniques herein and associated processing that may be performed by states of the state machine in an embodiment in accordance with the techniques herein; shows active SMs and task status).
Regarding claim 14, O’Reilly teaches after iterating the state machine through the scenario, removing the state machine from the list of active state machines and reporting the state machine as complete with the state machine result (Fig. 3 and Fig. 4 shows SMs and their corresponding state).
Regarding claim 15, O’Reilly teaches after iterating the state machine through a portion of the scenario, identifying a failed subtask and reporting the state machine as incomplete with a state associated with the failed subtask ([0087] In at least one embodiment, an error policy may optionally be specified as a property of each task. The error policy may indicate whether processing of the task, and thus state generated from the task, is to be retried more than once should a failure or error result during the task processing. With reference back to FIG. 3, the SM 301 generally provides for transitioning to task rollback processing if any state or task results in a failure. The failure trigger may be generated in connection with the SM 301 of FIG. 3 the first time processing of the task or state results in an error or failure. As a variation, the error policy may indicate to retry the task or state up to a specified maximum number of times. In this manner, the state may transition back to itself up to the maximum number of times. If an error or failure occurs during processing of the task or state the maximum number of times, then a failure trigger is generated causing transitioning out of the state to another state associated with task rollback processing. In at least one embodiment, the error policy for a task and associated state may identify MAX, that is an integer value denoting the specified maximum number of times that processing of the task, and thus associated state, may be retried in the event an error or failure occurs during task processing. By default, an embodiment may set MAX to 1 and achieve the behavior as described above in connection with FIG. 3.).
Regarding claim 16, Nicolson teaches a system comprising:
a processing system comprising a processor ([0215] a computer system including a microprocessor);
a computer readable storage medium in data communication with the processing system, the hardware storage device having computer readable instructions stored thereon that, when executed by the processing system ([0215] a computer system including a microprocessor, a ROM, a RAM, a hard disk unit, a display unit, a keyboard, a mouse, and the so on. A computer program is stored in the RAM or the hard disk unit. The respective apparatuses achieve their functions through the microprocessor's operation according to the computer program. Here, the computer program is configured by combining plural instruction codes indicating instructions for the computer.), cause the system to:
obtain a trace file ([0099] The original code execution unit 906a runs the executable, which is a runnable combination of the original code module 200 and the logging library 206, with the data sets 220 (S406). It should be noted that the data sets 220 are used as input to produce the trace output file 214.);
obtain a configuration file ([0100] The obfuscation unit 910 creates a control record 412 for the obfuscation (S410). In other words, the obfuscation unit 910 creates a basic set of obfuscation control parameters, or the control record 412, using either values from user input or a set of predefined values. This control record 412 will play an important role in the feedback process, as will be described later.; [0117] Before the obfuscation in Step S416, there is a process for creating an initial obfuscation control record 412. This control record 412 contains a set of instructions on how to obfuscate. In the present embodiment, for zero or more fundamental blocks of code (as identified by the insertion of block identifiers (S402)) within the original code module 200 there will be an entry in the control record 412 to suggest at least the preferred obfuscation type or the preferred level of obfuscation for the block in question, as well as default values for the rest of the blocks of code.);
identify a first scenario in the configuration file including a first plurality of subtasks ([0119] For example, an original code module 200 that includes a Block (A) is obfuscated into an obfuscated code module 204 which includes five blocks, or A0, A1, A2, A3, and A4. To put it differently, the obfuscator 1000 creates the blocks A0, A1, A2, A3, and A4.);
implement a first state machine for the first scenario ([0083] Therefore, with the obfuscation method of the present embodiment, the obfuscation process is performed based on dynamic analysis. In other words, by evaluating metrics used on the trace output file 218, which indicates the result of executing the obfuscated code module 204, it can be determined whether or not the obfuscated code module 204 has been obfuscated to the optimum degree. If it is determined that the obfuscated code module 204 has not been obfuscated to the optimum degree, the obfuscation process is caused to reflect the result of the aforementioned metrics evaluation, and is run again.; [0089]; Fig. 8 Before 200 and After 204 modified code with additional tasks; [0101] Next, the obfuscation unit 910 performs the obfuscation (S416). Here, the obfuscation unit 910 takes the inputted original code module 200, the control record 412, the result record 418 (if present), and the obfuscation record 420 (if present), and applies one or more obfuscation techniques to the original code 200.)
iterate the state machine through the first scenario based at least partially on the trace file ([0109] The obfuscation tuning unit 914 determines whether or not the obfuscation of the obfuscated code module 204 produced in Step S416 is of sufficient quality based on the metrics report 218 produced in Step S428 (S432). In other words, the obfuscation tuning unit 914 determines whether or not to continue iterating round the feedback loop.);
exceed a timeout value associated with the first scenario ([0110] In the present invention, the determination whether or not to continue iterating may be based on one or more of the following factors: average score of specific metrics (such as execution speed, code size, path coverage, etc.), weighted as desired (including a weight of zero to effectively ignore certain metrics), pass a user-defined threshold (permissible range); specific metrics pass a user-defined threshold (permissible range); number of iterations performed exceed a limit (predetermined number of iterations); optimisation with feedback process execution time or memory requirements exceed a limit, and so on. Note that the determination to iterate may be made in the case where the average value of plural metrics does not fall within a permissible range without the above weighting being performed.);
identify a second scenario including a second plurality of subtasks ([0171] The obfuscator 1000 analyzes the trace output file 218a, and because the percentages of the block A.fwdarw.block C path and the block B.fwdarw.block D path are significantly lower than the expected probability P.sub.p, it is deemed that the obfuscation is insufficient, and thus the obfuscation process is repeated with an increase in the percentages of these paths.; [0172] The obfuscator 1000 produces an obfuscated code module 204b (204) through the re-obfuscation. Comparing the obfuscated code module 204b with the obfuscated code module 204a produced through the previous obfuscation, it can be seen that the "if" statement between block B and block C has been changed.);
implement a second state machine for the second scenario ([0173] In the same manner as the obfuscated code module 204a mentioned above, the obfuscated code module 204b is executed upon being produced by the obfuscator 1000.); and
report a timeout event for a subtask of the second plurality of subtasks of the second state machine ([0173] Then, the obfuscator 1000 generates a metrics report 208b (208), that includes metrics for evaluating the patterns of the execution paths).
Nicolson teaches performing iterations/re-obfuscation of the same tasks with varying parameters to optimize it to be within a permissible range. While Nicolson teaches these metrics to include exceed limits, Nicolson does not define the subtasks (A0-A4) as a scenario nor teach wherein metrics include timeout values.
In addition, O’Reilly teaches state machines (Abstract: Techniques for processing a request may include: providing tasks to a state machine framework, wherein the tasks perform processing of a workflow for servicing the request; generating, by the state machine framework, a state machine for processing the request, wherein the state machine includes states associated with the tasks, wherein generating the state machine may include automatically determining a first state transition of the state machine between a first and a second of the states; receiving the request; and responsive to receiving the request, performing first processing using the state machine to service the request. The framework may automatically generate triggers that drive the state machine to determine subsequent states in accordance with defined state transitions.; [0004] The plurality of tasks may have sequential order denoting an order in which the plurality of tasks are executed when servicing the command; [0012] State Machines (SMs)).
In addition, Geer teaches running testcases to measure behavior of an integrated circuits performing desired functions. The test cases are performed according to parameters in a testcase definition file (See Col. 1 through Col. 2 line 33; Fig. 3). Further Geer teaches a scenario (Col. 11, lines 64-65: A scenario is usually in the form of "first X happened, then Y, and then Z", where X, Y and Z are events or sets of events.) and timeout (Col. 7, lines 50-60: Step 350 allows the designer to specify the degree of test coverage that is adequate. If adequate test coverage is not achieved on the first pass, step 360 will modify the testcase generation to achieve one or more testcases that test the as-yet untested aspects of the microarchitecture models 126 during the next iteration. This process will continue until step 350 determines that the test coverage is adequate. In addition, a predetermined limit on the number of iterations or the testing time may be specified that halts the iterations after the limit is met or exceeded, even though the test coverage is not adequate.)
Regarding claim 17, Nicolson teaches wherein the first plurality of subtasks and second plurality of subtasks are the same (Fig. 13 shows two iterations of the same tasks A-D).
Regarding claim 18, Geer teaches wherein reporting a timeout event for the subtask of the second plurality of subtasks of the second state machine further comprises reporting a status for each subtask of the second plurality of subtasks (Col. 7, lines 50-60: Step 350 allows the designer to specify the degree of test coverage that is adequate. If adequate test coverage is not achieved on the first pass, step 360 will modify the testcase generation to achieve one or more testcases that test the as-yet untested aspects of the microarchitecture models 126 during the next iteration. This process will continue until step 350 determines that the test coverage is adequate. In addition, a predetermined limit on the number of iterations or the testing time may be specified that halts the iterations after the limit is met or exceeded, even though the test coverage is not adequate.).
Regarding claim 19, it is a media/product type claim having similar limitations as claim 16 above. Therefore, it is rejected under the same rationale above.
Regarding claim 20, it is a media/product type claim having similar limitations as claim 16 above. Therefore, it is rejected under the same rationale above.
Claims 7-9 are rejected under 35 U.S.C. 103 as being unpatentable over Nicolson, O’Reilly Jr and Geer, as applied to claim 1, in further view of Breternitz et al. (US 2014/0047084 A1).
Regarding claim 7, Nicolson, O’Reilly nor Geer teach wherein the configuration file is a plain text file.
However, Breternitz teaches wherein the configuration file is a plain text file ([0129] a trace file (e.g., configuration file)… The trace file includes data that describe desired computational characteristics of the synthetic test workload, as described herein…The trace file is illustratively a JSON file format, although other suitable file types may be provided.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Breternitz of using a JSON file format for user’s configuration file containing parameters such as the ones used for the obfuscation and testing of Nicolson, O’Reilly and Geer. The modification would have been motivated by the desire of combining known elements to yield predictable results.
Regarding claim 8, Breternitz teaches further comprising validating the configuration file with a schema ([0130] The trace file further identifies at least a portion of a target instruction set architecture (ISA) used as input by synthesizer 79. The trace file further identifies other characteristics associated with instructions of the synthetic workload, including: inter-instruction dependencies (e.g., a first instruction depends on the completion of a second instruction before executing the first instruction), memory register allocation constraints (e.g., constrain an instruction to take a value from a particular register), and architectural execution constraints (e.g., a limited number of logic units being available for executing a particular type of instruction).).
Regarding claim 9, Breternitz teaches wherein the configuration file includes a first subtask and a second subtask and validating the configuration file includes confirming a dependency of a variable in the second subtask to the variable in the first subtask ([0130] The trace file further identifies at least a portion of a target instruction set architecture (ISA) used as input by synthesizer 79. The trace file further identifies other characteristics associated with instructions of the synthetic workload, including: inter-instruction dependencies (e.g., a first instruction depends on the completion of a second instruction before executing the first instruction), memory register allocation constraints (e.g., constrain an instruction to take a value from a particular register), and architectural execution constraints (e.g., a limited number of logic units being available for executing a particular type of instruction).; [0131] Exemplary user-defined workload parameters set forth in the trace file include the following: the total number of instructions to be generated; the types of instructions to be generated including, for example, a floating point instruction, an integer instruction, and a branch instruction; the behavior (e.g., execution flow) of instruction execution, such as, for example, the probabilities of the execution flow branching off (i.e., whether branches are likely to be taken during instruction execution or whether execution will continue along the execution flow path and not jump to a branch); the distribution of data dependencies among instructions).
Claims 10-12 are rejected under 35 U.S.C. 103 as being unpatentable over Nicolson, O’Reilly Jr and Geer, as applied to claim 1, in further view of Raghuraman et al. (US 2005/0021708 A1).
Regarding claim 10, Nicolson, O’Reilly nor Geer teaches further comprising parsing the trace file based at least partially on an initial state of the state machine and defining a variable of the state machine based at least partially on a value from the trace file.
However, Raghuraman teaches further comprising parsing the trace file based at least partially on an initial state of the state machine and defining a variable of the state machine based at least partially on a value from the trace file ([0047] Turning to FIG. 3a, an exemplary set of fields of a trace log record stored by the event tracing sessions 208 is depicted. In an embodiment of the invention, trace records provide the following base information. A thread ID 300 corresponds to a value assigned to the thread from which the event fired. A process ID 302 corresponds the process within which the identified thread operates. A TimeStamp 304 records a machine time assigned to a fired event. It is noted that this value may need to be corrected by an offset in the case of requests executed across multiple machines. An Event Guid 306 identifies a class (grouping) of events. Examples of classes of events include: DiskIO, PageFault, etc. An Event Type 308 specifies a specific type of event within a particular event class. Examples of various identified event types include: Start, End, CheckPoint, Dequeue, Deliver etc. A checkpoint event type signals a thread relinquishing processing of a request. A dequeue event type signals a thread acquiring processing of a request.; [0048] An Instance ID 310 is an identification assigned to an object associated with the currently executing task. The Instance ID 310 enables identification of a particular instance of an object that is responsible for the logged event record and provides yet another piece of information potentially available for tracking completion of a request; [0079] State machines also define the boundaries of particular of requests in a way that builds upon and differs from the limited ways of recording express boundaries through Start/End points in the trace event log files.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Raghuraman with the teachings of Nicolson, O’Reilly and Geer to verify the trace file and determining the state based on identifiers. The modification would have been motivated by the desire of determining whether a request needs to be reexecuted.
Regarding claim 11, Raghuraman teaches wherein the variable is a globally unique identifier (GUID) ([0047] event GUID).
Regarding claim 12, Raghuraman teaches further comprising obtaining an initial GUID value of the trace file before implementing the state machine, wherein defining the variable includes comparing the value from the trace file to the initial GUID value ([0079] State machines also define the boundaries of particular of requests in a way that builds upon and differs from the limited ways of recording express boundaries through Start/End points in the trace event log files. Referring to FIG. 7b, an XML state machine defines the boundaries of a request from event types provided in a trace record file.).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee J Li can be reached at (571)272-4169. 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.
/JORGE A CHU JOY-DAVILA/Primary Examiner, Art Unit 2195