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 .
Allowable Subject Matter
Claim 7 and 15 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.
The following is a statement of reasons for the indication of allowable subject matter: the prior art, either alone or in combination does not expressly disclose a unified API request that includes a header that indicates two-way secure socket layer (SSL) information associated with the user, the two-way SSL information is validated based on the comparison, and the two-way SSL information indicates a common name whitelisted domain associated with the user and a certification status associated with the user.
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.
Claim(s) 1-6, 8, 10-14 and 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jha et al (US 10,425,465) in view of Cross et al (US 2004/0162786).
Regarding claims 1, 10 and 17, Jha et al discloses a method, a device, comprising: one or more processors and a non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a device, cause the device to [column 2 lines 13-30]:
receiving, by an application programming interface (API) management platform and from a user equipment (UE), a request to a unified API proxy that supports multiple users with different certifications, different sets of registered endpoints, different API keys, and different authentication tokens, wherein the request is associated with a user of the multiple users [column 4 lines 5-17, column 7 lines 29-47, column 14 lines 21-40, column 15 lines 22-42] (the client makes an API request for a backend service which is verified by the proxy API).
However, Jha et al does not expressly disclose but Cross et al discloses performing, by the API management platform, an evaluation of the request based on a comparison of information indicated in the request and information associated with the user, wherein the request is accepted based on a validation of the request or the request is blocked based on an invalidation of the request [0023, 0026, 0066] (the digital identity with different security information is verified to allow the access to the API programs].
It would have been obvious to one of ordinary skill in the art at to create the invention as claimed for the following reasons. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Jha et al by performing an evaluation, for the purpose of validating security information, based upon the beneficial teachings provided by Cross et al, see for example [0066]. These modifications would result in ease of use and increased security, both of which are obvious benefits to the skilled artisan. Additionally, the cited references are in the field of computer security, as is the current application, and thus, are in analogous arts.
Regarding claims 2, 11 and 18, Jha et al and Cross et al disclose all the limitations of claims 1, 10, and 17. Jha et al additionally discloses wherein the unified API proxy is a single API proxy that simultaneously supports multiple internet facing users [column 4 lines 26-37] (the API is able to provide backend services to the requesting user).
Regarding claims 3, 12 and 19, Jha et al and Cross et al disclose all the limitations of claims 1, 10, and 17. Jha et al additionally discloses wherein the request is associated with a request uniform resource locator (URL) having a standardized URL pattern, and the request URL indicates one or more of: a domain name, a context path, a user name, an environment, a service name, or an endpoint [column 6 lines 36-52] (several information such as URL information is used to validate the request).
Regarding claims 4 and 13, Jha et al and Cross et al disclose all the limitations of claims 1, 10, and 17. Jha et al additionally discloses generating, based on the validation of the request, a target endpoint URL that is derived from the request URL, wherein the request URL is for a backend service [column 6 lines 36-52, column 1 lines 5-22] (several information such as URL information is used to validate the request).
Regarding claims 5 and 14, Jha et al and Cross et al disclose all the limitations of claims 1, 10, and 17. Jha et al additionally discloses wherein the request indicates one or more of an API key associated with the user or an authentication token associated with the user, and performing the evaluation of the request comprises: validating one or more of the API key or the authentication token based on the comparison; or invalidating one or more of the API key or the authentication token based on the comparison [column 7 lines 29-47] (a token can be used for validation).
Regarding claims 6, Jha et al and Cross et al disclose all the limitations of claims 1, 10, and 17. Jha et al additionally discloses wherein the request includes a header that indicates two-way secure socket layer (SSL) information associated with the user, and performing the evaluation of the request comprises: validating the two-way SSL information based on the comparison; or invalidating the two-way SSL information based on the comparison [column 14 lines 21-40, fig 14] (a key can be used for validation).
Regarding claims 8 and 16, Jha et al and Cross et al disclose all the limitations of claims 1, 10, and 17. Jha et al additionally discloses wherein the request indicates one or more registered endpoints associated with the user, and performing the evaluation of the request comprises: validating the one or more registered endpoints based on the comparison; or invalidating the one or more registered endpoints based on the comparison [column 15 lines 22-42] (a local proxy may be validated).
Regarding claims 20, Jha et al and Cross et al disclose all the limitations of claims 1, 10, and 17. Jha et al additionally discloses wherein the request indicates one or more of an API key associated with the user, an authentication token associated with the user, two-way secure socket layer (SSL) information associated with the user, or one or more registered endpoints associated with the user, and the one or more instructions, when executed by the one or more processors, further cause the device to: validate or invalidate one or more of the API key, the authentication token, the two-way SSL information, or the one or more registered endpoints based on the comparison [column 4 lines 5-17, column 7 lines 29-47, column 14 lines 21-40, column 15 lines 22-42] (the client makes an API request for a backend service which is verified by the proxy API).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jha et al (US 10,425,465) in view of Cross et al (US 2004/0162786) and in further view of Cantrell et al (US 9,531,801).
Regarding claims 9, Jha et al and Cross et al disclose all the limitations of claims 1, 10, and 17. Jha et al and Cross et al does not expressly disclose but Cantrell et al additionally discloses wherein the information associated with the user is indicated in a key value map (KVM) for registered users [column 11 lines 54-column 12 lines 9, fig 7].
It would have been obvious to one of ordinary skill in the art at to create the invention as claimed for the following reasons. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Jha et al and Cross et al by performing an evaluation, for the purpose of validating security information, based upon the beneficial teachings provided by Cantrell et al, see for example [column 11 lines 54-column 12 lines 9]. These modifications would result in ease of use and increased security, both of which are obvious benefits to the skilled artisan. Additionally, the cited references are in the field of computer security, as is the current application, and thus, are in analogous arts.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bommisetty et al (WO 2025/172853): discloses a method implemented at a common application programming interface (API) framework (CAPIF) core function is provided. The method includes establishing a secure session with an API invoker onboarded with the CAPIF core function from an onboarding based on onboarding information. The method includes receiving an onboarding update request message including the onboarding information from the API invoker, and validating the onboarding update request message and the onboarding based on the onboarding information. The method includes performing a renewal of the onboarding based on the onboarding update request message, and sending an onboarding update response message to the API invoker based on the renewal.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENDALL DOLLY whose telephone number is (571)270-1948. The examiner can normally be reached Monday-Friday 7am-3pm (EST).
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, Shewaye Gelagay can be reached at (571)272-4219. 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.
/KENDALL DOLLY/Primary Examiner, Art Unit 2436