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 .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1 – 3, 8 – 10, and 15 - 17 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 4, 7, 15, 16, and 19 of U.S. Patent No. US-12081585-B2. Although the claims at issue are not identical, they are not patentably distinct from each other because each element of the above noted pending claims is fully anticipated by an element corresponding patented claim.
Regarding pending claim 1, said claim is anticipated by patented claims 1 and 4 as illustrated below. Note that pending claim 1 corresponds to a method performed at a client, where patented claim 1 corresponds to a method performed at a server. In other words, the pending claims are directed to the client half of a client/server exchange, while the patented claims are directed to the server half of the same client/server exchange; the presently claimed client device corresponds to the client device appearing in patented claim 1.
Pending claim 1
A computer-implemented method performed at a client device, the method comprising:
transmitting a request to a processing server to join an application server;
receiving a virtual internet protocol (VIP) address, a private IP address for a targeted application server, a port number, and a token from the processing server;
generating an ingress packet, wherein the ingress packet includes a routing and authentication header that includes the token and a message; and transmitting the ingress packet to the VIP address associated with a demultiplexer.
Patented claim 1
A computer-implemented method performed at a processing server, the method comprising:
receiving a request to join an application server from a client device;
identifying a targeted application server from a set of application servers, a private internet protocol (IP) address for the targeted application server, and a port number associated with the targeted application server; generating a token based at least in part on the private IP address for the targeted application server . . .
Patented claim 4
The method of claim 1, further comprising:
receiving, from the client device, an ingress packet . . . wherein the ingress packet includes a routing and authentication header; receiving, from the client device, an ingress packet at a demultiplexer that corresponds to the VIP address.
Pending claim 2
The method of claim 1, wherein the demultiplexer authenticates the token and responsive to the token being valid,
generates an encapsulated packet from the ingress packet that enables the application server to communicate directly with the client device.
Patented claim 4
determining, using a secret key, whether the token is valid; and responsive to determining that the token is valid . .
Patented claim 7
. . . wherein forwarding the ingress packet to the targeted application server includes using a tunnel to forward the ingress packet by generating an encapsulated packet.
Pending claim 3
The method of claim 2, further comprising: responsive to the demultiplexer confirming that the token is valid, receiving communications at the client device directly from the targeted application server.
Patented claim 4
The method of claim 1, further comprising:
. . . at a demultiplexer . . . determining that the token is valid, forwarding the ingress packet to the targeted application server
Regarding pending claims 8 and 15, said claims corresponds to patented claims 15 and 16 in the same manner pending claim 1 corresponds to patented claim 1.
Regarding pending claims 9 and 16, said claims corresponds to patented claims 19 and 7 in the same manner pending claim 2 corresponds to patented claims 4 and 7.
Regarding pending claims 10 and 17, said claims corresponds to patented claim 19 and in the same manner pending claim 3 corresponds to patented claim 4.
Claims 4, 7, 11, 14, and 18 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 4 and 8 of U.S. Patent No. US-12081585-B2 in view of Arai (US-20150350311-A1).
Regarding pending claim 4, said claim is anticipated by patented claims 1, 4, and 8 as illustrated below:
Pending claim 4
The method of claim 2, further comprising:
responsive to the demultiplexer determining that the token is invalid . . .
Patented claim 8
The method of claim 4, further comprising:
responsive to determining that the token is invalid . . .
US-12081585-B2, while claiming the demultiplexer (see the above analysis of patented claim 4) does not claim receiving a notification that the token is invalid. Arai shows receiving a notification that the token is invalid ([237, 241], claim 9 on pg. 34, claim 19 on page 5).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify patented claim 4 of US-12081585-B2 with the notification techniques of Arai in order to enable the client to respond and adapt to improper requests, thus better ensuring that clients can utilize the offered services provided by the application server.
Regarding pending claim 7, said claim is anticipated by patented claims 1 and 4 as illustrated below:
Pending claim 7
The method of claim 1, further comprising: . . . the demultiplexer.
Patented claim 4
The method of claim 1, further comprising: receiving, . . . at a demultiplexer . .
US-12081585-B2 does not claim receiving a notification that the ingress packet is invalid. ([237, 241], claim 9 on pg. 34, claim 19 on page 5).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify patented claim 4 of US-12081585-B2 with the notification techniques of Arai in order to enable the client to respond and adapt to improper requests, thus better ensuring that clients can utilize the offered services provided by the application server.
Regarding pending claims 11 and 18 said claims corresponds to patented claims 4 and 19 in view of Arai in the same manner pending claim 4 corresponds to patented claim 8 in view of Arai.
Regarding pending claim 14, said claim corresponds to patented claim 19 in view of Arai in the same manner pending claim 7 corresponds to patented claim 4 in view of Arai.
Claims 5, 12, and 19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 4, 15, 16, and 19 of U.S. Patent No. US-12081585-B2 in view of RFC 7230 (R. Fielding and J. Reschke. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing (RFC 7230). (Year: 2014)).
Regarding pending claim 5, the method of claim 1 is anticipated by patented claims 1 and 4, and further discusses the ingress packet via the ingress packet recited in patented claim 4.
US-12081585-B2 does not claim inclusion of an extensible custom application-layer header. RFC 7230 suggests use of an extensible custom application-layer header (pg. 23, Section 3.2.1, where RFC 7230 is directed to HTTP, an exemplary application-layer protocol).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify patented claims 1 and 4 of US-12081585-B2 with the standardized use of HTTP discussed in the RFC 7230 standards document in order to utilize a common, well-understood protocol (i.e., HTTP) in the manner intended.
Regarding pending claims 12 and 19, said claims corresponds to patented claims 16 in view of 19 and RFC 7230 in the same manner pending claim 5 corresponds to patented claims 1 and 4 in view of RFC 7230.
Claims 6, 13, and 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 15, and 16 of U.S. Patent No. US-12081585-B2 in view of Krause (US-20130170451-A1).
Regarding pending claim 6, patented claim 1 anticipated pending claim 1, including discussion of the targeted application server (see “identifying the targeted application server” in the second clause of patented claim 1) and the ingress packet (the transmitted data, including the VIP address, private IP address, port number, and token claimed in the concluding clause of patented claim 1). Patented claim 1 does not anticipate receiving a responsive encapsulated packet. Krause shows receiving a responsive encapsulated packet ([62] and Fig. 9).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify patented claim 1 US-12081585-B2 with the encapsulation of Krause in order to facilitate support for additional types of protocols being transmitted over existing network interfaces, supporting a more flexible and efficient networking architecture.
Regarding pending claims 13 and 20, said claims are anticipated by patented claims 15 and 16 in view of Krause in the same manner that pending claim 6 is anticipated by patented claim 1 in view of Krause.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1 – 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Regarding claim 1, said claim concludes with the recitation of “transmitting the ingress packet to the VIP address associated with a demultiplexer”. While a “VIP address” is supported in claim 1, there is no antecedent basis for “the VIP address associated with a demultiplexer”.
Regarding claims 8 and 15, said claims recite subject matter analogous to that addressed above in claim 1, and thus suffer from issues analogous to those in claim 1. Regarding claims 2 – 7, 9 – 11, and 16 – 20, each of said claims depends on one of claims 1, 8, and 15, and fails to clarify the issues noted above. Further regarding claim 4, said claim recites being responsive to “determining that the token is invalid”. While parent claim 2 provides antecedent basis for a determination for “the token being valid”, there is no support for a determination that a token is “invalid”.
Further regarding claim 6, said claim recites a reception “from the targeted application server” that includes a “response to the ingress packet”. Parent claim 1 provides support for sending the ingress packet to a “VIP address associated with a demultiplexer”, but provides no other association between the ingress packet and the “targeted application sever”; i.e., claim 1 recites a targeted application server but fails to link this server to the ingress packet, and thus it is unclear how the “targeted application server” response in claim 6 is associated with this “ingress packet”. In other words, it is unclear how the targeted application server may be responsive to a packet that it has no claimed association with. Regarding claims 11 and 18, said claims recite subject matter analogous to that addressed above in claim 4, and thus suffer from issues analogous to those in claim 4. Regarding claims 13 and 20, said claims recite subject matter analogous to that addressed above in claim 6, and thus suffer from issues analogous to those in claim 6.
Subject Matter Allowable over Prior Art
Claims 1 - 20 would be allowable, absent the pending Double Patenting rejections and clarity issues noted in the rejections made under 35 USC 112. The presently pending claims correspond to a client process/device of a client/server exchange. Parent application 17/704,767 (now patent US-12081585-B2) claims the server process/device of this exchange. Thus the prior art cited in the analysis of US-12081585-B2 remains highly relevant to the present application, as do the reasons for allowance presented in US-12081585-B2. Just as the prior art failed to teach or suggest the server of US-12081585-B2, the client presently claimed is similarly lacking. When considering the limitations as recited in the entirety of said claims, the particular mechanisms utilizing a VIP address, private IP address of a target application server, a port number, and a token to generate the claimed authentication-header contained ingress packet is neither anticipated nor would have been rendered obvious over the prior art. Just as noted in the parent application, while many of the individual functionality recited in claims 1, 15, and 16 is anticipated by the prior art (e.g., token utilization, the use of virtual and private IP addresses, address mappings, authentication headers, etc.,) it is the particular combination of these features – and any suggestion or motivation to combine them in the manner as claimed - that is lacking in the prior art. Prior art most relevant to Applicant’s disclosure includes:
Sarangapani (US-9807016-B1) discusses processing client requests for services (col. 7 lines 41-45) from an application server (col. 7 lines 29-37). A targeted application server is identified along with its private IP address (col. 7 lines 28-48), and the private IP address of the server is mapped to a virtual IP address (col. 7 lines 34-36). However, Sarangapani lacks the token generation presently claimed, as well as the transmission of each of the private IP address, VIP address, port number and token to the requesting client.
Carney (US-20220029973-A1) provides relevant teachings regarding support for private networking where, via unique device ID generation and public/private key pairs, a user is authenticated for access to a web service ([12-14,16,20,22]). However, Carney lacks the VIP to IP address mapping claimed, and no VIP address, private IP address, token, and port number is ever returned to the accessing client. Furthermore, Carney lacks discussion regarding associating an accessing user with a particular (i.e., “targeted”) application server. Thus, despite having much in common and sharing many key terms with the present invention, the functioning of Carney is fundamentally different.
Chao (US-8553537-B2) generates tokens based on IP addresses for a targeted server (col. 4 lines 39-65) and also returns requesting clients a VIP address and port number of a particular server (coll. 5 lines 5-11, col. 5 lines 32-48). The claimed address mapping, however, is absent, and the way the generated token is utilized in Chao is different than the behavior presently claimed.
Pei (Pei, Chao, et al. English translation of CN_103491053_A_I. (Year: 2014)) discusses processing requests from clients ([38]) and identifying a targeted server via its port number and private IP address for handling the client request ([40] discussing a “real server” address and a “real port” that correspond to a private address and port number, in contrast with, e.g., their virtual address). Similar to the claimed invention, Pei also utilizes a combination of IP and UDP transmissions, including where the ingress packet at the VIP address occurs over UDP (Abstract, [10]). However, Pei lacks the token generation claimed, and the associating of an IP address with a VIP address in Pei is made differently than claimed; instead of linking a private IP address with the VIP address, the requesting client’s (public) IP address is linked ([10]). In addition, less information is returned by Pei to the requesting client.
Olteanu (Olteanu, Vladimir, et al. "Stateless datacenter load-balancing with beamer." 15th USENIX Symposium on Networked Systems Design and Implementation (NSDI 18). (Year: 2018)), similar to the present invention, is related to maintaining operational integrity of a pool of servers (Abstract). This is achieved via use of a virtual IP address Infront of a servers private addresses (pg. 1, R22-R27, pg. 3 L30-L35). Token generation via hashing is also utilized (pg. 3 R22-R30). Newton (US-20130173806-A1) discusses processing client requests for access to servers ([37,41]) as well as load-balancing techniques for identifying a targeted server to pair with the client ([53,60-63]). Suganthi (US-8213393-B2) discloses a similar operating environment to the one presently claimed, including functionality for associating a client with a particular application server from a group of servers (col. 7 lines 11-23, col. 8 lines 20-24, col. 9 lines 18-26) Additionally relevant prior art includes: Sharma (US-20210084003-A1) and McCullagh (US-10412159-B1).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN M MACILWINEN whose telephone number is (571)272-9686. The examiner can normally be reached Monday - Friday, 9:00 - 5:00.
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, Glenton B Burgess can be reached at (571) 272 - 3949. 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.
JOHN MACILWINEN
Primary Examiner
Art Unit 2442
/JOHN M MACILWINEN/Primary Examiner, Art Unit 2454