DETAILED ACTION
This action is in response to the application filed on 19 December 2023.
Claims 1-20 are under examination.
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 .
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant's cooperation is requested in correcting any errors of which applicant may become aware in the specification.
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 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–3, 5–6 and 8–9 are rejected under 35 U.S.C. §102(a)(1) as being anticipated by Aiken et al (US Pub. 2002/0143965).
Regarding claim 1, Aiken discloses receiving, by one or more processors, a data packet transmitted to a destination node by a source node, the data packet comprising a source node identifier, because Aiken receives a client request including source IP address and source port number (Aiken ¶[0099]; Fig. 7 Block 705; Fig. 3A fields 330, 340). Aiken discloses determin[ing] the source node identifier matches an affinity group in a forwarding table by comparing the source IP/port to affinity table entries 330, 335, and 340 (Aiken ¶[0063]–[0065]; Fig. 3A; Fig. 7 Block 715). Aiken further discloses rout[ing] the data packet to a network service stack that is assigned to the matched affinity group, by selecting the receiving/owning stack field 320 and forwarding the request (Aiken ¶[0100]; Fig. 7 Blocks 725–735).
Regarding claim 2, Aiken discloses the data packet further comprises a destination node identifier, since packets include destination IP address and destination port (Aiken ¶[0099]; Fig. 7 Block 710; Fig. 3A entries 310, 315).
Regarding claim 3, Aiken discloses determin[ing] the destination node identifier matches the affinity group in the forwarding table by matching destination IP/port to affinity entries 310 and 315 (Aiken ¶[0063]–[0064]; Fig. 3A; Fig. 7 Block 715).
Regarding claim 5, Aiken discloses determin[ing] the source node identifier matches the affinity group causes the one or more processors to compare the source node identifier to a collection of affinity groups, because affinity table 300 contains multiple entries including source identifiers and corresponding stacks (Aiken ¶[0063]–[0065]; Fig. 3A).
Regarding claim 6, Aiken discloses receiv[ing], from the network service stack, a processed data packet and rout[ing] the processed data packet to the destination node, because the processed response is returned and forwarded back to the requester (Aiken ¶[0100]; Fig. 7 Blocks 735–740).
Regarding claim 8, Aiken discloses retriev[ing], from the forwarding table, an identifier of a next hop to steer the data packet toward the assigned network service stack, by retrieving the receiving/owning stack field 320 and forwarding the packet accordingly (Aiken ¶[0100]; Fig. 3A; Fig. 7 Blocks 725–730).
Regarding claim 9, Aiken discloses rout[ing] the processed data packet back to the enforcement node using tunnels, since the processed response is routed over internal paths between the server/application stack and the balancer (Aiken ¶[0100]; Fig. 5; Fig. 7 Blocks 735–740).
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 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 4, 7, and 10–20 are rejected under 35 U.S.C. §103 as being unpatentable over Aiken (US Pub. 2002/0143965) in view of Zhan (US Pub. 2025/0062980).
Regarding claim 4, Aiken does not teach the source node is in a first domain and the destination node is in a second domain, nor that the destination node identifier indicates a region in the second domain. Zhan teaches explicit network domains, including creation of a first network domain (Zhan Fig. 1, S400) and depiction of multiple domains such as Q1 and Q2 (Zhan Fig. 3). Zhan further teaches region-like groupings and master/slave node relationships based on routing-table-derived metrics (Zhan Fig. 5; Fig. 6, ¶ [0026], [0145]). It would have been obvious to incorporate Zhan’s domain and region structures into Aiken’s affinity system to enable domain-aware routing.
Regarding claim 7, Aiken does not teach determining affiliation using a master forwarding table, nor determining whether the source node or the destination node is affiliated in such a table. Zhan teaches domain-wide, synchronized routing information used to establish domain membership and node roles (Zhan Fig. 1 S300; Fig. 7) and teaches determining node affiliation using this consolidated table-derived information (Zhan Fig. 5; Fig. 6, ¶ [0026], [0145])). It would have been obvious to combine Zhan’s domain-wide table structure with Aiken’s affinity matching.
Regarding claim 10, Aiken teaches a routing system including client (source) and server/application stack (destination) communicating through a workload balancer (Aiken ¶[0023]–[0025]; Fig. 1). Aiken teaches processors configured to receive a data packet transmitted to the destination node by the source node, the data packet comprising a source node identifier, because incoming client requests include source IP address and port (Aiken ¶[0099]; Fig. 7 Block 705; Fig. 3A fields 330, 340).
Aiken further teaches determin[ing] the source node identifier matches an affinity group in a forwarding table, because Aiken compares the source IP/port to affinity entries 330, 335, and 340 in affinity table 300 (Aiken ¶[0063]–[0065]; Fig. 3A; Fig. 7 Block 715).
Aiken also teaches rout[ing] the data packet to a network service stack that is assigned to the matched affinity group, by selecting receiving/owning stack 320 and forwarding the request (Aiken ¶[0100]; Fig. 7 Blocks 725–735).
However, Aiken does not teach a source node within a first domain and a destination node within a second domain. Zhan teaches explicit network domains, including creation of a first network domain (Zhan Fig. 1, S400) and depiction of multiple domains such as Q1 and Q2 (Zhan Fig. 3, ¶ [0026], [0145])). Zhan further teaches region-like groupings and node-role classification within domains based on routing-table–derived information (Zhan Fig. 5; Fig. 6).
A POSITA would have found it obvious to incorporate Zhan’s domain architecture into Aiken’s affinity-based routing to support domain partitioning of client nodes and service stacks, consistent with predictable use of known techniques in a related routing context. Therefore, claim 10 is unpatentable over Aiken in view of Zhan.
Regarding claim 11, Aiken further teaches the data packet includes a destination node identifier (Aiken ¶[0099]; Fig. 3A entries 310, 315).
Regarding claim 12, Aiken further teaches determin[ing] the destination node identifier matches the affinity group in the forwarding table, but because claim 12 depends from claim 10, claim 12 is also unpatentable over Aiken in view of Zhan.
Regarding claim 13, Aiken teaches compar[ing] the source node identifier to a collection of affinity groups (Aiken ¶[0063]–[0065]), but since claim 13 depends from claim 10, claim 13 is unpatentable over Aiken in view of Zhan.
Regarding claim 14, Aiken does not teach determin[ing] the destination node is located in a same region as the one or more processors, nor routing to a stack in that region. Zhan teaches region-like groupings and domain-based node clustering (Zhan Fig. 3; Fig. 5; Fig. 6, ¶ [0026], [0145])). Combining Zhan with Aiken would make it obvious to route packets to a service stack in the same region.
Regarding claim 15, Aiken does not teach determin[ing] the destination node is located in a different region nor routing accordingly. Zhan teaches distinguishing nodes inside and outside a domain (Zhan Fig. 3; Fig. 5; ¶ [0026], [0145])) and grouping nodes based on domain membership. It would have been obvious to use Zhan’s region/domain distinctions in Aiken’s routing.
Regarding claim 16, Aiken teaches processors executing stored instructions for receiving and routing packets (Aiken ¶[0023]–[0025]; Fig. 1). Aiken teaches receiv[ing] a data packet transmitted to a destination node by a source node, the data packet comprising a source node identifier, because incoming requests include source IP address and port (Aiken ¶[0099]; Fig. 7 Block 705; Fig. 3A fields 330, 340).
Aiken further teaches determin[ing] the source node identifier matches an affinity group in a forwarding table, by comparing the source IP/port to affinity entries 330, 335, and 340 (Aiken ¶[0063]–[0065]; Fig. 3A; Fig. 7 Block 715).
Aiken also teaches rout[ing] the data packet to a network service stack that is assigned to the matched affinity group, by selecting stack identifier 320 and forwarding accordingly (Aiken ¶[0100]; Fig. 7 Blocks 725–735).
However, Aiken does not teach instructions executing within a multi-domain networking context. Zhan teaches explicit construction of network domains (Zhan Fig. 1, S400), synchronization of routing tables across domain members (Zhan Fig. 1, S300; Fig. 7), and depiction of nodes distributed across separate domains (Zhan Fig. 3). Zhan further teaches domain membership determination and hierarchical node roles using routing-derived data (Zhan Fig. 5; Fig. 6, ¶ [0026], [0145])).
Integrating Zhan’s domain-aware architecture with Aiken’s affinity routing would have been an obvious improvement to support domain-based segmentation and scaling of routing decisions. Therefore, claim 16 is unpatentable over Aiken in view of Zhan.
Regarding claim 17, although Aiken teaches receiving and routing processed packets (Aiken ¶[0100]; Fig. 7 Blocks 735–740), because claim 17 depends from claim 16, claim 17 is unpatentable over Aiken in view of Zhan.
Regarding claim 18, Aiken does not teach the source node is in a first domain and the destination node is in a second domain, whereas Zhan teaches explicit multi-domain structures (Zhan Fig. 1; Fig. 3, ¶ [0026], [0145])). It would have been obvious to apply Zhan’s domain structure to Aiken. Therefore, claim 18 is unpatentable over Aiken in view of Zhan.
Regarding claim 19, Aiken teaches a destination identifier but not that it indicates a region in the second domain. Zhan teaches region determinations and domain-group relationships (Zhan Fig. 3; Fig. 5; Fig. 6). Combining Zhan’s region information with Aiken’s routing renders claim 19 obvious. Therefore, claim 19 is unpatentable over Aiken in view of Zhan.
Regarding claim 20, Aiken teaches compar[ing] the source node identifier to a collection of affinity groups (Aiken ¶[0063]–[0065]; Fig. 3A), but because claim 20 depends from claim 16, claim 20 is unpatentable over Aiken in view of Zhan.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure (see form 892).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARCUS R SMITH whose telephone number is (571)270-1096. The examiner can normally be reached on Monday-Friday 9:00 AM -5:00 PM.
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, Marcus Smith can be reached on (571) 272-0734. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Luat Phung/
Primary Examiner, Art Unit 2468