Prosecution Insights
Last updated: October 04, 2026
Application No. 18/829,901

METHOD AND APPARATUS FOR INTER-COMMUNICATION BETWEEN LAYER 2 AND LAYER 3 VPNS

Final Rejection §103
Filed
Sep 10, 2024
Priority
Sep 22, 2023 — CN 202311236323.6
Examiner
RECEK, JASON D
Art Unit
2458
Tech Center
2400 — Computer Networks
Assignee
New H3C Technologies Co., Ltd.
OA Round
2 (Final)
71%
Grant Probability
Favorable
3-4
OA Rounds
1y 5m
Est. Remaining
93%
With Interview

Examiner Intelligence

Grants 71% — above average
71%
Career Allowance Rate
527 granted / 743 resolved
+12.9% vs TC avg
Strong +22% interview lift
Without
With
+22.4%
Interview Lift
resolved cases with interview
Typical timeline
3y 6m
Avg Prosecution
25 currently pending
Career history
771
Total Applications
across all art units

Statute-Specific Performance

§101
10.4%
-29.6% vs TC avg
§103
55.9%
+15.9% vs TC avg
§102
12.8%
-27.2% vs TC avg
§112
13.7%
-26.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 743 resolved cases

Office Action

§103
DETAILED ACTION This is in response to the amendment filed on July 7th 2026. Response to Arguments Applicant’s arguments, see pg. 8, filed 7/7/26, with respect to the claim objection have been fully considered and are persuasive. The objection of claims 1 and 6 has been withdrawn. Applicant's arguments, pg. 8-14, have been fully considered but they are not persuasive. Applicant asserts the features of the claim achieve inter-switching “without using a loopback solution” and thereby “solving the bandwidth limitation of a loopback port” and “avoiding additional occupation of physical interfaces of the PE” (pg. 10). In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., all the features in quotes) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. Applicant argues (pg. 10-11) the PE of Bickhart cannot be the PE of the claims because of the specific interface structure (i.e. 2 physical and 2 logical interfaces). This is not persuasive. Bickhart clearly discloses the PE supports communication between network layer 2 and layer 3 (abstract). Bickhart explicitly discloses the PE has physical interfaces and logical interfaces to support this (paragraphs 44, 56, Fig. 1). There is no teaching that these interfaces “are multiplexed on a same interface”, as suggested by applicant. In fact, examiner could not find a single instance of the term “multiplex” in the reference. Therefore, this argument is not persuasive because applicant is mischaracterizing the reference, and because Bickhart explicitly teaches the plurality of physical and logical interfaces recited by the claim as explained above. Applicant argues “feature B” (pg. 11) using the same logic – that Bickart does not have a physical interface. This is not persuasive for the same reasons. Bickhart explicitly discloses a plurality of links and interface cards which represent “physical interfaces” (see paragraph 56, Fig. 2). Applicant also states that Bickart snoops ARP messages and thus is only a passive process and not an active process. This is also not persuasive. First, examiner disagrees with the characterization that snooping is passive. Snooping data involves capturing and analyzing data. This is not a passive process as suggested by applicant. Even assuming arguendo, the claims are silent regarding passive vs. active. Thus by arguing the claims are active while Bickhart is passive, applicant is again relying on features not in the claims. Regarding “feature C” and “feature D”, applicant presents the same arguments (pg. 12). These are again not persuasive for the same reasons. Bickhart is silent regarding “multiplexed” logical interfaces as suggested by applicant. In fact, Bickhart explicitly discloses an interfaces table that includes corresponding entry for each logical interface (paragraph 70, emphasis added). Applicant discusses the Hao reference (pg. 13-14) and submits it does not cure the deficiencies because it does not teach the claimed PE interface architecture. This is not persuasive because Hao was not relied upon for these features. As explained above, Bickhart discloses the PE with different physical and logical interfaces. Applicant does not appear to dispute what Hao was relied upon for teaching. Claim Rejections - 35 USC § 103 The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action. Claim(s) 1-3, 5-8, 10-13, 15-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bickhart et al. US 2017/0373973 A1 in view of Hao et al. US 2016/0359745 A1. Regarding claim 1, Bickhart discloses: a method for inter-communication between Layer 2 [VPN] and Layer 3 [networks] (provide bridge between L2 and L3 networks using VPN – see abstract, paragraphs 2-3, Fig. 1), applied to a Provider Edge- Aggregation (PE-AGG) equipment comprising a physical interface of a pseudo wire (PW) of L2 VPN, a physical interface of a public network of L3 VPN, a L2 Virtual Ethernet logical interface, and a L3 VE logical interface (provider edge “PE” equipment has physical/logical interfaces and facilitates forwarding between different networks – see abstract, paragraphs 3, 5, Fig. 1 and paragraphs 55-56, Fig. 2) , wherein the method comprises: sending an address resolution protocol (ARP) request packet to a central processing unit, wherein the ARP request packet requesting a media access control (MAC) address of the L3 VE logical interface by a target user is received through the physical interface of the PW (use ARP – paragraph 47, ARP is used by the learning module to discover MAC address information – see paragraphs 66 and 70; method is performed using a processor – paragraphs 11, 57-58 and Fig. 2); learning a target ARP table entry corresponding to the ARP request packet on the L3 VE logical interface (use ARP – paragraphs 47, 70), wherein a MAC address comprised in the target ARP table entry is a MAC address of the target user, an outgoing interface comprised in the target ARP table entry is the L2 VE logical interface, and the target ARP table entry is used to indicate traffic forwarding from the target user's L3 [network] to L2 VPN (store MAC address information in a table – paragraph 31; also see Fig. 2, paragraphs 62 and 66 which teaches storing forwarding information in tables; this information is used to “learn” MAC address info for forwarding packets); feeding back an ARP response to the target user comprising the MAC address of the L3 VE logical interface (use ARP to “learn” – paragraphs 47, 70; use learned MAC address to forward traffic – paragraphs 7-8, including which specific interface corresponds to the MAC address – paragraphs 31-33, 54 and 67). Bickhart does not explicitly disclose a L3 VPN but this is taught by Hao (L3 VPN – see paragraphs 11, 29 and 43). Hao also discloses interconnecting a plurality of VPNs (Figs. 1-3, paragraphs 29 and 44) and using ARP requests/reply packets (paragraph 47). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bickhart with the techniques taught by Hao, including a layer 3 VPN, for the purpose of interconnecting VPN traffic. Hao explicitly teaches this provides more efficient packet forwarding for VPNs (paragraphs 5, 12 and 42). Regarding claim 2, Bickhart discloses obtaining an original packet … L2 VPN packet received through the L2 VE interface, wherein a destination MAC address of the original packet is the MAC address of the L3 VE logical interface (connect L2 VPN with L3 network as explained above, lookup MAC address information for packets – abstract, paragraphs 2-3, 31, 47 and Figs. 1-3); sending the original packet to the L3 VE logical interface based on the destination MAC address of the original packet (VPN has logical interfaces, route to MAC address associated with interface – paragraphs 31-33, 54); performing a routing lookup (lookup – paragraph 54), implementing an … encapsulation on the original packet through the L3 VE logical interface, and forwarding an encapsulated L3 … packet through the physical interface of the public network of L3 [network] (encapsulate packets to transmit between L2 and L3 networks – see paragraph 3). Bickhart does not explicitly disclose “terminating a L2 VPN packet” but this is taught by Hao (perform layer 2 termination – paragraphs 7, 52, Fig. 4). Hao also discloses performing encapsulation and decapsulation of packets to forward between different network layers (abstract, paragraphs 4, 7, Fig. 4). This is routine and conventional network operation. Hao also discloses a L3 VPN as discussed above. The motivation to combine is the same. Regarding claim 3, Bickhart discloses obtaining an original packet … L3 [network] packet received through the L3 VE logical interface (receive layer 3 network packets – paragraphs 2-3, Fig. 1); looking up an ARP table based on a destination IP address of the original packet to obtain a target MAC address corresponding to the destination IP address of the original packet (use ARP to lookup/learn MAC address and IP address binding – Fig. 3, paragraphs 47, 66); replacing the destination MAC address of the original packet with the target MAC address, to obtain a packet with the replaced MAC address (replace header information – paragraph 54; use learned MAC address from table to forward data – paragraphs 31-33); implementing a L2 VPN encapsulation on the packet (perform encapsulation – paragraph 3) with the replaced MAC address through the L2 VE logical interface, and forwarding an encapsulated L2 VPN packet through the physical interface of the PW of L2 VPN (forward/bridge packets over L2 VPN using corresponding interfaces – abstract, paragraphs 2-3, Figs. 1-3; also see paragraphs 31 and 53-56 regarding the interface). Bickhart does not explicitly disclose decapsulating a L3 VPN but encapsulation/decapsulation is convention and routine network behavior that is extremely well-known in the prior art. Hao explicitly disclose a L3 VPN as explained above and performing decapsulation (paragraph 8, Fig. 2, paragraph 55). The motivation to combine is the same. Regarding claim 5, it is identical to claim 3; thus it is rejected for the same reasons. Regarding claims 6-8 and 10, they are apparatus claims interpreted under 112(f) that directly correspond to the method of claims 1-3 and 5 respectively. Since the combination of Bickhart and Hao discloses the equivalent hardware (see Fig. 2 and paragraph 57 and Bickhart; and Fig. 13, paragraph 121 of Hao), the claims are rejected for the same reasons. Regarding claims 11-13 and 15, they are apparatus claims that recite a memory and processor to perform the method of claims 1-3 and 5 respectively. This is also taught by Bickhart (Fig. 2, paragraph 57) and Hao (Fig. 13, paragraph 121). Therefore, the claims are rejected for the same reasons. Regarding claims 16-18 and 20, they are “non-transitory” computer readable medium claims that correspond to the method of claims 1-3 and 5 respectively. Therefore, they are rejected for the same reasons given above. Claim(s) 4, 9, 14 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bickhart and Hao in view of Mohanty et al. US 2022/0255835 A1. Regarding claims 4, 9, 14 and 19, Bickhart discloses the outgoing interfaces of the target ARP are multiple L2 VE logical interfaces (multiple interfaces/ports connect virtual/logical networks – see paragraph 56, Fig. 2); determining a target PW for transmitting traffic to which the L3 [network] packet belongs (lookup interface in table – paragraph 31, also see rejections above); replacing the destination MAC address of the original packet with the target MAC address (replace header information – paragraph 54; use learned MAC address from table to forward data – paragraphs 31-33) and encapsulating a private network label of the target PW (encapsulation – paragraph 3); obtaining the encapsulated L2 VPN packet by encapsulating a public network label of the target PW through a second-level … encapsulation to L2 VPN (encapsulation/decapsulation of packets is conventional and routine network behavior as explained above; the process happens multiple times between layers, thus there is a “first level”, “second level”, etc. encapsulation process). Bickhart also discloses the corresponding hardware recited by the apparatus claims (see Fig. 2, paragraph 57). Bickhart does not explicitly disclose the L3 VPN but this is taught by Hao as explained above. The motivation to combine is the same. The combination of Bickhart and Hao does not explicitly disclose in response to determining the PW is a primary or a secondary PW or an ECMP equivalent multi-path route; or a first-level Forwarding Equivalence Class (FEC) encapsulation based on the ECMP. However, ECMP, or equal cost multipath routing is very well-known in the art, as is FEC in the context of MPLS. Mohanty teaches using both ECMP and FEC for VPN communication (abstract, paragraphs 2, 9 and 51). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Bickhart and Hao with to use ECMP and FEC as taught by Mohanty. This is merely the combination of a well-known technique according to its established function in order to yield a predictable result. Furthermore, Mohanty suggest specific advantages (paragraphs 13, 51). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Moreno et al. US 2022/0029915 A1 discloses a method for forwarding data between different virtual private networks (abstract) including layer 2 and layer 3 VPNs (paragraph 2), encapsulation/decapsulation for layer 2 network data (Fig. 5), and MAC address table lookup (paragraph 80). THIS ACTION IS MADE FINAL. 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 JASON D RECEK whose telephone number is (571)270-1975. The examiner can normally be reached Flex M-F 9-5. 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 at 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 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. /JASON D RECEK/Primary Examiner, Art Unit 2458
Read full office action

Prosecution Timeline

Sep 10, 2024
Application Filed
Apr 08, 2026
Non-Final Rejection mailed — §103
Jul 07, 2026
Response Filed
Sep 17, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12726427
CARBON FOOTPRINT-BASED ROUTING OF A PACKET
2y 2m to grant Granted Sep 01, 2026
Patent 12720455
CLOCK CALIBRATION USING SINE WAVES
2y 3m to grant Granted Aug 25, 2026
Patent 12712831
SYSTEM AND METHOD FOR IMPLEMENTING CLIENT SERVICE ASPECT OF ENTERPRISE
3y 2m to grant Granted Aug 18, 2026
Patent 12706962
SIGNALING USAGE OF PDU SET AND END OF BURST MARKING FOR COMMUNICATING WEBRTC MEDIA DATA
2y 4m to grant Granted Aug 11, 2026
Patent 12705677
SYSTEMS AND METHODS FOR DETECTING BUILDING EVENTS AND TRENDS
2y 2m to grant Granted Aug 11, 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

3-4
Expected OA Rounds
71%
Grant Probability
93%
With Interview (+22.4%)
3y 6m (~1y 5m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 743 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