DETAILED ACTION
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 .
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The factual inquiries 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 non-obviousness.
Claims 1, 3-8, 10-15, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over US Pub. 2017/0054623 to Amulothu et al (hereinafter Amulothu) in view of US Pub. 2020/0267650 to Lee et al. (hereinafter Lee).
In regard claim 1, Amulothu teaches or discloses a method comprising:
receiving a broadcast discovery frame at a network interface controller of a device in a
suspend state, the network interface controller operating at a data link layer (see paragraphs [0003], [0004], and [0041], one or more networking devices that received a resource discovery packet one or more networking devices that received a resource discovery packet a first one of networking device(s) 150 receiving a resource discovery packet from a second one of networking device(s) 150);
determining that an EtherType of the broadcast discovery frame matches a particular
EtherType, the particular EtherType stored on the network interface controller (see paragraphs [0043], [0044], [0045], and [0053], if there is a match (decision 302, YES branch), then the EtherType is validated (decision 306). In decision 306, the EtherType is validated. For example, the router compares the value in the EtherType field of the resource discovery packet to a predefined expected EtherType value (e.g., 0x8673), which signifies that the packet is a resource discovery packet and that appropriate action is required);
determining that a payload of the broadcast discovery frame matches a particular payload value, the particular payload value stored on the network interface controller (see paragraphs [0043], [0044], [0045], [0053], [0061], a router (i.e., one of networking device(s) 150) compares the value in the destination MAC address field of the resource discovery packet to its own MAC address. If there is not a match (decision 302, NO branch), then operations 300 end. If there is a match (decision 302, YES branch), then the EtherType is validated (decision 306). If there is a match (decision 306, YES branch), then the router determines whether the resource discovery packet is a reply or a request (decision 308));
in response to determining that the EtherType and the payload of the broadcast discovery
frame match the particular EtherType and the particular payload value (see paragraphs [0043], [0044], [0045], [0053], and [0054], the router compares the value in the EtherType field of the resource discovery packet to a predefined expected EtherType value (e.g., 0x8673), which signifies that the packet is a resource discovery packet and that appropriate action is required. If there is not a match (decision 306, NO branch), then operations 300 end. If there is a match (decision 306, YES branch), then the router determines whether the resource discovery packet is a reply or a request (decision 308). In decision 408, the packet is determined to be a reply or a request. For example, if the value in the type of packet field of the resource discovery packet is “reply”, then the endpoint determines that the resource discovery packet is a reply (decision 408, REPLY branch), and the endpoint updates the resource discovery table (operation 414));
retrieving a device identifier of the device, the device identifier stored by the network interface controller (see paragraphs [0026], [0036], and [0037], responsive to receiving the request, audit program 134 determines that, in order to perform the audit, the IP addresses of the networking devices along the data path between endpoint 130 and endpoint 140 must be identified);
transmitting, from the network interface controller, a response frame, wherein a payload of the response frame comprises the retrieved device identifier (see paragraphs [0032], and [0034], controller program 112 presents the audit data to a user and, in response, receives user input identifying one or more networking device(s) 150. Audit data includes networking device data describing the endpoints at either end of the path of communication. Controller program 112 may receive audit data in response to an audit being completed).
Amulothu may not explicitly teach or disclose determining that a payload of the broadcast discovery frame and suspend state.
However, Lee teaches or discloses determining that a payload of the broadcast discovery frame and suspend state (see paragraphs [0532], [0605], the length of WLAN module “OFF” period in WUR will be much longer than that of sleep-mode currently defined and thus much power can be saved. The Payload field may include a Wake-Up Preamble, MAC Header, Frame Body and FCS field).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify auditing networking device of Amulothu by including determining that a payload of the broadcast discovery frame and suspend state suggested by Lee. This modification would provide to reduce power consumption of a UE read in paragraph [0022].
In regard claims 3, 10, and 17, Amulothu teaches or discloses the method of claim 1, wherein the broadcast discovery frame is a Wi-Fi frame (see paragraphs [0020], [0041], a local area network (LAN), a wide area network (WAN) such as the Internet, or a combination of the two, and may include wired, wireless, fiber optic or any other connection known in the art. In general, network 120 can be any combination of connections and protocols that will support communications between endpoint 130, user device 110, endpoint 140, and networking device(s) 150. If the device that receives the packet is a router (decision 212, ROUTER branch), then audit program 134 moves to decision 302. If the device that receives the packet is an endpoint (decision 212, ENDPOINT branch), then audit program 134 moves to decision 402).
In regard claims 4, 11, and 18, Amulothu teaches or discloses the method of claim 1, wherein the particular EtherType is a reserved EtherType (see paragraphs [0040], the fields within the resource discovery packet include: a reserved multicast MAC address in the “destination MAC address” field, wherein the reserved multicast MAC address is a predetermined value used to identify that the packet is a resource discovery packet; the MAC address of endpoint 130 in the “source MAC address” field; a predefined EtherType value for this function in the “EtherType” field; a label (e.g., the word “request”) in the “type of packet” field; the IP addresses of endpoint 130, networking device 150a, networking device 150c, and endpoint 140 in the “underlay hop information TLV” field; the MAC address of endpoint 130 in the “target MAC address” field; the MAC address of the next hop (e.g., the MAC address of networking device 150a in the “next hop's MAC address” field; and no value in the “resource information type-length-value (TLV)” field. In one embodiment, the predefined EtherType value for a resource discovery packet is “0x8673”).
In regard claims 5, 12, and 19, Amulothu teaches or discloses the method of claim 1, wherein the particular EtherType is 0x8200 (see paragraph [0040], the fields within the resource discovery packet include: a reserved multicast MAC address in the “destination MAC address” field, wherein the reserved multicast MAC address is a predetermined value used to identify that the packet is a resource discovery packet; the MAC address of endpoint 130 in the “source MAC address” field; a predefined EtherType value for this function in the “EtherType” field; a label (e.g., the word “request”) in the “type of packet” field; the IP addresses of endpoint 130, networking device 150a, networking device 150c, and endpoint 140 in the “underlay hop information TLV” field; the MAC address of endpoint 130 in the “target MAC address” field; the MAC address of the next hop (e.g., the MAC address of networking device 150a in the “next hop's MAC address” field; and no value in the “resource information type-length-value (TLV)” field. In one embodiment, the predefined EtherType value for a resource discovery packet is “0x8673”).
In regard claims 6, 13, and 20, Amulothu teaches or discloses the method of claim 1, further comprising:
providing the device identifier of the device to the network interface controller (see paragraphs [0016], [0026], each computing device in the network is identified by its internet protocol (IP) address, which may be a four- to twelve-digit number separated by periods that identifies the computing device on the network).
Amulothu may not explicitly teach or disclose entering the suspend state.
However, Lee teaches or discloses entering the suspend state (see paragraphs [0532], the length of WLAN module “OFF” period in WUR will be much longer than that of sleep-mode currently defined and thus much power can be saved).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify auditing networking device of Amulothu by including entering the suspend state suggested by Lee. This modification would provide to reduce power consumption of a UE read in paragraph [0022].
In regard claims 7 and 14, Amulothu teaches or discloses the method of claim 1, wherein the device identifier is stored on a memory of the network interface controller (see paragraphs [0037], and [0068], traceroute program 132 identifies IP addresses associated with networking devices 150a and 150c, and traceroute program 132 stores the IP address information in database 136. In another example, traceroute program 132 provides the IP address information to audit program 134 in lieu of, or in addition to, storing the IP address information in database 136).
In regard claim 8, Amulothu teaches or discloses a device comprising:
a network interface controller comprising firmware and a memory, the firmware
configured to:
receive a broadcast discovery frame (see paragraphs [0003], [0004], and [0041], one or more networking devices that received a resource discovery packet one or more networking devices that received a resource discovery packet a first one of networking device(s) 150 receiving a resource discovery packet from a second one of networking device(s) 150);
determine that an EtherType of the broadcast discovery frame matches a particular EtherType, the particular EtherType stored on the network interface controller (see paragraphs [0043], [0044], [0045], and [0053], if there is a match (decision 302, YES branch), then the EtherType is validated (decision 306). In decision 306, the EtherType is validated. For example the router compares the value in the EtherType field of the resource discovery packet to a predefined expected EtherType value (e.g., 0x8673), which signifies that the packet is a resource discovery packet and that appropriate action is required);
determine that a payload of the broadcast discovery frame matches a particular
payload value, the particular payload value stored on the network interface controller (see paragraphs [0043], [0044], [0045], [0053], and [0061], a router (i.e., one of networking device(s) 150) compares the value in the destination MAC address field of the resource discovery packet to its own MAC address. If there is not a match (decision 302, NO branch), then operations 300 end. If there is a match (decision 302, YES branch), then the EtherType is validated (decision 306). If there is a match (decision 306, YES branch), then the router determines whether the resource discovery packet is a reply or a request (decision 308));
in response to determining that the EtherType and the payload of the broadcast
discovery frame match the particular EtherType and the particular payload value (see paragraphs [0043], [0044], [0045], [0053], and [0054], the router compares the value in the EtherType field of the resource discovery packet to a predefined expected EtherType value (e.g., 0x8673), which signifies that the packet is a resource discovery packet and that appropriate action is required. If there is not a match (decision 306, NO branch), then operations 300 end. If there is a match (decision 306, YES branch), then the router determines whether the resource discovery packet is a reply or a request (decision 308). In decision 408, the packet is determined to be a reply or a request. For example, if the value in the type of packet field of the resource discovery packet is “reply”, then the endpoint determines that the resource discovery packet is a reply (decision 408, REPLY branch), and the endpoint updates the resource discovery table (operation 414));
retrieve a device identifier of the device, the device identifier stored on the memory of the network interface controller (see paragraphs [0026], [0036], and [0037], responsive to receiving the request, audit program 134 determines that, in order to perform the audit, the IP addresses of the networking devices along the data path between endpoint 130 and endpoint 140 must be identified);
transmit, from the network interface controller, a response frame, wherein a payload of the response frame comprises the retrieved device identifier (see paragraphs [0032], and [0034], controller program 112 presents the audit data to a user and, in response, receives user input identifying one or more networking device(s) 150. Audit data includes networking device data describing the endpoints at either end of the path of communication. Controller program 112 may receive audit data in response to an audit being completed); and
a processing component to store the device identifier of the device on the memory of the
network interface controller (see paragraphs [0037], traceroute program 132 identifies IP addresses associated with networking devices 150a and 150c, and traceroute program 132 stores the IP address information in database 136. In another example, traceroute program 132 provides the IP address information to audit program 134 in lieu of, or in addition to, storing the IP address information in database 136).
Amulothu may not explicitly teach or disclose determining that a payload of the broadcast discovery frame.
However, Lee teaches or discloses determining that a payload of the broadcast discovery frame (see paragraphs [0605], the Payload field may include a Wake-Up Preamble, MAC Header, Frame Body and FCS field).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify auditing networking device of Amulothu by including determining that a payload of the broadcast discovery frame suggested by Lee. This modification would provide to reduce power consumption of a UE read in paragraph [0022].
In regard claim 15, Amulothu teaches or discloses one or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to:
receive a broadcast discovery frame at a network interface controller of a device in a suspend state, the network interface controller operating at a data link layer (see paragraphs [0003], [0004], and [0041], one or more networking devices that received a resource discovery packet one or more networking devices that received a resource discovery packet a first one of networking device(s) 150 receiving a resource discovery packet from a second one of networking device(s) 150);
determine that an EtherType of the broadcast discovery frame matches a particular EtherType, the particular EtherType stored on the network interface controller (see paragraphs [0043], [0044], [0045], and [0053], if there is a match (decision 302, YES branch), then the EtherType is validated (decision 306). In decision 306, the EtherType is validated. For example, the router compares the value in the EtherType field of the resource discovery packet to a predefined expected EtherType value (e.g., 0x8673), which signifies that the packet is a resource discovery packet and that appropriate action is required);
determine that a payload of the broadcast discovery frame matches a particular payload value, the particular payload value stored on the network interface controller (see paragraphs [0043], [0044], [0045], [0053], [0061], a router (i.e., one of networking device(s) 150) compares the value in the destination MAC address field of the resource discovery packet to its own MAC address. If there is not a match (decision 302, NO branch), then operations 300 end. If there is a match (decision 302, YES branch), then the EtherType is validated (decision 306). If there is a match (decision 306, YES branch), then the router determines whether the resource discovery packet is a reply or a request (decision 308));
in response to determining that the EtherType and the payload of the broadcast discovery frame match the particular EtherType and the particular payload value (see paragraphs [0043], [0044], [0045], [0053], and [0054], the router compares the value in the EtherType field of the resource discovery packet to a predefined expected EtherType value (e.g., 0x8673), which signifies that the packet is a resource discovery packet and that appropriate action is required. If there is not a match (decision 306, NO branch), then operations 300 end. If there is a match (decision 306, YES branch), then the router determines whether the resource discovery packet is a reply or a request (decision 308). In decision 408, the packet is determined to be a reply or a request. For example, if the value in the type of packet field of the resource discovery packet is “reply”, then the endpoint determines that the resource discovery packet is a reply (decision 408, REPLY branch), and the endpoint updates the resource discovery table (operation 414));
retrieve a device identifier of the device, the device identifier stored by the network interface controller (see paragraphs [0026], [0036], and [0037], responsive to receiving the request, audit program 134 determines that, in order to perform the audit, the IP addresses of the networking devices along the data path between endpoint 130 and endpoint 140 must be identified); and
transmit, from the network interface controller, a response frame, wherein a payload of the response frame comprises the retrieved device identifier (see paragraphs [0032], and [0034], controller program 112 presents the audit data to a user and, in response, receives user input identifying one or more networking device(s) 150. Audit data includes networking device data describing the endpoints at either end of the path of communication. Controller program 112 may receive audit data in response to an audit being completed).
Amulothu may not explicitly teach or disclose determining that a payload of the broadcast discovery frame and suspend state.
However, Lee teaches or discloses determining that a payload of the broadcast discovery frame and suspend state (see paragraphs [0532], and [0605], the length of WLAN module “OFF” period in WUR will be much longer than that of sleep-mode currently defined and thus much power can be saved. The Payload field may include a Wake-Up Preamble, MAC Header, Frame Body and FCS field).
Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to modify auditing networking device of Amulothu by including determining that a payload of the broadcast discovery frame and suspend state suggested by Lee. This modification would provide to reduce power consumption of a UE read in paragraph [0022].
Allowable Subject Matter
Claims 2, 9, and 16 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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHIRIN SAM whose telephone number is (571)272-3082. The examiner can normally be reached Mon - Fri, 10:30am - 5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ayaz R. Sheikh can be reached at (571) 272 - 3795. 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.
/PHIRIN SAM/Primary Examiner, Art Unit 2476