Prosecution Insights
Last updated: October 26, 2026
Application No. 19/308,422

MULTI-CLOUD SITE-SITE SECURE CONNECTIVITY AS A SERVICE

Non-Final OA §DOUBLEPATENT
Filed
Aug 25, 2025
Priority
Oct 03, 2023 — IN 202341066355 +1 more
Examiner
MEKY, MOUSTAFA M
Art Unit
2457
Tech Center
2400 — Computer Networks
Assignee
Cisco Technology Inc.
OA Round
1 (Non-Final)
94%
Grant Probability
Favorable
1-2
OA Rounds
1y 1m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 94% — above average
94%
Career Allowance Rate
688 granted / 736 resolved
+35.5% vs TC avg
Moderate +5% lift
Without
With
+5.2%
Interview Lift
resolved cases with interview
Typical timeline
2y 3m
Avg Prosecution
12 currently pending
Career history
750
Total Applications
across all art units

Statute-Specific Performance

§101
6.4%
-33.6% vs TC avg
§103
15.7%
-24.3% vs TC avg
§102
37.4%
-2.6% vs TC avg
§112
6.4%
-33.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 736 resolved cases

Office Action

§DOUBLEPATENT
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 . Detailed Action Claims 1-20 are presenting for examination. non-statutory double patenting rejection The non-statutory 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 non-statutory 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 non-statutory 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 § 2146 et seq. 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 filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13. The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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/apply/applying-online/eterminal-disclaimer. Claims 1-20 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1, 4, 6, 8-9, , and 10-11 of U.S. Patent No. 12,425,329. Although the claims at issue are not identical, they are not patentably distinct from each other because the patent 329 anticipates the claimed invention as been shown in the table below. 19/308,422 12,425,329 1.A method comprising: receiving one or more metrics from devices at a first site and a second site, wherein the one or more metrics provide information about a health and/or a load for an existing instance of a tunnel between the first site and the second site; analyzing a sample of the one or more metrics to determine a trend in traffic between the first site and the second site; determining whether the trend exceeds or falls below a threshold level; and in response to the determining, dynamically changing communication between the first site and the second site. 3. The method of claim 1, wherein dynamically changing the communication between the first site and the second site further comprising: dynamically removing the existing instance of the tunnel based on the trend that the traffic will fall below the threshold level 8. The method of claim 1, the method further comprising: receiving one or more metrics from the devices at the first site and the second site, wherein the one or more metrics provide information about a health and a load for an existing instance of the tunnel between the selected devices at the first and second sites; analyzing a sample of the one or more metrics to determine a trend that traffic will fall below a threshold level; and dynamically removing the existing instance of the tunnel based on a determination of the trend that the traffic will fall below the threshold level. 2. The method of claim 1, wherein dynamically changing the communication between the first site and the second site further comprising: dynamically creating a second tunnel between the first site and the second site using a template based on the trend that the traffic will exceed the threshold level. 6. The method of claim 4, the method further comprising: receiving one or more metrics from the devices at the first site and the second site, wherein the one or more metrics provide information about a health and a load for an existing instance of tunnel between the selected devices at the first and second sites; analyzing a first sample of the one or more metrics to determine a trend that traffic will exceed a threshold level; and dynamically creating a second tunnel between the first site and the second site using the template based on a determination of the trend that the traffic will exceed the threshold level. 4. The method of claim 1, further comprising: generating a template for site-to-site connections between the first site and the second site, the template is created from input settings for use in connecting the devices at the first site and the second site, first site-specific protocols and configurations, and second site-specific protocols and configurations. 4. The method of claim 1, the method further comprising: generating a template for site-to-site connections between the first site and the second site, the template is created from the input settings for use in connecting the selected devices at the first site and the second site, the first site-specific protocols and configurations, and the second site-specific protocols and configurations. 5. The method of claim 1, further comprising: determining whether any traffic within the existing instance of the tunnel is stateless traffic. 6. The method of claim 5, further comprising: in response to determine the traffic is stateless traffic, routing the traffic through a remaining tunnel. 7. The method of claim 5, further comprising: in response to determine the traffic is stateful traffic, removing the existing instance of the tunnel from an ECMP route table prior to tearing down the tunnel. 9. The method of claim 8, the method further comprising: determining whether any traffic within the existing instance of the tunnel is stateless traffic; routing traffic through a remaining tunnel when the traffic is stateless traffic; and removing the existing instance of the tunnel from an ECMP route table prior to tearing down the tunnel when the traffic is stateful traffic. 8. The method of claim 1, wherein determining the trend further comprising: analyzing a moving window of the one or more metrics as the sample to determine the trend in traffic levels and connection health for the existing instance of the tunnel between the first site and the second site; and determine whether to create a new instance of the tunnel or remove the existing instance of the tunnel based on an analysis of the moving window of sample collection to prevent bouncing when handling bursting traffic trends. 10. The method of claim 1, the method further comprising: receiving one or more metrics from the devices at the first site and the second site, wherein the one or more metrics provide information about a health and a load for an existing instance of tunnel between the selected devices at the first and second sites; analyzing a moving window of one or more metrics as a first sample of the one or more metrics to determine a trend in traffic levels and connection health for the existing instance of the tunnel between the selected devices at the first and second sites; and determine whether to create a new instance of the tunnel or remove the existing instances of the tunnel based on an analysis of the moving window of sample collection to prevent bouncing when handling bursting traffic trends. 9. The method of claim 8, further comprising: determining, from the moving window of the one or more metrics, that a first application at the first site experiences a burst of traffic at one or more time periods; determining a head room needed for handling the burst of traffic from the first application; and determining that one or more existing instance of the tunnel is capable of handling the head room prior to removing the tunnel. 11. The method of claim 10, the method further comprising: determining, from the moving window of one or more metrics, that a first application at the first site experiences a burst of traffic at one or more time periods; determining a head room needed for handling the burst of traffic from the first application; determining that one or more existing instance of the tunnel is capable of handling the head room prior to removing the tunnel. 10. The method of claim 1, further comprising: initiating an automatic set up of a tunnel for communication between the first site and the second site; selecting the devices at the first site and the second site which will form respective connection points for a site-to-site connection; receiving input settings for use in connecting the selected devices at the first site and the second site; and causing the site-to-site connection to be created between one or more network sites using the settings, wherein the site-to-site connection is a tunnel between the selected devices at the first site and the second site. 1. A method comprising: receiving a first input at a user interface to initiate an automatic set up of tunnel for communication between a first site and a second site; receiving second inputs in the user interface to select devices populated in a list for selection, wherein the second inputs are effective in selecting the devices at the first site and the second site which will form respective connection points for a site-to-site connection, wherein the devices are routers or gateways to which a respective router is associated; receiving third inputs in the user interface, wherein the third inputs are effective to input settings for use in connecting the selected devices at the first site and the second site; causing the site-to-site connection to be created between one or more network sites using the settings, wherein the site-to-site connection is a tunnel between the selected devices at the first and second sites, wherein the creating the site-to-site connection includes interacting with the first site using first site-specific protocols and configurations and interacting with the second site using second site-specific protocols and the configurations. As to claims 11-20, the claims are similar in scope to claims 1-10, and they are rejected under the same rationale. Claims 1-20 would be allowable upon receiving an approved terminal disclaimer. The closet prior art. US11245627 (Zhang et al.) teaches the status of the second tunnel further includes a delay of the second tunnel, and the status of the first tunnel further includes a delay of the first tunnel. Determining whether the status of the first tunnel and the status of the second tunnel meet a backoff condition includes determining, by the HAAP, whether a difference between the delay of the second tunnel and the delay of the first tunnel is less than a fourth threshold. The fourth threshold is a threshold corresponding to the difference between the delay of the second tunnel and the delay of the first tunnel. If the difference between the delay of the second tunnel and the delay of the first tunnel is less than the fourth threshold, the HAAP determines that the status of the first tunnel and the status of the second tunnel meet the backoff condition. The prior art. US20190208473 (LIU) teaches a base station supports the terminal in transmitting data by using the second tunnel when the terminal is in a connected state the terminal is currently not synchronized with the base station, and to-be-transmitted data is less than the preset threshold, selecting, by the terminal, the second tunnel to transmit the to-be-transmitted data; or when the terminal is in a connected state and is currently synchronized with a base station and to-be-transmitted data is less than the preset threshold, selecting, by the terminal, the second tunnel to transmit the to-be-transmitted data. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Moustafa M Meky whose telephone number is (571)272-4005. The examiner can normally be reached Monday-Friday 9AM-5PM. 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, Ario Etienne can be reached at 571-272-4001. 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. MOUSTAFA M. MEKY Primary Patent Examiner Art Unit 2457 /MOUSTAFA M MEKY/Primary Examiner, Art Unit 2457 10/14/2026
Read full office action

Prosecution Timeline

Aug 25, 2025
Application Filed
Oct 16, 2026
Non-Final Rejection mailed — §DOUBLEPATENT (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12771754
PEER-TO-PEER MOBILE CHARGING SERVICE NETWORK
2y 1m to grant Granted Oct 20, 2026
Patent 12771653
SYSTEMS AND METHODS FOR MITIGATING LATENCY ISSUES BETWEEN CLOUD COMPUTING COMPONENTS FEATURING RELATIONAL DATABASES WITHOUT REQUIRING SESSION PERSISTENCE USING STATE-SPECIFIC COMMUNICATION REFERENCE DIRECTORIES
1y 10m to grant Granted Oct 20, 2026
Patent 12764043
AUTOMATED TICKET CREATION AND ASSIGNMENT FOR CLOUD-BASED APPLICATIONS
1y 10m to grant Granted Oct 13, 2026
Patent 12755256
SYSTEM, METHOD, AND APPLICATION FOR EXCHANGING CONTENT IN A SOCIAL NETWORK ENVIRONMENT
1y 8m to grant Granted Oct 06, 2026
Patent 12739309
USAGE-BASED NETWORK CONNECTION MANAGEMENT
1y 11m to grant Granted Sep 15, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
94%
Grant Probability
99%
With Interview (+5.2%)
2y 3m (~1y 1m remaining)
Median Time to Grant
Low
PTA Risk
Based on 736 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month