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 § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 10-11 and 17-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Agarwal, et al (Pub. No. US 2015/0109924 A1, hereinafter referred to as Agarwal).
Claim 1 is an independent claim and Agarwal discloses a method performed by a network device for suppressing flooding of link-local multicast or broadcast traffic, the method comprising:
receiving a link-local multicast or broadcast message from an endpoint that is connected to the network device (client device sends a multicast or broadcast packet, para. [0026], a user packet received from an end device at a network switch, para. [0055], FIG. 3A), the endpoint being part of a local network segment (user vlan VLAN.sub.NATIVE 355 which the packet was received from, para. [0055]);
dropping, by a data plane of the network device (forwarding mechanism to determine where to forward a copy of the user packet, para. [0104]), the link-local multicast or broadcast message in hardware, such that the link-local multicast or broadcast message is not flooded on the local network segment (based on packet marking, the user packet will be flooded only on the service VLAN VLAN.sub.SERVICE 350, and not on the user VLAN VLAN.sub.NATIVE 355, which the packet was received from, para. [0055]);
copying, by the data plane, the link-local multicast or broadcast message to a central processing unit (CPU) of the network device (network switch A 310 will flood a copy of the packet to each of the servers connected to network switch A 310 on service VLAN VLAN.sub.SERVICE 350, para. [0057]); and
processing, by a software component running on the CPU (see para. [0108]), the link-local multicast or broadcast message received from the data plane (network device processor processing network data packets, para. [0099]).
As per claim 10, claim 1 is incorporated and Agarwal further discloses wherein the link-local multicast or broadcast message is a multicast Domain Name System (mDNS) announcement originating from a service device in the local network segment or an mDNS query originating from a client in the local network segment (any multicast and/or broadcast message, such as an mDNS message received from client device, para. [0016]), and wherein the software component running on the CPU is an mDNS gateway (any multicast and/or broadcast message, such as an mDNS message, para. [0016]; receiving broadcast/multicast packets and forwarding a copy of the packet generally shows a gateway as claimed, and in conjunction with the messages being mDNS messages, this generally shows an mDNS gateway as claimed, para. [0057]).
As per claim 11, claim 10 is incorporated and Agarwal further discloses wherein the processing performed by the mDNS gateway on the mDNS announcement comprises: extracting information regarding the service from the mDNS announcement; and creating a service record including the extracted information in an mDNS record database residing on the network device (the mDNS announcement is part of an optional limitation not being considered by the examiner. Therefore, the limitations in this claim, which depend on the mDNS announcement, are also optional and not being considered by the exaimner).
Claim 17 is an independent claim and Agarwal discloses a network device comprising:
a plurality of ports (see para. [0043]-[0045]);
a data plane (forwarding mechanism to determine where to forward a copy of the user packet, para. [0104]); and
a central processing unit (CPU) (see para. [0099]),
wherein the network device is configured to:
receive a link-local multicast or broadcast message from an endpoint that is connected to the network device (client device sends a multicast or broadcast packet, para. [0026], a user packet received from an end device at a network switch, para. [0055], FIG. 3A), the endpoint being part of a local network segment (user vlan VLAN.sub.NATIVE 355 which the packet was received from, para. [0055]);
drop, by the data plane (forwarding mechanism to determine where to forward a copy of the user packet, para. [0104]), the link-local multicast or broadcast message in hardware, such that the link-local multicast or broadcast message is not flooded on the local network segment (based on packet marking, the user packet will be flooded only on the service VLAN VLAN.sub.SERVICE 350, and not on the user VLAN VLAN.sub.NATIVE 355, which the packet was received from, para. [0055]);
copy, by the data plane, the link-local multicast or broadcast message to the CPU (network switch A 310 will flood a copy of the packet to each of the servers connected to network switch A 310 on service VLAN VLAN.sub.SERVICE 350, para. [0057]); and
process, using the CPU, the link-local multicast or broadcast message received from the data plane (network device processor processing network data packets, para. [0099]).
As per claim 18, claim 17 is incorporated and Agarwal further discloses wherein the link-local multicast or broadcast message is a Dynamic Host Configuration Protocol (DHCP) message or a multicast Domain Name System (mDNS) message (any multicast and/or broadcast message, such as an mDNS message received from client device, para. [0016]).
Claim 19 is an independent claim and Agarwal discloses a method performed by a network device for suppressing flooding of link-local multicast or broadcast traffic, the method comprising:
receiving a link-local multicast or broadcast message from an endpoint that is connected to the network device (client device sends a multicast or broadcast packet, para. [0026], a user packet received from an end device at a network switch, para. [0055], FIG. 3A), the endpoint being part of a local network segment (user vlan VLAN.sub.NATIVE 355 which the packet was received from, para. [0055]);
preventing the link-local multicast or broadcast message from being flooded on the local network segment (based on packet marking, the user packet will be flooded only on the service VLAN VLAN.sub.SERVICE 350, and not on the user VLAN VLAN.sub.NATIVE 355, which the packet was received from, para. [0055]); and
processing the link-local multicast or broadcast message via a CPU of the network device (network device processor processing network data packets, para. [0099]), the processing being performed in accordance with a networking protocol to which the link-local multicast or broadcast message pertains (any multicast and/or broadcast message, such as an mDNS message, para. [0016]).
As per claim 20, claim 19 is incorporated and Agarwal further discloses wherein the networking protocol is Dynamic Host Configuration Protocol (DHCP) or multicast Domain Name System (mDNS) (see para. [0016]).
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.
Claims 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal as applied above, and further in view of Xiaomu, et al (“A method and device for discovering equipment”, 09-18-2013, CN103312571A (English translation), hereinafter referred to as Xiaomu).
As per claim 13, claim 10 is incorporated and Agarwal does not specifically disclose, but Xiaomu teaches wherein the mDNS query includes a setting indicating that responses to the mDNS query should be unicast (in a multicast query request, set a response flag bit to indicate QU set to 1, page 5, 10th paragraph), and wherein the mDNS response is transmitted directly to the client via a unicast packet (QU set to 1 indicates a unicast response, see page 5, 10th paragraph).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the applicant’s claimed invention to incorporate Xiaomu’s flag for mDNS queries to control mDNS responses with Agarwal’s mDNS queries because it would have allowed for more efficient resource utilization when warranted.
As per claim 14, claim 10 is incorporated and Agarwal does not specifically disclose, but Xiaomu teaches wherein the mDNS query does not include a setting indicating that responses to the mDNS query should be unicast, and wherein the mDNS response is flooded on the local network segment (in a multicast query request, set a response flag bit to indicate QU set to 0 for devices in the LAN to return a multicast response).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the applicant’s claimed invention to incorporate Xiaomu’s flag for mDNS queries to control mDNS responses with Agarwal’s mDNS queries because it would have allowed for more efficient resource utilization when warranted.
Allowable Subject Matter
Claims 2-9, 12 and 15-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.
The following is a statement of reasons for the indication of allowable subject matter: The prior arts, whether alone or in combination, fail to teach or suggest the subject matter found in claims 2-9, 12 and 15-16 when considered in conjunction with the limitations of all their respective base claim and intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Pub. No. US 2025/0106062 A1 – generally teaches suppressing flooding of unknown multcast data packets.
CN 109194559 A – generally teaches dropping a multicast message to prevent multicast traffic flooding and avoid wasting network bandwidth.
Pub. No. US 2016/0006822 A1 – generally teaches using a QU flag and QM flag to signal response messages as unicast or multicast.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JONATHAN A BUI whose telephone number is (571)270-7168. The examiner can normally be reached Mon-Fri: 9AM - 530PM.
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, Nicholas R Taylor can be reached at (571) 272-3889. 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.
/JONATHAN A BUI/Primary Examiner, Art Unit 2443