DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This office action is a response to an amendment filed on 08/11/2026. Claims 1-20 are cancelled and claims 21, 28 and 35 are amended. Claims 21-40 are currently pending.
Response to Arguments
Applicant’s remarks, see pages 8-9, with respect to the non-statutory double patenting rejections have been fully considered. However, “[a]s filing a terminal disclaimer, or filing a showing that the claims subject to the rejection are patentably distinct from the reference application’s claims, is necessary for further consideration of the rejection of the claims, such a filing should not be held in abeyance. Only objections or requirements as to form not necessary for further consideration of the claims may be held in abeyance until allowable subject matter is indicated” (MPEP 804 (I)(B)(1)). Therefore, Applicant is required to address double patenting rejections as they can not be held in abeyance until an agreement regarding allowable subject matter has been reached.
For examination purposes, the Examiner will consider the amendments to the claims an attempt by Applicant to overcome the double patenting rejection. The amended claims overcome the double patenting rejections; therefore, the rejections are withdrawn. However, upon further consideration, a new ground(s) of rejection is made.
Applicant’s remarks, see pages 9-10, with respect to the rejections under 35 USC 103 have been fully considered. The amended claims overcome the prior rejections; therefore, the rejections are withdrawn. However, upon further consideration, a new ground(s) of rejection is made, necessitated by the amendments.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 21, 22, 24-29, 31-33 and 35 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 2, 6-12, 16-18 and 20 of US Patent No. 12244473 in view of Shaw et al. (US 2023/0077440). For example, claim 21 of the instant application encompasses all of the limitations of claim 1 of US Patent No. 12244473 as follows:
Instant Application: 19046769
Patented Application: 12244473
Claim 21: A method, comprising:
Claim 1: A method, comprising:
collecting properties associated with each of a plurality of paths between at least one device and an Application Programing Interface (API) gateway, wherein the at least one device comprises an endpoint device;
collecting properties associated with each of a plurality of paths between at least one device and an Application Programing Interface (API) gateway, wherein the at least one device comprises at least an endpoint device;
monitoring the properties associated with each of the plurality of paths to determine a current level of performance for each of the plurality of paths;
monitoring the properties associated with each of the plurality of paths to determine a current level of performance for each of the plurality of paths;
collecting system telemetry comprising at least historical data associated with the plurality of paths
monitoring the at least one device to determine a current load of the at least one device;
analyzing, using machine learning, the current level of performance for each of the plurality of paths and the system telemetry to produce a predictive analytics model for congestion on each of the plurality of paths; and
analyzing, using machine learning, the current level of performance for each of the plurality of paths and the current load of the at least one device to produce a predictive analytics model for congestion on each of the plurality of paths;
determining, using the predictive analytics model, if a corrective action is needed to maintain an optimal performance of the API gateway and the plurality of paths, based on at least the current level of performance for each of the plurality of paths and the system telemetry.
determining, using the predictive analytics model, if a corrective action is needed to maintain an optimal performance of the API gateway, the plurality of paths, and the at least one device based on at least the current level of performance for each of the plurality of paths and the current load of the at least one device; and
performing the corrective action when the predictive analytics model indicates that the corrective action is needed.
Claims 21, 22, 24-29, 31-33 and 35 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 2, 6-12, 16-18 and 20 of US Patent No. 12244473 in view of Shaw et al. (US 2023/0077440).
Claims 21, 22, 24-29, 31-33 and 35 of the instant application and claims 1, 2, 6-12, 16-18 and 20 of the patented application are both directed using machine learning to analyze performance of multiple network paths between an endpoint device and an API gateway, predict congestion of the paths, and determine corrective action to maintain optimal performance. The claims of the instant application additionally recite collecting system telemetry comprising historical data associated with the plurality of paths and using that historical telemetry with the current performance of each path in the machine learning analysis and corrective action determination.
In related art, Shaw discloses
collecting system telemetry comprising at least historical data associated with the plurality of paths (Shaw, [0182], [0110]: real-time network telemetry and recorded (historical) network information associated with routing paths);
analyzing, using machine learning, the current level of performance and the system telemetry to produce a predictive analytics model for congestion (Shaw, [0183]: applying real-time packet data set (current level of performance) and network operational history (system telemetry) to a machine learning/artificial intelligence algorithm to generate a routing/performance model (predictive analytics model) that identifies congestion); and
determining, using the predictive analytics model, if a corrective action is needed, based on at least the current level of performance and the system telemetry (Shaw, [0183]: using the model (predictive analytics model) generated from real-time data (current level of performance) and operational history (system telemetry) to identify congestion and modify network routing tables (corrective action)).
It would have been obvious to modify claims 1, 2, 6-12, 16-18 and 20 of the patented application to additionally collect and analyze historical network telemetry as taught by Shaw to be utilized with the current path performance information, because Shaw teaches that instantaneous telemetry may be insufficient and that historical path information may be used with current network information to improve predictive routing decisions (Shaw, [0110]). The motivation for doing so would have been to facilitate accounting for network conditions that are not apparent from current measurements alone.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 21-23, 28-30 and 35-37 are rejected under 35 U.S.C. 103 as being unpatentable over Vasseur et al. (US 2015/0332145), hereinafter Vasseur, in view of Dinh et al. (US 2021/0136095), hereinafter Dinh, further in view of Shaw et al. (US 2023/0077440), hereinafter Shaw. Dinh is cited by Applicant in the IDS filed on 02/06/2025.
Regarding claim 21, Vasseur discloses a method, comprising:
collecting properties associated with each of a plurality of paths between at least one device and gateway (Vasseur, Fig. 1: CE router 110 (gateway); Fig. 2, [0026]- [0027]: CE router (gateway) includes a network analyzer module/NAM 246; [0048]: NAM 246 determines the performance of a plurality of paths connecting a remote office (at least one device) to a corporate network; [0049]-[0053]: feature data (properties) collected by NAM 246);
monitoring the properties associated with each of the plurality of paths to determine a current level of performance for each of the plurality of paths (Vasseur, [0048]: NAM 246 tracks all the network conditions visible to the router. NAM 246 determines the performance of each link/path available; [0049]-[0053]: feature data (properties) monitored by NAM 246);
analyzing, using machine learning, the current level of performance for each of the plurality of paths, to produce a predictive analytics model for congestion on each of the plurality of paths (Vasseur, [0048]: NAM 246 is used to compute a model of the network performance using learning machine 404; [0055]: learning machine 404 uses a predictive model to predict future network performance metrics based on the feature data (current level of performance); [0050]-[0053]: performance metrics include delay, bandwidth, jitter and packet loss [These are all indicators of network congestion]); and
determining, using the predictive analytics model, if a corrective action is needed to maintain an optimal performance of the gateway and the plurality of paths, based on at least the current level of performance for each of the plurality of paths (Vasseur, Fig. 2, [0059]: predictive control manager/PCM 247 receives network performance model data generated by learning machine 404; [0060]: if an application SLA is predicted not to be met, PCM 247 takes corrective measures; [0063]: PCM 247 generates path selection parameters to ensure corresponding traffic is routed over different paths [i.e., CE router 110 (gateway) optimizes path selection]).
Vasseur does not explicitly disclose between at least one device and an Application Programing Interface (API) gateway, wherein the at least one device comprises an endpoint device; collecting system telemetry comprising at least historical data associated with the plurality of paths; analyzing, using machine learning, the current level of performance for each of the plurality of paths and the system telemetry; based on at least the current level of performance for each of the plurality of paths and the system telemetry.
However, Dinh discloses
collecting properties associated with each of a plurality of paths between at least one device and an Application Programing Interface (API) gateway (Dinh, Fig. 1, Fig. 6, step 602; [0021]: monitoring and logging transactions between client devices (at least one device) and an API gateway), wherein the at least one device comprises an endpoint device (Dinh, [0021]);
determining, using the predictive analytics model, if a corrective action is needed to maintain an optimal performance of the API gateway (Dinh, Fig. 1, [0041]: AI/ML layer performs data analytics to make predictions regarding potential errors or failures; Fig. 6, steps 604-608).
It would have been obvious to one of ordinary skill in the art, having the teachings of Vasseur and Dinh before him or her before the effective filing date of the claimed invention, to modify a predictive network optimization system as taught by Vasseur, to include the API gateway monitoring and anomaly management techniques as taught by Dinh. The motivation for doing so would have been to proactively identify and remediate service degradation affecting API traffic, thereby improving the reliability and availability for API communications over the network paths.
Furthermore, the combination of Vasseur and Dinh does not explicitly disclose collecting system telemetry comprising at least historical data associated with the plurality of paths; analyzing, using machine learning, the current level of performance for each of the plurality of paths and the system telemetry; based on at least the current level of performance for each of the plurality of paths and the system telemetry.
However, Shaw discloses
collecting system telemetry comprising at least historical data associated with the plurality of paths (Shaw, [0182], [0110]: real-time network telemetry and recorded (historical) network information associated with routing paths);
analyzing, using machine learning, the current level of performance and the system telemetry to produce a predictive analytics model for congestion (Shaw, [0183]: applying real-time packet data set (current level of performance) and network operational history (system telemetry) to a machine learning/artificial intelligence algorithm to generate a routing/performance model (predictive analytics model) that identifies congestion); and
determining, using the predictive analytics model, if a corrective action is needed, based on at least the current level of performance and the system telemetry (Shaw, [0183]: using the model (predictive analytics model) generated from real-time data (current level of performance) and operational history (system telemetry) to identify congestion and modify network routing tables (corrective action)).
It would have been obvious to one of ordinary skill in the art, having the teachings of Vasseur, Dinh and Shaw before him or her before the effective filing date of the claimed invention, to modify a predictive multi-path network optimization system implemented in an API gateway environment as taught by Vasseur and Dinh, to include utilizing real-time network data along with recorded network operational history in the machine learning analysis as taught by Shaw. The motivation for doing so would have been to enable congestion to be identified and routing modified accordingly, thereby maintaining reliable API communications over the available network paths.
Regarding claim 28, Vasseur discloses gateway (Vasseur, Fig. 1: CE router 110), comprising:
one or more processors (Vasseur, Fig. 2, [0026]-[0028]); and
one or more computer-readable non-transitory storage media coupled to the one or more processors that stores instructions operable when executed by the one or more processors to cause the gateway to perform operations comprising (Vasseur, Fig. 2, [0026]-[0028]):
collecting properties associated with each of a plurality of paths between at least one device and the gateway (Vasseur, Fig. 1: CE router 110 (gateway); Fig. 2, [0026]- [0027]: CE router (gateway) includes a network analyzer module/NAM 246; [0048]: NAM 246 determines the performance of a plurality of paths connecting a remote office (at least one device) to a corporate network; [0049]-[0053]: feature data (properties) collected by NAM 246);
monitoring the properties associated with each of the plurality of paths to determine a current level of performance for each of the plurality of paths (Vasseur, [0048]: NAM 246 tracks all the network conditions visible to the router. NAM 246 determines the performance of each link/path available; [0049]-[0053]: feature data (properties) monitored by NAM 246);
analyzing, using machine learning, the current level of performance for each of the plurality of paths to produce a predictive analytics model for congestion on each of the plurality of paths (Vasseur, [0048]: NAM 246 is used to compute a model of the network performance using learning machine 404; [0055]: learning machine 404 uses a predictive model to predict future network performance metrics based on the feature data (current level of performance); [0050]-[0053]: performance metrics include delay, bandwidth, jitter and packet loss [These are all indicators of network congestion]); and
determining, using the predictive analytics model, if a corrective action is needed to maintain an optimal performance of the gateway and the plurality of paths, based on at least the current level of performance for each of the plurality of paths (Vasseur, Fig. 2, [0059]: predictive control manager/PCM 247 receives network performance model data generated by learning machine 404; [0060]: if an application SLA is predicted not to be met, PCM 247 takes corrective measures; [0063]: PCM 247 generates path selection parameters to ensure corresponding traffic is routed over different paths [i.e., CE router 110 (gateway) optimizes path selection]).
Vasseur does not explicitly disclose between at least one device and an Application Programing Interface (API) gateway, wherein the at least one device comprises an endpoint device; collecting system telemetry comprising at least historical data associated with the plurality of paths; analyzing, using machine learning, the current level of performance for each of the plurality of paths and the system telemetry; based on at least the current level of performance for each of the plurality of paths and the system telemetry.
However, Dinh discloses an Application Programing Interface (API) gateway (Dinh, Fig. 1: API management platform), comprising:
one or more processors (Dinh, [0079]);
and one or more computer-readable non-transitory storage media coupled to the one or more processors that stores instructions operable when executed by the one or more processors to cause the API gateway to perform operations comprising (Dinh, [0079]):
collecting properties associated with each of a plurality of paths between at least one device and an Application Programing Interface (API) gateway (Dinh, Fig. 1, Fig. 6, step 602: monitoring and logging transactions between clients (devices) and an API gateway), wherein the at least one device comprises an endpoint device (Dinh, [0021]);
determining, using the predictive analytics model, if a corrective action is needed to maintain an optimal performance of the API gateway (Dinh, Fig. 1, [0041]: AI/ML layer performs data analytics to make predictions regarding potential errors or failures; Fig. 6, steps 604-608).
It would have been obvious to one of ordinary skill in the art, having the teachings of Vasseur and Dinh before him or her before the effective filing date of the claimed invention, to modify a predictive network optimization system as taught by Vasseur, to include the API gateway monitoring and anomaly management techniques as taught by Dinh. The motivation for doing so would have been to proactively identify and remediate service degradation affecting API traffic, thereby improving the reliability and availability for API communications over the network paths.
Furthermore, the combination of Vasseur and Dinh does not explicitly disclose collecting system telemetry comprising at least historical data associated with the plurality of paths; analyzing, using machine learning, the current level of performance for each of the plurality of paths and the system telemetry; based on at least the current level of performance for each of the plurality of paths and the system telemetry.
However, Shaw discloses
collecting system telemetry comprising at least historical data associated with the plurality of paths (Shaw, [0182], [0110]: real-time network telemetry and recorded (historical) network information associated with routing paths);
analyzing, using machine learning, the current level of performance and the system telemetry to produce a predictive analytics model for congestion (Shaw, [0183]: applying real-time packet data set (current level of performance) and network operational history (system telemetry) to a machine learning/artificial intelligence algorithm to generate a routing/performance model (predictive analytics model) that identifies congestion); and
determining, using the predictive analytics model, if a corrective action is needed, based on at least the current level of performance and the system telemetry (Shaw, [0183]: using the model (predictive analytics model) generated from real-time data (current level of performance) and operational history (system telemetry) to identify congestion and modify network routing tables (corrective action)).
It would have been obvious to one of ordinary skill in the art, having the teachings of Vasseur, Dinh and Shaw before him or her before the effective filing date of the claimed invention, to modify a predictive multi-path network optimization system implemented in an API gateway environment as taught by Vasseur and Dinh, to include utilizing real-time network data along with recorded network operational history in the machine learning analysis as taught by Shaw. The motivation for doing so would have been to enable congestion to be identified and routing modified accordingly, thereby maintaining reliable API communications over the available network paths.
Regarding claim 35, the limitations have been addressed in the rejection of claim 21, and furthermore, Vasseur discloses one or more computer-readable non-transitory storage media embodying instructions that, when executed by a processor, cause the processor to perform operations (Vasseur, [0028]).
Regarding claim 22, Vasseur discloses wherein monitoring the properties of each of the plurality of paths includes determining latency, jitter, available bandwidth, and packet loss of each of the plurality of paths (Vasseur, [0049]-[0053]).
Regarding claim 23, Vasseur discloses further comprising performing the corrective action when the predictive analytics model indicates that the corrective action is needed (Vasseur, [0060]: if an application SLA is predicted not to be met, PCM 247 takes corrective measures).
Regarding claims 29 and 36, the limitations have been addressed in the rejection of claim 22.
Regarding claims 30 and 37, the limitations have been addressed in the rejection of claim 23.
Claims 24-26, 31-33 and 38-40 are rejected under 35 U.S.C. 103 as being unpatentable over Vasseur in view of Dinh and Shaw, further in view of Mui et al. (US 2019/0373531), hereinafter Mui.
Regarding claim 24, Vasseur as modified by Dinh and Shaw discloses an API gateway (Dinh, Fig. 1) but does not explicitly disclose wherein the corrective action comprises establishing an additional path between the at least one device and the API gateway.
However, Mui discloses wherein the corrective action comprises establishing an additional path between the at least one device and the gateway (Mui, [0017]: modifying a data path between a UE (device) and a core network node (gateway); [0064]-[0069]: GW node 148 (gateway) manages handover and path operations; [0060]: when a handover is required (i.e., corrective action), a new data path is created connecting to TBS 510).
It would have been obvious to one of ordinary skill in the art, having the teachings of Vasseur, Dinh, Shaw and Mui before him or her before the effective filing date of the claimed invention, to modify a predictive network optimization system in an API gateway environment as taught by Vasseur, Dinh and Shaw, to include utilizing dynamic data path creation techniques as taught by Mui. The motivation for doing so would have been to enable the system to dynamically establish communication paths when predicted conditions indicate degraded API communication performance.
Regarding claim 25, Vasseur as modified by Dinh and Shaw discloses an API gateway (Dinh, Fig. 1) but does not explicitly disclose wherein the corrective action comprises removing at least one path between the at least one device and the API gateway.
However, Mui discloses wherein the corrective action comprises removing at least one path between the at least one device and the gateway (Mui, [0017]: modifying a data path between a UE (device) and a core network node (gateway); [0064]-[0069]: GW node 148 (gateway) manages handover and path operations; [0060]: when a handover is required (i.e., corrective action), a ‘UE Context Release’ message is communicated to SB 500 leading to the removal of the previously established user data path).
It would have been obvious to one of ordinary skill in the art, having the teachings of Vasseur, Dinh, Shaw and Mui before him or her before the effective filing date of the claimed invention, to modify a predictive network optimization system in an API gateway environment as taught by Vasseur, Dinh and Shaw, to include utilizing dynamic path removal techniques as taught by Mui. The motivation for doing so would have been to enable the system to dynamically remove inefficient or unnecessary communication paths, thereby improving API communication performance and resource efficiency.
Regarding claim 26, Vasseur as modified by Dinh and Shaw discloses an API gateway (Dinh, Fig. 1) but does not explicitly disclose wherein the corrective action comprises reconfiguring at least one path between the at least one device and the API gateway.
However, Mui discloses wherein the corrective action comprises reconfiguring at least one path between the at least one device and the API gateway (Mui, [0017]: modifying a data path between a UE (device) and a core network node (gateway); [0064]-[0072]: GW node 148 (gateway) handling and modifying the path; [0072]: ‘Handover Required’ (i.e., corrective action needed); the GW node is able to modify the existing data path and reassign it to the TBS).
It would have been obvious to one of ordinary skill in the art, having the teachings of Vasseur, Dinh, Shaw and Mui before him or her before the effective filing date of the claimed invention, to modify a predictive network optimization system in an API gateway environment as taught by Vasseur, Dinh and Shaw, to include utilizing dynamic path reconfiguration techniques as taught by Mui. The motivation for doing so would have been to enable the system to dynamically reconfigure communication paths to maintain efficient and reliable API communications under changing network conditions.
Regarding claims 31 and 38, the limitations have been addressed in the rejection of claim 24.
Regarding claims 32 and 39, the limitations have been addressed in the rejection of claim 25.
Regarding claims 33 and 40, the limitations have been addressed in the rejection of claim 26.
Claims 27 and 34 are rejected under 35 U.S.C. 103 as being unpatentable over Vasseur in view of Dinh, Shaw and Mui, further in view of Shen et al. (US 2020/0413283), hereinafter Shen.
Regarding claim 27, Vasseur, Dinh, Shaw and Mui do not explicitly disclose wherein reconfiguring the at least one path comprises: moving the API gateway to a new location; or instructing a network controller associated with a Software Defined-Wide Area Network (SD-WAN) to increase network resources of at least one of the plurality of paths.
However, Shen discloses wherein reconfiguring the at least one path comprises:
moving the API gateway to a new location; or
instructing a network controller associated with a Software Defined-Wide Area Network (SD-WAN) to increase network resources of at least one of the plurality of paths (Shen, [0077]-[0078]: SD-WAN controller receives a congestion indication (instruction) indicating that bandwidth utilization on a WAN interface of a branch edge router exceeds a threshold, and it reduces congestion at the branch edge router (i.e., on the path) by modifying a bandwidth shaper ratio from 100% to 40% (i.e., increasing bandwidth/resources)).
It would have been obvious to one of ordinary skill in the art, having the teachings of Vasseur, Dinh, Shaw, Mui and Shen before him or her before the effective filing date of the claimed invention, to modify a predictive network optimization system in an API gateway environment as taught by Vasseur, Dinh, Shaw and Mui, to include utilizing SD-WAN adaptive congestion control and resource allocation techniques as taught by Shen. The motivation for doing so would have been to enable the system to dynamically increase network resources and reconfigure SD-WAN communication paths when degraded conditions affect API communications.
Regarding claim 34, the limitations have been addressed in the rejection of claim 27.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LESA M KENNEDY whose telephone number is (571)431-0704. The examiner can normally be reached on Monday-Wednesday 9:30 am - 5:30 pm ET.
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, Umar Cheema can be reached on (571) 270-3037. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
The examiner also requests, in response to this Office Action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
/LESA M KENNEDY/Primary Examiner, Art Unit 2458
