Prosecution Insights
Last updated: April 19, 2026
Application No. 16/044,307

SYSTEM AND METHOD FOR ENABLING VPN-LESS SESSION SETUP FOR CONNECTING MOBILE DATA DEVICES TO AN ENTERPRISE DATA NETWORK

Non-Final OA §103§112
Filed
Jul 24, 2018
Examiner
LINDENBAUM, ALAN LOUIS
Art Unit
2413
Tech Center
2400 — Computer Networks
Assignee
Tango Networks Inc.
OA Round
8 (Non-Final)
48%
Grant Probability
Moderate
8-9
OA Rounds
3y 7m
To Grant
64%
With Interview

Examiner Intelligence

Grants 48% of resolved cases
48%
Career Allow Rate
204 granted / 421 resolved
-9.5% vs TC avg
Strong +16% interview lift
Without
With
+15.8%
Interview Lift
resolved cases with interview
Typical timeline
3y 7m
Avg Prosecution
69 currently pending
Career history
490
Total Applications
across all art units

Statute-Specific Performance

§101
2.2%
-37.8% vs TC avg
§103
56.7%
+16.7% vs TC avg
§102
20.4%
-19.6% vs TC avg
§112
17.5%
-22.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 421 resolved cases

Office Action

§103 §112
Notice of Pre-AIA or AIA Status The present application is being examined under the pre-AIA first to invent provisions. Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. Claims 1, 8 and 14 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 1 recites “Identifying … an enterprise network based on routing information comprising a pilot directory number (DN).” This limitation is not disclosed in Applicant’s original Specification. Applicant’s original Specification does not disclose that an enterprise network is identified based on a pilot DN. Claim 1 recites “implementing a first set of functions via the first component, wherein the first set of functions controls roaming and handoff in the carrier network, and provides the carrier network with mobility management that allows the carrier network to track a location of the mobile terminal.” This limitation is not disclosed in Applicant’s original Specification. Applicant asserts that the limitation is disclosed by a combination of paragraphs [0004] and [0029] and [00031]. However, paragraphs [0004] and [0029] and [00031] disclose conflicting embodiments. Paragraph [0004] deals with an embodiment where GGSN functions are not split between the carrier network and enterprise network, while paragraphs[0029] and [0031] deals with the disclosed invention where GGSN functions are split between the carrier network and enterprise network. Applicant’s original Specification does not disclose that roaming and handoff and mobility are handled by the carrier network when GGSN functions are split between the carrier network and enterprise network. Claims 8 and 14 are rejected for substantially the same reason as claim 1. Claim Rejections - 35 USC § 103 The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action: (a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived 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 pre-AIA 35 U.S.C. 103(a) 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. Claims 1, 3, 5, 7-8, 10, 12, 14, 16, 18 and 20 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Feather et al. (US 2004/0081173) in view of Amara et al. (US 2004/0083295), and further in view of Furukawa et al. (US 2002/0009073), and further in view of Madour et al. (USPN 6,904,025). Regarding claim 1, Feather discloses a method, comprising: identifying, by a first component, of a Gateway GPRS Support Node (GGSN) in a gateway server of a carrier network (Feather, Fig. 1, Border Gateway 20 [first component] in operator network 18; paragraph [0015], request identifying enterprise network; paragraph [0017], using GPRS proxy protocols, the border gateway 20 can receive and forward network access request and other appropriate information to enterprise network gateway 22; paragraph [0020]), an enterprise network based on routing information provisioned for a subscriber to the enterprise network (Feather, Fig. 1, Enterprise Gateway 22 in enterprise network 14; paragraph [0015], request identifying enterprise network; paragraph [0016], access request uses information from the mobile device 12; paragraph [0020]; paragraph [0027], mapping information maps operator configuration information to enterprise network domain names identifying various enterprise gateways); forwarding, by the first component, a request to invoke a data session issued by a mobile terminal, corresponding to the subscriber, to a second component of the GGSN deployed in an enterprise gateway server of the enterprise network (Feather, Fig. 1; paragraphs [0013]-[0015], Operator network 18 receives the requests via Radio access network 16 generated by mobile nodes 12 where RAN 16 provides service for voice and data access to mobile node 12 communicating with RAN 16 and mobile node 12 support wireless communications to provide voice and/or data service where operator network 18 support GPRS protocol and serving node 26 acts as a serving GPRS support node (SGSN); paragraph [0016], access request uses information from the mobile device 12; paragraph [0017,] border gateway 20 forwards network access requests to enterprise gateway 22 [second component]; the Examiner interprets border gateway 20 [first component] and enterprise gateway 22 [second component] to be components of a single gateway server, as was affirmed by the PTAB decision issued for the present application on November 10, 2022, and as components of a single GGSN [Gateway GPRS Support Node] for the same reasons as discussed by the PTAB and by the Examiner with regard to the term “gateway server”), implementing a first set of functions via the first component, wherein the first set of functions controls roaming and handoff in the carrier network, and provides the carrier network with mobility management that allows the carrier network to track a location of the mobile terminal (Feather, Fig. 1, border gateway 20 and enterprise gateway 22; paragraph [0002], GPRS gateways within operator networks provide access to data networks; paragraph [0012], provides access to one or more enterprise networks; paragraph [0019], gateway 22 provides GPRS node services; paragraph [0020], enterprise gateway 22 may communicate with border gateway 20 over secure fixed line 30. Determining the address for border gateway 20 may include transmitting a message directly to border gateway 20 using fixed line 30 to request the address from the border gateway 20; paragraph [0021], a secure link may be established between the enterprise gateway 22 and border gateway 20 which can be refer to as establishing a secure tunnel between the first gateway and the second gateway server; paragraph [0023], Upon receiving the network access request, operator network 18 performs initial processing of the request and determines that enterprise gateway 22 is configured to provide access to enterprise network 14. The Operator network 18 transmits the network access request to enterprise gateway 22. In response to the request, enterprise gateway 22 and serving node 26 may form a communication channel or tunnel for transporting packets communicated between mobile node 12 and one or more elements within enterprise network 14; paragraph [0032], the modules and functionalities described may be combined, separated, or otherwise distributed among any suitable functional components), and implementing a second set of functions via the second component, wherein the second set of functions implements security and encryption specific to requirements of the enterprise network (Feather, Fig. 1, border gateway 20 and enterprise gateway 22; paragraph [0019], gateway 22 provides GPRS node services; paragraph [0023], Upon receiving the network access request, operator network 18 performs initial processing of the request and determines that enterprise gateway 22 is configured to provide access to enterprise network 14. The Operator network 18 transmits the network access request to enterprise gateway 22. In response to the request, enterprise gateway 22 and serving node 26 may form a communication channel or tunnel for transporting packets communicated between mobile node 12 and one or more elements within enterprise network 14; Paragraph [0020], enterprise gateway 22 may communicate with border gateway 20 over secure fixed line 30. Determining the address for border gateway 20 may include transmitting a message directly to border gateway 20 using fixed line 30 to request the address from the border gateway 20; paragraph [0021], a secure link may be established between the enterprise gateway 22 and border gateway 20 which can be refer to as establishing a secure tunnel between the first gateway and the second gateway server; paragraph [0040], enterprise gateway 22 performs authentication, security protocol, encryption; paragraph [0042], the modules and functionalities described may be combined, separated, or otherwise distributed among any suitable functional components) and automatically provisions the routing information to the first component to enable the first component to enable service to the subscriber (Feather, Fig. 1, border gateway 20 and enterprise gateway 22; paragraph [0004], enterprise network determines IP address that identifies the interface of the enterprise gateway, an enterprise domain name and an address for a border gateway within an operator network and communicates the information to the border gateway in a configuration request; paragraph [0031], border gateway 20 supports billing features to enable operator network to reconcile accounts for mobile nodes); connecting the first set of functions with a Serving GPRS Support Node (SGSN) in the carrier network (Feather, Fig. 1, border gateway 20 and serving node 26; paragraph [0015,] serving node 26 forwards the request to border gateway 20); and transmitting, by the first component, data of the data session to the enterprise network via a tunnel (Feather, paragraph [0023], Upon receiving the network access request, operator network 18 performs initial processing of the request and determines that enterprise gateway 22 is configured to provide access to enterprise network 14. The Operator network 18 transmits the network access request to enterprise gateway 22. In response to the request, enterprise gateway 22 and serving node 26 may form a communication channel or tunnel for transporting packets communicated between mobile node 12 and one or more elements within enterprise network 14). In order to expedite prosecution, the Examiner additionally includes the Amara reference. Amara discloses implementing a second set of functions via the second component, wherein the second set of functions are carried out in the enterprise network and implement security and encryption specific to requirements of the enterprise network, and automatically provisions information to the first component to enable the first component to enable service to the subscriber (Amara, Fig. 1 and Abstract, paragraphs [0039], [0041], [0049]-[0050], initiating security gateway may be in communication with the home agent i.e., refer to as the first gateway in data network, and a terminating security gateway 180 i.e., second gateway which is inside a receiving network 170 which may be a corporate LAN that is accessible from network backbone 120 (paragraph [0048]) may be in communication with the initiating security gateway via a tunnel (e.g., Internet Protocol in Internet Protocol (IP-in-IP) or Internet Protocol security (IPsec) tunnel) i.e., establishing a secure tunnel between the first gateway server and the second gateway server. Further, a virtual local area network (VLAN) tag associated with the user session may map to a selector operable in a security policy database. The selector may be used to find a security policy defining an IPsec procedure and the security policy may be applied to the tunnel i.e., the secure tunnel supports selectable security and encryption specific to requirements of the enterprise network). It would be obvious for one having ordinary skill in the art at the time the invention was made to modify the method of Feather with the method of Amara. The motivation would have been to extend the network connectivity of LANs beyond their physical limits while reducing cost and simplifying network topology (See Amara Paragraph [0003]). Feather does not explicitly disclose that routing information comprises a pilot directory number (DN) provisioned for a subscriber to the enterprise network. Furukawa discloses Identifying an enterprise network based on routing information comprising a pilot directory number (DN) provisioned for a subscriber to the enterprise network (Furukawa, paragraph [0707], telephone number indicates a pilot telephone number; paragraph [0887], when a telephone number is indicated, an IP address of a gateway having the telephone number is responded). It would be obvious for one having ordinary skill in the art, at the time the invention was made, to identify an enterprise network based on a pilot DN, in the invention of Feather. The motivation would have been to efficiently perform routing of connections to the correct enterprise gateway. Madour discloses implementing a first set of functions via the first component of a gateway server of a carrier network, wherein the first set of functions controls roaming and handoff in the carrier network, and provides the carrier network with mobility management that allows the carrier network to track a location of the mobile terminal (Madour, column 3, lines 2-20, roaming is provided at the GPRS gateway level by allowing a request for handover resources; column 3, lines 32-35, UE roams from a first routing area to a second routing area; column 6, lines 18-36, location update request). It would be obvious for one having ordinary skill in the art, at the time the invention was made, for a gateway of the carrier network to provide the carrier network with functions controls roaming and handoff and mobility management that allows the carrier network to track a location of the mobile terminal, in the invention of Feather. The motivation would have been to perform cellular communication according to common wireless standards. Regarding claim 3, Feather in view of Amara, and further in view of Furukawa, and further in view of Madour discloses the method of claim 1, further comprising: invoking the data session without a virtual private network client operating on the mobile terminal (Feather, Fig. 1; paragraph [0023], in response to the request, enterprise gateway 22 forms a tunnel with serving node 25. The data sessions of Feather are invoked without a VPN). Regarding claim 5, Feather in view of Amara, and further in view of Furukawa, and further in view of Madour discloses the method of claim 1, wherein the establishing the tunnel further comprises: automatically establishing the tunnel based on receipt of the request by the first component (Feather, Fig. 1; paragraph [0023], in response to the request, enterprise gateway 22 forms a tunnel with serving node 25). Regarding claim 7, Feather in view of Amara, and further in view of Furukawa, and further in view of Madour discloses the method of claim 1, further comprising implementing the security and encryption via the second set of functions (Amara, Fig. 1 and Abstract, Paragraphs [0041], [0049]-[0050], initiating security gateway may be in communication with the home agent i.e., refer to as the first gateway in data network, and a terminating security gateway 180 i.e., second gateway which is inside a receiving network 170 which may be a corporate LAN that is accessible from network backbone 120 (Para 48) may be in communication with the initiating security gateway via a tunnel (e.g., Internet Protocol in Internet Protocol (IP-in-IP) or Internet Protocol security (IPsec) tunnel) i.e., establishing a secure tunnel between the first gateway server and the second gateway server. Further, a virtual local area network (VLAN) tag associated with the user session may map to a selector operable in a security policy database. The selector may be used to find a security policy defining an IPsec procedure and the security policy may be applied to the tunnel i.e., the secure tunnel supports selectable security and encryption specific to requirements of the enterprise network. It would be obvious for one having ordinary skill in the art at the time the invention was made to modify the method of Feather with the method of Amara. The motivation would have been to extend the network connectivity of LANs beyond their physical limits while reducing cost and simplifying network topology (See Amara Para 3). Claims 8,10 and 12 are rejected under substantially the same rationale as claims 1, 3 and 5, respectively. Claims 14, 16, 18 and 20 are rejected under substantially the same rationale as claims 1, 3, 5 and 7, respectively. Claims 4, 11 and 17 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Feather in view of Amara, and further in view of Furukawa, and further in view of Madour, and further in view of Gage et al. (US 2004/0151136). Regarding claim 4, Feather in view of Amara, and further in view of Furukawa, and further in view of Madour discloses the method of claim 1. Amara discloses routing the data session through the enterprise network without an interaction with an originating party (Amara; Fig. 9 and Para 86, the packet may be forwarded to the IPsec module 148, which may initiate IPsec-procedures on the packet. The IPsec module 148 may initiate an IPsec tunnel between the initiating security gateway 140 and the terminating security gateway 180a in order to forward the packet to the network domain 172a. No interaction with an originating party is required in the method disclosed in Fig. 9). It would be obvious for one having ordinary skill in the art at the time the invention was made to modify the method of Feather with the method of Amara. The motivation would have been to extend the network connectivity of LANs beyond their physical limits while reducing cost and simplifying network topology (See Amara Para 3). Feather and Amara do not explicitly disclose wherein the data is transmitted through a firewall of the network to a destination outside the enterprise network. Gage discloses wherein the transmitting of the data further comprises: transmitting the data through a firewall of the network to a destination outside the network (Fig. 3 and Para 28-30) the MCL 320 in the wireless device 302 is configured to select one wireless communication protocol as a "preferred" interface for current communications. The wireless device is within a given geographic region, and the available links comprise more than one protocol, such as an 802.11 link 304A and a CDMA link 304C, then the MCL 320 determines the quality of each link and selects one as the preferred interface or link to the Destination Host 310. The link is selected based on predetermined criteria and can also be read as selectable security. The "preferred" interface, as used herein, does not necessarily indicate the best link or some other measure of link quality on an absolute basis, but rather represents the "selected" available interface in accordance with the aforementioned criteria. The preferred interface can also be selected based on criteria other than the link quality, such as maximum connection speed, cost, or priority of the link as compared with others. Further, transmitting data of the data session from the control center to the destination host via a firewall. It would have been obvious to one having ordinary skill in the art, at the time the invention was made, for data of the data session in Feather to be transmitted through a firewall of the enterprise network to a destination outside the enterprise network, as in Gage. The motivation would have been to provide efficient roaming between various communication protocol without repeated terminations and re-establishment of the network connection (See Paragraph 8). Claims 11 and 17 are rejected under substantially the same rationale as claim 4. Response to Arguments Applicant's arguments filed October 8, 2025 have been fully considered but they are not persuasive or are moot in view of the new grounds of rejection. Applicant asserts that the limitation is disclosed by a combination of paragraphs [0004] and [0029] and [00031]. However, paragraphs [0004] and [0029] and [00031] disclose conflicting embodiments. Paragraph [0004] deals with an embodiment where GGSN functions are not split between the carrier network and enterprise network, while paragraphs[0029] and [0031] deals with the disclosed invention where GGSN functions are split between the carrier network and enterprise network. Applicant’s original Specification does not disclose that roaming and handoff and mobility are handled by the carrier network when GGSN functions are split between the carrier network and enterprise network. Further, Applicant’s assertion that a disclosure of a carrier network with no connectivity to enterprise network means that all network functionality, such as handoff and mobility and roaming functionality, occurs on the carrier network gateway, is treated as prosecution history estoppel for the purposes of interpreting the Examiner’s cited references. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAN LOUIS LINDENBAUM whose telephone number is (571)270-3858. The examiner can normally be reached on Monday through Friday 9:00 AM to 5:00 PM EST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Faruk Hamza can be reached on (571) 272-7969. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /ALAN L LINDENBAUM/Examiner, Art Unit 2466 /FARUK HAMZA/Supervisory Patent Examiner, Art Unit 2466
Read full office action

Prosecution Timeline

Jul 24, 2018
Application Filed
Feb 03, 2020
Non-Final Rejection — §103, §112
May 26, 2020
Response Filed
Jul 30, 2020
Final Rejection — §103, §112
Oct 05, 2020
Response after Non-Final Action
Oct 26, 2020
Request for Continued Examination
Nov 01, 2020
Response after Non-Final Action
Dec 17, 2020
Non-Final Rejection — §103, §112
Mar 23, 2021
Response Filed
Apr 09, 2021
Final Rejection — §103, §112
Jun 14, 2021
Notice of Allowance
Jun 14, 2021
Response after Non-Final Action
Jul 16, 2021
Response after Non-Final Action
Aug 23, 2021
Response after Non-Final Action
Sep 07, 2021
Response after Non-Final Action
Oct 23, 2021
Response after Non-Final Action
Dec 26, 2021
Response after Non-Final Action
Dec 28, 2021
Response after Non-Final Action
Dec 29, 2021
Response after Non-Final Action
Dec 29, 2021
Response after Non-Final Action
Nov 08, 2022
Response after Non-Final Action
Dec 13, 2022
Applicant Interview (Telephonic)
Dec 13, 2022
Examiner Interview Summary
Jan 10, 2023
Request for Continued Examination
Jan 15, 2023
Response after Non-Final Action
Feb 27, 2023
Non-Final Rejection — §103, §112
Jun 09, 2023
Response Filed
Jun 29, 2023
Final Rejection — §103, §112
Sep 05, 2023
Response after Non-Final Action
Oct 18, 2023
Applicant Interview (Telephonic)
Oct 18, 2023
Examiner Interview Summary
Oct 25, 2023
Request for Continued Examination
Oct 27, 2023
Response after Non-Final Action
Dec 19, 2023
Non-Final Rejection — §103, §112
Mar 28, 2024
Notice of Allowance
Mar 28, 2024
Response after Non-Final Action
Apr 11, 2024
Response after Non-Final Action
May 30, 2024
Response after Non-Final Action
Aug 12, 2024
Response after Non-Final Action
Aug 14, 2024
Response after Non-Final Action
Aug 15, 2024
Response after Non-Final Action
Aug 15, 2024
Response after Non-Final Action
Sep 09, 2025
Response after Non-Final Action
Oct 06, 2025
Examiner Interview Summary
Oct 06, 2025
Applicant Interview (Telephonic)
Oct 08, 2025
Request for Continued Examination
Oct 17, 2025
Response after Non-Final Action
Dec 03, 2025
Non-Final Rejection — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12603845
Device-Assisted Services for Protecting Network Capacity
2y 5m to grant Granted Apr 14, 2026
Patent 12557092
Data Scheduling in High Frequency
2y 5m to grant Granted Feb 17, 2026
Patent 12526661
Radio Link Monitoring for Sidelink Communications
2y 5m to grant Granted Jan 13, 2026
Patent 12483974
METHOD AND APPARATUS FOR REDUCED CAPABILITY TERMINAL TO ACCESS A CELL IN MOBILE WIRELESS COMMUNICATION SYSTEM
2y 5m to grant Granted Nov 25, 2025
Patent 12396051
METHOD AND APPARATUS FOR FAILURE RECOVERY IN WIRELESS COMMUNICATION SYSTEM
2y 5m to grant Granted Aug 19, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

8-9
Expected OA Rounds
48%
Grant Probability
64%
With Interview (+15.8%)
3y 7m
Median Time to Grant
High
PTA Risk
Based on 421 resolved cases by this examiner. Grant probability derived from career allow 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