DETAILED ACTION
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 .
This Office Action is in response to amendment filed on 07/22/2026.
Response to Amendment
By this amendment, claims 1-4, 7-8, 10, and 15-19 are amended. Therefore, claims 1-20 are pending. Any objections and rejections not repeated below is withdrawn due to Applicant's amendment.
Response to Arguments
Applicant's arguments filed 07/22/2026 have been fully considered but they are not persuasive. Applicant argues in substance:
The respective elements recited in claim 15 do not recite, nor does any part of claim 15 recite, the terms "means" or "step." Therefore, there is a rebuttable presumption that 35 U.S.C. § 112(f) does not apply. This rebuttable presumption is not and cannot be overcome at least because the components, in particular, the at least one processor, the at least one memory, the monitor, the interceptor, and the monitor manager recited in claim 15 connote sufficiently definite structure for performing the respective particular operations and functions (as more fully recited in claim 15) that would be recognized and understood by a person of ordinary skill in the art, and a person of ordinary skill in the art, when considering the claimed subject matter of claim 15, including the at least one processor, the at least one memory, the monitor, the interceptor, and the monitor manager recited in claim 15 and the respective particular operations and functions performed by the at least one processor, the at least one memory, the monitor, the interceptor, and the monitor manager, in view of the disclosed subject matter of the present application (see specification, e.g., at least at [0077], [0078], [00115], [00116], and [00126]; and FIGs. 1, 2, and 4-6), would readily recognize that the at least one processor, the at least one memory, the monitor, the interceptor, and the monitor manager have sufficiently definite structures for performing their respective recited operations and functions, as more fully recited in claim 15.
With regard to point (a), Examiner agrees with Applicant and all 112(f) interpretations are withdrawn due to Applicant’s arguments.
As can readily be seen, claim 15 recites structural terms, in particular, the at least one processor, the at least one memory, the monitor, the interceptor, and the monitor manager that can perform various respective operations and functions, as more fully recited in claim 15, and such respective operations and functions are supported by the specification. Further, based on at least the foregoing, the specification recites processes and an algorithm (e.g., as reflected or indicated in the various operations, processes, and functions recited in the specification; and as stored in the data store and as executed by the processor component) that enable the at least one processor, the at least one memory, the monitor, the interceptor, and the monitor manager to perform the respective operations and functions recited in the specification, and correspondingly recited in claim 15. Furthermore, based on at least the foregoing, the specification discloses the corresponding structure, material, or acts for performing the entire claimed function and clearly links the structure, material, or acts to the function.
Accordingly, claim 15 contains subject matter that was described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the subject patent application was filed, had possession of the claimed invention of claim 15, and claim 15 satisfies the written description requirement of 35 U.S.C. § 112(a) or (pre-AIA ) 112, first paragraph.
With regard to point (b), Examiner agrees with Applicant and all 112(a) rejections are withdrawn due to Applicant’s arguments and withdrawal of the 112(f) interpretations.
As Claims 15-18 stand rejected under 35 U.S.C. § 112(b) or (pre-AIA ) § 112 second paragraph, as allegedly being indefinite. For at least reasons similar to that stated herein, invocation of 35 U.S.C. § 112(f) or (pre-AIA ) 112, sixth paragraph, with respect to claims 15-18 is not warranted or proper, claims 15-18 satisfy the written description requirement of 35 U.S.C. § 112(a) or (pre-AIA ) 112, first paragraph, and claims 15-18 particularly point out and distinctly claim the respective 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 respective inventions of claims 15-18. Accordingly, claims 15-18 are sufficiently clear and definite, in accordance with 35 U.S.C. § 112(b) or (pre-AIA ) 112, second paragraph. Withdrawal of this rejection is therefore requested.
With regard to point (c), Examiner agrees with Applicant and all 112(b) rejections are withdrawn due to Applicant’s arguments and withdrawal of the 112(f) interpretations.
By giving task and service performance monitoring, and computer-related, methods such technical capabilities and the ability to perform such operations, as recited in claim 1, claim 1 focuses on, recites, is directed to, and embodies a significant technological improvement to existing task and service performance monitoring, and computer-related, methods, systems, and devices. Indeed, one way of showing that a claim is patent eligible and not directed to an abstract idea is by demonstrating that the claim allows the method, system, or device to perform a function that a method, system, or device previously could not perform. Claim 1 does exactly that; it enables a method to perform the aforementioned specific functions, which such methods, systems, and devices were unable to perform previously. Thus, the technological improvements of claim 1 (e.g., the technological improvements to task and service performance monitoring technologies and computer-related technologies of claim 1) provide enhancements over existing task and service performance monitoring technologies and existing computer-related technologies. (See also specification, e.g., at [0018]-[0021], [0027], [0077], [0078], and [00126].) Further, claim 1 recites specific claim elements, as more fully recited above, that do not preempt all applications of the alleged mental process relating to performance of the limitation in the human mind…
For at least reasons similar to that stated herein with regard to independent claim 1, independent claims 15 and 19 are directed to statutory subject matter that is patent-eligible in accordance with 35 U.S.C. § 101. Also, claims 2-14 depend from independent claim 1, claims 16-18 depend from independent claim 15, and claim 20 depends from independent claim 19. Based at least in part on the respective dependence of claims 2-14, 16-18, and 20 from independent claims 1, 15, and 19, claims 2-14, 16-18, and 20 are directed to statutory subject matter that is patent-eligible in accordance with 35 U.S.C. § 101.
With regard to point (d), Examiner agrees with Applicant and all 101 claim rejections are withdrawn due to Applicant’s arguments in combination with Applicant’s stated improvements above. Specifically, the limitations of “deducing, by the system, respective processing states of the respective service requests associated with the respective services based on analyzing respective first header information items contained in respective first headers of the respective service request messages, and respective second header information items contained in respective second headers of the respective response messages, wherein the information comprises the respective first header information items and the respective second header information items” cannot be done mentally and thus fails Step 2A Prong One of MPEP 2106.
However, while Goldberg et al. discloses that each trace event may include trace data and/or metadata, such as a trace identifier (e.g., a request identifier), call path data identifying the other service(s) in the service interaction, a timestamp, parameters of the request or response, and/or other suitable information, discloses that the elements of log data 332A-332N may include information regarding the processing or receipt of a service request or service response, including error messages, debug messages, internal checkpoints, processing results, timestamps, trace identifiers (e.g., request identifiers), request parameters or response parameters, and/or other suitable data and/or metadata, discloses that inbound service request 2310 may also include a request identifier 2240, which may include values for an origin identifier, transaction depth, and request stack, discloses that the request identifier may be presented as part of metadata in a service framework, as part of a Hypertext Transfer Protocol (HTTP) header, or as part of a SOAP header, discloses that log reporting agent 2350 may in various embodiments report the contents of inbound request log 2330 and/or outbound request log 2340 to a log repository (e.g., a data store, such as a database or other location in memory), discloses that, as a request is detected or generated, the log reporting agent may immediately report the information to the log repository, and discloses that log data may specify, for each request identifier, the service that generated the request identifier and/or the service that received the request identifier, as can readily be seen, Goldberg et al. fails to disclose deducing ... respective processing states of the respective service requests associated with the respective services based on analyzing respective first header information items contained in respective first headers of the respective service request messages, and respective second header information items contained in respective second headers of the respective response messages, wherein the information comprises the respective first header information items and the respective second header information items, as recited in claim 1. Further, Goldberg et al. fails to disclose: based on the tracking and based on the deducing of the respective processing states of the respective service requests, determining ... the respective processing states of the respective service requests associated with the respective services, as recited in claim 1…
With regard to point (e), Examiner disagrees with Applicant as Goldberg discloses deducing, by the system, respective processing states of the respective service requests associated with the respective services based on analyzing respective first header information items contained in respective first headers of the respective service request messages, and respective second header information items contained in respective second headers of the respective response messages, wherein the information comprises the respective first header information items and the respective second header information items (Col. 17 lines 40-53: “In various embodiments, inbound service request 2310 may also include a request identifier 2240, which may include values for an origin identifier, transaction depth, and request stack, as described above with respect to FIG. 11. In various embodiments, request identifier 2240 may be embedded within inbound service request 2310 (e.g., as metadata). For example, according to various embodiments, the request identifier may be presented as part of metadata in a service framework, as part of a Hypertext Transfer Protocol (HTTP) header, as part of a SOAP header, as part of a Representational State Transfer (REST) protocol, as part of a remote procedural call (RPC), or as part of metadata of some other protocol, whether such protocol is presently known or developed in the future.”, Col. 8 lines 39-45: “Each trace event may relate to a particular interaction (e.g., a service request or service response) with another service. Each trace event may include trace data and/or metadata, such as a trace identifier (e.g., a request identifier), call path data identifying the other service(s) in the service interaction, a timestamp, parameters of the request or response, and/or other suitable information.”, Note: The embedded request identifiers of service requests are interpreted as the first headers, the embedded request identifiers of service responses are interpreted as the second headers, and the values within each request identifier (origin identifier, transaction depth, and request stack) are interpreted as the deduced processing states); based on the tracking and based on the deducing of the respective processing states of the respective service requests, determining, by the system, the respective processing states of the respective service requests associated with the respective services (Col. 21 lines 15-20: “For instance, as a request is detected or generated, the log reporting agent may immediately report the information to the log repository. In various embodiments, log data may specify, for each request identifier, the service that generated the request identifier and/or the service that received the request identifier.”, Col. 9 lines 26-33: “The elements of log data 332A-332N may include information regarding the processing or receipt of a service request or service response, including error messages, debug messages, internal checkpoints, processing results, timestamps, trace identifiers (e.g., request identifiers), request parameters or response parameters, and/or other suitable data and/or metadata.”, Note: Log data for different request identifiers are interpreted as processing states, Col. 17 lines 40-53: “In various embodiments, inbound service request 2310 may also include a request identifier 2240, which may include values for an origin identifier, transaction depth, and request stack, as described above with respect to FIG. 11. In various embodiments, request identifier 2240 may be embedded within inbound service request 2310 (e.g., as metadata). For example, according to various embodiments, the request identifier may be presented as part of metadata in a service framework, as part of a Hypertext Transfer Protocol (HTTP) header, as part of a SOAP header, as part of a Representational State Transfer (REST) protocol, as part of a remote procedural call (RPC), or as part of metadata of some other protocol, whether such protocol is presently known or developed in the future.”, Col. 8 lines 39-45: “Each trace event may relate to a particular interaction (e.g., a service request or service response) with another service. Each trace event may include trace data and/or metadata, such as a trace identifier (e.g., a request identifier), call path data identifying the other service(s) in the service interaction, a timestamp, parameters of the request or response, and/or other suitable information.”, Note: The embedded request identifiers of service requests are interpreted as the first headers, the embedded request identifiers of service responses are interpreted as the second headers, and the values within each request identifier (origin identifier, transaction depth, and request stack) are interpreted as the deduced processing states). Therefore, the claims are rejected for the reasons in this Office Action’s 102 and 103 rejections below. Argument has not been found to be persuasive.
Wei et al. does not cure the aforementioned deficiencies of Goldberg et al. with regard to the claimed subject matter of claim 3. Rather, Wei et al. discloses the following. Additionally, as shown in FIG. 3C, process execution status table 303 includes a column 310 regarding the process as well as a column 311 indicating whether such a process, including a subprocess, includes a timeout, and if so, the expiration time that pod 202 ceases to perform processing of its assigned tasks. (See [0070].)…
However, while Wei et al. discloses that process execution status table 303 includes a column 310 regarding the process as well as a column 311 indicating whether such a process, including a subprocess, includes a timeout, and if so, the expiration time that pod 202 ceases to perform processing of its assigned tasks, and discloses that process execution status table 303 includes a column 801 directed to the pod end time, which corresponds to the time (e.g., 00:08:00) that the processing of the assigned tasks by that subprocess pod 202 (e.g., subprocess pod 202D handling subprocess B23) was completed, Wei et al. does not disclose, teach, or suggest: in connection with the service request message, from the first device, that requests or invokes the second service, receiving ... a monitoring request message from the first device or an interceptor device, wherein the monitoring request message specifies a timeout period for performance of a service task associated with the service request by the second service, as recited in claim 3. To be clear, although Wei et al. does disclose that process execution status table 303 includes a column 311 indicating whether such a process, including a subprocess, includes a timeout, and discloses that process execution status table 303 includes a column 801 directed to the pod end time, Wei et al. does not disclose, teach, or suggest receiving ... a monitoring request message from the first device or an interceptor device, wherein the monitoring request message specifies a timeout period for performance of a service task associated with the service request by the second service.
With regard to point (f), Examiner disagrees with Applicant as Wei teaches receiving, by the system, a monitoring request message from the first device or an interceptor device, wherein the monitoring request message specifies a timeout period for performance of a service task associated with the service request by the second service ([0070] “Additionally, as shown in FIG. 3C, process execution status table 303 includes a column 310 regarding the process as well as a column 311 indicating whether such a process, including a subprocess, includes a timeout, and if so, the expiration time that pod 202 ceases to perform processing of its assigned tasks.”, [0193] “Furthermore, as discussed above, process planner 210 selects subprocess pod 202B to be restarted on the available node 201 (e.g., node 201C) to handle subprocess B21. As a result, jobs updater 209 updates the timeout of the selected subprocess pod 202 (e.g., subprocess pod 202B) based on the current and timeout for the parent process…”). Therefore, the claims are rejected for the reasons in this Office Action’s 102 and 103 rejections below. Argument has not been found to be persuasive.
Wei et al. does not cure the aforementioned deficiencies of Goldberg et al. with regard to the claimed subject matter of claim 4. Although Wei et al. discloses the previously referenced subject matter ([0070] and [0104]), as is readily apparent, Wei et al. does not disclose, teach, or suggest: in connection with the second service request message, from the second device, that requests or invokes the third service, receiving ... a second monitoring request message from the second device or the interceptor device, wherein the second monitoring request message specifies a second timeout period for performance of a second service task associated with the second service request by the third service, as recited in claim 4.
Rather, Wei et al. discloses that process execution status table 303 includes a column 310 regarding the process as well as a column 311 indicating whether such a process, including a subprocess, includes a timeout, and if so, the expiration time that pod 202 ceases to perform processing of its assigned tasks; and discloses that process execution status table 303 includes a column 801 directed to the pod end time, which corresponds to the time (e.g., 00:08:00) that the processing of the assigned tasks by that subprocess pod 202 (e.g., subprocess pod 202D handling subprocess B23) was completed. (See [0070] and [0104].).
With regard to point (g), Examiner disagrees with Applicant as Wei further teaches wherein the timeout period is a first timeout period … receiving, by the system, a second monitoring request message from the second device or the interceptor device, wherein the second monitoring request message specifies a second timeout period for performance of a second service task associated with the second service request by the third service ([0070] “Additionally, as shown in FIG. 3C, process execution status table 303 includes a column 310 regarding the process as well as a column 311 indicating whether such a process, including a subprocess, includes a timeout, and if so, the expiration time that pod 202 ceases to perform processing of its assigned tasks.”, [0193] “Furthermore, as discussed above, process planner 210 selects subprocess pod 202B to be restarted on the available node 201 (e.g., node 201C) to handle subprocess B21. As a result, jobs updater 209 updates the timeout of the selected subprocess pod 202 (e.g., subprocess pod 202B) based on the current and timeout for the parent process…”). Therefore, the claims are rejected for the reasons in this Office Action’s 102 and 103 rejections below. Argument has not been found to be persuasive.
Wei et al. does not cure the aforementioned deficiencies of Goldberg et al. with regard to the claimed subject matter of claim 17. While Wei et al. discloses the previously referenced subject matter (see [0070] and [0104]), as can readily be seen, Wei et al. does not disclose, teach, or suggest: in connection with the item of service request data, from the first node, that requests or invokes the second service, the monitor manager receives monitoring request data from the first node or the interceptor, wherein the monitoring request data indicates a timeout period for performance of a service task associated with the service request by the second service, as recited in claim 17.
Rather, Wei et al. discloses that process execution status table 303 includes a column 310 regarding the process as well as a column 311 indicating whether such a process, including a subprocess, includes a timeout, and if so, the expiration time that pod 202 ceases to perform processing of its assigned tasks; and discloses that process execution status table 303 includes a column 801 directed to the pod end time, which corresponds to the time (e.g., 00:08:00) that the processing of the assigned tasks by that subprocess pod 202 (e.g., subprocess pod 202D handling subprocess B23) was completed. (See [0070] and [0104].).
With regard to point (h), Examiner disagrees with Applicant for the same reasons in points (f) and (g) above. Therefore, the claims are rejected for the reasons in this Office Action’s 102 and 103 rejections below. Argument has not been found to be persuasive.
Based on at least the foregoing, Parthasarathy et al. at least does not cure the aforementioned deficiencies of Goldberg et al. and Wei et al. with regard to independent claim 1, from which claims 9, 11, and 12 depend. Accordingly, claims 9, 11, and 12 are in condition for allowance, and withdrawal of this rejection is respectfully requested.
With regard to point (i), Examiner disagrees with Applicant for the reasons in point (e) above. Therefore, the claims are still rejected for the reasons in this Office Action’s 102 and 103 rejections below. Argument has not been found to be persuasive.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2, 13-16, and 19-20 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Goldberg et al. Pat. No. US 10,397,343 Bl (hereafter Goldberg).
Regarding claim 1, Goldberg anticipates the invention as claimed, including: A method, comprising: tracking, by a system comprising at least one processor (Col. 27 lines 59-60: “System memory 3020 may be configured to store program instructions and data accessible by processor(s) 3010.”), information associated with respective service requests associated with respective services in connection with performance of a task based on respective service request messages communicated to respective devices associated with the respective services, respective response messages received from the respective devices associated with the respective services, or respective update messages updating respective processing statuses of the respective service requests (Col. 3 lines 15-16: “The services 110A-110N may be implemented using a plurality of hosts”, Col. 20 lines 61-67: “Referring collectively to FIG. 12 and FIG. 13, each service within the service-oriented system may include a log reporting agent, such as log reporting agent 2350. Log reporting agent 2350 may in various embodiments report the contents of inbound request log 2330 and/or outbound request log 2340 to a log repository (e.g., a data store, such as a database or other location in memory).”, Col. 21 lines 15-20: “For instance, as a request is detected or generated, the log reporting agent may immediately report the information to the log repository. In various embodiments, log data may specify, for each request identifier, the service that generated the request identifier and/or the service that received the request identifier.”, Col. 9 lines 26-33: “The elements of log data 332A-332N may include information regarding the processing or receipt of a service request or service response, including error messages, debug messages, internal checkpoints, processing results, timestamps, trace identifiers (e.g., request identifiers), request parameters or response parameters, and/or other suitable data and/or metadata.”, Note: Processing of a service request is interpreted as a service request message, receipt of a service request or service response is interpreted as a response message, a report/update by a log reporting agent of a service on a host (device) is interpreted as an update message, and log data for different request identifiers are interpreted as processing states), wherein the respective service request messages, the respective response messages, or the respective update messages comprise a correlation identifier that identifies the task (Col. 14 lines 9-11: “Accordingly, each of such requests may be associated with each other by virtue of containing the same origin identifier.”); deducing, by the system, respective processing states of the respective service requests associated with the respective services based on analyzing respective first header information items contained in respective first headers of the respective service request messages, and respective second header information items contained in respective second headers of the respective response messages, wherein the information comprises the respective first header information items and the respective second header information items (Col. 17 lines 40-53: “In various embodiments, inbound service request 2310 may also include a request identifier 2240, which may include values for an origin identifier, transaction depth, and request stack, as described above with respect to FIG. 11. In various embodiments, request identifier 2240 may be embedded within inbound service request 2310 (e.g., as metadata). For example, according to various embodiments, the request identifier may be presented as part of metadata in a service framework, as part of a Hypertext Transfer Protocol (HTTP) header, as part of a SOAP header, as part of a Representational State Transfer (REST) protocol, as part of a remote procedural call (RPC), or as part of metadata of some other protocol, whether such protocol is presently known or developed in the future.”, Col. 8 lines 39-45: “Each trace event may relate to a particular interaction (e.g., a service request or service response) with another service. Each trace event may include trace data and/or metadata, such as a trace identifier (e.g., a request identifier), call path data identifying the other service(s) in the service interaction, a timestamp, parameters of the request or response, and/or other suitable information.”, Note: The embedded request identifiers of service requests are interpreted as the first headers, the embedded request identifiers of service responses are interpreted as the second headers, and the values within each request identifier (origin identifier, transaction depth, and request stack) are interpreted as the deduced processing states); based on the tracking and based on the deducing of the respective processing states of the respective service requests, determining, by the system, the respective processing states of the respective service requests associated with the respective services (Col. 21 lines 15-20: “For instance, as a request is detected or generated, the log reporting agent may immediately report the information to the log repository. In various embodiments, log data may specify, for each request identifier, the service that generated the request identifier and/or the service that received the request identifier.”, Col. 9 lines 26-33: “The elements of log data 332A-332N may include information regarding the processing or receipt of a service request or service response, including error messages, debug messages, internal checkpoints, processing results, timestamps, trace identifiers (e.g., request identifiers), request parameters or response parameters, and/or other suitable data and/or metadata.”, Note: Log data for different request identifiers are interpreted as processing states, Col. 17 lines 40-53: “In various embodiments, inbound service request 2310 may also include a request identifier 2240, which may include values for an origin identifier, transaction depth, and request stack, as described above with respect to FIG. 11. In various embodiments, request identifier 2240 may be embedded within inbound service request 2310 (e.g., as metadata). For example, according to various embodiments, the request identifier may be presented as part of metadata in a service framework, as part of a Hypertext Transfer Protocol (HTTP) header, as part of a SOAP header, as part of a Representational State Transfer (REST) protocol, as part of a remote procedural call (RPC), or as part of metadata of some other protocol, whether such protocol is presently known or developed in the future.”, Col. 8 lines 39-45: “Each trace event may relate to a particular interaction (e.g., a service request or service response) with another service. Each trace event may include trace data and/or metadata, such as a trace identifier (e.g., a request identifier), call path data identifying the other service(s) in the service interaction, a timestamp, parameters of the request or response, and/or other suitable information.”, Note: The embedded request identifiers of service requests are interpreted as the first headers, the embedded request identifiers of service responses are interpreted as the second headers, and the values within each request identifier (origin identifier, transaction depth, and request stack) are interpreted as the deduced processing states); and determining, by the system, a status of the performance of the task based on the respective processing states of the respective service requests associated with the respective services (Col. 21 lines 15-20: “For instance, as a request is detected or generated, the log reporting agent may immediately report the information to the log repository. In various embodiments, log data may specify, for each request identifier, the service that generated the request identifier and/or the service that received the request identifier.”, Col. 9 lines 26-33: “The elements of log data 332A-332N may include information regarding the processing or receipt of a service request or service response, including error messages, debug messages, internal checkpoints, processing results, timestamps, trace identifiers (e.g., request identifiers), request parameters or response parameters, and/or other suitable data and/or metadata.”, Col. 14 lines 9-11: “Accordingly, each of such requests may be associated with each other by virtue of containing the same origin identifier.”, Col. 8 lines 39-45: “Each trace event may relate to a particular interaction (e.g., a service request or service response) with another service. Each trace event may include trace data and/or metadata, such as a trace identifier (e.g., a request identifier), call path data identifying the other service(s) in the service interaction, a timestamp, parameters of the request or response, and/or other suitable information.”, Note: Log data for different request identifiers are interpreted as processing states, and the status of an overall task can be traced based on timestamps and trace data. Col. 17 lines 40-53: “In various embodiments, inbound service request 2310 may also include a request identifier 2240, which may include values for an origin identifier, transaction depth, and request stack, as described above with respect to FIG. 11. In various embodiments, request identifier 2240 may be embedded within inbound service request 2310 (e.g., as metadata). For example, according to various embodiments, the request identifier may be presented as part of metadata in a service framework, as part of a Hypertext Transfer Protocol (HTTP) header, as part of a SOAP header, as part of a Representational State Transfer (REST) protocol, as part of a remote procedural call (RPC), or as part of metadata of some other protocol, whether such protocol is presently known or developed in the future.”, Note: The embedded request identifiers of service requests are interpreted as the first headers, the embedded request identifiers of service responses are interpreted as the second headers, and the values within each request identifier (origin identifier, transaction depth, and request stack) are interpreted as the deduced processing states).
Regarding claim 2, Goldberg anticipates: presenting, by the system, status-related information relating to the status of the performance of the task or the respective processing states of the respective service requests associated with the respective services (Col. 8 lines 39-45: “Each trace event may relate to a particular interaction (e.g., a service request or service response) with another service. Each trace event may include trace data and/or metadata, such as a trace identifier (e.g., a request identifier), call path data identifying the other service(s) in the service interaction, a timestamp, parameters of the request or response, and/or other suitable information.”, Col. 9 lines 26-33: “The elements of log data 332A-332N may include information regarding the processing or receipt of a service request or service response, including error messages, debug messages, internal checkpoints, processing results, timestamps, trace identifiers (e.g., request identifiers), request parameters or response parameters, and/or other suitable data and/or metadata.”, Col. 9 lines 53-58: “FIG. 4 illustrates retrieval of stored distributed trace data upon request in a service-oriented system, according to some embodiments. Upon request, the individual services 110A-110N may retrieve stored elements of trace data (and optionally, related log data) and provide them to an external component such as the trace analysis system 160.”).
Regarding claim 13, Goldberg anticipates: wherein the task relates to a transaction involving at least one of a product, a service, or a subscription (Col. 3 lines 49-53: “For instance, an end-user operating a web browser on a client computer system may submit a request for data (e.g., data associated with a product detail page, a shopping cart application, a checkout process, search queries, etc.).”).
Regarding claim 14, Goldberg anticipates: wherein at least a portion of the respective service requests for the respective services are asynchronous service requests (Col. 3 lines 46-48: “The service-oriented system 100 may be configured to process requests from various internal or external systems, such as client computer systems”).
Regarding claim 15, Goldberg further anticipates: a system, comprising: at least one memory that stores computer executable components (Col. 28 lines 35-39: “In some embodiments, system memory 3020 may be one embodiment of a computer-readable (i.e., computer-accessible) medium configured to store program instructions and data as described above for implementing embodiments of the corresponding methods and apparatus.”, Col. 28 lines 42-44: “Generally speaking, a computer-readable medium may include non-transitory storage media”); and at least one processor that executes the computer executable components stored in the at least one memory, wherein the computer executable components comprise (Col. 27 lines 59-60: “System memory 3020 may be configured to store program instructions and data accessible by processor(s) 3010.”). The other limitations are substantially the same as those of claim 1. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 16, it is a machine claim whose limitations are substantially the same as those of claim 2. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 19, Goldberg further anticipates: a non-transitory machine-readable medium, comprising executable instructions that, when executed by at least one processor, facilitate performance of operations, comprising (Col. 28 lines 35-39: “In some embodiments, system memory 3020 may be one embodiment of a computer-readable (i.e., computer-accessible) medium configured to store program instructions and data as described above for implementing embodiments of the corresponding methods and apparatus.”, Col. 28 lines 42-44: “Generally speaking, a computer-readable medium may include non-transitory storage media”, Col. 27 lines 59-60: “System memory 3020 may be configured to store program instructions and data accessible by processor(s) 3010.”). The other limitations are substantially the same as those of claim 1. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 20, it is an article of manufacture claim whose limitations are substantially the same as those of claim 2. Accordingly, it is rejected for substantially the same reasons.
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 3-8, 10, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Goldberg et al. Pat. No. US 10,397,343 Bl (hereafter Goldberg) as applied to claims 1-2, 13-16, and 19-20 above, in view of Wei et al. Pub. No. US 2026/0079749 Al (hereafter Wei).
Regarding claim 3, Goldberg teaches the method of claim 1, and Goldberg further teaches wherein the respective services comprise a first service and a second service, wherein the respective devices comprise a first device associated with the first service (Col. 3 lines 15-16: “The services 110A-110N may be implemented using a plurality of hosts”), wherein the respective service request messages comprise a service request message, comprising a service request of the respective service requests, and wherein the method further comprises: in connection with the service request message, from the first device, that requests or invokes the second service (Col. 13 lines 66-67 and Col. 14 lines 1-4: “To fulfill one of such requests, the service-oriented system may call multiple different services. For instance, service "A" may be the initial service called to fulfill a request (e.g., service "A" may be called by an external system). To fulfill the initial request, service "A" may call service "B," which may call service "C," and so on.”) … and generating, by the system, a monitoring service record relating to the service task for the second service … and the correlation identifier associated with the task, a first service identifier associated with the first service, or a second service identifier associated with the second service, and wherein the performance of the service task facilitates the performance of the task (Col. 21 lines 15-20: “For instance, as a request is detected or generated, the log reporting agent may immediately report the information to the log repository. In various embodiments, log data may specify, for each request identifier, the service that generated the request identifier and/or the service that received the request identifier.”, Col. 9 lines 26-33: “The elements of log data 332A-332N may include information regarding the processing or receipt of a service request or service response, including error messages, debug messages, internal checkpoints, processing results, timestamps, trace identifiers (e.g., request identifiers), request parameters or response parameters, and/or other suitable data and/or metadata.”, Note: The request identifier is interpreted as the correlation identifier, the log data of the service that generated the request identifier is interpreted as the first service identifier, and the log data of the service that received the request identifier is interpreted as the second service identifier).
Goldberg fails to teach receiving, by the system, a monitoring request message from the first device or an interceptor device, wherein the monitoring request message specifies a timeout period for performance of a service task associated with the service request by the second service … wherein the monitoring service record comprises the timeout period for the performance of the service task by the second service.
In analogous art Wei teaches receiving, by the system, a monitoring request message from the first device or an interceptor device, wherein the monitoring request message specifies a timeout period for performance of a service task associated with the service request by the second service ([0070] “Additionally, as shown in FIG. 3C, process execution status table 303 includes a column 310 regarding the process as well as a column 311 indicating whether such a process, including a subprocess, includes a timeout, and if so, the expiration time that pod 202 ceases to perform processing of its assigned tasks.”, [0193] “Furthermore, as discussed above, process planner 210 selects subprocess pod 202B to be restarted on the available node 201 (e.g., node 201C) to handle subprocess B21. As a result, jobs updater 209 updates the timeout of the selected subprocess pod 202 (e.g., subprocess pod 202B) based on the current and timeout for the parent process…”) … wherein the monitoring service record comprises the timeout period for the performance of the service task by the second service ([0070] “Additionally, as shown in FIG. 3C, process execution status table 303 includes a column 310 regarding the process as well as a column 311 indicating whether such a process, including a subprocess, includes a timeout, and if so, the expiration time that pod 202 ceases to perform processing of its assigned tasks.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Goldberg to incorporate the teachings of Wei to lower resource consumption in nodes (Wei [0033] “Pods of a node in a container orchestration system utilizing the serverless workflow may be evicted due to resource consumption (e.g., processor, memory) in the node reaching a threshold level thereby freeing up the resource…”).
Regarding claim 4, Goldberg and Wei teach the method of claim 3, Goldberg further teaches wherein the respective services comprise a third service, wherein the respective devices comprise a second device associated with the second service (Col. 3 lines 15-16: “The services 110A-110N may be implemented using a plurality of hosts”), wherein the respective service request messages comprise a first service request message and a second service request message, wherein the service request message is the first service request message, wherein the service request is a first service request, wherein the second service request message comprises a second service request of the respective service requests, wherein the monitoring request message is a first monitoring request message, wherein the monitoring service record is a first monitoring service record … wherein the service task is a first service task, and wherein the method further comprises: in connection with the second service request message, from the second device, that requests or invokes the third service (Col. 13 lines 66-67 and Col. 14 lines 1-4: “To fulfill one of such requests, the service-oriented system may call multiple different services. For instance, service "A" may be the initial service called to fulfill a request (e.g., service "A" may be called by an external system). To fulfill the initial request, service "A" may call service "B," which may call service "C," and so on.”) … and generating, by the system, a second monitoring service record relating to the second service task for the third service … and the correlation identifier associated with the task, the second service identifier associated with the second service, a third service identifier associated with the third service, or a monitoring service record identifier associated with the monitoring service record, and wherein the performance of the second service task facilitates the performance of the task (Col. 13 lines 66-67 and Col. 14 lines 1-4: “To fulfill one of such requests, the service-oriented system may call multiple different services. For instance, service "A" may be the initial service called to fulfill a request (e.g., service "A" may be called by an external system). To fulfill the initial request, service "A" may call service "B," which may call service "C," and so on.”, Col. 21 lines 15-20: “For instance, as a request is detected or generated, the log reporting agent may immediately report the information to the log repository. In various embodiments, log data may specify, for each request identifier, the service that generated the request identifier and/or the service that received the request identifier.”, Col. 9 lines 26-33: “The elements of log data 332A-332N may include information regarding the processing or receipt of a service request or service response, including error messages, debug messages, internal checkpoints, processing results, timestamps, trace identifiers (e.g., request identifiers), request parameters or response parameters, and/or other suitable data and/or metadata.”, Note: The request identifier is interpreted as the correlation identifier, the log data of the second service that generated the request identifier is interpreted as the second service identifier, and the log data of the third service that received the request identifier is interpreted as the third service identifier), and Wei further teaches wherein the timeout period is a first timeout period … receiving, by the system, a second monitoring request message from the second device or the interceptor device, wherein the second monitoring request message specifies a second timeout period for performance of a second service task associated with the second service request by the third service ([0070] “Additionally, as shown in FIG. 3C, process execution status table 303 includes a column 310 regarding the process as well as a column 311 indicating whether such a process, including a subprocess, includes a timeout, and if so, the expiration time that pod 202 ceases to perform processing of its assigned tasks.”, [0193] “Furthermore, as discussed above, process planner 210 selects subprocess pod 202B to be restarted on the available node 201 (e.g., node 201C) to handle subprocess B21. As a result, jobs updater 209 updates the timeout of the selected subprocess pod 202 (e.g., subprocess pod 202B) based on the current and timeout for the parent process…”) … wherein the second monitoring service record comprises the second timeout period for the performance of the second service task by the third service ([0070] “Additionally, as shown in FIG. 3C, process execution status table 303 includes a column 310 regarding the process as well as a column 311 indicating whether such a process, including a subprocess, includes a timeout, and if so, the expiration time that pod 202 ceases to perform processing of its assigned tasks.”, [0193] “Furthermore, as discussed above, process planner 210 selects subprocess pod 202B to be restarted on the available node 201 (e.g., node 201C) to handle subprocess B21. As a result, jobs updater 209 updates the timeout of the selected subprocess pod 202 (e.g., subprocess pod 202B) based on the current and timeout for the parent process…”).
Regarding claim 5, Goldberg and Wei teach the method of claim 4, and Goldberg further teaches wherein the interceptor device intercepts at least one of the first service request message or the second service request message (Col. 21 lines 15-20: “For instance, as a request is detected or generated, the log reporting agent may immediately report the information to the log repository. In various embodiments, log data may specify, for each request identifier, the service that generated the request identifier and/or the service that received the request identifier.”, Note: The log reporting agent is interpreted as the interceptor device which intercepts generated requests at each service).
Regarding claim 6, Goldberg and Wei teach the method of claim 5, and Goldberg further teaches wherein at least one of the tracking, the determining of the respective processing states, or the intercepting of at least one of the first service request message or the second service request message are able to be performed agnostically and independently with respect to, and without interacting with, executable code and programming languages employed by the respective services (Col. 21 lines 15-20: “For instance, as a request is detected or generated, the log reporting agent may immediately report the information to the log repository. In various embodiments, log data may specify, for each request identifier, the service that generated the request identifier and/or the service that received the request identifier.”, Col. 13 lines 19-26: “As may sometimes be the case with service-oriented architectures employing modularity, each service may in some embodiments be independent of other services in the service-oriented system (e.g., the source code of services or their underlying components may be configured such that interdependencies among source and/or machine code are not present).”, Note: The log reporting agent is interpreted as the interceptor device which does not share code and is not interdependent on its service).
Regarding claim 7, Goldberg and Wei teach the method of claim 3, and Goldberg further teaches wherein the respective processing states comprise a processing state of the service task, wherein the tracking comprises tracking the processing state of the service task, wherein the respective devices comprise a second device associated with the second service (Col. 3 lines 15-16: “The services 110A-110N may be implemented using a plurality of hosts”, Col. 20 lines 61-67: “Referring collectively to FIG. 12 and FIG. 13, each service within the service-oriented system may include a log reporting agent, such as log reporting agent 2350. Log reporting agent 2350 may in various embodiments report the contents of inbound request log 2330 and/or outbound request log 2340 to a log repository (e.g., a data store, such as a database or other location in memory).”, Col. 21 lines 15-20: “For instance, as a request is detected or generated, the log reporting agent may immediately report the information to the log repository. In various embodiments, log data may specify, for each request identifier, the service that generated the request identifier and/or the service that received the request identifier.”, Col. 9 lines 26-33: “The elements of log data 332A-332N may include information regarding the processing or receipt of a service request or service response, including error messages, debug messages, internal checkpoints, processing results, timestamps, trace identifiers (e.g., request identifiers), request parameters or response parameters, and/or other suitable data and/or metadata.”), wherein the respective response messages comprise a response message received by the first device from the second device, and wherein the method further comprises: receiving, by the system, an update message from the first device or the interceptor device, wherein the update message indicates that the service task is successfully performed, wherein the update message is based on the response message indicating that the service task is successfully performed by the second service (Col. 20 lines 61-67: “Referring collectively to FIG. 12 and FIG. 13, each service within the service-oriented system may include a log reporting agent, such as log reporting agent 2350. Log reporting agent 2350 may in various embodiments report the contents of inbound request log 2330 and/or outbound request log 2340 to a log repository (e.g., a data store, such as a database or other location in memory).”, Col. 9 lines 26-33: “The elements of log data 332A-332N may include information regarding the processing or receipt of a service request or service response, including error messages, debug messages, internal checkpoints, processing results, timestamps, trace identifiers (e.g., request identifiers), request parameters or response parameters, and/or other suitable data and/or metadata.”, Note: The receipt of a service request or service response is interpreted as a response message which holds processing results when successful), and wherein the response message comprises the correlation identifier and a monitoring service record identifier associated with the monitoring service record; and based on the update message indicating that the service task is successfully performed, updating, by the system, the processing state in the monitoring service record to indicate that the service task is successfully performed (Col. 21 lines 15-20: “For instance, as a request is detected or generated, the log reporting agent may immediately report the information to the log repository. In various embodiments, log data may specify, for each request identifier, the service that generated the request identifier and/or the service that received the request identifier.”, Col. 9 lines 26-33: “The elements of log data 332A-332N may include information regarding the processing or receipt of a service request or service response, including error messages, debug messages, internal checkpoints, processing results, timestamps, trace identifiers (e.g., request identifiers), request parameters or response parameters, and/or other suitable data and/or metadata.”, Note: The receipt of a service request or service response is interpreted as a response message which holds processing results when successful).
Regarding claim 8, Goldberg and Wei teach the method of claim 3, and Goldberg further teaches wherein the respective processing states comprise a processing state of the service task, wherein the tracking comprises tracking the processing state of the service task, wherein the respective devices comprise a second device associated with the second service (Col. 3 lines 15-16: “The services 110A-110N may be implemented using a plurality of hosts”, Col. 20 lines 61-67: “Referring collectively to FIG. 12 and FIG. 13, each service within the service-oriented system may include a log reporting agent, such as log reporting agent 2350. Log reporting agent 2350 may in various embodiments report the contents of inbound request log 2330 and/or outbound request log 2340 to a log repository (e.g., a data store, such as a database or other location in memory).”, Col. 21 lines 15-20: “For instance, as a request is detected or generated, the log reporting agent may immediately report the information to the log repository. In various embodiments, log data may specify, for each request identifier, the service that generated the request identifier and/or the service that received the request identifier.”, Col. 9 lines 26-33: “The elements of log data 332A-332N may include information regarding the processing or receipt of a service request or service response, including error messages, debug messages, internal checkpoints, processing results, timestamps, trace identifiers (e.g., request identifiers), request parameters or response parameters, and/or other suitable data and/or metadata.”), wherein the respective response messages comprise a response message received by the first device from the second device, and wherein the method further comprises: receiving, by the system, an update message from the first device or the interceptor device, wherein the update message indicates that the service task has failed to be successfully performed, wherein the update message is based on the response message indicating that the service task has failed to be successfully performed (Col. 20 lines 61-67: “Referring collectively to FIG. 12 and FIG. 13, each service within the service-oriented system may include a log reporting agent, such as log reporting agent 2350. Log reporting agent 2350 may in various embodiments report the contents of inbound request log 2330 and/or outbound request log 2340 to a log repository (e.g., a data store, such as a database or other location in memory).”, Col. 9 lines 26-33: “The elements of log data 332A-332N may include information regarding the processing or receipt of a service request or service response, including error messages, debug messages, internal checkpoints, processing results, timestamps, trace identifiers (e.g., request identifiers), request parameters or response parameters, and/or other suitable data and/or metadata.”, Note: The receipt of a service request or service response is interpreted as a response message which holds error messages when it has failed), and wherein the response message comprises the correlation identifier and a monitoring service record identifier associated with the monitoring service record; and based on the update message indicating that the service task has failed to be successfully performed, updating, by the system, the processing state in the monitoring service record to indicate that the service task has failed to be successfully performed (Col. 21 lines 15-20: “For instance, as a request is detected or generated, the log reporting agent may immediately report the information to the log repository. In various embodiments, log data may specify, for each request identifier, the service that generated the request identifier and/or the service that received the request identifier.”, Col. 9 lines 26-33: “The elements of log data 332A-332N may include information regarding the processing or receipt of a service request or service response, including error messages, debug messages, internal checkpoints, processing results, timestamps, trace identifiers (e.g., request identifiers), request parameters or response parameters, and/or other suitable data and/or metadata.”, Note: The receipt of a service request or service response is interpreted as a response message which holds error messages when it has failed).
Regarding claim 10, Goldberg and Wei teach the method of claim 3, and Wei further teaches wherein the respective processing states comprise a processing state of the service request, wherein the tracking comprises tracking the processing state of the service request, and wherein the method further comprises: determining, by the system, that a timeout has occurred with regard to the service task, wherein the timeout indicates that the timeout period for the performance of the service task by the second service has elapsed without a response message indicating a successful performance of the service task or failure to successfully perform the service task ([0070] “Additionally, as shown in FIG. 3C, process execution status table 303 includes a column 310 regarding the process as well as a column 311 indicating whether such a process, including a subprocess, includes a timeout, and if so, the expiration time that pod 202 ceases to perform processing of its assigned tasks.”, [0104] “As shown in FIG. 8, process execution status table 303 includes a column 801 directed to the pod end time…”, Note: When the end time is equal to or greater than the timeout time, a timeout and eviction of the subprocess occurs); and based on the determining that the timeout has occurred, updating, by the system, the processing state in the monitoring service record to indicate that the timeout has occurred ([0104] “As shown in FIG. 8, process execution status table 303 includes a column 801 directed to the pod end time…”, Note: When the end time is equal to or greater than the timeout time, a timeout and eviction of the subprocess occurs, and the end time of the subprocess is updated).
Regarding claim 17, it is a machine claim whose limitations are substantially the same as those of claim 3. Accordingly, it is rejected for substantially the same reasons.
Regarding claim 18, it is a machine claim whose limitations are substantially the same as those of claims 7, 8, and 10. Accordingly, it is rejected for substantially the same reasons.
Claims 9 and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Goldberg et al. Pat. No. US 10,397,343 Bl (hereafter Goldberg) in view of Wei et al. Pub. No. US 2026/0079749 Al (hereafter Wei), and further in view of Parthasarathy et al. Pub. No. US 2020/0120000 Al (hereafter Parthasarathy).
Regarding claim 9, Goldberg and Wei teach the method of claim 8.
Goldberg and Wei fail to teach analyzing, by the system, historical data relating previous service requests for services, comprising previous service requests for the second service; and based on a result of the analyzing, determining, by the system, a mitigation action that is able to be performed to facilitate mitigating or reducing failures to successfully perform subsequent service requests for services, comprising subsequent service requests for the second service.
In analogous art Parthasarathy teaches analyzing, by the system, historical data relating previous service requests for services, comprising previous service requests for the second service ([0033] “There may be a reference data source 112 that provides training data 113, sometimes referred to herein as historical data, to the auto tuner engine 110. In one embodiment, the auto tuner engine 110 is configured to use algorithms that can learn from and/or make predictions based on a corpus of training data 113 that includes key performance indicators (KPI's) provided by the reference data source 112. The KPI's may include various communication parameters such as, but not limited to, delay between particular microservices at different load conditions, error rate, timeout settings, number of retries that led to success, etc…”); and based on a result of the analyzing, determining, by the system, a mitigation action that is able to be performed to facilitate mitigating or reducing failures to successfully perform subsequent service requests for services, comprising subsequent service requests for the second service ([0033] “…Optimization may be implemented by adjusting timeout and retry parameters for each identified microservice of an application, which provides a highest reward value for the application…”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Goldberg and Wei to incorporate the teachings of Parthasarathy to improve the performance of a microservice-based application (Parthasarathy [0035] “…Accordingly, by virtue of optimizing at least the timeout and retry parameters of each identified microservice, the performance of a microservice-based application is improved while controlling the error rate.”).
Regarding claim 11, Goldberg and Wei teach the method of claim 10.
Goldberg and Wei fail to teach analyzing, by the system, historical data relating previous service requests for services, comprising previous service requests for the second service; and based on a result of the analyzing, determining, by the system, a mitigation action that is able to be performed to facilitate mitigating or reducing timeouts relating to performance of subsequent service requests for services, comprising subsequent service requests for the second service.
In analogous art Parthasarathy teaches analyzing, by the system, historical data relating previous service requests for services, comprising previous service requests for the second service ([0033] “There may be a reference data source 112 that provides training data 113, sometimes referred to herein as historical data, to the auto tuner engine 110. In one embodiment, the auto tuner engine 110 is configured to use algorithms that can learn from and/or make predictions based on a corpus of training data 113 that includes key performance indicators (KPI's) provided by the reference data source 112. The KPI's may include various communication parameters such as, but not limited to, delay between particular microservices at different load conditions, error rate, timeout settings, number of retries that led to success, etc…”); and based on a result of the analyzing, determining, by the system, a mitigation action that is able to be performed to facilitate mitigating or reducing timeouts relating to performance of subsequent service requests for services, comprising subsequent service requests for the second service ([0033] “…Optimization may be implemented by adjusting timeout and retry parameters for each identified microservice of an application, which provides a highest reward value for the application…”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Goldberg and Wei to incorporate the teachings of Parthasarathy to improve the performance of a microservice-based application (Parthasarathy [0035] “…Accordingly, by virtue of optimizing at least the timeout and retry parameters of each identified microservice, the performance of a microservice-based application is improved while controlling the error rate.”).
Regarding claim 12, Goldberg, Wei, and Parthasarathy teach the method of claim 11, and Parthasarathy further teaches wherein the determining of the mitigation action comprises determining an adjustment to the timeout period to facilitate the mitigating or reducing of timeouts relating to the performance of the subsequent service requests for services, comprising the subsequent service requests for the second service ([0033] “…Optimization may be implemented by adjusting timeout and retry parameters for each identified microservice of an application, which provides a highest reward value for the application…”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. In particular, US 20260058893 A1 is cited because it discloses tracing sub-requests.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Examiner respectfully requests, in response to this Office action, support be
shown for language added to any original claims on amendment and any new claims.
That is, indicate support for newly added claim language by specifically pointing to
page(s) and line number(s) in the specification and/or drawing figure(s). This will assist
Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111 (c).
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUSTIN CHE-CHUN TONG whose telephone number is (703)756-1737. The examiner can normally be reached Monday-Thursday: 7:30 AM to 5:00 PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on (571)270-1014. 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.
/J.C.T./Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
