DETAILED ACTION
Notice of 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 .
Response to Arguments
Applicant's arguments filed 02/05/2026 have been fully considered.
Applicant argues that the amendments to the independent claims overcome the prior art of record. In response to the argument, Examiner respectfully agrees in-part. The argument is partially persuasive as Tsubota still teaches on sending a list of active IP addresses to the AP. The amendments change the scope of the invention by clarifying that the client device is querying itself. An updated search was conducted and a prior art was discovered to read on most of the limitations of the independent claims: US 2019/0058731 Al (Garg). Seok still teaches on the limitations of Claims 5-7, 15, 20.
Applicant argues that Tsubota does not teach on a list of active IP addresses. In response to the argument, Examiner respectfully disagrees. Tsubota teaches on a table (ie. list) of MAC addresses with a mapping to IP addresses – these are addresses used by the client device.
Tsubota: A hand over at the hand over destination causes a data frame to be generated containing the MAC address of the wireless terminal device as a source address, a broadcast address as a destination address and address information of its own device. A table holds terminal connection information defining the relationship of the MAC address to the IP address of the wireless terminal device, Abstract.
Applicant argues that the prior art of record does not teach on determining that an AP supports a collaborative IP exchange function. In response to the argument, Examiner respectfully disagrees. The claim recites “a collaborative IP exchange function” but does not further limit or define this claimed element. BRI of this claimed element is a function. Seok determines that the AP is able to provide the client device with a service and this allows for a collaborative exchange between the AP and the client device. Garg, the newly discovered also teaches on determining whether a particular AP supports collaboration with a client device.
Seok: [0007] STA receiving network prefix information [from the AP]; configuring an IP address on the basis of the network prefix information; and transmitting a Generic initial Advertisement Service (GAS) initial request frame including the configured IP address information to an access point (AP). [0014] The GAS initial request frame may be an Access Network Query Protocol (ANQP) request frame, and the GAS initial response frame may be an Access Network Query Protocol (ANQP) response frame.
Garg: [0032] The ARP cache in the user device may then be checked to find if there exists an entry mapping the gateway's IP address to the WLAN access point's MAC address. If such an entry exists, that the WLAN access point itself is working as a gateway ( or router) may be assumed. If such an IP address to MAC address mapping does not exist in the ARP cache of the user device, an ARP request message is sent out. If a single ARP response message is received, it is checked to determine if the IP address matches the IP address of the gateway and the MAC address matches the MAC address of the WLAN access point. A match would indicate that the WLAN access point is also working as a gateway (or router) for this subnetwork.
Please see updated rejection below in view of:
Claim(s) 1, 8, 10-11, 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0058731 Al (Garg) in view of US 2007/0097919 A1 (Tsubota).
Claim(s) 3, 13, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0058731 Al (Garg) in view of US 2007/0097919 A1 (Tsubota) further in view of US 20220012110 A1 (Dhillon).
Claim(s) 4, 14, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0058731 Al (Garg) in view of US 2007/0097919 A1 (Tsubota) more in view of US 9189264 B1 (Steffen).
Claim(s) 5-7, 15, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0058731 Al (Garg) in view of US 2007/0097919 A1 (Tsubota) further in view of US 2014/0092779 A1 (Seok).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0058731 Al (Garg) in view of US 2007/0097919 A1 (Tsubota) further in view of US 2014/0016612 A1 (Montemurro).
Claim Objections
Claims 1, 3-11, 13-16, 18-23 are objected to because of the following informalities:
Claims 1, 11, 16 recite “a Address Resolution Protocol (ARP)-proxy function”. It should read “[[a]]an Address Resolution Protocol (ARP)-proxy function”.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
Claim(s) 1, 8, 10-11, 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0058731 Al (Garg) in view of US 2007/0097919 A1 (Tsubota).
Regarding Claim 1:
Garg teaches A method comprising: querying, by a client device, an Operating System (OS) stack of the client device for a list of active Internet Protocol (IP) addresses used by the client device; ([0032] the following MAC and IP address information may be obtained from the High Level Operating System (HLOS)/kernel/platform layer of the user device: (1) the MAC address of the WLAN access point, which is known when the user device registers with the access point, and additionally can be known from the WLAN scans yielding the basic service set identifier (BSSID)/MAC address (e.g., from the wirelessly broadcast beacon frames); and (2) the IP address of the gateway (or router).)
determining, by the client device, that an Access Point (AP) supports a collaborative IP exchange function; ([0032] The ARP cache in the user device may then be checked to find if there exists an entry mapping the gateway's IP address to the WLAN access point's MAC address. If such an entry exists, that the WLAN access point itself is working as a gateway ( or router) may be assumed. If such an IP address to MAC address mapping does not exist in the ARP cache of the user device, an ARP request message is sent out. If a single ARP response message is received, it is checked to determine if the IP address matches the IP address of the gateway and the MAC address matches the MAC address of the WLAN access point. A match would indicate that the WLAN access point is also working as a gateway (or router) for this subnetwork.)
and sending, by the client device in response to determining that the AP supports the collaborative IP exchange function, an ARP request/response to the AP, ([0026] The ARP cache is constructed based on ARP messages on the subnetwork. [0034] At block 420, an ARP request message that requests an IP address to MAC address mapping for the gateway device may be transmitted onto the subnetwork. At block 430, an ARP response message that comprises the IP address to MAC address mapping for the gateway device may be received. [0027] In the uncompromised state, the ARP cache 222 of the user device 120 stores the correct mapping 225A for the gateway device 110, and the ARP cache 212 of the gateway device 110 stores the correct mapping 215A for the user device 120. Accordingly, network communications between the user device 120 and the gateway device 110 work properly in either direction.) The ARP cache is built by received ARP requests/responses. IP address information is in the ARP messages.
wherein the AP injects the list of active IP addresses in a Address Resolution Protocol (ARP)-proxy function (ie. ARP cache 212). ([0027] In the uncompromised state, the ARP cache 222 of the user device 120 stores the correct mapping 225A for the gateway device 110, and the ARP cache 212 of the gateway device 110 stores the correct mapping 215A for the user device 120. Accordingly, network communications between the user device 120 and the gateway device 110 work properly in either direction.)
Garg teaches on the client device obtaining by querying, a list of active IP addresses ([0032]) and sending IP address information via multiple ARP messages. However, Garg is silent on the sending of the list of active IP addresses (ie. user device ARP cache).
Tsubota teaches, in the same field of endeavor, on services which are handed over between the access point devices responsively to the wireless terminal device moving, Abstract.
Tsubota also teaches sending the list of active IP addresses (ie. address table) to the AP. ([0027] The network switcher 12, as with switchers having a general function of transmitting and receiving information, has an MAC address table 38 in which the MAC addresses of the wireless LAN terminal device 20, etc., transmitted and received by its own device 12 are related with the port numbers, device identification of the access point device 18. [0055] A data frame in which a broadcast address is incorporated in the destination address field is transmitted, so that MAC address tables 38 and 108 in all the network switchers 12 and 106 can be updated. Abstract: A hand over at the hand over destination causes a data frame to be generated containing the MAC address of the wireless terminal device as a source address, a broadcast address as a destination address and address information of its own device. A table holds terminal connection information defining the relationship of the MAC address to the IP address of the wireless terminal device.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify Garg per Tsubota to include sending the list of active IP addresses to the AP. This would have been advantageous as discussed above, as it would allow the modified system to provide all the IP addresses in one message, saving resources.
Regarding Claim 11:
Garg teaches A system comprising: a memory storage; and a processing unit disposed in a client device and coupled to the memory storage ([0047] such a program may be implemented in firmware or software (e.g., stored in memory and/or other locations) and may be implemented by processors and/or other circuitry of the devices.), wherein the processing unit is operative to:
query an Operating System (OS) stack of the client device for a list of active Internet Protocol (IP) addresses used by the client device; ([0032] the following MAC and IP address information may be obtained from the High Level Operating System (HLOS)/kernel/platform layer of the user device: (1) the MAC address of the WLAN access point, which is known when the user device registers with the access point, and additionally can be known from the WLAN scans yielding the basic service set identifier (BSSID)/MAC address (e.g., from the wirelessly broadcast beacon frames); and (2) the IP address of the gateway (or router).)
determine that an Access Point (AP) supports a collaborative IP exchange function; ([0032] The ARP cache in the user device may then be checked to find if there exists an entry mapping the gateway's IP address to the WLAN access point's MAC address. If such an entry exists, that the WLAN access point itself is working as a gateway ( or router) may be assumed. If such an IP address to MAC address mapping does not exist in the ARP cache of the user device, an ARP request message is sent out. If a single ARP response message is received, it is checked to determine if the IP address matches the IP address of the gateway and the MAC address matches the MAC address of the WLAN access point. A match would indicate that the WLAN access point is also working as a gateway (or router) for this subnetwork.)
and send, in response to determining that the AP supports the collaborative IP exchange function, an ARP request/response to the AP, ([0026] The ARP cache is constructed based on ARP messages on the subnetwork. [0034] At block 420, an ARP request message that requests an IP address to MAC address mapping for the gateway device may be transmitted onto the subnetwork. At block 430, an ARP response message that comprises the IP address to MAC address mapping for the gateway device may be received. [0027] In the uncompromised state, the ARP cache 222 of the user device 120 stores the correct mapping 225A for the gateway device 110, and the ARP cache 212 of the gateway device 110 stores the correct mapping 215A for the user device 120. Accordingly, network communications between the user device 120 and the gateway device 110 work properly in either direction.) The ARP cache is built by received ARP requests/responses. IP address information is in the ARP messages.
wherein the AP injects the list of active IP addresses in a Address Resolution Protocol (ARP)-proxy function (ie. ARP cache 212). ([0027] In the uncompromised state, the ARP cache 222 of the user device 120 stores the correct mapping 225A for the gateway device 110, and the ARP cache 212 of the gateway device 110 stores the correct mapping 215A for the user device 120. Accordingly, network communications between the user device 120 and the gateway device 110 work properly in either direction.)
Garg teaches on the client device obtaining by querying, a list of active IP addresses ([0032]) and sending IP address information via multiple ARP messages. However, Garg is silent on the sending of the list of active IP addresses (ie. user device ARP cache).
Tsubota teaches sending the list of active IP addresses (ie. address table) to the AP. ([0027] The network switcher 12, as with switchers having a general function of transmitting and receiving information, has an MAC address table 38 in which the MAC addresses of the wireless LAN terminal device 20, etc., transmitted and received by its own device 12 are related with the port numbers, device identification of the access point device 18. [0055] A data frame in which a broadcast address is incorporated in the destination address field is transmitted, so that MAC address tables 38 and 108 in all the network switchers 12 and 106 can be updated. Abstract: A hand over at the hand over destination causes a data frame to be generated containing the MAC address of the wireless terminal device as a source address, a broadcast address as a destination address and address information of its own device. A table holds terminal connection information defining the relationship of the MAC address to the IP address of the wireless terminal device.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify Garg per Tsubota to include sending the list of active IP addresses to the AP. This would have been advantageous as discussed above, as it would allow the modified system to provide all the IP addresses in one message, saving resources.
Regarding Claim 16:
Garg teaches A non-transitory computer-readable medium that stores a set of instructions ([0047] such a program may be implemented in firmware or software (e.g., stored in memory and/or other locations) and may be implemented by processors and/or other circuitry of the devices.) which when executed perform a method executed by the set of instructions comprising:
querying, by a client device, an Operating System (OS) stack of the client device for a list of active Internet Protocol (IP) addresses used by the client device; ([0032] the following MAC and IP address information may be obtained from the High Level Operating System (HLOS)/kernel/platform layer of the user device: (1) the MAC address of the WLAN access point, which is known when the user device registers with the access point, and additionally can be known from the WLAN scans yielding the basic service set identifier (BSSID)/MAC address (e.g., from the wirelessly broadcast beacon frames); and (2) the IP address of the gateway (or router).)
determining, by the client device, that an Access Point (AP) supports a collaborative IP exchange function; ([0032] The ARP cache in the user device may then be checked to find if there exists an entry mapping the gateway's IP address to the WLAN access point's MAC address. If such an entry exists, that the WLAN access point itself is working as a gateway ( or router) may be assumed. If such an IP address to MAC address mapping does not exist in the ARP cache of the user device, an ARP request message is sent out. If a single ARP response message is received, it is checked to determine if the IP address matches the IP address of the gateway and the MAC address matches the MAC address of the WLAN access point. A match would indicate that the WLAN access point is also working as a gateway (or router) for this subnetwork.)
and sending, by the client device in response to determining that the AP supports the collaborative IP exchange function, an ARP request/response to the AP, ([0026] The ARP cache is constructed based on ARP messages on the subnetwork. [0034] At block 420, an ARP request message that requests an IP address to MAC address mapping for the gateway device may be transmitted onto the subnetwork. At block 430, an ARP response message that comprises the IP address to MAC address mapping for the gateway device may be received. [0027] In the uncompromised state, the ARP cache 222 of the user device 120 stores the correct mapping 225A for the gateway device 110, and the ARP cache 212 of the gateway device 110 stores the correct mapping 215A for the user device 120. Accordingly, network communications between the user device 120 and the gateway device 110 work properly in either direction.) The ARP cache is built by received ARP requests/responses. IP address information is in the ARP messages.
wherein the AP injects the list of active IP addresses in a Address Resolution Protocol (ARP)-proxy function (ie. ARP cache 212). ([0027] In the uncompromised state, the ARP cache 222 of the user device 120 stores the correct mapping 225A for the gateway device 110, and the ARP cache 212 of the gateway device 110 stores the correct mapping 215A for the user device 120. Accordingly, network communications between the user device 120 and the gateway device 110 work properly in either direction.)
Garg teaches on the client device obtaining by querying, a list of active IP addresses ([0032]) and sending IP address information via multiple ARP messages. However, Garg is silent on the sending of the list of active IP addresses (ie. user device ARP cache).
Tsubota teaches sending the list of active IP addresses (ie. address table) to the AP. ([0027] The network switcher 12, as with switchers having a general function of transmitting and receiving information, has an MAC address table 38 in which the MAC addresses of the wireless LAN terminal device 20, etc., transmitted and received by its own device 12 are related with the port numbers, device identification of the access point device 18. [0055] A data frame in which a broadcast address is incorporated in the destination address field is transmitted, so that MAC address tables 38 and 108 in all the network switchers 12 and 106 can be updated. Abstract: A hand over at the hand over destination causes a data frame to be generated containing the MAC address of the wireless terminal device as a source address, a broadcast address as a destination address and address information of its own device. A table holds terminal connection information defining the relationship of the MAC address to the IP address of the wireless terminal device.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify Garg per Tsubota to include sending the list of active IP addresses to the AP. This would have been advantageous as discussed above, as it would allow the modified system to provide all the IP addresses in one message, saving resources.
Regarding Claim 8:
Garg (as modified by Tsubota) teaches the invention of claim 1 as described.
Garg teaches wherein sending the list of active Internet Protocol (IP) addresses to the AP comprises using a data frame (ie. ARP request/response messages). ([0026] The ARP cache is constructed based on ARP messages on the subnetwork. [0034] At block 420, an ARP request message that requests an IP address to MAC address mapping for the gateway device may be transmitted onto the subnetwork. At block 430, an ARP response message that comprises the IP address to MAC address mapping for the gateway device may be received.)
Regarding Claim 10:
Garg (as modified by Tsubota) teaches the invention of claim 1 as described.
Garg teaches further comprising refreshing, by the client device, the list of active IP addresses with the AP (ie. gateway device 110). ([0027] In the uncompromised state, the ARP cache 222 of the user device 120 stores the correct mapping 225A for the gateway device 110, and the ARP cache 212 of the gateway device 110 stores the correct mapping 215A for the user device 120. Accordingly, network communications between the user device 120 and the gateway device 110 work properly in either direction.)
Claim(s) 3, 13, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0058731 Al (Garg) in view of US 2007/0097919 A1 (Tsubota) further in view of US 20220012110 A1 (Dhillon).
Regarding Claims 3, 13, 18:
Garg (as modified by Tsubota) teaches on the inventions of claims 1, 11, 16 as described.
Garg teaches on querying the OS stack of the client device ([0032]). However, Garg (as modified by Tsubota) is silent on wherein querying the OS stack of the client device comprises using an upcall Application Programming Interface (API).
Dhillon teaches, in the same field of endeavor, on a method that includes intercepting a system calls from a client application, Abstract.
Dhillon teaches on using an upcall Application Programming Interface (API). ([0037] System kernel 120 is an operating system kernel of computing device 100. System kernel 120 performs system functions such as managing hardware devices including storage 114, I/O device interface 104, and network interface 106. System kernel 120 also provides process and memory management models for client 118, intermediary service 124, and manager 122. In some embodiments, system kernel 120 receives system calls requesting kernel level services from the operating system of computing device 100.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify Garg (as modified by Tsubota) by modifying Garg per Dhillon to include wherein querying the OS stack of the client device comprises using an upcall Application Programming Interface (API). This would have been advantageous as discussed above, as it would allow the combined system to provide kernel services to requesting applications on the computing device.
Claim(s) 4, 14, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0058731 Al (Garg) in view of US 2007/0097919 A1 (Tsubota) more in view of US 9189264 B1 (Steffen).
Regarding Claims 4, 14, 19:
Garg (as modified by Tsubota) teaches on the invention of claims 1, 11, 16 as described.
Garg teaches on utilizing DHCP discovery messages ([0044]). However, Garg (as modified by Tsubota) is silent on is silent on wherein querying the OS stack of the client device comprises snooping Multicast Listener Discovery (MLD).
Steffen teaches, in the same field of endeavor, Systems and methods are disclosed for propagating notifications between computing environments, such as virtual computing environments, Abstract.
Steffen teaches wherein querying the OS stack of the client device comprises snooping Multicast Listener Discovery (MLD) (ie. listening socket). (The host OS may open up a listening socket, wherein other operating systems running on the device may connect to the socket to receive and/or transmit notification information. That is, an application running on the host OS stack may open up a socket and listen for broadcasts on the socket from systems running on top of the host OS or from the host OS, wherein each machine running on top of the host OS may open up its own listening socket. Virtual machines may utilize network address translation for inter-system communication. The locally-running OS stacks may thereby effectively connect over a private LAN, thereby allowing for enhanced security.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify Garg (as modified by Tsubota) by modifying Garg per Steffen to include wherein querying the OS stack of the client device comprises snooping Multicast Listener Discovery (MLD). This would have been advantageous as discussed above, as it would allow the combined system to provide management of the routing information on the client device utilizing the OS stack which would an essential part of any client device.
Claim(s) 5-7, 15, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0058731 Al (Garg) in view of US 2007/0097919 A1 (Tsubota) further in view of US 2014/0092779 A1 (Seok).
Regarding Claims 5, 15, 20:
Garg (as modified by Tsubota) teaches on the invention of claims 1, 11, 16 as described.
Garg teaches on querying the OS stack of the client device ([0032]). However, Garg (as modified by Tsubota) is silent on wherein determining that the AP supports the collaborative IP exchange function comprises exchanging capability information wherein the client device queries the AP through Generic Advertisement Service (GAS)/Access Network Query Protocol (ANQP).
Seok teaches, in the same field of endeavor, a wireless communication system, and more particularly, to a method and apparatus for finding a neighbor, Abstract.
Seok teaches wherein determining that the AP supports the collaborative IP exchange function comprises exchanging capability information wherein the client device queries the AP through Generic Advertisement Service (GAS)/Access Network Query Protocol (ANQP). ([0007] STA receiving network prefix information [from the AP]; configuring an IP address on the basis of the network prefix information; and transmitting a Generic initial Advertisement Service (GAS) initial request frame including the configured IP address information to an access point (AP). [0014] The GAS initial request frame may be an Access Network Query Protocol (ANQP) request frame, and the GAS initial response frame may be an Access Network Query Protocol (ANQP) response frame.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify Garg (as modified by Tsubota) by modifying Garg per Seok to include wherein determining that the AP supports the collaborative IP exchange function comprises exchanging capability information wherein the client device queries the AP through Generic Advertisement Service (GAS)/Access Network Query Protocol (ANQP). This would have been advantageous as discussed above, as it would allow the combined system to ensure that the particular access point will support the client device properly.
Regarding Claim 6:
Garg (as modified by Tsubota) teaches the invention of claim 1 as described.
Garg teaches on querying the OS stack of the client device ([0032]). However, Garg (as modified by Tsubota) is silent on wherein determining that the AP supports the collaborative IP exchange function comprises exchanging capability information using a capability Information Element (IE) in association exchanges.
Seok teaches wherein determining that the AP supports the collaborative IP exchange function comprises exchanging capability information using a capability Information Element (IE) in association exchanges. ([0089] Referring to FIG. 5(a), the advertisement protocol information element may include an element ID field, a length field, and one or more advertisement protocol tuples. The element ID field may include a specific value for identifying that the corresponding element format relates to advertisement protocol information. The length field may include a specific value indicating a total length of subsequent field(s). [0091] Table 2 shows exemplary ID values of the advertisement protocol: MIH Command and Event Service Capability.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify Garg (as modified by Tsubota) by modifying Garg per Seok to include wherein determining that the AP supports the collaborative IP exchange function comprises exchanging capability information using a capability Information Element (IE) in association exchanges. This would have been advantageous as discussed above, as it would allow the combined system to ensure that the particular access point will support the client device properly and to utilize the packet fields to carry the capability information as this would save on bandwidth/resources.
Regarding Claim 7:
Garg (as modified by Tsubota) teaches the invention of claim 1 as described.
Garg teaches on querying the OS stack of the client device ([0032]). However, Garg (as modified by Tsubota) is silent on wherein sending the list of active Internet Protocol (IP) addresses to the AP comprises using Generic Advertisement Service (GAS)/Access Network Query Protocol (ANQP).
Seok teaches wherein sending the list of active Internet Protocol (IP) addresses to the AP comprises using Generic Advertisement Service (GAS)/Access Network Query Protocol (ANQP). ([0007] The object of the present invention can be achieved by providing a method for performing Internet Protocol (IP) configuration by a station (STA) of a wireless communication network including: receiving network prefix information; configuring an IP address on the basis of the network prefix information; and transmitting a Generic initial Advertisement Service (GAS) initial request frame including the configured IP address information to an access point (AP).)
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify Garg (as modified by Tsubota) by modifying Garg per Seok to include wherein sending the list of active Internet Protocol (IP) addresses to the AP comprises using Generic Advertisement Service (GAS)/Access Network Query Protocol (ANQP). This would have been advantageous as discussed above, as it would allow the combined system to ensure that the particular access point is able to support the client device properly.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0058731 Al (Garg) in view of US 2007/0097919 A1 (Tsubota) further in view of US 2014/0016612 A1 (Montemurro).
Regarding Claim 9:
Garg (as modified by Tsubota) teaches the invention of claim 8 as described.
Garg teaches on communications between the user device and the gateway router (AP) ([0032]). However, Garg (as modified by Tsubota) is silent on wherein the data frame is preceded by an action frame signaling a start of an exchange.
Montemurro teaches, in the same field of endeavor, that a mobile device may receive an IP address from a pool of addresses, such that the mobile device can keep that IP address as it is roaming, Abstract.
Montemurro teaches wherein the data frame is preceded by an action frame signaling a start of an exchange. ([0011] Communications prior to network association may be referred to as pre-association communications. ANQP may allow a device to determine that a network, to which a mobile device may transition to, operates under a particular protocol (e.g. LCP) which allows the same IP address to be utilized during and upon transition to that network.)
It would have been obvious to a person having ordinary skill in the art before the effective filing date, to modify Seok (as modified by Tsubota) by modifying Seok per Montemurro to include wherein the data frame is preceded by an action frame signaling a start of an exchange. This would have been advantageous as discussed above, as it would allow the combined system to provide pre-communication authorization/verification which allows for expedient setup.
Allowable Subject Matter
Claims 21-23 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim 21: The method of Claim 1, further comprising: receiving, by the client device, an indication from the AP that a predetermined limit for a number of active IP addresses that could be stored for the client device is reached; and sending, by the client device in response to receiving indication, a refreshed list of active IP addresses.
Claim 22: The method of Claim 1, further comprising: sending, by the client device, meta information for each address in the list of active IP addresses, wherein the meta information comprises one or more of: a time since address was formed, a lifetime expectation for that address; and a recent amount of traffic and projection for the future.
Claim 23: The method of Claim 1, further comprising: sending, by the client device, meta information for each address in the list of active IP addresses, wherein the meta information comprises a sorted list of IP addresses, wherein the AP uses the meta information to arbitrate which addresses to store if all addresses cannot be stored.
Conclusion & Contact Information
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 RACHEL J HACKENBERG whose telephone number is (571)272-5417. The examiner can normally be reached 9am-5pm M-F.
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, Glenton B Burgess can be reached at (571)272-3949. 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.
/RACHEL J HACKENBERG/Primary Examiner, Art Unit 2454