DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This action is in response to the communication filed on 06/11/2026. Claims 1-4 and 6-18 are pending in this application.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 06/11/2026 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the IDS(s) is/are being considered by the examiner.
Response to Amendment
The claim rejections under 35 U.S.C. 112(b) to claims 1-7 and 9-20 are now withdrawn in view of the claim amendments. The claim rejection under 35 U.S.C. 112(b) to claim 8 remains due to lack of amendment.
The claim rejections under 35 U.S.C. 112(a) to claims 13 and 20 are now withdrawn in view of the claim amendments.
Applicant’s arguments with respect to claims 1-4 and 6-18 have been considered but are moot based on the new grounds of rejection necessitated by Applicant’s amendments. Specifically, the arguments present that Chayat or Osiecki or other cited references fails to provide for the amended language, where the rejection below now relies on Bae to teach this subject matter.
Claim Objections
Claims 1 and 11 are objected to because of the following informalities:
Claims 1 and 11 recite the limitation “on or more metric datasets” in line 12 and line 17 respectively. For examination purpose and based on the context of the claim, “on or more metric datasets” will read as “one or more metric datasets.”
Claim 11 removes the limitation “wherein the short-term metric comprises a metric collected upon occurrence of a condition” without marking the change status.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-4 and 6-18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claims 1 and 11 recite the limitation “the structured format” in line 14 and line 17 respectively. There is insufficient antecedent basis for this limitation in the claims. For examination purpose, “the structured format” will read as “a structured format.”
Claim 6 recites the limitation “the producer” in line 1. There is insufficient antecedent basis for this limitation in the claim. For examination purpose, “the producer” will read as “a producer.”
Claim 8 recites the limitation “the producer” in line 1. There is insufficient antecedent basis for this limitation in the claim. For examination purpose, “the producer” will read as “a producer.”
The dependent claims of the above rejected claims are rejected due to their dependencies.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-4, 7 and 11-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20180288503 A1 (hereinafter Chayat), in view of US 20170111242 A1 (Osiecki), and in further view of US 20100321204 A1 (hereinafter Bae).
For Claim 1, Chayat teaches a method of processing telemetry data in a cluster network having a plurality of nodes (Chayat, FIG. 1, FIG. 2; ¶ 0014 “… the example network 100 may represent a grouping of related or interconnected devices, such as a datacenter, a computing cluster, a Local Area Network (LAN), a Wide Area Network (WAN) …”; ¶ 0019 “… the system 200 may correspond generally to some or all of the telemetry logic 120 shown in FIG. 1 …”), comprising:
storing the telemetry data as generated by telemetry producers (Chayat exemplifies Network Devices 110 including telemetry logic in FIG. 1) in the network in a datastore (Chayat exemplifies Destination Node 160 in FIG. 1) as metric datasets … (Chayat, FIGS 1-3; ¶ 0017 “… the network device 110 may include telemetry logic 120 to generate telemetry data associated with the network device 110 … The telemetry logic 120 may generate a telemetry container including multiple types of telemetry data, and may send the telemetry container to a destination entity specified in a profile …”; ¶ 0030 “… the destination field 330 may specify a network address, a memory address, a register, a process identifier, an application, a Virtual Machine (VM), a Virtual Network Function (VNF), a destination device, a hardware component, and so forth …”);
… a short-term metric as a trace metric capturing instantaneous events (Chayat teaches instantaneous point-in-time telemetry capture; ¶ 0029 “… Note that, because multiple telemetry registers may be read in response to a trigger being satisfied, the collected telemetry data values may be synchronized to a point in time. Accordingly, some embodiments may provide a telemetry ‘snapshot’ corresponding to a given point in time …”)…;
registering the short-term metric (Chayat exemplifies telemetry profiles in FIG. 2 and FIG. 3) with … condition for triggering collection of the metric (Chayat teaches storing the telemetry profiles specifying the collection trigger conditions; FIGS 1-3; ¶ 0017 “… the telemetry logic 120 may use profiles specifying triggers, source registers, and destinations for telemetry data …”; ¶ 0019 “… the storage 205 may include a set of telemetry profiles 220 and a set of message profiles 230 …”; ¶ 0020 “… the telemetry registers 240 may be any memory locations to store multiple types of telemetry data associated with a source device (e.g., network device 110 or component 140 shown in FIG. 1) …”; ¶ 0027 “… The collection trigger field 310 may specify one or more conditions to trigger the collection of telemetry data …”); …;
the telemetry data associated with user identifiers and data transport parameters … parameters associated with a specific transport mechanism (Chayat teaches the telemetry data requester identification and transport/message parameters; FIG. 2; FIG. 4; FIG. 5; ¶ 0021 “… the virtualized telemetry controller 210 may utilize the message profiles 230 to determine how to package the telemetry data for transmission to the appropriate destination …”; ¶ 0025 “… the telemetry profiles 220 and/or the message profiles 230 may be customizable. For example, the virtualized telemetry controller 210 may provide an interface to allow a user to specify parameters or fields in a telemetry profile 220 (e.g., triggers, source registers, destinations, etc.) or a message profile 230 (e.g., network headers, message format, etc.) …”; ¶ 0033 “… the message profile 2301 may specify the appropriate encapsulation for the telemetry container 440 to generate a telemetry message 470 that is compatible with the IP network. Such encapsulation may include headers such as MAC, IP, UDP, etc. …”; ¶ 0035 “… the telemetry container 500 may include a header section 510 and a telemetry data section 520. The header section 510 may include information describing the telemetry container 500, including requester identification, destination address, length, etc. …”); …;
initiating, upon detection of the condition, collection of the short-term metric (Chayat teaches performing monitoring when detecting satisfaction of the conditions; FIG. 2, FIG. 3; ¶ 0028 “… the virtualized telemetry controller 210 (shown in FIG. 2) may perform monitoring according to the collection trigger field 310 of each telemetry profile 300, and may detect satisfaction of the condition(s) specified in collection trigger field 310. For example, the virtualized telemetry controller 210 may determine that a time period specified in the collection trigger field 310 has expired. In another example, the virtualized telemetry controller 210 may determine that a command or exception specified in the collection trigger field 310 has occurred …”; also see steps 620, 640 corresponding to FIG. 6);
transmitting the respective data … through a selected transport mechanism and … (Chayat teaches transport-specific message formatting and destination transmission; 0033 “… Accordingly, the message profile 2301 may specify the appropriate encapsulation for the telemetry container 440 to generate a telemetry message 470 that is compatible with the IP network. Such encapsulation may include headers such as MAC, IP, UDP, etc. …”); …
Chayat does not explicitly teach, but Osiecki teaches storing the telemetry data in a datastore having a defined schema (Osiecki teaches storing data models representing the metrics; FIG. 1; ¶ 0022 “… Further, a data store 149 is stored in a memory that is accessible to the server 103. Stored within the data store 149 are data models 151 that represent the metrics 109 …”; ¶ 0025 “… The aggregation application 126 processes the metrics 109 in the aggregation queue 143 and applies the results to the storage queue 146 to be stored in the data store 149 by the data store application 129 …”);
defining a short-term metric as a … metric … to be collected for a duration on the order of minutes (Osiecki teaches that collected metrics are associated with a minute-scale time period; FIG. 1; ¶ 0022 “… Each of the data models 151 is stored in association with time periods 156 …”; ¶ 0027 “… the metrics 109 associated with each respective consecutive time period 156 are represented by a data model 151 …”; ¶ 0028 “… For example, assume each of the consecutive time periods 156 is specified as a single minute, although it is understood that the time periods 156 can be specified as any time interval …”);
registering the short-term metric with a metric schema, defined duration (Osiecki teaches storing the data models in active metric list(s) and the data models associating with time periods; FIG. 1; ¶ 0022 “… Each of the data models 151 is stored in association with time periods 156 …”; ¶ 0042 “… the applications executable on the server further include a metric directory application 163 that maintains one or more active metric lists 169 in a data store 166. The metric directory application 163 serves to maintain a list of active metrics 109 for which data models 151 may be retrieved. To this end, each time a data model 151 generated from one or more instances of a metric 109 is to be stored in the data store 149, a copy of the same is supplied to the metric directory application 163 … Each active metric list 169 may be stored in the form of a table, database, or other data structure …”), and …; …;
… a database having tables … (Osiecki teaches table/database organization; FIG. 1; ¶ 0042 “… Each active metric list 169 may be stored in the form of a table, database, or other data structure …”); …; …; …;
stopping collection of the metric at the end of the defined duration (Osiecki teaches a time period associating with the generated data model, therefore there is a point of time which ends calculating the collected metrics into the data model; FIG. 1; ¶ 0022 “… Each of the data models 151 is stored in association with time periods 156 …”); and
unregistering any short-term metric that is no longer needed or requires updating to clean up the telemetry catalog (Osiecki teaches the metric directory application removing the out of date metrics from the active metric list(s); FIG. 1, ¶ 0048 “… when the timestamp associated with a given metric 109 in an active metric list 169 indicates that the most recent data associated with a metric 109 has been stored in the data store 149 longer than the predefined storage time period mentioned above, the metric directory application 163 proceeds to remove such metric 109 from the active metric list 169 …”).
Osiecki and Chayat are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the generating data models from the collected metrics techniques of Osiecki with the system of Chayat to reduce the storage demand for the metrics data and facilitate metrics searching ability (Osiecki ¶ 0014).
Chayat-Osiecki does not explicitly teach, but Bae teaches defining one or more consumers of respective data of the telemetry data in the network, wherein the one or more consumers subscribe to receive the respective data through a subscription process specifying dynamic subscription states and values for the one or more consumers to allow individual consumers to select one or more metric datasets to receive at a desired frequency of receipt (Bae teaches consumer/application subscriptions to selected data items, dynamic add/delete subscription state, and consumer specific desired sampling frequency; FIG. 1; ¶ 0006 “… The system combines subscriptions of multiple applications to same data items from same entities so that load on entities for sensor reading and the wireless network is reduced …”; ¶ 0017 “… When a subscription for a client's telemetry data is received, the telemetry subscription service (TSS) 110 first analyzes the subscription with respect to other subscriptions for the same client application, with the goal of adjusting the subscriptions relative to each other in order to create an optimized set …”; ¶ 0023 “… Each subscription includes two specifications for the desired interval between telemetry samples: 1) a minimum interval and 2) a maximum interval …”; ¶ 0025 “… The interval range matching function or process is specified by a procedure addSubscription (invoked when an application subscribes to telemetry), and deleteSubscription (invoked when an application stops a subscription) …”);
formatting the subscription states and values in a structured format for storage in a database …, wherein the tables store user identifiers and data transport parameters, and the sub-tables store parameters associated with a specific transport mechanism (Bae teaches subscription records/database and user/session state; Examiner notes that none of the cited references expressly uses the term “sub-tables,” however, under KSR, storing shared user/subscription fields in a parent table and transport-specific fields in related subordinate tables is a routine, predictable database organization of these already-known record types, particularly where Chayat supports different message/transport configurations; FIG. 1; ¶ 0020 “… Group subscription requests are handled by first listing the users in the specified group and entering a single-user subscription for each user. One additional step involves creating a separate subscription record for the group subscription …”; ¶ 0050 “… FIG. 2 depicts condition expression processing. When ‘requestTelemetry’ received at server, the invention parses infix expression, validate it, and converts it to postfix form, store postfix form in subscriptions database, transmit postfix form to client …”; ¶ 0062 “… The Load balancer allows load balancing for HTTP requests from the client to the cluster member among several TOPAZ cluster nodes. Session cookies are used to provide node affinity for HTTP requests from the same client node. However, since the load of these sessions can vary over time, depending on the subscriptions on a client, it is valuable to be able to move a session from one TOPAZ node to another. This is done through the database: information about the current state of a session is placed in a record when a session is moved …”);
checking, upon initiation of a request for telemetry data for a telemetry job, the database to verify collection of the respective data through the specific transport mechanism (Bae teaches request-initiation checking against recorded capability/state retrieved from the database; Chayat also teaches transport/message-profile selection (¶ 0021 as indicated above); ¶ 0051 “… Validity is checked when subscription request is received. The checking enables immediate error message to application, and avoids handling these errors at condition evaluation time. What each device/client is capable of is recorded. …”; ¶ 0052 “… Client capability is checked when subscription is received and processed, so the decision can be made then …”; ¶ 0060 “… TOPAZ processing involves receiving an aggregate request, retrieving any required information from the database …”); …;
transmitting the respective data to subscribed consumers through a selected transport mechanism and at the respective selected frequency (Bae teaches subscribed consumers, selected timing, and an identified transport; as discussed above, Chayat teaches transport-specific message formatting and destination transmission; ¶ 0023 “… Each subscription includes two specifications for the desired interval between telemetry samples: 1) a minimum interval and 2) a maximum interval …”; 0057 “… clients communicate with TOPAZ using HTTP over TCP …”; ¶ 0065 “… Once inside the Telemetry Receiver, the data must be routed to one or more applications that have requested the data …”).
Bae and Chayat-Osiecki are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the subscription management techniques of Bae with the system of Chayat-Osiecki to facilitate the scalable and efficient telemetry data acquisition for consumers (Bae ¶ 0004).
For Claim 2, Chayat-Osiecki-Bae teaches the method of claim 1 further comprising mapping a function of the short-term metric to the condition (Chayat, FIG. 3; 0027 “… The collection trigger field 310 may specify one or more conditions to trigger the collection of telemetry data. For example, the collection trigger field 310 may specify a periodic timer, a control signal, an interrupt, a device status, a processing exception, a register flag, a system state, a trigger packet, and so forth …”).
For Claim 3, Chayat-Osiecki-Bae teaches the method of claim 1 wherein the telemetry data comprises data generated periodically by each producer upon operation in the cluster network, and consists of performance data, topology information, alerts, security states, and service features (Chayat, FIG. 1; ¶ 0014 “… the example network 100 may represent a grouping of related or interconnected devices, such as a datacenter, a computing cluster, a Local Area Network (LAN), a Wide Area Network (WAN) …”; ¶ 0017 “… the network device 110 may include telemetry logic 120 to generate telemetry data associated with the network device 110. Examples of such telemetry data may include link statistics, system statistics, access control list statistics, system status, temperature level, power consumption data, and so forth …”).
For Claim 4, Chayat-Osiecki-Bae teaches the method of claim 3 wherein the telemetry data comprises log data (Osiecki, FIG. 1; ¶ 0018 “… In addition, the data communication network 100 includes a monitored system 106 that generates logs and/or metrics 109 that may be transmitted to the servers 103 as a data stream …”), and the short-term metric comprises trace data of the cluster network (Chayat teaches instantaneous point-in-time telemetry capture based on the definition of “trace data” in claim 1; ¶ 0029 “… Note that, because multiple telemetry registers may be read in response to a trigger being satisfied, the collected telemetry data values may be synchronized to a point in time. Accordingly, some embodiments may provide a telemetry ‘snapshot’ corresponding to a given point in time …”).
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the generating data models from the collected metrics techniques of Osiecki with the system of Chayat to reduce the storage demand for the metrics data and facilitate metrics searching ability (Osiecki ¶ 0014).
For Claim 7, Chayat-Osiecki-Bae teaches the method of claim 1 further comprising storing the short-term metric schema, duration, and condition in a telemetry catalog (Chayat teaches storing the telemetry profiles specifying the collection trigger conditions, Osiecki teaches storing the data models in active metric list(s) and the data models associating with time periods) accessible by a telemetry transmitter (Chayat exemplifies the telemetry logic in FIG. 1), and wherein the short-term metric is collected for transmission by the telemetry transmitter to the … consumers of the telemetry data, the … consumers comprising at least one of: pod components of the nodes, storage users (Chayat teaches a memory address ¶ 0030), graphical user interfaces (GUI), and storage vendors (Chayat, FIGS 1-3; ¶ 0017 “… the network device 110 may include telemetry logic 120 to generate telemetry data associated with the network device 110 … The telemetry logic 120 may generate a telemetry container including multiple types of telemetry data, and may send the telemetry container to a destination entity specified in a profile …”; ¶ 0030 “… the destination field 330 may specify a network address, a memory address, a register, a process identifier, an application, a Virtual Machine (VM), a Virtual Network Function (VNF), a destination device, a hardware component, and so forth …”).
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the generating data models from the collected metrics techniques of Osiecki with the system of Chayat to reduce the storage demand for the metrics data and facilitate metrics searching ability (Osiecki ¶ 0014).
Chayat-Osiecki-Bae further teaches the subscribed consumers (Bae teaches consumer/application subscriptions to selected data items; FIG. 1; ¶ 0017 “… When a subscription for a client's telemetry data is received, the telemetry subscription service (TSS) 110 first analyzes the subscription with respect to other subscriptions for the same client application, with the goal of adjusting the subscriptions relative to each other in order to create an optimized set …”).
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the subscription management techniques of Bae with the system of Chayat-Osiecki to facilitate the scalable and efficient telemetry data acquisition for consumers (Bae ¶ 0004).
For Claim 11, Chayat teaches a method of processing telemetry data in a cluster network having a plurality of telemetry producers (Chayat exemplifies Network Devices 110 including telemetry logic in FIG. 1) each periodically generating metric datasets (Chayat, FIG. 1, FIG. 2; ¶ 0014 “… the example network 100 may represent a grouping of related or interconnected devices, such as a datacenter, a computing cluster, a Local Area Network (LAN), a Wide Area Network (WAN) …”; ¶ 0019 “… the system 200 may correspond generally to some or all of the telemetry logic 120 shown in FIG. 1 …”), comprising: …; …;
defining a short-term metric as a trace metric capturing instantaneous events (Chayat) to be collected … (Chayat teaches exemplified telemetry profiles in FIG. 2 and FIG. 3, and instantaneous point-in-time telemetry capture; FIGS 1-3; ¶ 0017 “… the telemetry logic 120 may use profiles specifying triggers, source registers, and destinations for telemetry data …”; ¶ 0019 “… the storage 205 may include a set of telemetry profiles 220 and a set of message profiles 230 …”; ¶ 0029 “… Note that, because multiple telemetry registers may be read in response to a trigger being satisfied, the collected telemetry data values may be synchronized to a point in time. Accordingly, some embodiments may provide a telemetry ‘snapshot’ corresponding to a given point in time …”); …;
storing the … condition for the short-term metric … (Chayat teaches storing the telemetry profiles specifying the collection trigger conditions; FIGS 1-3; ¶ 0017 “… the telemetry logic 120 may use profiles specifying triggers, source registers, and destinations for telemetry data …”; ¶ 0019 “… the storage 205 may include a set of telemetry profiles 220 and a set of message profiles 230 …”; ¶ 0020 “… the telemetry registers 240 may be any memory locations to store multiple types of telemetry data associated with a source device (e.g., network device 110 or component 140 shown in FIG. 1) …”; ¶ 0027 “… The collection trigger field 310 may specify one or more conditions to trigger the collection of telemetry data …”);
collecting, by the telemetry transmitter (Chayat exemplifies the telemetry logic in FIG. 1 and corresponding virtualized telemetry controller 210 in FIG. 2) …, the short-term metric dataset, upon detecting the occurrence of the condition (Chayat teaches performing monitoring when detecting satisfaction of the conditions; FIG. 2, FIG. 3; ¶ 0019 “… the system 200 may correspond generally to some or all of the telemetry logic 120 shown in FIG. 1 …”; ¶ 0028 “… the virtualized telemetry controller 210 (shown in FIG. 2) may perform monitoring according to the collection trigger field 310 of each telemetry profile 300, and may detect satisfaction of the condition(s) specified in collection trigger field 310. For example, the virtualized telemetry controller 210 may determine that a time period specified in the collection trigger field 310 has expired. In another example, the virtualized telemetry controller 210 may determine that a command or exception specified in the collection trigger field 310 has occurred …”; also see steps 620, 640 corresponding to FIG. 6); …;
the telemetry data associated with user identifiers and data transport parameters … parameters associated with a specific transport mechanism (Chayat teaches the telemetry data requester identification and transport/message parameters; FIG. 2; FIG. 4; FIG. 5; ¶ 0021 “… the virtualized telemetry controller 210 may utilize the message profiles 230 to determine how to package the telemetry data for transmission to the appropriate destination …”; ¶ 0025 “… the telemetry profiles 220 and/or the message profiles 230 may be customizable. For example, the virtualized telemetry controller 210 may provide an interface to allow a user to specify parameters or fields in a telemetry profile 220 (e.g., triggers, source registers, destinations, etc.) or a message profile 230 (e.g., network headers, message format, etc.) …”; ¶ 0033 “… the message profile 2301 may specify the appropriate encapsulation for the telemetry container 440 to generate a telemetry message 470 that is compatible with the IP network. Such encapsulation may include headers such as MAC, IP, UDP, etc. …”; ¶ 0035 “… the telemetry container 500 may include a header section 510 and a telemetry data section 520. The header section 510 may include information describing the telemetry container 500, including requester identification, destination address, length, etc. …”); …;
transmitting the short-term metric … through a selected transport mechanism (Chayat teaches transport-specific message formatting and destination transmission; 0033 “… Accordingly, the message profile 2301 may specify the appropriate encapsulation for the telemetry container 440 to generate a telemetry message 470 that is compatible with the IP network. Such encapsulation may include headers such as MAC, IP, UDP, etc. …”).
Chayat does not explicitly teach, but Osiecki teaches first receiving schema definitions of metric datasets of the telemetry data produced by the telemetry producers; storing the schema definitions in a telemetry catalog accessed by a telemetry transmitter (Osiecki teaches storing the data models in active metric list(s); FIG. 1; ¶ 0022 “… Each of the data models 151 is stored in association with time periods 156 …”; ¶ 0042 “… the applications executable on the server further include a metric directory application 163 that maintains one or more active metric lists 169 in a data store 166. The metric directory application 163 serves to maintain a list of active metrics 109 for which data models 151 may be retrieved. To this end, each time a data model 151 generated from one or more instances of a metric 109 is to be stored in the data store 149, a copy of the same is supplied to the metric directory application 163 … Each active metric list 169 may be stored in the form of a table, database, or other data structure …”);
defining a short-term metric as a … metric … to be collected for a duration on the order of minutes (Osiecki teaches that collected metrics are associated with a minute-scale time period; FIG. 1; ¶ 0022 “… Each of the data models 151 is stored in association with time periods 156 …”; ¶ 0027 “… the metrics 109 associated with each respective consecutive time period 156 are represented by a data model 151 …”; ¶ 0028 “… For example, assume each of the consecutive time periods 156 is specified as a single minute, although it is understood that the time periods 156 can be specified as any time interval …”);
second receiving a schema definition for a short-term metric dataset produced by a producer; storing the schema definition, duration, and … for the short-term metric in the telemetry catalog (Osiecki teaches storing the data models in active metric list(s) and the data models associating with time periods; FIG. 1; ¶ 0022 “… Each of the data models 151 is stored in association with time periods 156 …”; ¶ 0042 “… the applications executable on the server further include a metric directory application 163 that maintains one or more active metric lists 169 in a data store 166. The metric directory application 163 serves to maintain a list of active metrics 109 for which data models 151 may be retrieved. To this end, each time a data model 151 generated from one or more instances of a metric 109 is to be stored in the data store 149, a copy of the same is supplied to the metric directory application 163 … Each active metric list 169 may be stored in the form of a table, database, or other data structure …”); and
collecting, … and for the duration, the short-term metric (Osiecki, FIG. 1; 0025 “… The aggregation application 126 processes the metrics 109 in the aggregation queue 143 and applies the results to the storage queue 146 to be stored in the data store 149 by the data store application 129. According to various embodiments, the aggregation application 126 serves to aggregate multiple metrics 109 for respective time periods 156 …”); …;
… a database having tables … (Osiecki teaches table/database organization; FIG. 1; ¶ 0042 “… Each active metric list 169 may be stored in the form of a table, database, or other data structure …”).
Osiecki and Chayat are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the generating data models from the collected metrics techniques of Osiecki with the system of Chayat to reduce the storage demand for the metrics data and facilitate metrics searching ability (Osiecki ¶ 0014).
Chayat-Osiecki does not explicitly teach, but Bae teaches defining one or more consumers of respective data of the telemetry data in the network, wherein the one or more consumers subscribe to receive the respective data through a subscription process specifying dynamic subscription states and values for the one or more consumers to allow individual consumers to select one or more metric datasets to receive at a desired frequency of receipt (Bae teaches consumer/application subscriptions to selected data items, dynamic add/delete subscription state, and consumer specific desired sampling frequency; FIG. 1; ¶ 0006 “… The system combines subscriptions of multiple applications to same data items from same entities so that load on entities for sensor reading and the wireless network is reduced …”; ¶ 0017 “… When a subscription for a client's telemetry data is received, the telemetry subscription service (TSS) 110 first analyzes the subscription with respect to other subscriptions for the same client application, with the goal of adjusting the subscriptions relative to each other in order to create an optimized set …”; ¶ 0023 “… Each subscription includes two specifications for the desired interval between telemetry samples: 1) a minimum interval and 2) a maximum interval …”; ¶ 0025 “… The interval range matching function or process is specified by a procedure addSubscription (invoked when an application subscribes to telemetry), and deleteSubscription (invoked when an application stops a subscription) …”);
formatting the subscription states and values in a structured format for storage in a database …, wherein the tables store user identifiers and data transport parameters, and the sub-tables store parameters associated with a specific transport mechanism (Bae teaches subscription records/database and user/session state; Examiner notes that none of the cited references expressly uses the term “sub-tables,” however, under KSR, storing shared user/subscription fields in a parent table and transport-specific fields in related subordinate tables is a routine, predictable database organization of these already-known record types, particularly where Chayat supports different message/transport configurations; FIG. 1; ¶ 0020 “… Group subscription requests are handled by first listing the users in the specified group and entering a single-user subscription for each user. One additional step involves creating a separate subscription record for the group subscription …”; ¶ 0050 “… FIG. 2 depicts condition expression processing. When ‘requestTelemetry’ received at server, the invention parses infix expression, validate it, and converts it to postfix form, store postfix form in subscriptions database, transmit postfix form to client …”; ¶ 0062 “… The Load balancer allows load balancing for HTTP requests from the client to the cluster member among several TOPAZ cluster nodes. Session cookies are used to provide node affinity for HTTP requests from the same client node. However, since the load of these sessions can vary over time, depending on the subscriptions on a client, it is valuable to be able to move a session from one TOPAZ node to another. This is done through the database: information about the current state of a session is placed in a record when a session is moved …”);
checking, upon initiation of a request for telemetry data for a telemetry job, the database to verify collection of the respective data through the specific transport mechanism (Bae teaches request-initiation checking against recorded capability/state retrieved from the database; Chayat also teaches transport/message-profile selection (¶ 0021 as indicated above); ¶ 0051 “… Validity is checked when subscription request is received. The checking enables immediate error message to application, and avoids handling these errors at condition evaluation time. What each device/client is capable of is recorded. …”; ¶ 0052 “… Client capability is checked when subscription is received and processed, so the decision can be made then …”; ¶ 0060 “… TOPAZ processing involves receiving an aggregate request, retrieving any required information from the database …”); …;
transmitting the short-term metric to subscribed consumers through a selected transport mechanism (Bae teaches subscribed consumers, selected timing, and an identified transport; as discussed above, Chayat teaches transport-specific message formatting and destination transmission; ¶ 0023 “… Each subscription includes two specifications for the desired interval between telemetry samples: 1) a minimum interval and 2) a maximum interval …”; 0057 “… clients communicate with TOPAZ using HTTP over TCP …”; ¶ 0065 “… Once inside the Telemetry Receiver, the data must be routed to one or more applications that have requested the data …”).
Bae and Chayat-Osiecki are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the subscription management techniques of Bae with the system of Chayat-Osiecki to facilitate the scalable and efficient telemetry data acquisition for consumers (Bae ¶ 0004).
For Claim 12, Chayat-Osiecki-Bae teaches the method of claim 11 wherein the telemetry data comprises data generated periodically by each producer upon operation in the cluster network, and consists of performance data, topology information, alerts, security states, and service features (Chayat, FIG. 1; ¶ 0014 “… the example network 100 may represent a grouping of related or interconnected devices, such as a datacenter, a computing cluster, a Local Area Network (LAN), a Wide Area Network (WAN) …”; ¶ 0017 “… the network device 110 may include telemetry logic 120 to generate telemetry data associated with the network device 110. Examples of such telemetry data may include link statistics, system statistics, access control list statistics, system status, temperature level, power consumption data, and so forth …”), and further wherein the subscribed consumers comprise at least one of: pod components of the nodes, storage users (Chayat teaches a memory address ¶ 0030), graphical user interfaces (GUI), and storage vendors (Chayat, FIGS 1-3; ¶ 0030 “… the destination field 330 may specify a network address, a memory address, a register, a process identifier, an application, a Virtual Machine (VM), a Virtual Network Function (VNF), a destination device, a hardware component, and so forth …”; Bae teaches consumer/application subscriptions to selected data items; FIG. 1; ¶ 0017 “… When a subscription for a client's telemetry data is received, the telemetry subscription service (TSS) 110 first analyzes the subscription with respect to other subscriptions for the same client application, with the goal of adjusting the subscriptions relative to each other in order to create an optimized set …”).
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the subscription management techniques of Bae with the system of Chayat-Osiecki to facilitate the scalable and efficient telemetry data acquisition for consumers (Bae ¶ 0004).
Claim Rejections - 35 USC § 103
Claim 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20180288503 A1 (hereinafter Chayat), in view of US 20170111242 A1 (Osiecki), and in further view of US 20100321204 A1 (hereinafter Bae), and in further view of US 20220417117 A1 (hereinafter Tayeb).
For Claim 6, Chayat-Osiecki-Bae teaches the method of claim 1. Chayat-Osiecki-Bae does not explicitly teach, but Tayeb teaches wherein a producer comprises a security node (Tayeb teaches collecting telemetry data from computing devices such as firewall; FIG. 1; ¶ 0024 “… the controlled entity 160 is embodied as a computing device, the collector 110 includes one or more sensors in the computing device or otherwise accessible to computing device …”; ¶ 0175 “… The term ‘security appliance’, ‘firewall’, and the like at least in some examples refers to a computer appliance designed to protect computer networks from unwanted traffic and/or malicious attacks …”).
Tayeb and Chayat-Osiecki-Base are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the telemetry collection techniques of Tayeb with the system of Chayat-Osiecki-Bae to improve system performance and/or reduce resource consumption (Tayeb ¶ 0002).
Claim Rejections - 35 USC § 103
Claims 8-9 and 15-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20180288503 A1 (hereinafter Chayat), in view of US 20170111242 A1 (Osiecki), in view of US 20100321204 A1 (hereinafter Bae), and in further view of Lyer et al. (US 20220414026 A1, published 12/29/2022; hereinafter Lyer).
For Claim 8, Chayat-Osiecki-Bae teaches the method of claim 7. Chayat-Osiecki-Bae does not explicitly teach, but Lyer teaches wherein a producer is provided with a telemetry library (Lyer teaches a platform framework 200) for connection through an application programming interface (API) in the telemetry transmitter for registering the schema of the short-term metric (Lyer teaches a producer registering the platform framework via an API with its variables ; FIG. 2; ¶ 0056 “… platform framework 200 may be provided as a software library or an ‘.exe’ file …”; ¶ 0058 “… In operation, platform framework 200 enables the management and orchestration of its participants' communications. The term ‘participant,’ as used herein, refers to any entity (e.g., hardware device driver, software module, etc.) configured to register with platform framework 200 by issuing a registration command to management and oversight engine 202 via API 205 …”; ¶ 0060 “… Producers are entities (e.g., 207A-N) configured to advertise or publish the capabilities (e.g., variables, primitives, etc.) and statuses of associated hardware (e.g., 206A) or software components (e.g., 206N) to platform framework 200 via API 205, which can then be consumed and/or modified by other participants (e.g., 210A-N) …”).
Lyer and Chayat-Osiecki-Bae are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the telemetry producer registration techniques of Lyer with the system of Chayat-Osiecki-Bae to facilitate communicating and utilizing information or data (Lyer ¶ 0002).
For Claim 9, Chayat-Osiecki-Bae teaches the method of claim 7. Chayat-Osiecki-Bae does not explicitly teach, but Lyer teaches wherein the defining and registering steps are performed while the network is running and executing applications, in order to maintain up-to-date collection of short-term metrics generated by producers in the cluster network (Lyer teaches distributed platform framework so as to facilitate running various operations concurrently; FIG. 2; ¶ 0085 “… platform framework 200 may be extensible or distributed. For example, different instances or portions of platform framework 200 may be executed by different processing components (e.g., processor(s) 101 and EC 120) of IHS 100, or across different IHSs. Additionally, or alternatively, independent instances of platform framework 200 may be executed by different workspaces and in secure communications with each other, such that a participant, service, or runtime object's handle may identify the particular platform framework 200 that the participant or service is registered with …”).
Lyer and Chayat-Osiecki-Bae are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the telemetry producer registration techniques of Lyer with the system of Chayat-Osiecki-Bae to facilitate communicating and utilizing information or data (Lyer ¶ 0002).
For Claim 15, Chayat-Osiecki-Bae teaches the method of claim 11. Chayat-Osiecki-Bae does not explicitly teach, but Lyer teaches wherein the metric datasets and short-term metric data are collected and registered by the telemetry transmitter while the network is running and executing applications, in order to maintain up-to-date collection of short-term metrics generated by producers in the cluster network (Lyer teaches distributed platform framework so as to facilitate running various operations concurrently; FIG. 2; ¶ 0085 “… platform framework 200 may be extensible or distributed. For example, different instances or portions of platform framework 200 may be executed by different processing components (e.g., processor(s) 101 and EC 120) of IHS 100, or across different IHSs. Additionally, or alternatively, independent instances of platform framework 200 may be executed by different workspaces and in secure communications with each other, such that a participant, service, or runtime object's handle may identify the particular platform framework 200 that the participant or service is registered with …”).
Lyer and Chayat-Osiecki-Bae are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the telemetry producer registration techniques of Lyer with the system of Chayat-Osiecki-Bae to facilitate communicating and utilizing information or data (Lyer ¶ 0002).
For Claim 16, the claim is substantially similar to claim 8 and therefore is rejected for the same reasoning set forth above.
For Claim 17, Chayat-Osiecki-Bae-Lyer teaches the method of claim 16 wherein the telemetry transmitter (Chayat exemplifies Telemetry Logic 120 in FIG. 1 and corresponding Virtualized Telemetry Controller 210 in FIG. 2) interfaces with the producer through a telemetry handler (Chayat’s Telemetry Logic 120 in FIG. 1 and corresponding Virtualized Telemetry Controller 210 in FIG. 2 also teaches the functionality of the telemetry handler) to provide notification of the occurrence of the condition to trigger the producer to transmit the short-term metric dataset to a datastore (Chayat exemplifies a Destination Node in FIG. 1) for collection by the telemetry transmitter (Chayat, FIGS 1-3; ¶ 0019 “… the system 200 may correspond generally to some or all of the telemetry logic 120 shown in FIG. 1 …”; ¶ 0021 “… the virtualized telemetry controller 210 may utilize the telemetry profiles 220 to determine triggers, source registers, and destinations for telemetry data …”; ¶ 0027 “… The collection trigger field 310 may specify one or more conditions to trigger the collection of telemetry data. For example, the collection trigger field 310 may specify a periodic timer, a control signal, an interrupt, a device status, a processing exception, a register flag, a system state, a trigger packet, and so forth …”).
Claim Rejections - 35 USC § 103
Claims 10 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20180288503 A1 (hereinafter Chayat), in view of US 20170111242 A1 (Osiecki), in view of US 20100321204 A1 (hereinafter Bae), in view of Lyer et al. (US 20220414026 A1, published 12/29/2022; hereinafter Lyer), and in further view of Gupta et al. (US 20250219894 A1, filed 12/29/2023; hereinafter Gupta).
For Claim 10, Chayat-Osiecki-Bae-Lyer teaches the method of claim 9. Chayat-Osiecki-Bae-Lyer does not explicitly teach, but Gupta teaches wherein the cluster network includes a telemetry pipeline implementing an Open Telemetry (OTEL) protocol (Gupta teaches collecting logs using OTEL protocol; FIG. 4B; ¶ 0107 “… Log collector tools 444 may obtain and pre-process candidate logs from multiple layers of a network infrastructure …”; ¶ 0114 “… otel.library.name …: aos-otel-collector …”), and wherein the telemetry transmitter includes a collector receiving the telemetry data from producers through a remote procedure call (RPC) process (Gupta, FIG. 1; ¶ 0046 “… Services 122 may communicate with each other using calls, such as remote procedure calls (RPCs). Services 122 may communicate with each other along a chain of RPCs to provide the functionality of the network application …”; ¶ 0060 “… Log collector tools 144 may include software tools (e.g., FluentBit and FluentD) configured to collect, filter, format, and tag logs and metrics from multiple sources (e.g., an application layer, a compute layer, and a network layer) …”), and further wherein cluster network includes nodes each containing a plurality of pods performing network functions and generating the telemetry data for transmission to the consumers (Gupta, FIG. 1; ¶ 0035 “… Each of compute nodes 110 may host one or more workloads. The term ‘workload’ encompasses virtual machines, containers, Kubernetes Pods, and/or other virtualized computing resources that provide an at least partially independent execution environment for applications …”; ¶ 0077 “… Log collector tools 244 may include software tools for collecting telemetry data from various sources throughout computing infrastructure 100. Log collector tools 244 may collect telemetry data such as logs, traces, and performance metrics …”).
Gupta and Chayat-Osiecki-Bae-Lyer are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the collecting and analyzing network telemetry data techniques of Gupta with the system of Chayat-Osiecki-Bae-Lyer to facilitate efficient, thorough, and simplified troubleshooting of performance issues of network applications (Gupta ¶ 0010).
For Claim 18, Chayat-Osiecki-Bae-Lyer teaches the method of claim 17 further comprising: processing the short-term telemetry dataset in the telemetry handler of the producer (Chayat, FIG. 2; 0021 “… the virtualized telemetry controller 210 may utilize the telemetry profiles 220 to determine triggers, source registers, and destinations for telemetry data. Further, in some embodiments, the virtualized telemetry controller 210 may utilize the message profiles 230 to determine how to package the telemetry data for transmission to the appropriate destination …”); and …
Chayat-Osiecki-Bae-Lyer does not explicitly teach, but Gupta teaches inputting the telemetry data to the datastore through a telemetry pipeline, wherein the telemetry pipeline implements an Open Telemetry (OTEL) protocol (Gupta teaches collecting logs using OTEL protocol; FIG. 4B; ¶ 0107 “… Log collector tools 444 may obtain and pre-process candidate logs from multiple layers of a network infrastructure …”; ¶ 0114 “… otel.library.name …: aos-otel-collector …”), and comprises a collector receiving the telemetry data through a remote procedure call (RPC) process (Gupta, FIG. 1; ¶ 0046 “… Services 122 may communicate with each other using calls, such as remote procedure calls (RPCs). Services 122 may communicate with each other along a chain of RPCs to provide the functionality of the network application …”; ¶ 0060 “… Log collector tools 144 may include software tools (e.g., FluentBit and FluentD) configured to collect, filter, format, and tag logs and metrics from multiple sources (e.g., an application layer, a compute layer, and a network layer) …”).
Gupta and Chayat-Osiecki-Bae-Lyer are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the collecting and analyzing network telemetry data techniques of Gupta with the system of Chayat-Osiecki-Bae-Lyer to facilitate efficient, thorough, and simplified troubleshooting of performance issues of network applications (Gupta ¶ 0010).
Claim Rejections - 35 USC § 103
Claim 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20180288503 A1 (hereinafter Chayat), in view of US 20170111242 A1 (Osiecki), in view of US 20100321204 A1 (hereinafter Bae), and in further view of US 20240403137 A1 (hereinafter Rao).
For Claim 13, Chayat-Osiecki-Bae teaches the method of claim 12 … further wherein the telemetry data comprises log data (Osiecki, FIG. 1; ¶ 0018 “… In addition, the data communication network 100 includes a monitored system 106 that generates logs and/or metrics 109 that may be transmitted to the servers 103 as a data stream …”).
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the generating data models from the collected metrics techniques of Osiecki with the system of Chayat to reduce the storage demand for the metrics data and facilitate metrics searching ability (Osiecki ¶ 0014).
Chayat-Osiecki-Bae does not explicitly teach, but Rao teaches wherein the cluster network processes containerized data utilizing a Kubernetes-based framework, and further wherein the plurality of nodes each contain a plurality of pods performing network functions and generating the telemetry data for transmission to the subscribing consumers (Rao teaches edge nodes, cloud nodes, cluster of devices, utilization of edge/MEC/Kubernetes on deployment, management of microservices process; FIGS 1-5; ¶ 0064 “… In block 424, the runtime component for App n can execute the application according to the provided specifications, collecting telemetry data and making dynamic adjustments as deemed necessary. The runtime system can continuously evaluate the collected telemetry data against the specified placement rules to determine if adjustments are needed …”; ¶ 0069 “… In block 442, the edge/MEC/Kubernetes can orchestrate the deployment and management of microservices across edge and cloud environments using containerization technologies. Kubernetes can provide the necessary tools for automating the deployment, scaling, and management of containerized applications, ensuring that microservices are deployed efficiently and can scale dynamically to handle varying workloads …”; ¶ 0074 “… In block 506, one or more devices (e.g., DataX cluster) can be utilized to represent the physical and virtual IoT devices and sensors that generate data for real-time analytics applications. These devices can include, for example, cameras, environmental sensors, other IoT endpoints that produce telemetry data, etc., and the DataX cluster can provide sufficient computational resources to process data locally, reducing latency and improving response times …”).
Rao and Chayat-Osiecki-Bae are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the containerized network architecture techniques of Rao with the system of Chayat-Osiecki-Bae to enhance performance, reduce latency, and provide optimal resource utilization for various computing systems and applications (Rao ¶ 0002).
Claim Rejections - 35 USC § 103
Claim 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20180288503 A1 (hereinafter Chayat), in view of US 20170111242 A1 (Osiecki), in view of US 20100321204 A1 (hereinafter Bae), in view of US 20240403137 A1 (hereinafter Rao), and in further view of Tayeb et al. (US 20220417117 A1, published 12/29/2022; hereinafter Tayeb).
For Claim 14, Chayat-Osiecki-Bae-Rao teaches the method of claim 13. Chayat-Osiecki-Bae-Rao does not explicitly teach, but Tayeb teaches wherein the producer comprises a security pod (Tayeb teaches collecting telemetry data from computing devices such as firewall; FIG. 1; ¶ 0024 “… the controlled entity 160 is embodied as a computing device, the collector 110 includes one or more sensors in the computing device or otherwise accessible to computing device …”; ¶ 0175 “… The term ‘security appliance’, ‘firewall’, and the like at least in some examples refers to a computer appliance designed to protect computer networks from unwanted traffic and/or malicious attacks …”).
Tayeb and Chayat-Osiecki-Bae-Rao are analogous art because they are both related to telemetry data.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the telemetry collection techniques of Tayeb with the system of Chayat-Osiecki-Bae-Rao to improve system performance and/or reduce resource consumption (Tayeb ¶ 0002).
Citation of Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is listed below, thank you:
i. US 2006/0294439 A1 (Rolia) teaches a method comprises providing a machine-readable monitoring model that maintains configuration of a monitoring environment. An element of the monitoring environment reads the machine-readable monitoring model and adapts its operation to the configuration defined thereby (Abstract). The monitoring data stored to monitoring data store 201A is configured in accordance with metric model 202A (¶ 0027)
ii. US 2015/0046512 A1 (Ashby) teaches that Technologies are generally described for collecting, analyzing and reporting telemetry data. A telemetry engine is built into a client application installed on a client device, and the telemetry engine is configured to collect and analyze application data at the client device and report the analyzed data to a service provider associated with the application. The telemetry application includes a specialized set of components, such as a telemetry transport component configured to communicate with the service provider, a data collection module configured to retrieve data from the application, and a rule manager and analyzer configured to analyze collected data according to a set of data collection rules provided by the service provider. The telemetry engine enables collection and analysis of telemetry data from multiple distributed client devices. The client devices dynamically change over time to ensure that current and important information is reported to the service provider (Abstract).
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 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZONGHUA DU whose telephone number is (408)918-7596. The examiner can normally be reached Monday - Friday 8 AM - 5 PM PST.
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, John Follansbee can be reached on (571) 272-3964. 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.
/Z.D./Examiner, Art Unit 2444
/SCOTT B CHRISTENSEN/Primary Examiner, Art Unit 2444
Prosecution Insights