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 .
This office action is responsive to communication filed on 09/26/2024.
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.
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 nonobviousness.
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.
Claims 1, 4, 9 – 11, 14, and 19 - 20 are rejected under 35 U.S.C. 103 as being unpatentable over Windisch et al (US 20060018333; hereinafter Windisch in view of N et al (US 2024/0137307; hereinafter N).
Regarding claim 1, Windisch discloses a method, comprising:
receiving, by a network device in a network, a static multicast route associated
with a multicast group and a source of the multicast group (paragraphs [0006], [0010]; Windisch discloses that IP multicast may be deployed on a computer network using a specific rendezvous point to build a shared multicast distribution tree for a multicast group falling within a destination address prefix or to build a separate SPT for each source originating traffic to the multicast group.), the network device comprising a plurality of ingress interfaces, each corresponding to a path via which the network device is reachable from the source (paragraphs [0010], [0022]; Windisch discloses that the MFIB performs a lookup operation into its forwarding table to find a route of an entry that matches a multicast destination address of the packet. The matching route instructs the router as to which egress interfaces the packet should be forwarded);
determining, based on an indicator in the static multicast route, that the network device is to dynamically select an ingress interface for the static multicast route (paragraphs [0010], [0022]; Windisch discloses that PIM populates an entry of the MFIB forwarding table with routing information (i.e., a route) that specifies an ingress interface on which an incoming multicast packet should be accepted, as well as a list of egress interfaces over which the incoming packet should be forwarded).
Windisch discloses all the limitations, but fails to specifically disclose the steps of determining respective weights allocated to the plurality of ingress interfaces; selecting the ingress interface for the static multicast route from the plurality of ingress interfaces based on their respective weights; and programming the static multicast route in forwarding hardware of the network device with the selected ingress interface.
N, in an analogous art, discloses the steps of determining respective weights allocated to the plurality of ingress interfaces (paragraphs [0006 – 0008]; N discloses that the egress network device may receive messages from each of the ingress network devices that specify an upstream multicast hop (UMH) weight value for the corresponding ingress network device); selecting the ingress interface for the static multicast route from the plurality of ingress interfaces based on their respective weights (paragraphs [0006 – 0008]; N discloses that selecting, by the egress network device and based on the upstream multicast hop weight values specified by the received messages, one of the plurality of ingress network devices to which to send a multicast join message of a plurality of multicast join messages for the multicast source and multicast group; and sending, by the egress network device, the multicast join message to the selected one of the plurality of ingress network devices); and programming the static multicast route in forwarding hardware of the network device with the selected ingress interface (paragraphs [0074], [0095]; N discloses that routing component 56 analyzes routing information 62 and multicast state information 64 to generate forwarding information 78 installed in forwarding component 58. Forwarding component 58 provides data plane functionality for network device 50. Although not shown in FIG. 5, forwarding component 58 may comprise a central processing unit (CPU), memory and one or more programmable packet-forwarding application-specific integrated circuits (ASICs)).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teaching of Windisch by determining respective weights allocated to the plurality of ingress interfaces; selecting the ingress interface for the static multicast route from the plurality of ingress interfaces based on their respective weights; and programming the static multicast route in forwarding hardware of the network device with the selected ingress interface as evidenced by N for the purpose of flexibly distributing multicast join messages to enable tailored delivery of multicast traffic; thereby ensuring a highly reliable manner of sending multicast messages.
Regarding claim 4, Windisch and N disclose the method of claim 1, further comprising:
receiving multicast traffic from the source at the plurality of ingress interfaces (paragraphs [0008 - 0009], [0022 – 0023]); and
forwarding, to a requesting host, the received multicast traffic based on the programmed static multicast route in the forwarding hardware (paragraphs [0008 – 0009], [0022 – 0023]; N discloses that send the multicast join message to the selected one of the plurality of ingress network devices). Sa motivation as in claim 1.
Regarding claim 9, Windisch and N discloses the method of claim 1, further comprising: receiving, by the network device, a configuration command comprising the static multicast route with the indicator (paragraphs [0010], [0022], [0039]);
detecting the indicator in the configuration command (paragraph [0051]); and
selecting the ingress interface for the static multicast route from the plurality of ingress interfaces (paragraph [0051]; Windisch discloses that A multicast routing protocol populates an MFIB entry with information that specifies an ingress interface on which an incoming multicast packet should be accepted, as well as a set of egress interfaces over which the incoming packet should be forwarded).
Regarding claim 10, Windisch discloses the method of claim 9, wherein the indicator specifies an RPF interface as the ingress interface for the source in the configuration command (paragraph [0052]; Windisch discloses that for example in response to receiving an incoming multicast packet, the router consults the MFIB to find an entry that matches the multicast destination address of the packet. The matching MFIB entry instructs the router as to which egress interfaces the packet should be forwarded. Typically, the multicast packet is accepted on a single ingress interface i.e., the RPF interface that represents the shortest path to the source, and is forwarded out a set of egress interfaces to other destinations (routers) that have expressed interest in receiving the data traffic).
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Windisch et al (US 20060018333; hereinafter Windisch in view of N et al (US 2024/0137307; hereinafter N), and further in view of Iovine et al (US 8,995,275; hereinafter Iovine).
Regarding claim 5, Windisch and N disclose all the limitations in claim 4, but fail to specifically disclose discarding the multicast traffic received at an unselected ingress interface of the plurality of ingress interfaces.
Iovine, in an analogous art, discloses discarding the multicast traffic received at an unselected ingress interface of the plurality of ingress interfaces (fig. 11; col. 12, lines 33 - 65; col. 14, lines 39 – 62; Iovine discloses that In the event that a host on the local LAN attempts to send multicast traffic to that unmapped group, the IP stack of the radio receiving the traffic from the upstream LAN may discard the traffic, since there may be no entry in the multicast routing table for that group).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Windisch and N by discarding the multicast traffic received at an unselected ingress interface of the plurality of ingress interfaces as evidenced by Iovine for the purpose of allowing a radio to select a single ingress interface, then choosing the appropriate egress interfaces in a away that avoids pushing duplicate traffic back onto those interfaces.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Windisch et al (US 20060018333; hereinafter Windisch in view of N et al (US 2024/0137307; hereinafter N), and further in view of Shinsuke Suzuki (US 20090135820; hereinafter Suzuki).
Regarding claim 6, Windisch and N disclose all the limitations in claim 1, but fails to specifically disclose that the plurality of ingress interfaces corresponds to equal-cost paths between the source and the network device.
Suzuki, in an analogous art, discloses that the plurality of ingress interfaces corresponds to equal-cost paths between the source and the network device (abstract; paragraphs [0006]; see claims 1, 4).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Windisch and N by showing that the plurality of ingress interfaces corresponds to equal-cost paths between the source and the network device as evidenced by Suzuki for the purpose of efficiently implementing the multicast service in a multicast network in a reliable manner.
Allowable Subject Matter
Claims 2 – 3, 7 – 8, 12 – 13, and 17 – 18 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.
Claims 10 – 11, 14, and 19 - 20 incorporate substantively all the limitations of claims 1, 4 - 6, and 9 in system and computer product form rather than method form with minor modifications in the claimed language. The reasons for rejecting claims 1, 4 - 6, and 9 apply in claims 10 – 11, 14, and 19 - 20. Therefore, claims 10 – 11, 14, and 19 – 20 are rejected for the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
LIU et al (US 2023/0155921) discloses multicast packet sending method, apparatus, and system.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YVES DALENCOURT whose telephone number is (571)272-3998. The examiner can normally be reached M-F 8AM-5:30PM.
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, Ario Etienne can be reached at 571-272-4001. 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.
/YVES DALENCOURT/Primary Examiner, Art Unit 2457