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 Final Office Action is in response to the application 18/906,399 filed on 11/18/2025.
Status of Claims:
Claims 19-20 are new in this Office Action.
Claims 1, 9, and 17 are amended in this Office Action.
Claims 1-20 are pending in this Office Action.
Response to Arguments
CLAIM REJECTIONS UNDER 35 U.S.C. § 101
Applicant’s arguments filed on 11/18/2025 (pages 9-13) regarding claim rejections under 35 U.S.C 101 and the amendments submitted have been fully considered. The rejections made under 35 U.S.C 101 in the previous office action are now withdrawn after considering the applicant’s remarks and amendments.
CLAIM REJECTIONS UNDER 35 U.S.C. § 102(a)(2)
Applicant’s arguments filed on 11/18/2025 (pages 13-14) regarding claim rejections under 35 U.S.C 102(a)(2) have been fully considered. However, after further examination, new grounds of rejection are presented necessitated by applicant’s amendments.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not 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 applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding 1, 9, and 17, there is no description in the specification that would allow the examiner to determine the scope of limitations “wherein the storage node records span information for execution stages of the execution process that are executed by the storage node, and does not record span information for execution stages of the execution process that are not executed by the storage node”.
Paragraph [0086] of the specification discloses “In this example, the driver does not locally record the locally generated Span information, but records the locally generated Span information in the proxy server. As such, in a stage of collection of the Span information, the Span information in the client device can be collected from the proxy server, to avoid invading an application in the client device to collect the Span information in the client device”. One of ordinary skills in the art would understand that at best, the paragraph discloses that a node would not locally record the locally generated span information within the node but rather record span information in other node. This is actually the opposite of what the amendment is claiming such that a node records span information for process executed by the node and not record information of other nodes.
The examiner struggles to find support or description for the limitation, therefore, the originally filed specification fails to show that the inventor had possession of the claimed “wherein the storage node records span information for execution stages of the execution process that are executed by the storage node, and does not record span information for execution stages of the execution process that are not executed by the storage node” and fails to provide an explanation that one of ordinary skill in the art can determine the scope of the invention as claimed.
Claims 2-8, 10-16, and 18-20 are rejected because they inherit the deficiencies of claims 1, 9, and 17, from which they depend, respectively, with respect to 35 U.S.C. 112(a).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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, 4-9, 12-17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal et al. (US Patent 11347625) "Agarwal" in view of Vasireddy et al. (US PGPUB 20200364093) “Vasireddy”.
Regarding claim 1, Agarwal teaches a computer-implemented method for performing full-link tracing on a transaction in a distributed database comprising: determining a current execution stage of a transaction to be traced, wherein the current execution stage comprises a current execution action in an execution process, wherein information transferred in the execution process comprises a trace ID of the transaction and span IDs, and wherein the span IDs correspond to spans of execution stages comprised in the execution process (Fig. 2A-2B & Col 6 line 25-45: “The term “span” as used herein generally refers to the primary building block of a trace, representing an individual unit of work done in a distributed system. A trace is composed of one or more spans where a span represents a call within the request. It is appreciated that a call may be to a separate microservice or a function within a microservice. The trace represents the work done by each microservice which is captured as a collection of linked spans sharing the same unique Trace ID. Each component of the distributed system may contribute a span—a named, timed operation representing a piece of the workflow. A span may also include a unique span ID, a service name (e.g., “analytics”), an operation name (e.g., “start”), duration (latency), start and end timestamps and additional annotations and attributes (e.g., tags such as key:value pairs). The annotations and attributes can describe and contextualize the work being done under a span. For example, each span may be annotated with one or more tags that provide context about the execution, such as the client instrumenting the software, a document involved in the request, an infrastructure element used in servicing a request, etc.”… Examiner’s note: Each span within a trace can represent an individual unit of work done in a distributed system thus it can be equivalent to an execution stage with execution action in an execution process. The linked spans that make up a trace also have Trace ID and span ID that describe the corresponding spans); locally recording span information corresponding to a span comprising the current execution stage (Col 6 line 35-45 : “A span may also include a unique span ID, a service name, an operation name (e.g., “start”), duration (latency), start and end timestamps and additional annotations and attributes (e.g., tags such as key:value pairs). The annotations and attributes can describe and contextualize the work being done under a span. For example, each span may be annotated with one or more tags that provide context about the execution, such as the client instrumenting the software, a document involved in the request, an infrastructure element used in servicing a request, etc.”), wherein the span has a semantic meaning determined based on a transaction execution logic in the distributed database, and each piece of span information determines a reference relationship between a corresponding span and another span in the same transaction comprising the corresponding span (Fig. 2A-2B & Col 9 line 4-22: “FIG. 2A illustrates an exemplary trace tree. The first span in the trace tree, Span A 202, is known as the root span. A trace tree typically comprises a root span, which is a span that does not have a parent. It may be followed by one or more child spans. Child spans may also be nested as deep as the call stack goes. Span B 206 and Span E 204 are child spans of the parent span, Span A. Further, Span C 208 and Span D 210 are child spans of the parent Span B 208…FIG. 2B illustrates an alternate view of the trace from FIG. 2A adjusted for timeline. The trace starts with the Span A 202, the root span, where the request starts. When the trace starts, a Trace ID is generated (e.g., Trace ID: 1 as shown in FIG. 2B), which follows the request as it propagates through the distributed system. A new span is generated for each logical chunk of work in the request, where the new span includes the same Trace ID, a new Span ID and a Parent Span ID, which points to the span ID of the new span's logical parent. The Parent Span ID creates a parent-child relationship between spans”…Examiner’s note: Each span can include information such as trace ID and its parent/child span within a trace thus each span has a semantic meaning and a reference relationship between a corresponding span and another span in the same transaction comprising the corresponding span); collecting span information in the execution stages comprised in the transaction after execution of the transaction is completed (Fig. 2B & Col 9 line 40-53: “Distributed tracing data is generated through the instrumentation of browsers, microservices-based applications, libraries and frameworks. Software may be instrumented to emit spans and traces… Each span may be annotated with one or more tags that provide context about the execution”…Col 10 line 35-51: “An agent is typically configured at the client-side host or service for receiving spans collected from the various tasks on the client-side and transmitting the spans to a collector. An agent may receive generated spans locally using, for example, User Datagram Protocol (UDP)… Batches of span data collected by the agent are periodically received at the collector”… Col 60-63: “The tasks may send span information collected from the various services at the client end to the instrumentation analysis system”); and determining a full-link execution process of the transaction based on the collected span information (Col 12 line 17-31: “In one implementation, an application owner may submit queries to gain further insight into the spans and traces. For example, the query engine and reporting system within the monitoring service may be configured to generate reports, render graphical user interfaces (GUIs) and/or other graphical visualizations to represent the trace and span information received from the various clients. The query engine and reporting system may, for example, interact with the instrumentation analysis system to generate a visualization, e.g., a histogram or an application topology graph to represent information regarding the traces and spans received from a client”... Col 50 line 16-32: “The spans displayed may be root-level or parent spans that can be expanded out to reveal other child spans. For example, the document load event associated with parent span may be a combination of other sub-events, e.g., a document fetch associated with the child span and other different resource accesses such as the one associated with child span. Although not shown in FIG. 20A, in one implementation, each of the spans shown in the waterfall view of the panel is displayed adjacent to an icon indicating whether one or more errors are associated with the span. Displaying an error status of a span enables a client to visually identify whether a particular span needs to be explored further. Note that each of the spans (including both the parent and children spans) may be expanded out to get further information regarding the various attributes associated with the spans”… Examiner’s note: The system displays trace and spans visualizations of a transaction for further insight wherein a root span can be expanded out to reveal other child spans. Thus, this visualization is equivalent to a full-link execution process of the transaction).
Agarwal does not explicitly teach locally recording, by a storage node of the distributed database, wherein the storage node records information for execution stages of the execution process that are executed by the storage node, and does not record information for execution stages of the execution process that are not executed by the storage node; collecting, from a plurality of storage nodes of the distributed database comprising the storage node.
Vasireddy teaches locally recording, by a storage node of the distributed database, wherein the storage node records information for execution stages of the execution process that are executed by the storage node, and does not record information for execution stages of the execution process that are not executed by the storage node ([0028]: As an example, the system 100 can include one or more computing nodes 104… [0029] In one or more examples of the disclosure, each computing node 104 can also include a data storage resource 106 that is configured to store data that is to be analyzed and or processed. Additionally the data storage resource 106 can also be configured to store the results of the analysis/processing (i.e., the output) in addition to also storing the data to be analyzed/processed (i.e., the input). In the example of FIG. 1, the computing nodes and data storage are implemented together, meaning that each node can store its own data… Examiner’s note: The system can comprise plurality of nodes wherein each node can contain a storage resource. Each node can store particular data that is to be analyzed and or processed and subsequently store the results of the analysis/processing. This can correspond to nodes storing data locally for data processed by the nodes thus data processed by other nodes are also stored by the nodes that processed the data.); collecting, from a plurality of storage nodes of the distributed database comprising the storage node ([0030] In one or more examples, the data storage resources 106 can also be configured to provide efficient access to the stored data, for instance by running database software that can index the data stored in it, thereby giving easy access to the computing hub or another computing resource to retrieve the specific data they are looking to access…Examiner’s note: Computing hub or other resources can collect data from the nodes that each store its own data in a local data storage). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Vasireddy teachings in the Agarwal system. Skilled artisan would have been motivated to incorporate processing and storing data locally by each processing node taught by Vasireddy in the Agarwal system to distribute the load to plurality of processing nodes, thus improves the processing speed, organization of the data and data retrieval process. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 4, Agarwal in view of Vasireddy teaches all of the limitations of claim 1. Agarwal further teaches sampling each transaction to be executed in the distributed database; and determining the sampled transaction as the transaction to be traced (Col 10 line 48-57: “Batches of span data collected by the agent are periodically received at the collector...Traces often generate duplicative data that is not relevant for monitoring or troubleshooting. The collector may avoid redundancies by sampling the data before processing and storing it”…Examiner’s note: The sampling data before processing and storing to avoid data that is not relevant for monitoring or troubleshooting in a trace is equivalent to sampling transaction and determining the sampled transaction as the transaction to be traced).
Regarding claim 5, Agarwal in view of Vasireddy teaches all of the limitations of claim 1. Agarwal further teaches wherein the determining a full-link execution process of the transaction based on the collected span information comprises: arranging, in a time dimension based on a reference relationship between spans determined by the collected span information, execution stages corresponding to the span information to display the full-link execution process of the transaction (Fig. 2B & Col 9 line 12-22: “FIG. 2B illustrates an alternate view of the trace from FIG. 2A adjusted for timeline. The trace starts with the Span A 202, the root span, where the request starts. When the trace starts, a Trace ID is generated (e.g., Trace ID: 1 as shown in FIG. 2B), which follows the request as it propagates through the distributed system. A new span is generated for each logical chunk of work in the request, where the new span includes the same Trace ID, a new Span ID and a Parent Span ID, which points to the span ID of the new span's logical parent. The Parent Span ID creates a parent-child relationship between spans”… Examiner’s note: Spans can include parent-child relationships and their corresponding jobs where the set of spans can also be arranged in a timeline).
Regarding claim 6, Agarwal in view of Vasireddy teaches all of the limitations of claim 1. Agarwal further teaches wherein the distributed database is communicatively connected to a proxy server, the proxy server is configured to forward a transaction request initiated by a driver deployed in a client device to the distributed database, and an execution process of each transaction respectively passes through the driver, the proxy server, and the distributed database (Fig. 3 & col 10 line 35-47: “An agent 303 is typically configured at the client-side host or service for receiving spans collected from the various tasks on the client-side and transmitting the spans to a collector 304… The tasks may include various front-end tasks such as those performed by a web browser running on a client's computer. While spans may be collected from the client-side tasks without configuring an agent, using an agent may provide benefits including batching, buffering and updating trace libraries”… Col 11 line 24-30: “The monitoring service 306 receives and analyzes the span data for monitoring and troubleshooting purposes. It should be noted that, in addition to monitoring service 306, span and tracing data might also be simultaneously transmitted to other types of storage and monitoring back-end services, e.g., a data ingestion and query system 326”... Examiner’s note: The system is structed similar to the application where a collector is connected to a storage such as a data ingestion and query system and tasks representing client applications. Thus, the collector component can be mapped to a proxy server, the data ingestion and query system can be mapped to a database, and the client applications can be mapped to driver deployed in a client device. The spans are received by the collector from the client application and the collector then sends the spans to the data ingestion and query system thus is equivalent to an execution passes through the driver, the proxy server, and the distributed database).
Regarding claim 7, Agarwal in view of Vasireddy teaches all of the limitations of claim 6. Agarwal further teaches generating, at the driver, a corresponding trace ID for the transaction to be executed (Col 9 line 23-27: “A given request typically comprises one span (e.g., the root Span A 202) for the overall request and a child span for each outbound call made to another service, database, or a function within the same microservice etc. as part of that request”… Col 10 line 16-22: “The tasks 301 and 302 may be instrumented using open source or common commercial tracing libraries, from tracing applications (e.g., Jaeger or Zipkin), in-house formats, or auto-instrumentation. Each task may be configured to generate spans that describe the processing of a portion of a request as the request traverses through the various tasks on the client-side”...col 16 line 8-12: “A request that the user initiates would generate an associated trace at the backend. It is appreciated that each user request will be assigned its own Trace ID, which will then propagate to the various spans that are generated during the servicing of that request”…Examiner’s note: The client side can generate spans that describe request and a request can comprise one span. Thus, the client side is able to generate information relating to a trace ID); and sending, at the driver, locally generated span information comprising the trace ID to the proxy server, so that the proxy server records the span information in the proxy server (Fig. 3 & Col 10 line 35-51: “An agent is typically configured at the client-side host or service for receiving spans collected from the various tasks on the client-side and transmitting the spans to a collector. An agent may receive generated spans locally using, for example, User Datagram Protocol (UDP)…Batches of span data collected by the agent are periodically received at the collector . The collector may be implemented within a client's on-prem software or in the cloud computing environment”…Examiner’s note: The client side sends spans collected from the various tasks to the collector thus is equivalent to a driver sending span information to a proxy server).
Regarding claim 8, Agarwal in view of Vasireddy teaches all of the limitations of claim 7. Agarwal further teaches sending, at the driver, locally generated span information comprising the trace ID to the proxy server comprises: sending, at the driver, the locally generated span information comprising the trace ID to the proxy server in a piggyback way (Col 19 line 48-51: “Batches of span data collected by the agent are periodically received at the collector. The collector may be implemented within a client's on-prem software or in the cloud computing environment”… Examiner’s note: The span data can be sent from an agent on a client side to a collector in batches. This is equivalent to sending data in a piggy back way because the agent can determine other information such as other span data and add particular span data to form a batch and send it to the collector).
Regarding claims 9, note the rejections of claim 1. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claims 12, note the rejections of claim 4. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claims 13, note the rejections of claim 5. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claims 14, note the rejections of claim 6. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claims 15, note the rejections of claim 7. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claims 16, note the rejections of claim 8. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claims 17, note the rejections of claim 1. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claims 19, note the rejections of claim 4. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claims 20, note the rejections of claim 5. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Claims 2-3, 10-11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal et al. (US Patent 11347625) "Agarwal" in view of Vasireddy et al. (US PGPUB 20200364093) “Vasireddy” and Dalgaard et al. (US Patent 12321250) “Dalgaard”.
Regarding claim 2, Agarwal in view of Vasireddy teaches all of the limitations of claim 1. Agarwal further teaches wherein execution granularities are divided based on the transaction execution logic, and the span comprising each execution stage corresponds to one execution granularity (Fig. 2A-B & col 9 line 23-39: “A given request typically comprises one span (e.g., the root Span A 202) for the overall request and a child span for each outbound call made to another service, database, or a function within the same microservice etc. as part of that request. For example, in the example of FIG. 2B, the Span A 202 is the root span for the overall request and generates several child spans to service the request. The Span A 202 makes a call to the Span B 206, which in turn makes a call to the Span C 208, which is a child span of the Span B 206. The Span B 206 also makes a call to the Span D 210, which is also a child span of the Span B 206. The Span A 202 subsequently calls the Span E 204, which is a child span of the Span A 202. Note, that the spans in a given trace comprise the same Trace ID. The Trace ID along with the Parent Span ID may be used to consolidate the spans together into a trace”.…Examiner’s note: An overall request can be represented by a span wherein the particular span can generate child spans and the child spans can each have their own child spans. The different levels of spans, for example shown in fig. 2A-2B, can be equivalent to execution granularities and each span can associate with one execution granularity).
Agarwal does not explicitly teach locally recording the span information corresponding to the span comprising the current execution stage when an execution granularity corresponding to the current execution stage is greater than an execution granularity threshold.
Dalgaard teaches locally recording the span information corresponding to the span comprising the current execution stage when an execution granularity corresponding to the current execution stage is greater than an execution granularity threshold (Col 3 line 1-7: “Many different users may want different types of telemetry data from an application and may want their type of telemetry data processed differently (e.g., at a higher or lower level of granularity)”…Col 12 line 39-60: A request may be initiated by a user or an application. Distributed tracing is a form of tracing that traverses process, network and security boundaries. Each unit of work in a trace is called a span; a trace is a tree of spans. Spans are objects that represent the work being done by individual services or components involved in a request as it flows through a system. The root span would measure the time it took from an end-user clicking that button to the operation being completed or failing and the result being displayed to the user. A trace may be made up of the single root span and any number of child spans, which represent operations taking place as part of the request. Each span contains metadata about the operation, such as its name, start and end timestamps, attributes, events, and status”…Col 15 line 61-67 & col 16 line 1-2: “Pipelines can be added, removed, and/or modified over time to change the observability processing without requiring additional modifications on the part of the application code developer. In some examples, the pipelines can also be added, removed, and/or modified based on particular events occurring, or on a scheduled basis, to allow different types or granularities or amounts of the telemetry data being processed to be changed according to changing conditions”… Examiner’s note: Thus, data can be stored in different granularities within trace/spans relationship and user can control the granularity, e.g. at a higher or lower level of granularity, of the data to be processed. Thus, data processed at a higher granularity can be equivalent to recording the span when an execution granularity is greater than an execution granularity threshold). It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the Dalgaard teachings in the Agarwal and Vasireddy system. Skilled artisan would have been motivated to incorporate processing data at desired granularities such as lower or higher granularities taught by Dalgaard in the Agarwal and Vasireddy system to increase the efficiency in data analysis, and deliver the appropriate level of detail as a user or application would desire. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 3, Agarwal in view of Vasireddy and Dalgaard teaches all of the limitations of claim 2. Agarwal further teaches wherein the transaction comprises at least one structured query language (SQL), an execution plan of each SQL comprises at least one data flow object (DFO), and each DFO comprises at least one operation, and wherein execution granularities obtained through division comprise an SQL granularity, a DFO granularity, and an operator granularity (Fig. 2A-2B & Col 6 line 20-24: “A trace may be conceptualized as a highly dimensional structured log that captures the full graph of user-generated and background request execution within an application”…col 8 line 23-27: “A trace represents a single user request, also referred to as a transaction, and represents the entire lifecycle of a request as it traverses across the various services or components of a distributed system”…col 9 line 4-11: “FIG. 2A illustrates an exemplary trace tree. The first span in the trace tree, Span A 202, is known as the root span. A trace tree typically comprises a root span, which is a span that does not have a parent. It may be followed by one or more child spans. Child spans may also be nested as deep as the call stack goes. Span B 206 and Span E 204 are child spans of the parent span, Span A. Further, Span C 208 and Span D 210 are child spans of the parent Span B 208”… col 20 line 47-55: “A client application associated with, for example, an online retailer's website may potentially generate millions of spans from which a monitoring platform may need to extract meaningful and structured information. To organize the significant amounts of incoming span data, in an implementation, incoming spans may be automatically grouped by mapping each span to a base “span identity,” wherein a base span identity comprises some key attributes that summarize a type of span”…Examiner’s note: A trace tree can have equivalent structure for example Span A can be mapped to an SQL granularity, Spans B and E can be mapped to DFO granularity, and Spans C and D can be mapped to operator granularity).
Regarding claims 10, note the rejections of claim 2. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claims 11, note the rejections of claim 3. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Regarding claims 18, note the rejections of claim 2. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under the same prior-art teachings.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CAO DANG VUONG whose telephone number is (571)272-1812. The examiner can normally be reached on M-F 7:30-5 EST.
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, Kavita Stanley can be reached at (571) 272-8352. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.D.V./Examiner, Art Unit 2153 02/13/2026
/KAVITA STANLEY/Supervisory Patent Examiner, Art Unit 2153