Prosecution Insights
Last updated: October 21, 2026
Application No. 19/086,725

BRIDGING WITH WEB MANAGER ACCESS

Non-Final OA §103§DOUBLEPATENT
Filed
Mar 21, 2025
Priority
Nov 25, 2015 — provisional 62/260,139 +2 more
Examiner
NGUYEN, HAO HONG
Art Unit
Tech Center
Assignee
Lantronix Inc.
OA Round
1 (Non-Final)
68%
Grant Probability
Favorable
1-2
OA Rounds
1y 4m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 68% — above average
68%
Career Allowance Rate
212 granted / 314 resolved
+7.5% vs TC avg
Strong +38% interview lift
Without
With
+37.9%
Interview Lift
resolved cases with interview
Typical timeline
2y 11m
Avg Prosecution
27 currently pending
Career history
342
Total Applications
across all art units

Statute-Specific Performance

§101
10.2%
-29.8% vs TC avg
§103
65.1%
+25.1% vs TC avg
§102
13.5%
-26.5% vs TC avg
§112
3.7%
-36.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 314 resolved cases

Office Action

§103 §DOUBLEPATENT
DETAILED ACTION Applicant’s Application filed on March 21, 2025 and July 17, 2025 has been reviewed. Claims 2-20 are newly added in the Preliminary Amendment filed on July 17, 2025. Claim 1 is amended in the Preliminary Amendment. Claims 1-20 have been examined. 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 . 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. Information Disclosure Statement The information disclosure statement (IDS) submitted on January 7, 2026 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Claim Objections Claim 1, 9, 17, 18 and 20 are objected to because of the following informalities: In claim 1, at line 2, “a DHCP server and a DNS server” should be changed to “a dynamic host configuration protocol (DHCP) server and a domain name system (DNS) server”; and at line 9, “an IP address” should be changed to “an Internet protocol (IP) address”. In claim 9, at line 3, “a DHCP server and a DNS server” should be changed to “a dynamic host configuration protocol (DHCP) server and a domain name system (DNS) server”; and at lines 3-4, “an IP address” should be changed to “an Internet protocol (IP) address”. In claim 17, at lines 2-3, “a DHCP client” should be changed to “a dynamic host configuration protocol (DHCP) client”. In claim 18, at line 2, “an IP address” should be changed to “an Internet protocol (IP) address”. In claim 20, at lines 1-2, “a DHCP ACK response” should be changed to “a DHCP acknowledgement (ACK) response”. 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 obviousness-type 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp. Claims 17-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1, 2 and 6 of US Patent No. 11,070,517. Although the conflicting claims are not identical, they are not patentably distinct from each other because the claims 1, 2 and 6 of US Patent No. 11,070,517 are similar to claims 17-20 in present application, the teachings of both applications are directed toward allowing incoming traffic to communicate with the network device and the applications running on the network device . Please see further explanation below. Differences are bolded and omissions are underlined in following comparison tables. Current Application claims 17-20 517’ patent claims 1, 2 and 6 17. A method comprising: determining whether an external device connected to a network device has a DHCP client running; retrieving at least one selected setting of packets sent to the external device if the external device has the DHCP client running; and applying the at least one selected setting to a stack stored in a memory of the network device to configure the network device to provide for communication between applications running on the network device and the external device. 18. The method of claim 17, wherein the at least one selected setting applied to the stack is an IP address associated with the external device. 19. The method of claim 17, further comprising determining whether a link to the external device is up. 20. The method of claim 17, further comprising detecting a DHCP ACK response transmitted to the external device by the network device, wherein the at least one selected setting is retrieved if the DHCP ACK response is detected. 1. A network device, comprising: an access point client having a first DHCP client and a DNS client; and a processor in communication with the access point client, the processor programmed to determine whether a link associated with an external device is connected with the access point client, and if a port address received by the network device is a port address of an application running on the external device, directing a content of a packet to a stack stored in a memory of the network device, wherein the processor is programmed to stop the first DHCP client of the access point client in response to the determination and verification of the external device utilizing a second DHCP client, wherein the processor is programmed to listen for a DHCP ACK response message from the external device in order to stop the first DHCP client, and wherein if the listened DHCP ACK response message is not received via the link to the external device, or if the directed content of the packet having already been applied to the stored stack, the processor is programmed to continue to listen and determine whether at least one of the link and any other link are up, wherein the processor is programmed to apply at least one of the retrieved selected settings to a protocol stack of the network device, wherein the at least one of the selected settings applied to the protocol stack of the network device is an IP address of the external device. 2. The network device of claim 1, wherein the network device is programmed to determine if a link associated with the external device is up. 6. The network device of claim 1, wherein the verification is accomplished via receipt of a DHCP ACK message. TABLE 1 The difference between claim 17 of the current application and claim 1 of the 517’ patent is that the current application retrieving at least one selected setting of packets sent to the external device if the external device has the DHCP client running and the 517’ patent listen for a DHCP ACK response message from the external device in order to stop the first DHCP client. Both the current application and the 517’ patent allowing incoming traffic to communicate with the network device and the applications running on the network device. It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to substitute “retrieving at least one selected setting of packets sent to the external device if the external device has the DHCP client running” with “listen for a DHCP ACK response message from the external device in order to stop the first DHCP client” because the remaining elements would have performed the same function (i.e., allowing incoming traffic to communicate with the network device and the applications running on the network device) as before. Such substitution would not interfere with the functionality of the remaining elements. The difference between claim 17 of the current application and claim 1 of the 517’ patent is that claim 17 of the current application recites the underlined elements as shown in the comparison table above. It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to omit the underlined elements because the person would have realized that the remaining element would perform the same functions as before. “Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before.” See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U. S. Court of Customs and Patent Appeals. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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. 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 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claims 1, 3-7, 9 and 11-15 are rejected under 35 U.S.C. 103 as being unpatentable over Elias et al. (US 2008/0019376 A1), hereinafter referred to as Elias, in view of Sumner (US 2006/0218296 A1). With respect to claim 1, Elias teaches A network device (inline network element 30, para. 0017; fig. 3), comprising: network element (the inline network element 30 comprises a first interface 32 connected to the first network element 12 and a second interface 34 connected to the second network element 14, para. 0017; fig. 3); a processor (processor 36, para. 0017; fig. 3) configured to: analyze incoming traffic received from an external device to determine whether an IP address received from the external device is the IP address of the network element (if the traffic is received from the second interface 34, the method is directed to block 80 wherein the inline network element 30 determines if the destination IP address is equal to the IP1 data 54 and if the destination port number is equal to the PID 64; if at least one of above comparisons fails, which occurs if the traffic comprises a packet 82 directed to block 84 wherein the inline network element 30 passes the traffic to the first interface 32 for communication to the first network element 12, para. 0021; fig. 4), and transmit the traffic to the network device if the received IP address is the IP address of the network element (if both of the above comparisons are true, which occurs if the traffic comprises a packet 86 directed to block 90 wherein the inline network element 30 intercepts and processes the traffic instead of passing the traffic to the first interface 32, para. 0021). Elias does not explicitly teach an access point server having a DHCP server and a DNS server, wherein the access point server is configured to connect to at least one bridged device; and communicate with the access point server, execute one or more applications, and transmit the traffic to a network layer of the network device. However, Sumner teaches an access point server having a DHCP server and a DNS server (the wireless device 102 establishes a connection through the access point 101 being assigned an IP address and the given the IP address of local DNS 105 from DHCP server 109, para. 0025), wherein the access point server is configured to connect to at least one bridged device (the wireless device 102 establishes a connection through the access point 101 being assigned an IP address and the given the IP address of local DNS 105 from DHCP server 109 and becoming a registered address on router list 104, para. 0025); and communicate with the access point server (the wireless device 102 establishes a connection through the access point 101 being assigned an IP address and the given the IP address of local DNS 105 from DHCP server 109 and becoming a registered address on router list 104; once a connection is established the client wireless device 102 make a request for web content 108 from a site that is shadowed on the local network; the request consists of first a DNS request from the client browser on the wireless device 102 for the IP address of a hostname for a website, which is passed, not to the Internet, but to DNS server 105. DNS server 105 examines the hostname to determine if the website is shadowed on the local network and returns the IP address of hypertext transfer protocol (HTTP) server 107 to the wireless device, para. 0025), execute one or more applications (the wireless device 102 establishes a connection through the access point 101 being assigned an IP address and the given the IP address of local DNS 105 from DHCP server 109 and becoming a registered address on router list 104; once a connection is established the client wireless device 102 make a request for web content 108 from a site that is shadowed on the local network; the request consists of first a DNS request from the client browser on the wireless device 102 for the IP address of a hostname for a website, which is passed, not to the Internet, but to DNS server 105. DNS server 105 examines the hostname to determine if the website is shadowed on the local network and returns the IP address of hypertext transfer protocol (HTTP) server 107 to the wireless device, para. 0025), and transmit the traffic to a network layer of the network device (if the IP address points to a process within the appliance, then the entire TCP/IP protocol stack need not be traversed to retrieve the web content, para. 0036) in order to achieve internetworking capabilities as taught by Sumner (para. 0002). Therefore, based on Elias in view of Sumner, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Sumner to the device of Elias in order to achieve internetworking capabilities as taught by Sumner (para. 0002). With respect to claim 3, Elias teaches The network device of claim 1, wherein the traffic is non-broadcast, and has a destination address for the bridged device (the address discovery component 52 causes IP1 data 54 indicating the first IP address of the first network element 12 and IP2 data 56 indicating the second IP address of the second network element 14 to be stored in a memory 60, para. 0018; if at least one of above comparisons fails, which occurs if the traffic comprises a packet 82 directed to block 84 wherein the inline network element 30 passes the traffic to the first interface 32 for communication to the first network element 12 [as unicast/non-broadcast], para. 0021). With respect to claim 4, Elias teaches The network device of claim 1, wherein the processor is configured to transmit the traffic to the bridged device if the received IP address is not the IP address of the access point server (the address discovery component 52 causes IP1 data 54 indicating the first IP address of the first network element 12 and IP2 data 56 indicating the second IP address of the second network element 14 to be stored in a memory 60, para. 0018; if at least one of above comparisons fails, which occurs if the traffic comprises a packet 82 directed to block 84 wherein the inline network element 30 passes the traffic to the first interface 32 for communication to the first network element 12 [as unicast/non-broadcast], para. 0021). With respect to claim 5, Elias in view of Sumner teaches The network device of claim 1 as described above, Further, Sumner teaches wherein the processor is configured to transmit the traffic to a protocol stack of the network device if the received IP address is the IP address of the access point server (if the IP address points to a process within the appliance, then the entire TCP/IP protocol stack need not be traversed to retrieve the web content, para. 0036; wherein the inline network element 30 determines if the destination IP address is equal to the IP1 data 54 and if the destination port number is equal to the PID 64; if at least one of above comparisons fails, which occurs if the traffic comprises a packet 82 directed to block 84 wherein the inline network element 30 passes the traffic to the first interface 32 for communication to the first network element 12, para. 0021; fig. 4) in order to achieve internetworking capabilities as taught by Sumner (para. 0002). Therefore, based on Elias in view of Sumner, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Sumner to the device of Elias in order to achieve internetworking capabilities as taught by Sumner (para. 0002). With respect to claim 6, Elias in view of Sumner teaches The network device of claim 1 as described above, Further, Sumner teaches wherein the processor is configured to transmit the traffic to either of the access point server or an access point client (the wireless device 102 establishes a connection through the access point 101 being assigned an IP address and the given the IP address of local DNS 105 from DHCP server 109 and becoming a registered address on router list 104; once a connection is established the client wireless device 102 make a request for web content 108 from a site that is shadowed on the local network; the request consists of first a DNS request from the client browser on the wireless device 102 for the IP address of a hostname for a website, which is passed, not to the Internet, but to DNS server 105. DNS server 105 examines the hostname to determine if the website is shadowed on the local network and returns the IP address of hypertext transfer protocol (HTTP) server 107 to the wireless device, para. 0025) in order to achieve internetworking capabilities as taught by Sumner (para. 0002). Therefore, based on Elias in view of Sumner, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Sumner to the device of Elias in order to achieve internetworking capabilities as taught by Sumner (para. 0002). With respect to claim 7, Elias in view of Sumner teaches The network device of claim 1 as described above, Further, Sumner teaches wherein the bridged device is configured to negotiate an IP address therefor (a server 109 to assign IP addresses for wireless devices 102, such as dynamic host configuration protocol (DHCP) is an application integral to the wireless access point, which might also be used for other non-integral hosts, para. 0024; fig. 1) in order to achieve internetworking capabilities as taught by Sumner (para. 0002). Therefore, based on Elias in view of Sumner, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Sumner to the device of Elias in order to achieve internetworking capabilities as taught by Sumner (para. 0002). With respect to claim 9, Elias teaches A method comprising: connecting a network element to at least one bridged device (the inline network element 30 comprises a first interface 32 connected to the first network element 12 and a second interface 34 connected to the second network element 14 [bridged device], para. 0017; fig. 3), analyzing incoming traffic received from an external device to determine whether an IP address received from the external device is the IP address of the network element (if the traffic is received from the second interface 34, the method is directed to block 80 wherein the inline network element 30 determines if the destination IP address is equal to the IP1 data 54 and if the destination port number is equal to the PID 64; if at least one of above comparisons fails, which occurs if the traffic comprises a packet 82 directed to block 84 wherein the inline network element 30 passes the traffic to the first interface 32 for communication to the first network element 12, para. 0021; fig. 4); and transmitting the traffic to the network device if the received IP address is the IP address of the network element (if both of the above comparisons are true, which occurs if the traffic comprises a packet 86 directed to block 90 wherein the inline network element 30 intercepts and processes the traffic instead of passing the traffic to the first interface 32, para. 0021). Elias does not explicitly teach connecting an access point server of a network device to at least one bridged device, the access point server having a DHCP server and a DNS server; transmitting the traffic to a network layer of the network device However, Sumner teaches connecting an access point server of a network device to at least one bridged device (the wireless device 102 establishes a connection through the access point 101 being assigned an IP address and the given the IP address of local DNS 105 from DHCP server 109 and becoming a registered address on router list 104, para. 0025), the access point server having a DHCP server and a DNS server (the wireless device 102 establishes a connection through the access point 101 being assigned an IP address and the given the IP address of local DNS 105 from DHCP server 109, para. 0025); transmitting the traffic to a network layer of the network device (if the IP address points to a process within the appliance, then the entire TCP/IP protocol stack need not be traversed to retrieve the web content, para. 0036) in order to achieve internetworking capabilities as taught by Sumner (para. 0002). Therefore, based on Elias in view of Sumner, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Sumner to the method of Elias in order to achieve internetworking capabilities as taught by Sumner (para. 0002). With respect to claim 11, Elias teaches The method of claim 9, wherein the traffic is non-broadcast, having a destination address for a bridged device (the address discovery component 52 causes IP1 data 54 indicating the first IP address of the first network element 12 and IP2 data 56 indicating the second IP address of the second network element 14 to be stored in a memory 60, para. 0018; if at least one of above comparisons fails, which occurs if the traffic comprises a packet 82 directed to block 84 wherein the inline network element 30 passes the traffic to the first interface 32 for communication to the first network element 12 [as unicast/non-broadcast], para. 0021). With respect to claim 12, Elias teaches The method of claim 9, further comprising communicating the traffic to the bridged device if the received IP address is not the IP address of the access point server (the address discovery component 52 causes IP1 data 54 indicating the first IP address of the first network element 12 and IP2 data 56 indicating the second IP address of the second network element 14 to be stored in a memory 60, para. 0018; if at least one of above comparisons fails, which occurs if the traffic comprises a packet 82 directed to block 84 wherein the inline network element 30 passes the traffic to the first interface 32 for communication to the first network element 12 [as unicast/non-broadcast], para. 0021). With respect to claim 13, Elias in view of Sumner teaches The method of claim 9 as described above, Further, Sumner teaches further comprising communicating the traffic to a protocol stack of the network device if the received IP address is the IP address of the access point server (if the IP address points to a process within the appliance, then the entire TCP/IP protocol stack need not be traversed to retrieve the web content, para. 0036; wherein the inline network element 30 determines if the destination IP address is equal to the IP1 data 54 and if the destination port number is equal to the PID 64; if at least one of above comparisons fails, which occurs if the traffic comprises a packet 82 directed to block 84 wherein the inline network element 30 passes the traffic to the first interface 32 for communication to the first network element 12, para. 0021; fig. 4) in order to achieve internetworking capabilities as taught by Sumner (para. 0002). Therefore, based on Elias in view of Sumner, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Sumner to the method of Elias in order to achieve internetworking capabilities as taught by Sumner (para. 0002). With respect to claim 14, Elias in view of Sumner teaches The method of claim 9 as described above, Further, Sumner teaches further comprising, determining whether the external device is connected to the access point server (the wireless device 102 establishes a connection through the access point 101 being assigned an IP address and the given the IP address of local DNS 105 from DHCP server 109 and becoming a registered address on router list 104, para. 0025; the wireless device 102 establishes a connection through the access point 101 being assigned an IP address and the given the IP address of local DNS 105 from DHCP server 109 and becoming a registered address on router list 104; once a connection is established the client wireless device 102 make a request for web content 108 from a site that is shadowed on the local network; the request consists of first a DNS request from the client browser on the wireless device 102 for the IP address of a hostname for a website, which is passed, not to the Internet, but to DNS server 105. DNS server 105 examines the hostname to determine if the website is shadowed on the local network and returns the IP address of hypertext transfer protocol (HTTP) server 107 to the wireless device, para. 0025) in order to achieve internetworking capabilities as taught by Sumner (para. 0002). Therefore, based on Elias in view of Sumner, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Sumner to the method of Elias in order to achieve internetworking capabilities as taught by Sumner (para. 0002). With respect to claim 15, Elias in view of Sumner teaches The method of claim 9 as described above, Furthermore, Sumner teaches wherein the incoming traffic is analyzed if the external device is connected to the access point server (the wireless device 102 establishes a connection through the access point 101 being assigned an IP address and the given the IP address of local DNS 105 from DHCP server 109 and becoming a registered address on router list 104, para. 0025; the wireless device 102 establishes a connection through the access point 101 being assigned an IP address and the given the IP address of local DNS 105 from DHCP server 109 and becoming a registered address on router list 104; once a connection is established the client wireless device 102 make a request for web content 108 from a site that is shadowed on the local network; the request consists of first a DNS request from the client browser on the wireless device 102 for the IP address of a hostname for a website, which is passed, not to the Internet, but to DNS server 105. DNS server 105 examines the hostname to determine if the website is shadowed on the local network and returns the IP address of hypertext transfer protocol (HTTP) server 107 to the wireless device, para. 0025) in order to achieve internetworking capabilities as taught by Sumner (para. 0002). Therefore, based on Elias in view of Sumner, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Sumner to the method of Elias in order to achieve internetworking capabilities as taught by Sumner (para. 0002). Claims 2 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Elias et al. (US 2008/0019376 A1), hereinafter referred to as Elias, in view of Sumner (US 2006/0218296 A1), and further in view of Herbert et al. (US 2012/0051346 A1), hereinafter referred to as Herbert. With respect to claim 2, Elias in view of Sumner teaches The network device of claim 1 as described above, Elias in view of Sumner does not explicitly teach further comprising an access point client, wherein the access point client is configured to connect to the at least one bridged device, and wherein the processor is further configured to analyze the incoming traffic to determine whether the IP address received from the external device is the IP address of the access point client. However, Herbert teaches further comprising an access point client, wherein the access point client is configured to connect to the at least one bridged device (the IAP 112 communicate with the IAP client STAs 114 using, e.g., Bluetooth, Wi-Fi, or some other network standard (or not in accordance with a standard) to form a connection between a non-AP station (the IAP client STAs 114) and an AP station (the IAP 112), para. 0028), and wherein the processor is further configured to analyze the incoming traffic to determine whether the IP address received from the external device is the IP address of the access point client (bridge table 202 must have data sufficient to enable identification of the end STA MAC address. This can be accomplished by maintaining an IP address in association with a MAC address of the STA. Thus, in a specific implementation that makes use of IP addresses and MAC addresses, the bridge table 202 includes at least a MAC address and an IP address for each client entry, para. 0038) in order to facilitate identification of a STA of a wireless network at an IAP that receives a WAP IP packet as taught by Herbert (para. 0037). Therefore, based on Elias in view of Sumner, and further in view of Herbert, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Herbert to the device of Elias in view of Sumner in order to facilitate identification of a STA of a wireless network at an IAP that receives a WAP IP packet as taught by Herbert (para. 0037). With respect to claim 10, Elias in view of Sumner teaches The method of claim 9 as described above, Elias in view of Sumner does not explicitly teach further comprising: connecting an access point client of the network device to the at least one bridged device; analyzing the incoming traffic to determine whether the IP address received from the external device is the IP address of the access point client; and transmitting the traffic to the bridged device if the received IP address is not the IP address of the access point client. However, Herbert teaches further comprising: connecting an access point client of the network device to the at least one bridged device (the IAP 112 communicate with the IAP client STAs 114 using, e.g., Bluetooth, Wi-Fi, or some other network standard (or not in accordance with a standard) to form a connection between a non-AP station (the IAP client STAs 114) and an AP station (the IAP 112), para. 0028); analyzing the incoming traffic to determine whether the IP address received from the external device is the IP address of the access point client (bridge table 202 must have data sufficient to enable identification of the end STA MAC address. This can be accomplished by maintaining an IP address in association with a MAC address of the STA, in a specific implementation that makes use of IP addresses and MAC addresses, the bridge table 202 includes at least a MAC address and an IP address for each client entry, para. 0038); and transmitting the traffic to the bridged device if the received IP address is not the IP address of the access point client (bridge table 202 must have data sufficient to enable identification of the end STA MAC address. This can be accomplished by maintaining an IP address in association with a MAC address of the STA. Thus, in a specific implementation that makes use of IP addresses and MAC addresses, the bridge table 202 includes at least a MAC address and an IP address for each client entry, para. 0038) in order to facilitate identification of a STA of a wireless network at an IAP that receives a WAP IP packet as taught by Herbert (para. 0037). Therefore, based on Elias in view of Sumner, and further in view of Herbert, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Herbert to the method of Elias in view of Sumner in order to facilitate identification of a STA of a wireless network at an IAP that receives a WAP IP packet as taught by Herbert (para. 0037). Claim 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Elias et al. (US 2008/0019376 A1), hereinafter referred to as Elias, in view of Sumner (US 2006/0218296 A1), and further in view of Boyer (US 2005/0089025 A1), hereinafter referred to as Boyer. With respect to claim 8, Elias in view of Sumner teaches The network device of claim 7 as described above, Elias in view of Sumner does not explicitly teach wherein the negotiated IP address of the bridged device is the same as the IP address of the network layer. However, Boyer teaches wherein the negotiated IP address of the bridged device is the same as the IP address of the network layer (each packet of data received from the large network, destined for the IP public address, is forwarded directly to the network device 16 on the local network 14, except if it belongs to an existing connection used by the hosted application, or to a server port currently opened, each IP packet received from the local network 14 is forwarded to the large network side, except for packets sent explicitly to a private address of the routing device 10) in order to allow sharing a public IP address between an application hosted on the routing device and a node of a local network as taught by Boyer (para. 0019). Therefore, based on Elias in view of Sumner, and further in view of Boyer, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Boyer to the device of Elias in view of Sumner in order to allow sharing a public IP address between an application hosted on the routing device and a node of a local network as taught by Boyer (para. 0019). With respect to claim 16, Elias in view of Sumner teaches The method of claim 9 as described above, Elias in view of Sumner does not explicitly teach further comprising negotiating an IP address for the bridged device, wherein the negotiated IP address of the bridged device is the same as the IP address of the network layer. However, Boyer teaches further comprising negotiating an IP address for the bridged device, wherein the negotiated IP address of the bridged device is the same as the IP address of the network layer (each packet of data received from the large network, destined for the IP public address, is forwarded directly to the network device 16 on the local network 14, except if it belongs to an existing connection used by the hosted application, or to a server port currently opened, each IP packet received from the local network 14 is forwarded to the large network side, except for packets sent explicitly to a private address of the routing device 10) in order to allow sharing a public IP address between an application hosted on the routing device and a node of a local network as taught by Boyer (para. 0019). Therefore, based on Elias in view of Sumner, and further in view of Boyer, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Boyer to the method of Elias in view of Sumner in order to allow sharing a public IP address between an application hosted on the routing device and a node of a local network as taught by Boyer (para. 0019). Claims 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Saunderson (US 2009/0300178 A1), hereinafter referred to as Saunderson, in view of Boyer (US 2005/0089025 A1), hereinafter referred to as Boyer. With respect to claim 17, Saunderson teaches A method comprising: determining whether an external device connected to a network device has a DHCP client running (using DHCP to monitor the signal traffic through the switch to or from the each edge device to determine, without changing the traffic signals, for each edge device, the MAC address, the IP address, and the port of the switch to which it is connected, para. 0009; using the table derived from the information learnt from DHCP packets passing through the switch between an attached DHCP client (an edge device connected to a port of the switch) and a DHCP server, para. 0028; also see para. 0009 and 0029); retrieving at least one selected setting of packets sent to the external device if the external device has the DHCP client running (the router 12 includes a memory 12M which includes an ARP table 12T of information about each device including includes a list of MAC addresses, corresponding IP addresses for the relevant device, and the IP Interface the relevant device connected to, para. 0039; also see para. 0047, 0034 and 0041); and Saunderson does not explicitly teach applying the at least one selected setting to a stack stored in a memory of the network device to configure the network device to provide for communication between applications running on the network device and the external device. However, Boyer teaches applying the at least one selected setting to a stack stored in a memory of the network device to configure the network device to provide for communication between applications running on the network device and the external device (sharing a public IP address such as a public IPv4 address, which comprises providing a routing device hosting an application and provided with an interface to a large network such as a WAN and an interface to a local network such as a LAN, providing a network device in the local network, connecting the network device to the LAN interface of the routing device, whereby the routing device shares a public IP, such as a public IPv4 address between the application it is hosting and the network device, para. 0036) in order to allow sharing a public IP address between an application hosted on the routing device and a node of a local network as taught by Boyer (para. 0019). Therefore, based on Saunderson in view of Boyer, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Boyer to the method of Saunderson in order to allow sharing a public IP address between an application hosted on the routing device and a node of a local network as taught by Boyer (para. 0019). With respect to claim 18, Saunderson in view of Boyer teaches The method of claim 17 as described above, Further, Boyer teaches wherein the at least one selected setting applied to the stack is an IP address associated with the external device (sharing a public IP address such as a public IPv4 address, which comprises providing a routing device hosting an application and provided with an interface to a large network such as a WAN and an interface to a local network such as a LAN, providing a network device in the local network, connecting the network device to the LAN interface of the routing device, whereby the routing device shares a public IP, such as a public IPv4 address between the application it is hosting and the network device, para. 0036) in order to allow sharing a public IP address between an application hosted on the routing device and a node of a local network as taught by Boyer (para. 0019). Therefore, based on Saunderson in view of Boyer, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Boyer to the method of Saunderson in order to allow sharing a public IP address between an application hosted on the routing device and a node of a local network as taught by Boyer (para. 0019). With respect to claim 19, Saunderson teaches The method of claim 17, further comprising determining whether a link to the external device is up (using DHCP to monitor the signal traffic through the switch to or from the each edge device to determine, without changing the traffic signals, for each edge device, the MAC address, the IP address, and the port of the switch to which it is connected, para. 0009; using the table derived from the information learnt from DHCP packets passing through the switch between an attached DHCP client (an edge device connected to a port of the switch) and a DHCP server, para. 0028). With respect to claim 20, Saunderson teaches The method of claim 17, further comprising detecting a DHCP ACK response transmitted to the external device by the network device, wherein the at least one selected setting is retrieved if the DHCP ACK response is detected (the client configuration parameters are learnt from the DHCPACK message, which must contain a transaction identifier that matches with the transaction identifier in the last DHCPREQUEST or DHCPINFORM message received from the client, para. 0047; determining whether the packet is DHCP response and if it is, the IP address is added, para. 0088; using the IP address learnt from a DHCP response and the MAC address learnt from the DHCP packets to allow all packets with this MAC address and IP address to be sent to the network and to prevent any packets from a different IP address from entering the network, para. 0031). Contact Information Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAO NGUYEN whose telephone number is (571)272-2666. The examiner can normally be reached on Monday through Friday from 7:30 A.M. to 4:00 P.M. (EST). If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Joon H. Hwang can be reached on 571-272-4036. 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. /H.H.N/Examiner, Art Unit 2447 October 4, 2026 /JOON H HWANG/Supervisory Patent Examiner, Art Unit 2447
Read full office action

Prosecution Timeline

Mar 21, 2025
Application Filed
Oct 09, 2026
Non-Final Rejection mailed — §103, §DOUBLEPATENT (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12757062
SMART 5G EDGE IMPROVING EXPERIENCE AND PERFORMANCE OF APPLICATIONS OVER 5G NETWORKS
3y 0m to grant Granted Oct 06, 2026
Patent 12744734
ADAPTIVE RATE THROTTLING FOR CLOUD-BASED SERVICE REQUESTS
2y 8m to grant Granted Sep 22, 2026
Patent 12744736
ACCESS POINT NAME TOTAL BANDWIDTH LIMITS
2y 11m to grant Granted Sep 22, 2026
Patent 12719747
MANAGING OPERATION OF AN ENDPOINT DEVICE USING OUT OF BAND METHODS
2y 3m to grant Granted Aug 25, 2026
Patent 12706805
SWITCH FABRIC MODIFICATION SYSTEM
2y 10m 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

1-2
Expected OA Rounds
68%
Grant Probability
99%
With Interview (+37.9%)
2y 11m (~1y 4m remaining)
Median Time to Grant
Low
PTA Risk
Based on 314 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