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 .
This Office Action is in response to the communications for the present US application number 18/784,707 last filed on July 25th, 2024.
Claims 1-20 are pending and have been examined, directed to METHOD FOR PROBING NETWORK PATHS IN DISAGGREGATED SCHEDULED FABRICS AND A SYSTEM THEREOF.
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, 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 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. US 2018/0062990 A1 to Kumar et al.
As to claim 1, Kumar discloses a device, comprising:
a processor (e.g., Kumar: ¶¶ 49-50); and
a memory communicatively coupled to the processor (e.g., Kumar: ¶¶ 49-50), wherein the memory comprises a path probing logic that is configured to:
receive a probe command associated with a destination device (Kumar discloses the system receiving probe requests for path detection and health monitoring, and each probe request would have a source and destination, e.g., Kumar: ¶¶ 15-16 and 27-28, and 30-31);
select at least one network path associated with the destination device (the SDN can optimize the path detection and selection process, e.g., Kumar: ¶¶ 27-28, and 30-31);
construct a fabric header indicative of the at least one network path (While Kumar does not explicitly use the terms “header” here, Kumar does describe of how the probe packets are generated with specific header based information like source IP address, destination IP address, etc. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the present application, that Kumar’s system is generating the probe packets with the appropriate header information to send to the selected pathways to reach the destination device/system at the destination IP address (e.g., Kumar: ¶¶ 27-28 and 31).
Also, while Kumar does not use the term fabric, it is understood by one of ordinary skill in the art, before the effective filing date of the present application, that a network fabric would be a highly interconnected topology, as with leaf-spine, and often have an SDN, all of which are present in Kumar’s disclosure (e.g., Kumar: Fig. 1-2)); and
generate a probe packet comprising the fabric header (Following the above steps and interpretations, the probe packet would be generated and sent along the selected pathway(s), e.g., Kumar: ¶¶ 16 and 28-32).
As to claim 2, Kumar further discloses the device of claim 1, wherein the path probing logic is further configured to access a database, and wherein the database is configured to store routing data indicative of a plurality of network paths (e.g., Kumar: ¶¶ 29-31).
As to claim 3, Kumar further discloses the device of claim 2, wherein the selection of the at least one network path is based on the plurality of network paths (e.g., Kumar: ¶¶ 30-31 and Figs. 1-2).
As to claim 4, Kumar further discloses the device of claim 3, wherein the path probing logic is further configured to determine at least one system port associated with the at least one network path (a source/destination pair would have its port(s) information associated to the selected path, e.g., Kumar: ¶¶ 28-32).
As to claim 5, Kumar further discloses the device of claim 4, wherein the path probing logic is further configured to map the probe packet to a virtual output queue associated with the at least one system port (e.g., Kumar: ¶¶ 38).
As to claim 6, Kumar further discloses the device of claim 4, wherein the path probing logic is further configured to identify, based on the routing data, at least one adjacent device associated with the at least one network path (Kumar discloses of incrementing port numbers, which means the system keeps track of adjacent ports and associated devices/systems, e.g., Kumar: ¶¶ 16, 28, and 46 and Figs. 3-4).
As to claim 7, Kumar further discloses the device of claim 6, wherein the path probing logic is further configured to identify, based on the routing data, at least one adjacent device port of the at least one adjacent device (e.g., Kumar: ¶¶ 16, 28, 38-39, and 46 and Figs. 3-4).
As to claim 8, Kumar further discloses the device of claim 7, wherein the at least one adjacent device port is connected to the destination device (e.g., Kumar: ¶¶ 16, 28, 38-39, and 46 and Figs. 3-4).
As to claim 9, Kumar further discloses the device of claim 8, wherein the fabric header comprises a fabric element field indicative of at least one of: an adjacent device identifier associated with the at least one adjacent device, or an adjacent device port identifier associated with the at least one adjacent device port (Following from claims 1, 4, and 6-8, the names or identifiers of each port are known, e.g., Kumar: ¶¶ 16, 28, and 39).
As to claim 10, Kumar further discloses the device of claim 9, wherein the fabric header further comprises a fabric link identifier associated with the at least one network path (Following from claims 1, 4, and 6-9, the system within this network/fabric would generate the probe packets with appropriate header information to send towards the selected pathways, and so the header section would include information like the source and destination IP addresses pairings, which maps to an associated pathway, e.g., Kumar: ¶¶ 27-28 and 31).
As to claim 11, Kumar further discloses the device of claim 10, wherein the path probing logic is further configured to transmit the probe packet to the at least one adjacent device through the at least one system port (Following from claims 1, 4, and 6-10, the probe packet would be generated with incremental ports, so the adjacent port would e selected, e.g., Kumar: ¶¶ 16, 28, and 46).
As to claim 12, Kumar further discloses the device of claim 11, wherein the probe packet is forwarded to the destination device based on the fabric header (Following from claims 1, 4, and 6-11, the probe packet would be sent along the selected pathway(s), based upon the information within the “header” section of the packets, as already established back in claim 1, e.g., Kumar: ¶¶ 16, 28-32, and 46).
As to claim 13, Kumar further discloses the device of claim 9, wherein the plurality of network paths interconnect a plurality of devices including the at least one adjacent device and the destination device (Following claims 1, 4, and 6-9, the system would be able to identify the interconnected devices, based on the probed pathways with the source/destination paired ports, which would include any adjacent devices, from the incrementing of the port numbers, e.g., Kumar: ¶¶ 16, 28-29, and 46).
As to claim 14, Kumar further discloses the device of claim 9, wherein the probe packet further comprises a network processing unit header and packet data (Following claims 1, 4, and 6-9, the generated probe packets would have a header and body (or packet data) sections).
As to claim 15, see the similar corresponding rejection of claim 1.
As to claim 16, see the similar corresponding rejections of claims 4 and 5.
As to claim 17, see the similar corresponding rejection of claim 7.
As to claim 18, see the similar corresponding rejection of claim 9.
As to claim 19, see the similar corresponding rejection of claims 11 and 12.
As to claim 20, see the similar corresponding rejection of claim 1 as claim 20 references the complimentary device on the receiving end.
Kumar further discloses a device, comprising:
a processor (e.g., Kumar: ¶¶ 49-50); and
a memory communicatively coupled to the processor (e.g., Kumar: ¶¶ 49-50), wherein the memory comprises a path probing logic that is configured to:
receive a probe command from a source device (Similar to claim 1, the probe packet would be coming from a source device/system, e.g., Kumar: ¶¶ 15-16 and 27-28, and 30-31);
retrieve a fabric header from the probe packet (Similar to claim 1, while Kumar does not explicitly use the terms “header” here, Kumar does describe of how the probe packets are generated with specific header based information like source IP address, destination IP address, etc. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the present application, that Kumar’s system is generating the probe packets with the appropriate header information to send to the selected pathways to reach the destination device/system at the destination IP address (e.g., Kumar: ¶¶ 27-28 and 31).
Additionally, while Kumar does not use the term fabric, it is understood by one of ordinary skill in the art, before the effective filing date of the present application, that a network fabric would be a highly interconnected topology, as with leaf-spine, and often have an SDN, all of which are present in Kumar’s disclosure (e.g., Kumar: Fig. 1-2));
determine an egress port based on the fabric header (Based upon the above interpretations, the system would send the probe packet in accordance with the source and destination information provided, e.g., Kumar: ¶¶ 17-18, 27-28 and 30-31);
identify a destination device associated with the egress port (The corresponding destination IP address and/or port would have its corresponding device, e.g., Kumar: ¶¶ 17-18, 27-28 and 30-31); and
forward the probe packet to the destination device through the egress port (e.g., Kumar: ¶¶ 17-18, 27-28 and 30-31).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Xiang Yu whose telephone number is (571)270-5695. The examiner can normally be reached M-F 9:30-3:00 (PST/PDT).
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, Emmanuel Moise can be reached at (571)272-3865. 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.
/Xiang Yu/Examiner, Art Unit 2455