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 .
Response to Amendment
Applicants’ arguments filed on 26 May 2026 have been fully considered have been fully considered and are persuasive. The rejection of claims 1-20 has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Aiken et al, Yadav et al, and Janakiraman et al, as cited in the Office action herein.
By the amendment filed 26 May 2026, claims 1, 4, 16, and 19 have been amended.
Claims 1-17 and 19-20 are now pending.
Claims 1-7, 9-13, 15-17 and 19-20 are rejected; claims 8 and 14 are objected to.
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 1–3, 6, 10–13, 16, and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over Aiken et al. (US 2002/0143965 A1) in view of Yadav et al. (US 2021/0266251 A1).
Claim 1. Aiken receives a client request packet containing a source IP address. Its affinity table 300 stores client source-address entries and masks or prefixes in fields 330 and 335 and identifies an associated receiving or owning target stack in field 320. Aiken describes affinity covering a range of client addresses as “affinity group” processing. Its balancer matches an incoming request’s source address to an affinity entry, selects the associated stack, and forwards the request to that stack. Aiken thus teaches “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; determining, by the one or more processors, the source node identifier matches an affinity group in a forwarding table; and routing, by the one or more processors, the data packet to a network service stack that is assigned to the matched affinity group.” (Aiken ¶¶ [0057], [0063]–[0065], [0099]–[0100]; Figs. 3A and 7.)
Aiken does not expressly place the destination node “in a second domain” and source node “in a first domain.” Yadav teaches forwarding a packet from a source node in a first domain toward a destination node in another domain through a multidomain network. (Yadav Abstract; Fig. 1; claims 1 and 15.) A skilled person would have had reason to carry Aiken’s client requests over such a multidomain packet path to reach services deployed in another domain, retaining Aiken’s affinity lookup to select the target stack. Yadav supplies the packet path between domains; Aiken supplies the affinity-based forwarding decision.
Claim 2. Claim 2 further recites “wherein the data packet further comprises a destination node identifier.” Aiken’s request contains the destination server application’s IP address and port, which Aiken uses to identify that application. (Aiken ¶¶ [0063]–[0064], [0099]; Fig. 3A, fields 310 and 315; Fig. 7, block 710.)
Claim 3. Claim 3 further recites “prior to routing the data packet, determining the destination node identifier matches the affinity group in the forwarding table.” Aiken first identifies the target application from the destination IP address and port and then checks the applicable affinity entry before selecting the target stack. Its affinity table stores the destination application’s address and port in fields 310 and 315 and the client-affinity information under that application entry. (Aiken ¶¶ [0063]–[0065], [0099]–[0100]; Figs. 3A and 7.)
Claim 6. Claim 6 further recites “comparing the source node identifier to a collection of affinity groups, each affinity group including source node and network service stack pairs.” Aiken’s affinity table contains client-address entries associated with target stacks and its balancer compares an incoming source address with the entries to select the matching stack. (Aiken ¶¶ [0057], [0063]–[0065], [0099]–[0100]; Figs. 3A and 7.)
Claim 10. Claim 10 recites “a source node within a first domain; a destination node within a second domain; and one or more processors configured to: receive a data packet transmitted to the destination node by the source node, the data packet comprising a source node identifier; determine the source node identifier matches an affinity group in a forwarding table; and route the data packet to a network service stack that is assigned to the matched affinity group.” Aiken teaches the processor operations through its balancer, affinity table, source-address comparison, and target-stack selection. Yadav teaches a source node in a first domain forwarding a packet destined for a node in another domain. It would have been obvious to carry Aiken’s requests over that multidomain path while retaining Aiken’s disclosed affinity selection, for the reasons stated for claim 1.
Claim 11. Claim 11 further recites “wherein the data packet further comprises a destination node identifier.” Aiken teaches this limitation as stated for claim 2.
Claim 12. Claim 12 further recites “prior to routing the data packet, determine the destination node identifier matches the affinity group in the forwarding table.” Aiken teaches this limitation as stated for claim 3.
Claim 13. Claim 13 further recites “compare the source node identifier to a collection of affinity groups, each affinity group including source node and network service stack pairs.” Aiken teaches this limitation as stated for claim 6.
Claim 16. Claim 16 recites instructions on a “non-transitory computer readable storage medium” that cause processors to receive the first-domain-to-second-domain packet, match its source identifier to an affinity group in a forwarding table, and route it to the assigned network service stack. Aiken describes implementing its affinity-processing operations through program instructions executed by data-processing systems; its balancer performs the receiving, matching, and forwarding operations stated for claim 1. Yadav supplies the multidomain packet path for the same reason stated for claim 1. The medium limitation should be tied to Aiken’s specific computer-program or storage-medium disclosure in the final draft, rather than inferred solely from its flowchart.
Claim 20. Claim 20 further recites “compare the source node identifier to a collection of affinity groups, each affinity group including source node and network service stack pairs.” Aiken teaches this limitation as stated for claim 6.
Claims 4, 5, 7, 9, 15, 17, and 19 are rejected under 35 U.S.C. § 103 as being unpatentable over Aiken et al. (US 2002/0143965 A1) in view of Yadav et al. (US 2021/0266251 A1), and further in view of Janakiraman et al. (US 2021/0266256 A1).
Janakiraman teaches routing packets identified by source and destination IP information between distinct user VPCs through a service VPC. Its router uses route table 122a to select the service path and subsequently forward a serviced packet toward the destination VPC. Janakiraman also teaches distinct regions containing routers and service VPCs, with routing to a service instance in another region when appropriate. A person implementing Aiken’s source-address affinity selection over Yadav’s multidomain packet path would have had reason to use Janakiraman’s service-path and regional-routing techniques to reach the selected service stack and then the destination. This would retain Aiken’s affinity-based stack assignment while providing a route through that stack across the managed network.
Claim 4 recites “wherein: the destination node identifier indicates a region in the second domain where the destination node is located.” Aiken’s packet includes a destination IP address used to identify its destination application. Janakiraman describes distinct VPCs within cloud regions, unique VPC address spaces or CIDR blocks, and a router’s use of the destination VPC’s IP address in route table 122a to direct a packet toward that VPC. (Aiken ¶¶ [0063]–[0064], [0099]; Janakiraman Fig. 1B and discussion of VPC address ranges and route table 122a.) It would have been obvious to assign the destination VPC in the second domain an address range associated with its region, such that the destination node’s address or prefix identifies the region containing the node and permits forwarding toward it.
Claim 5 recites “wherein the source node identifier is an internet protocol (IP) prefix that corresponds to the source node, and wherein the destination node identifier is an IP prefix that corresponds to the destination node.” Aiken expressly uses a source subnet address and mask or prefix for affinity-group processing. Janakiraman teaches assigning VPCs unique address ranges or CIDR blocks and routing using source and destination VPC IP information. A skilled person would have used the destination VPC’s CIDR prefix to identify destinations in that VPC, alongside Aiken’s source prefix, when applying the combination’s routing rules. (Aiken ¶ [0057]; Janakiraman discussion of VPC CIDR blocks and route table 122a.)
Claim 7 recites “receiving, by the one or more processors and from the network service stack, a processed data packet; and routing, by the one or more processors, the processed data packet to the destination node.” Janakiraman’s router sends a packet to service VPC 106i, receives it back after service A is performed, and subsequently forwards it along the service path and ultimately to destination VPC 106b. Applying this return-and-forward path to Aiken’s selected target service stack would allow the routing processors to receive the serviced packet and forward it toward its destination. (Janakiraman Fig. 1B; discussion of tunnels 114i and 114b and route table 122a.)
Claim 9 recites “determining the destination node is located in a different region than the one or more processors, wherein routing the data packet includes routing the data packet to the network service stack, the network service stack being in the different region than the one or more processors.” Janakiraman teaches routers and service VPC instances in different regions and routing a packet from receiving router 118a to a service instance through router 118b in another region. It also describes route-table decisions using the destination VPC’s IP information. For a destination VPC deployed in that other region, a skilled person would have used the destination’s address and route information to identify its region and route the packet to the assigned service instance there, avoiding an additional inter-region trip for service processing. (Janakiraman Figs. 1A–1C; discussion of router 118b and the remote service VPC.)
Claim 15 recites “determine the destination node is located in a different region than the one or more processors, wherein routing the data packet includes routing the data packet to the network service stack, the network service stack being in the different region than the one or more processors.” The limitation is taught or suggested for the system of claim 10 for the reasons stated for claim 9.
Claim 17 recites “receive, from the network service stack, a processed data packet; and route the processed data packet to the destination node.” The instructions of claim 16 would perform the return-and-forward operations for the reasons stated for claim 7. Aiken expressly describes a computer program product embodied on computer-readable media for receiving client requests and routing them using stored affinity information; Janakiraman supplies the serviced-packet return path.
Claim 19, as amended, depends from claim 16 and recites “wherein the data packet further comprises a destination node identifier; and wherein the destination node identifier indicates a region in the second domain where the destination node is located.” Aiken teaches the destination address in the received request; the destination-address-to-region modification is set forth for claim 4.
Allowable Subject Matter
Claims 8 and 14 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 LUAT T PHUNG whose telephone number is (571)270-3126. The examiner can normally be reached on M-F 9 AM - 6 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-3988. 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
