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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant's arguments filed 06/09/2026 have been fully considered but they are not persuasive.
In response to applicant’s argument in pages 10-12, the applicant asserts that “Tapia does not describe or suggest, inter alia, "identify, based on the application performance data, at least one failure condition of the application session" and "based on determining that the network feature satisfies the threshold, relating the at least one failure condition of the application session to the network feature to determine that the network feature caused the at least one failure condition of the application session," as recited in amended claim 1.” Examiner respectively disagrees since as indicated by par. 11-15, 19-29, 38-43 of TAPAI, the prediction of the root cause also including the application data or session, e.g. social media data, key performance indicator (KPI) data, and network data and the cause of failure for application data or session or network data would cause failure of application session, which would indicating the failure of the application session. Therefore, TAPAI teaches "identify, based on the application performance data, at least one failure condition of the application session". Therefore, the combination of TAPAI and the new reference, GANJALIZADEH, would teach the claims.
In response to applicant’s argument in pages 10-12, the applicant asserts that “Tapia does not describe or suggest, inter alia, "train a predictive model, based on the network data, to predict at least one failure condition of the application session and one or more network features that impact the predicted at least one failure condition" and "apply network data from the one or more network devices obtained over a second period of time, subsequent to the first period of time, to the predictive model to predict the at least one failure condition of the application session over the second period of time and one or more network features that impact the predicted at least one failure condition of the application session over the second period of time," as recited in amended claim 7.” Examiner respectively disagrees since as indicated by par. 11-15, 19-29, 38-43 of TAPAI, the prediction of the root cause also including the application data or session, e.g. social media data, key performance indicator (KPI) data, and network data and the cause of failure for application data or session or network data would cause failure of application session, which would indicating the failure of the application session. Therefore, TAPAI teaches "train a predictive model, based on the network data, to predict at least one failure condition of the application session and one or more network features that impact the predicted at least one failure condition". Therefore, the combination of TAPAI and the new reference, GANJALIZADEH, would teach the claims.
The rejection is maintained.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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.
Claim(s) 1, 2, 5, 6, 7, 8, 9, 12, 13, 14, 15, 16, 19, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over TAPIA (US 20170353991) in view of GANJALIZADEH et al. (US 20220294697).
Regarding claim 1, TAPIA (US 20170353991) teaches a network management system (fig. 1, par. 16, computing node) comprising:
one or more processors (fig. 1, par. 16, computing node); and
memory comprising instructions executable by the one or more processors to cause the network management system (fig. 1, par. 16, computing node) to:
obtain, from an application server, application performance data of an application session (par. 11-15, 19-29, 38-43, The user device performance data and the network performance data may be obtained from multiple data sources. Without limitation, the multiple data sources may provide RAN Operation Support System (OSS) counters, Call Detail Records (CDRs), alarm data, alert data, trouble ticket data comprising customer ticket data and network ticket data, social media data, operation data, key performance indicator (KPI) data, device performance data, planning data, as well as other data that are related to the operations of the wireless carrier network…high-level KPIs that capture service performance, such as call establishment delays, mean opinion scores (MOS) of call audio quality, one-way audio problems, and network cell handover problems, difficulties with transitions between VoWiFi and VoLTE, and/or so forth);
obtain, from one or more network devices of a network associated with the application session, network data (par. 11-15, 19-29, 38-43, The user device performance data and the network performance data may be obtained from multiple data sources. Without limitation, the multiple data sources may provide RAN Operation Support System (OSS) counters, Call Detail Records (CDRs), alarm data, alert data, trouble ticket data comprising customer ticket data and network ticket data, social media data, operation data, key performance indicator (KPI) data, device performance data, planning data, as well as other data that are related to the operations of the wireless carrier network);
combine the application performance data with the network data (par. 11-15, 19-29, 38-43, Data collected from the aforementioned sources are aggregated or consolidated via the data adaptor platform in order to perform a real or non-real time analysis to identify areas that comprise performance data that fall below a predetermined threshold);
identify, based on the application performance data, at least one failure condition of the application session (par. 11-15, 19-29, 38-43, using a data adaptor platform in conjunction with a network fix applications to perform a proactive analysis of user device performance data and network performance data of a wireless carrier network to predict root cause for short and long-term problems in network nodes and prioritize network fix to implement a solution in an efficient manner…the root cause analysis module 119 can provide a predicted root cause 122 for a problem that is related to one or more symptoms derived from the performance data in order to aid in the resolution of quality of service issues for the wireless carrier network and provide alerting 123 of predicted root cause (e.g., to a network engineer, an administrator, and/or an administrative entity));
determine one or more network features that caused the at least one failure condition (par. 11-15, 19-29, 38-43); and
invoke, based on the determined network feature that caused the at least one failure condition, an action to remedy the at least one failure condition of the application session (par. 11-15, 19-29, 38-43, using a data adaptor platform in conjunction with a network fix applications to perform a proactive analysis of user device performance data and network performance data of a wireless carrier network to predict root cause for short and long-term problems in network nodes and prioritize network fix to implement a solution in an efficient manner).
However, TAPIA does not explicitly teach determine, based on the network data, a network feature indicative of a performance of the network for the application session; comparing the network feature to a threshold; based on determining that the network feature satisfies the threshold, relating the at least one failure condition of the application session to the network feature to determine that the network feature caused the at least one failure condition of the application session.
But, GANJALIZADEH et al. (US 20220294697) in a similar or same field of endeavor teaches determine, based on the network data, a network feature indicative of a performance of the network for the application session (fig. 6, 7, 13, par. 100, 136, 137, 163, the network node can select one or more second TREs needed to meet the network performance requirements associated with the application-level performance requirements…based on determining that the one or more network performance parameters do not fulfill the mapped one or more network performance requirements, the network node can select one or more second TREs needed to meet the network performance requirements); comparing the network feature to a threshold (fig. 6, 7, 13, par. 100, 136, 137, 163, the network node can select one or more second TREs needed to meet the network performance requirements associated with the application-level performance requirements…based on determining that the one or more network performance parameters do not fulfill the mapped one or more network performance requirements, the network node can select one or more second TREs needed to meet the network performance requirements); based on determining that the network feature satisfies the threshold, relating the at least one failure condition of the application session to the network feature to determine that the network feature caused the at least one failure condition of the application session (fig. 6, 7, 13, par. 100, 106, 136, 137, 151, 163, where N is the number of consecutive packet failures that the application layer can tolerate while remaining available. The above relations can be rearranged mathematically to map from application-level availability (A) and reliability (R) to network-level packet failure probability (p), mean time to repair (τ.sub.TR), and mean time between failures…based on determining that the one or more network performance parameters do not fulfill the mapped one or more network performance requirements…based on determining that the one or more network performance parameters do not fulfill the mapped one or more network performance requirements, the network node can select one or more second TREs needed to meet the network performance requirements);
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by GANJALIZADEH in the system of TAPIA to determine failure.
The motivation would have been to determine the realistic condition to determine the application condition to provide reliable service.
Regarding claim 2, TAPIA teaches the network management system of claim 1, wherein to combine the application performance data with the network data, the instructions further cause the network management system to combine the application performance data with the network data based on one or more of a timestamp, a network device identifier, an organization identifier, or a site identifier (par. 11-15, 19-29, 38-43, aggregate data from multiple data sources for a particular time period into an aggregated data file of data sets according to one or more grouping parameters. The grouping parameters may include specific time periods (e.g., hourly, daily, etc.), network components, user device vendor, user device models, and/or so forth… the data may be aggregated into datasets that correspond to a subscriber level, a device level, a service area level, and a geographical market level).
Regarding claim 5, TAPIA (US 20170353991) teaches the network management system of claim 1, wherein to invoke the action to remedy the at least one failure condition, the instructions further cause the network management system to perform at least one of:
generate a notification comprising at least one of an indication that the network feature is a cause of the at least one failure condition, a recommended action to remedy the at least one failure condition, or a combination thereof (par. 11-15, 19-29, 31, 38-43);
reconfigure one or more components of the one or more network devices associated with the application session (par. 11-15, 19-29, 31, 38-43, the network fix application may recommend one or more courses of action to resolve the quality of service issues and prioritize a network fix to implement the resolution for each of the issues associated with a predicted root cause based on expected impact, duration, short or long-term effect, available resources, and/or so forth…The network fix application 118 can generate, record, and manage node tickets generated for each issue identification, predicted root cause, network fix prioritization, node fix, and the node tickets are stored in the node maintenance log 125); or a combination thereof (par. 11-15, 19-29, 31, 38-43).
Regarding claim 6, TAPIA (US 20170353991) teaches the network management system of claim 1, wherein the network feature that caused the at least one failure condition of the application session comprises at least one of:
a wireless network performance of the one or more network devices (par. 11-15, 19-29, 38-43, 54, the performance of a specific device or network component);
a wired network performance of the one or more network devices (par. 11-15, 19-29, 38-43, 54, the performance of a specific device or network component); or
a distance between a client device and a virtual private network (VPN) server for a VPN session operating concurrently with the application session (par. 11-15, 19-29, 38-43, 54).
Regarding claims 7, 14, TAPIA (US 20170353991) teaches a network management system (fig. 1, par. 16, computing node) comprising:
one or more processors (fig. 1, par. 16, computing node);
memory comprising instructions executable by the one or more processors to cause the network management system (fig. 1, par. 16, computing node) to:
obtain network data from one or more network devices associated with an application session over a first period of time (par. 11-15, 19-29, 38-43, The user device performance data and the network performance data may be obtained from multiple data sources…The data collection module 205 may include a workflow scheduler that periodically checks for and retrieves newly available data from the multiple data sources…The grouping parameters may include specific time periods (e.g., hourly, daily, etc.), network components, user device vendor, user device models, and/or so forth);
train a predictive model based on the network data to predict at least one failure condition of the application session and one or more network features that impact the predicted at least one failure condition (par. 11-15, 19-29, 38-43, The network fix application 118 may identify a root cause for an issue affecting one or more subscribers of a wireless carrier network based on a set of live performance data using at least one machine learning model. The network fix application 118 may further generate a solution for the root cause using the machine learning model and/or a solutions database…The live performance data may be analyzed to provide a predicted root cause and a network fix prioritization that are generated using the machine learning model and are presented via an application user interface of the network fix application);
apply network data from the one or more network devices obtained over a second period of time, subsequent to the first period of time, to the predictive model to predict at least one failure condition of the application session over the second period of time and one or more network features that impact the predicted at least one failure condition over the second period of time (par. 11-15, 19-29, 38-43, The user device performance data and the network performance data may be obtained from multiple data sources…The data collection module 205 may include a workflow scheduler that periodically checks for and retrieves newly available data from the multiple data sources…The grouping parameters may include specific time periods (e.g., hourly, daily, etc.), network components, user device vendor, user device models, and/or so forth…The live performance data may be analyzed to provide a predicted root cause and a network fix prioritization that are generated using the machine learning model and are presented via an application user interface of the network fix application); and
invoke, based on the predicted at least one failure condition of the application session over the second period of time and the one or more network features that impact the predicted at least one failure condition over the second period of time, an action to prevent the predicted at least one failure condition of the application session (par. 11-15, 19-29, 38-43, The network fix application 118 may identify a root cause for an issue affecting one or more subscribers of a wireless carrier network based on a set of live performance data using at least one machine learning model. The network fix application 118 may further generate a solution for the root cause using the machine learning model and/or a solutions database…The live performance data may be analyzed to provide a predicted root cause and a network fix prioritization that are generated using the machine learning model and are presented via an application user interface of the network fix application).
However, TAPIA does not explicitly teach one or more network features that impact the predicted at least one failure condition of the application session; the one or more network features that impact predicted at least one failure condition of the application session.
But, GANJALIZADEH et al. (US 20220294697) in a similar or same field of endeavor teaches one or more network features that impact the predicted at least one failure condition of the application session (fig. 6, 7, 13, par. 100, 136, 137, 163); the one or more network features that impact predicted at least one failure condition of the application session (fig. 6, 7, 13, par. 100, 136, 137, 163, the network node can select one or more second TREs needed to meet the network performance requirements associated with the application-level performance requirements…based on determining that the one or more network performance parameters do not fulfill the mapped one or more network performance requirements, the network node can select one or more second TREs needed to meet the network performance requirements).
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by GANJALIZADEH in the system of TAPIA to determine failure.
The motivation would have been to determine the realistic condition to determine the application condition to provide reliable service.
Regarding claims 8, 15, TAPIA (US 20170353991) teaches the network management system of claim 7, wherein to train the predictive model based on the network data from one or more network devices associated with the application session over the first period of time, the one or more processors are configured to:
generate, based on the network data obtained over the first period of time, the one or more network features associated with the application session over the second period of time (par. 11-15, 19-29, 38-43, The user device performance data and the network performance data may be obtained from multiple data sources…The data collection module 205 may include a workflow scheduler that periodically checks for and retrieves newly available data from the multiple data sources…The grouping parameters may include specific time periods (e.g., hourly, daily, etc.), network components, user device vendor, user device models, and/or so forth).
Regarding claims 9, 16, TAPIA (US 20170353991) teaches the network management system of claim 7, wherein to train the predictive model based on the network data obtained over the first period of time, the one or more processors are further configured to: apply, to each of the one or more network features used to train the predictive model, a value indicating a level of contribution of a corresponding network feature (par. 11-15, 19-30, 38-43, the recommendation module 120 can determine the potential impact (e.g., based a number of subscribers affected, size of a geolocation affected, a number of user devices and network components affected, etc.), short and/or long-term effects, time frequency, and/or time duration of each of the problems associated with the predicted root cause and provide network fix prioritization in order to address each of the problem and/or root cause in the most efficient manner. In some embodiments, additional factors such as resources and labor required to provide network fix can be further considered for determining network fix priority).
Regarding claims 12, 19, TAPIA (US 20170353991) teaches the network management system of claim 7, wherein to invoke the action to prevent the predicted at least one failure condition of the application session, the one or more processors are configured to perform at least one of:
generate a notification comprising at least one of an indication of the one or more network features that impact the predicted at least one failure condition of the application session or a recommended action to prevent the predicted at least one failure condition of the application session over the second period of time (par. 11-15, 19-29, 31, 38-43); or
reconfigure one or more components of the one or more network devices associated with the application session (par. 11-15, 19-29, 31, 38-43, the network fix application may recommend one or more courses of action to resolve the quality of service issues and prioritize a network fix to implement the resolution for each of the issues associated with a predicted root cause based on expected impact, duration, short or long-term effect, available resources, and/or so forth…The network fix application 118 can generate, record, and manage node tickets generated for each issue identification, predicted root cause, network fix prioritization, node fix, and the node tickets are stored in the node maintenance log 125); or a combination thereof (par. 11-15, 19-29, 31, 38-43).
However, TAPIA does not teach a notification comprising at least one of an indication of the one or more network features that impact the predicted at least one failure condition of the application session over the second period of time.
But, GANJALIZADEH et al. (US 20220294697) in a similar or same field of endeavor teaches a notification comprising at least one of an indication of the one or more network features that impact the predicted at least one failure condition of the application session over the second period of time (fig. 6, 7, 13, par. 100, 136, 137, 163, the network node can select one or more second TREs needed to meet the network performance requirements associated with the application-level performance requirements…based on determining that the one or more network performance parameters do not fulfill the mapped one or more network performance requirements, the network node can select one or more second TREs needed to meet the network performance requirements).
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by GANJALIZADEH in the system of TAPIA to determine failure.
The motivation would have been to determine the realistic condition to determine the application condition to provide reliable service.
Regarding claims 13, 20, TAPIA (US 20170353991) teaches the network management system of claim 7, wherein the one or more network features that impact the predicted at least one failure condition of the application session over the second period of time comprises at least one of:
a wireless network performance of the one or more network devices (par. 11-15, 19-29, 38-43, 54, the performance of a specific device or network component); a wired network performance of the one or more network devices (par. 11-15, 19-29, 38-43, 54, the performance of a specific device or network component); a distance between a client device and a virtual private network (VPN) server for a VPN session operating concurrently with the application session (optional, par. 11-15, 19-29, 38-43, 54); or a combination thereof (optional, par. 11-15, 19-29, 38-43, 54);
However, TAPIA does not teach wherein the one or more network features that impact the predicted at least one failure condition of the application session over the second period of time.
But, GANJALIZADEH et al. (US 20220294697) in a similar or same field of endeavor teaches wherein the one or more network features that impact the predicted at least one failure condition of the application session over the second period of time (fig. 6, 7, 13, par. 100, 136, 137, 163, the network node can select one or more second TREs needed to meet the network performance requirements associated with the application-level performance requirements…based on determining that the one or more network performance parameters do not fulfill the mapped one or more network performance requirements, the network node can select one or more second TREs needed to meet the network performance requirements).
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by GANJALIZADEH in the system of TAPIA to determine failure.
The motivation would have been to determine the realistic condition to determine the application condition to provide reliable service.
Claim(s) 3, 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over TAPIA (US 20170353991) and GANJALIZADEH et al. (US 20220294697) as applied to claim 1 above, and further in view of WANG et al. (US 20230070701).
Regarding claim 3, TAPIA does not teach the network management system of claim 1, wherein to determine that the feature that caused the at least one failure condition, the instructions further cause the network management system to:
determine, based on the network data, Received Signal Strength Indicator (RSSI) values of the one or more network devices associated with the application session;
compare the RSSI values to a threshold; and
determine, based on the comparison, that a wireless network performance of the one or more network devices is the network feature that caused the at least one failure condition of the application session.
But, WANG et al. (US 20230070701) in a similar or same field of endeavor teaches determine, based on the network data, Received Signal Strength Indicator (RSSI) values of the one or more network devices associated with the application session (par. 65, 68, 98, 106, 170, RSSI);
compare the RSSI values to a threshold (par. 65, 68, 98, 106, 170, if the RSSI, RSRP, and SNR values meet a weak signal or unstable signal threshold determined as all values falling under the poor band); and
determine, based on the comparison, that a wireless network performance of the one or more network devices is the network feature that caused the at least one failure condition of the application session (par. 65, 68, 98, 106, 170, The WAN link health SLE metric engine may determine a success or failure state associated with one or more of service provider reachability, physical interface operation, or logical path performance based on the aggregated path data, and classify the determined failure states).
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by WANG in the system of TAPIA and GANJALIZADEH to determine failure.
The motivation would have been to identify performance degradations and/or network failures that may not be detectable from assessments based on a shorter “snapshots” of path data, e.g., performed by the network devices themselves (WANG par. 8).
Regarding claim 4, TAPIA does not teach the network management system of claim 1, wherein to determine that the network feature caused the at least one failure condition, the instructions further cause the network management system to:
determine, based on the network data, a distance between a client device and a virtual private network (VPN) server for a VPN session operating concurrently with the application session;
compare the distance between the client device and the VPN server to a threshold;
determine, based on the distance between the client device and the VPN server satisfying the threshold, that the VPN session is the network feature that caused the at least one failure condition of the application session.
But, WANG et al. (US 20230070701) in a similar or same field of endeavor teaches determine, based on the network data, a distance between a client device and a virtual private network (VPN) server for a VPN session operating concurrently with the application session (table 1, par. 65, 68, 98, 101, 106, 116, 170, unreachable based arp or number of hop; jitter, latency, loss, degrade over a reasonable range from its baseline);
compare the distance between the client device and the VPN server to a threshold (table 1, par. 65, 68, 98, 101, 106, 116, 170, unreachable based arp or number of hop; jitter, latency, loss, degrade over a reasonable range from its baseline);
determine, based on the distance between the client device and the VPN server satisfying the threshold, that the VPN session is the network feature that caused the at least one failure condition of the application session (par. 65, 68, 98, 106, 116, 133-136, 170, unreachable… jitter, latency, loss, degrade over a reasonable range from its baseline… reach…a ping status to the next-hop gateway (TTL or number of hops that indicate reachable or unreachable)).
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by WANG in the system of TAPIA and GANJALIZADEH to determine failure.
The motivation would have been to reduce the transmission delay between transmitter and receiver.
Claim(s) 10, 11, 17, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over TAPIA (US 20170353991) and GANJALIZADEH et al. (US 20220294697) as applied to claims 9, 16 above, and further in view of CELLA et al. (US 20210182996).
Regarding claims 10, 17, TAPIA does not teach the network management system of claim 9, wherein the value comprises a Shapley Additive Explanation (SHAP) value.
But, CELLA et al. (US 20210182996) in a similar or same field of endeavor teaches wherein the value comprises a Shapley Additive Explanation (SHAP) value (par. 547, Shapley values).
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by CELLA in the system of TAPIA and GANJALIZADEH to provide machine learning model.
The motivation would have been to provide the one or more model interpretability systems may also be used by a human user to improve and guide training of the machine learning model 3000, to help debug the machine learning model 3000, to help recognize bias in the machine learning model 3000.
Regarding claims 11, 18, TAPIA does not teach the network management system of claim 9, wherein the value comprises a Local Interpretable Model-Agnostic Explanations (Lime) value.
But, CELLA et al. (US 20210182996) in a similar or same field of endeavor teaches wherein the value comprises a Local Interpretable Model-Agnostic Explanations (Lime) value (par. 547, a local surrogate (LIME) model).
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by CELLA in the system of TAPIA and GANJALIZADEH to provide machine learning model.
The motivation would have been to provide the one or more model interpretability systems may also be used by a human user to improve and guide training of the machine learning model 3000, to help debug the machine learning model 3000, to help recognize bias in the machine learning model 3000.
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 THINH D TRAN whose telephone number is (571)270-3934. The examiner can normally be reached mon-fri 9-6.
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, FARUK HAMZA can be reached at 5712727969. 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.
/THINH D TRAN/for /Thinh Tran/, Patent Examiner of Art Unit 2466 08/25/2026
Prosecution Insights