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 .
Continued Examination Under 37 CFR 1.114
1. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on December 30, 2025 has been entered.
Response to Arguments
2. Applicant’s arguments filed on 12/30/2025 regarding claims 21-45 in the remarks are fully considered but moot in view of new ground(s) of rejection.
Response to Amendments
Claim Rejections - 35 USC § 103
3. 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.
4. Claim(s) 21-25, 27, 28-33, 35, 36-39, 41-43 and 45 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rangasamy (US Patent No. 11,228,573) in view of Kamalakantha (US PG Pub. No. 2017/0351536) and further in view of Pal (US PG Pub. No. 2017/0359308) and Dukes (US Patent No. 8,612,612).
As per claim 21:
Rangasamy teaches network apparatus (see Figure 1, API exchange 101) to be communicatively coupled to at least one computing device (see Figure 1, API exchange 101 coupled to customer device(s) 130. Note: Examiner is reading said customer device(s) 130 as said computing device(s) 130), the network apparatus also to be communicatively coupled, via at least one cloud network, to at least one cloud service provider (see Figure 1, API exchange 101 coupled to application instances 110C and 110D of cloud network 108C via service gateway 112C), the network apparatus comprising:
application programming interface (API) gateway circuitry (see Figure 3, API exchange server 401 comprise of processor 412. Said processor 412 together with the service MAP 450 may match on the destination network address and the destination port of one or more packets of the service request 425A and specify a destination endpoint of service gateway 440B, see Col 23, lines 20-45) configurable to (1) map received network packet data to at least one corresponding service of the at least one cloud service provider (see Col 10, lines 10-13, API exchange 101 maps the service request 124A received at port 107 to API endpoint 114C. Note: Examiner is reading said API endpoint 114C as said corresponding service especially since they are usable for accessing the API/application 110C of the cloud network 108C, please see Col 10, lines 50-55) and (2) generate request data for use in requesting providing of the at least one corresponding service (see Col 10, lines 11-17, after mapping the service request 124A to API endpoint 114C, a new service request 124A’ is generated which includes service data from service request 124A and includes layer 4 header and a layer 3 header which causes the new service request 124A to be received at the API endpoint 114C exposed by service gateway 112C), the received network packet data being received from the at least one computing device by the network apparatus (see Figure 1, service request 124A is received by the API exchange 101 from customer device(s) 130), the at least one corresponding service to be provided in response, at least in part, to the request data (see Col 10, lines 38-51, service instance of application 110C in response to receiving the service request 124A’ from the service gateway 112C may generate a service response 124B destined for customer port 107 of API exchange 101), the providing of the at least one corresponding service to result in generation of response data to be provided to the at least one computing device via the at least one cloud network and the network apparatus (as shown figure 1, application 110C of the cloud network 108C sends the service response 124B to the customer device(s) via link 103C established between the service gateway 112C and the API exchange 101 and the link 102 established between API exchange 101 and customer device(s) 130 using API endpoint 114C, API exchange 106C and customer port 107. Note: each of the respective applications 110A-110D are configured to offer services upon receipt of service request from the respective service gateways 112A-112C, please see Col 7, lines 23-67);
and communication interface circuitry (see Figure 3, API exchange server 401 also comprise of communication units 402) to:
receive the network packet data (see Col 20, lines 60-67, communications unit 402 may receive data from external devices such as customer devices 130. Similarly, figure 1 shows API exchange 101 receiving said service request 124A from customer device(s) 130);
transmit the request data to the at least one cloud service provider via the at least one cloud network (see Figure 1, API exchange 101 transmitting service request 124’ to application instance 110C of cloud network 108C via the service gateway 112C);
and transmit the response data to the at least one computing device (see Figure 1, API exchange 101 transmitting/forwarding service response 124B’ to customer device(s) 130);
wherein:
a plurality of services are comprised, at least in part, in the at least one cloud service provider (see Col 6, lines 35-60, each of cloud networks 108 includes one or more host servers that each executes an instance of at least one of applications 110A-110D. Applications 110 offer services, such as data storage, eCommerce, billing, social media and other services accessible using machine-to-machine communication over the corresponding cloud network 108);
the plurality of services comprise the at least one corresponding service (see Col 7, lines 23-67 each of the respective applications 110A-110D are configured to offer services upon receipt of service request from the respective service gateways 112A-112C);
the plurality of services are configurable to include at least one firewall service (see Col 7, lines 50-59, besides routing service requests between requesters (i.e., issuers of service requests) and internal API endpoints, each of service gateways 112 may also verify requesters are authorized to make requests, prevent access to internal API endpoints by unauthorized requesters, perform load balancing among multiple service instances for the applications 110, etc.);
select, based at least in part upon the network packet data, the at least one corresponding service from among the plurality of services (see Col 10, lines 25-37, API exchange 101 may proxy a transport-layer (e.g., TCP) session between API exchange 101 and customer 130 and transport-layer session between API exchange 101 and a service instance of application 110C. In this way, API exchange 101 creates a service-to-service path for service requests and service responses between customer device 130 and service instance for application 110C);
and implement, at least in part, one or more of the plurality of services (see Col 10, lines 25-37, as explained earlier, since a service-to-service path is created service response for each service request may be transmitted from a service instance to the client via the API exchange 101), and the request data is to be generated based at least in part upon application layer policy data of the API gateway circuitry (see Col 20, lines 1-8, API exchange 301 in response to receiving service request 325A, may apply policies 332 to authorize, throttle, or route a representation of service 325A of service request 325A to API endpoint 314A as service request 325A’. Note: Examiner is reading said service request 325A’ as the generated request. See figure 3, Col 21, lines 65-67, Col 22, lines 1-13, the storage 440 may store one or more modules or applications. Operating system (OS 431) as the operating module may be operated in the application layer and further interact with the API exchange application 422 comprising the policies 423, please see Col 22, lines 9-13, lines 22-47).
Rangasamy does not clearly teach the plurality of services correspond, at least in part, to API calls for use, at least in part, in association with the API gateway circuitry;
the request data is for use in requesting calling of the at least one corresponding service.
Kamalakantha teaches the plurality of services correspond, at least in part, to API calls for use, at least in part, in association with the API gateway circuitry (see paragraph [0011], disclose API gateway for intercepting hypervisor manager native API calls so that requests of those API calls may be validated in relation to various protection(s) and restriction(s) provided by a cloud service provide. A native API call relates to request for a user to access particular resource (i.e., virtual machine, VM-101), please see paragraph [0025]. Therefore, the API native call is related to a service);
the request data is for use in requesting calling of the at least one corresponding service (see Figure 1, paragraph [0025] API gateway 121 comprise of instructions 122 for intercepting a hypervisor manager native API call from a user with identity “USER1”, requesting a resize operation on a virtual machine with an identifier of “VM-101” and instructions 124 may determine the series of validation checks to perform. Instructions 124 may perform a validation check to determine whether the particular user identity USER1 (i.e., requesting entity) has permission to resize a computing resource (i.e., VM-101). Note: Said API call of the user/client is identified based on its signature (e.g., the function name and number, order and types of parameters of the API call), please see paragraphs [0019] and [0044])).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the interception and validation of native API calls by API gateway (as disclosed in Kamalakantha) into Rangasamy as a way of enabling the API gateway to handle various protection(s) and restriction(s) provided by a cloud service provider for the cloud computing environment before the native calls are passed to underlying hypervisor manager instance(s) of the cloud computing environment behind the API gateway (please see paragraph [0011] of Kamalakantha).
The combination of Rangasamy and Kamalakantha do not teach the API gateway circuitry is configurable to:
provide application layer-related proxy services related to the plurality of services
Pal teaches the API gateway circuitry (see Figure 21, paragraph [0077], network channel process 2130 acting as dispatcher) is configurable to:
provide application layer-related proxy services related to the plurality of services (see Figure 21 and paragraph [0077], dispatcher 2130 for selectively directing requests from clients to particular proxy. System 2100 containing said dispatcher 2130 may enforce policies on the captured data at or near the application layer using library/storage channel disposition 2150. Upon receiving the request from the client, the dispatcher/network channel process 2130 may direct the request to one or more of the proxies for further processing to analyze and/or modify the network requests, please see paragraph [0078]).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the processing of processing of client requests at the application layer level (as disclosed in Pal) into Rangasamy and Kamalakantha as a way of enabling the channel process to further examine the static properties of the request before forwarding to the intended service (please see paragraphs [0083], [0087] and [0096] of Pal).
Rangasamy, Kamalakantha and Pal do not teach and the application layer policy data is dynamically changeable, at least in part, based upon resource availability and/or condition detection data.
Dukes teaches and the application layer policy data is dynamically changeable (see Col 1, lines 54-67. the policy control engine of the services module dynamically updates session policies applied for the subscriber session based on the identified application flows and a subscriber profile. Note: Said application flows are reassembled application-layer data from data packets in the subscriber session packet flow, please see Col 1, lines 54-60, and thus session policies are application layer policies), at least in part, based upon resource availability (Note: Limitation(s) is/are recited in alternate form and thus not addressed by the prior art) and/or condition detection data (Col 1, lines 60-67 disclose dynamically updating session policies applied for the subscriber session based on the identified application flows and a subscriber profile. Note: Examiner is reading said identified application flows and subscriber profile as said condition detection data).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to implement the updating of session policies (as disclosed in Dukes) into Rangasamy, Kamalakantha and Pal as a way of handling a single subscriber session from beginning to end with ongoing session policy updates based on individual application flows in high-availability environment that provides seamless transitioning of application flow processing (please see Col 2, lines 26-32 of Dukes).
As per claim 22:
Rangasamy in view of Kamalakantha and further in view of Pal and Dukes teaches the network apparatus of claim 21, wherein:
the plurality of services comprise virtualized services (Rangasamy, see Col 6, lines 35-51, one or more host servers of cloud networks 108A-108C executes an instance of at least one of applications 110A-110D. The host servers may include virtual servers or other virtualized execution environment, please see Col 6, lines 46-51)
and the network apparatus, the API gateway circuitry, and/or the at least one cloud service provider comprise one or more distributed computing systems (Rangasamy, see Figure 1, API exchange 100 includes distributed cloud networks 108A-108C, distributed service gateways 112A-112C and distributed applications 110A-110C).
As per claim 23:
Rangasamy in view of Kamalakantha and further in view of Pal and Dukes teaches the network apparatus of claim 22, wherein: the API gateway circuitry is configurable for use in association with one or more of the following:
at least one firewall service (Rangasamy, see Col 7, lines 50-59, besides routing service requests between requesters (i.e., issuers of service requests) and internal API endpoints, each of service gateways 112 may also verify requesters are authorized to make requests, prevent access to internal API endpoints by unauthorized requesters, perform load balancing among multiple service instances for the applications 110, etc.);
at least one load-balancing service (Rangasamy, see Col 7, lines 50-59, besides routing service requests between requesters (i.e., issuers of service requests) and internal API endpoints, each of service gateways 112 may also verify requesters are authorized to make requests, prevent access to internal API endpoints by unauthorized requesters, perform load balancing among multiple service instances for the applications 110, etc.);
and at least one deep packet inspection service (Rangasamy, see Col 2, lines 34-43, The API gateway may also provide a centralized location for multiple API endpoints to perform endpoint-specific (or at least customer specific) requester verification, security and packet inspection, policy enforcement at the API level, data collection and analytics).
As per claim 24:
Rangasamy in view of Kamalakantha and further in view of Pal and Dukes teaches the network apparatus of claim 23, wherein: the providing of the at least one corresponding service is associated with at least one uniform resource identifier (Rangasamy, see Col 10, line 67 and Col 11, lines 1-4, API endpoints and API exchange endpoints may be indicated in part using Uniform Resource Locators (URLs) or Uniform Resource Identifiers, in part using transport-layer ports, or by explicitly specifying a network address and transport-layer port for the API endpoint, for example).
As per claim 25:
Rangasamy in view of Kamalakantha and further in view of Pal and Dukes teaches the network apparatus of claim 23, wherein:
the application layer policy data is dynamically changeable, at least in part, based upon resource availability at least one administrator instruction (Rangasamy, see Col 22, lines 43-47, a user interface module 435 may output a portal and receive input data from input devices 404 accessible by a customer or administrator of API exchange server 401 to specify and/or manipulate policies 432).
As per claim 27:
Rangasamy in view of Kamalakantha and further in view of Pal and Dukes teaches the network apparatus of claim 23, wherein: the at least one corresponding service is to be provided, at least in part, via at least one internet network, to the at least one computing device (Rangasamy, see Col 7, lines 5-11, services offered by applications 110 may alternatively be referred to as “web services” in that the services communicate with other computing devices using application-layer protocols developed for the world-wide wed, such as HTTP or SMTP and operating over Internet Protocol networks); and the virtualized services are to be implemented via one or more virtual machines and/or one or more containers (Rangasamy, see Col 6, lines 46-51, “Host servers may represent real servers or virtual servers, such as virtual machines, containers, or other virtualized execution environment”).
As per claim 28:
Rangasamy teaches one or more non-transitory machine-readable storage media storing instructions for being executed by circuitry (see Col 29, lines 39-67, disclose a computer readable medium for storing executable instructions), the circuitry to be communicatively coupled to at least one computing device (see Figure 1, API exchange 101 coupled to customer device(s) 130. Note: Examiner is reading said customer device(s) 130 as said computing device(s) 130), the circuitry also to be communicatively coupled, via at least one cloud network, to at least one cloud service provider (see Figure 1, API exchange 101 coupled to application instances 110C and 110D of cloud network 108C via service gateway 112C), the instructions when executed by the circuitry resulting in the circuitry being configurable to perform operations (see Col 29, lines 39-67, processor to perform one or more of the methods by executing instructions stored in memory) comprising:
mapping received network packet data to at least one corresponding service of the at least one cloud service provider (see Col 10, lines 10-13, API exchange 101 maps the service request 124A received at port 107 to API endpoint 114C. Note: Examiner is reading said API endpoint 114C as said corresponding service especially since they are usable for accessing the API/application 110C of the cloud network 108C, please see Col 10, lines 50-55);
and generating request data for use in requesting providing of the at least one corresponding service (see Col 10, lines 11-17, after mapping the service request 124A to API endpoint 114C, a new service request 124A’ is generated which includes service data from service request 124A and includes layer 4 header and a layer 3 header which causes the new service request 124A to be received at the API endpoint 114C exposed by service gateway 112C), the received network packet data to be received from the at least one computing device (see Figure 1, service request 124A is received by the API exchange 101 from customer device(s) 130), the at least one corresponding service to be provided in response, at least in part, to the request data (see Col 10, lines 38-51, service instance of application 110C in response to receiving the service request 124A’ from the service gateway 112C may generate a service response 124B destined for customer port 107 of API exchange 101), the providing of the at least one corresponding service to result in generation of response data to be provided to the at least one computing device via the at least one cloud network (as shown figure 1, application 110C of the cloud network 108C sends the service response 124B to the customer device(s) via link 103C established between the service gateway 112C and the API exchange 101 and the link 102 established between API exchange 101 and customer device(s) 130 using API endpoint 114C, API exchange 106C and customer port 107. Note: each of the respective applications 110A-110D are configured to offer services upon receipt of service request from the respective service gateways 112A-112C, please see Col 7, lines 23-67);
wherein:
a plurality of services are comprised, at least in part, in the at least one cloud service provider (see Col 6, lines 35-60, each of cloud networks 108 includes one or more host servers that each executes an instance of at least one of applications 110A-110D. Applications 110 offer services, such as data storage, eCommerce, billing, social media and other services accessible using machine-to-machine communication over the corresponding cloud network 108);
the plurality of services comprise the at least one corresponding service (see Col 7, lines 23-67 each of the respective applications 110A-110D are configured to offer services upon receipt of service request from the respective service gateways 112A-112C);
the plurality of services are configurable to include at least one firewall service (see Col 7, lines 50-59, besides routing service requests between requesters (i.e., issuers of service requests) and internal API endpoints, each of service gateways 112 may also verify requesters are authorized to make requests, prevent access to internal API endpoints by unauthorized requesters, perform load balancing among multiple service instances for the applications 110, etc.);
select, based at least in part upon the network packet data, the at least one corresponding service from among the plurality of services (see Col 10, lines 25-37, API exchange 101 may proxy a transport-layer (e.g., TCP) session between API exchange 101 and customer 130 and transport-layer session between API exchange 101 and a service instance of application 110C. In this way, API exchange 101 creates a service-to-service path for service requests and service responses between customer device 130 and service instance for application 110C);
and implement, at least in part, one or more of the plurality of services (see Col 10, lines 25-37, as explained earlier, since a service-to-service path is created service response for each service request may be transmitted from a service instance to the client via the API exchange 101), and the request data is to be generated based at least in part upon application layer policy data of the API gateway circuitry (see Col 20, lines 1-8, API exchange 301 in response to receiving service request 325A, may apply policies 332 to authorize, throttle, or route a representation of service 325A of service request 325A to API endpoint 314A as service request 325A’. Note: Examiner is reading said service request 325A’ as the generated request. See figure 3, Col 21, lines 65-67, Col 22, lines 1-13, the storage 440 may store one or more modules or applications. Operating system (OS 431) as the operating module may be operated in the application layer and further interact with the API exchange application 422 comprising the policies 423, please see Col 22, lines 9-13, lines 22-47).
Rangasamy does not clearly teach the plurality of services correspond, at least in part, to application programming interface (API) calls for use, at least in part, in association with the circuitry;
the request data is for use in requesting calling of the at least one corresponding service.
Kamalakantha teaches the plurality of services correspond, at least in part, to application programming interface (API) calls for use, at least in part, in association with the circuitry (see paragraph [0011], disclose API gateway for intercepting hypervisor manager native API calls so that requests of those API calls may be validated in relation to various protection(s) and restriction(s) provided by a cloud service provide. A native API call relates to request for a user to access particular resource (i.e., virtual machine, VM-101), please see paragraph [0025]. Therefore, the API native call is related to a service);
the request data is for use in requesting calling of the at least one corresponding service (see Figure 1, paragraph [0025] API gateway 121 comprise of instructions 122 for intercepting a hypervisor manager native API call from a user with identity “USER1”, requesting a resize operation on a virtual machine with an identifier of “VM-101” and instructions 124 may determine the series of validation checks to perform. Instructions 124 may perform a validation check to determine whether the particular user identity USER1 (i.e., requesting entity) has permission to resize a computing resource (i.e., VM-101). Note: Said API call of the user/client is identified based on its signature (e.g., the function name and number, order and types of parameters of the API call), please see paragraphs [0019] and [0044])).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the interception and validation of native API calls by API gateway (as disclosed in Kamalakantha) into Rangasamy as a way of enabling the API gateway to handle various protection(s) and restriction(s) provided by a cloud service provider for the cloud computing environment before the native calls are passed to underlying hypervisor manager instance(s) of the cloud computing environment behind the API gateway (please see paragraph [0011] of Kamalakantha).
The combination of Rangasamy and Kamalakantha do not teach and the circuitry is configurable to:
provide application layer-related proxy services related to the plurality of services.
Pal teaches and the circuitry (see Figure 21, paragraph [0077], network channel process 2130 acting as dispatcher) is configurable to:
provide application layer-related proxy services related to the plurality of services (see Figure 21 and paragraph [0077], dispatcher 2130 for selectively directing requests from clients to particular proxy. System 2100 containing said dispatcher 2130 may enforce policies on the captured data at or near the application layer using library/storage channel disposition 2150. Upon receiving the request from the client, the dispatcher/network channel process 2130 may direct the request to one or more of the proxies for further processing to analyze and/or modify the network requests, please see paragraph [0078]).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the processing of processing of client requests at the application layer level (as disclosed in Pal) into Rangasamy and Kamalakantha as a way of enabling the channel process to further examine the static properties of the request before forwarding to the intended service (please see paragraphs [0083], [0087] and [0096] of Pal).
Rangasamy, Kamalakantha and Pal do not teach and the application layer policy data is dynamically changeable, at least in part, based upon resource availability and/or condition detection data.
Dukes teaches and the application layer policy data is dynamically changeable (see Col 1, lines 54-67. the policy control engine of the services module dynamically updates session policies applied for the subscriber session based on the identified application flows and a subscriber profile. Note: Said application flows are reassembled application-layer data from data packets in the subscriber session packet flow, please see Col 1, lines 54-60, and thus session policies are application layer policies), at least in part, based upon resource availability (Note: Limitation(s) is/are recited in alternate form and thus not addressed by the prior art) and/or condition detection data (Col 1, lines 60-67 disclose dynamically updating session policies applied for the subscriber session based on the identified application flows and a subscriber profile. Note: Examiner is reading said identified application flows and subscriber profile as said condition detection data).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to implement the updating of session policies (as disclosed in Dukes) into Rangasamy, Kamalakantha and Pal as a way of handling a single subscriber session from beginning to end with ongoing session policy updates based on individual application flows in high-availability environment that provides seamless transitioning of application flow processing (please see Col 2, lines 26-32 of Dukes).
As per claim 29:
Rangasamy in view of Kamalakantha and further in view of Pal and Dukes teaches the one or more machine-readable storage media of claim 28, wherein:
the instructions, when executed by the circuitry, result in the circuitry being configured to comprise:
API gateway circuitry (Rangasamy, see Figure 3, API exchange server 401 comprise of processor 412. Said processor 412 together with the service MAP 450 may match on the destination network address and the destination port of one or more packets of the service request 425A and specify a destination endpoint of service gateway 440B, see Col 23, lines 20-45) to perform:
the mapping of the received network packet data to the at least one corresponding service of the at least one cloud service provider (Rangasamy, see Col 10, lines 10-13, API exchange 101 maps the service request 124A received at port 107 to API endpoint 114C. Note: Examiner is reading said API endpoint 114C as said corresponding service especially since they are usable for accessing the API/application 110C of the cloud network 108C, please see Col 10, lines 50-55);
and the generating of the request data for use in the requesting of the providing of the at least one corresponding service (Rangasamy, see Col 10, lines 11-17, after mapping the service request 124A to API endpoint 114C, a new service request 124A’ is generated which includes service data from service request 124A and includes layer 4 header and a layer 3 header which causes the new service request 124A to be received at the API endpoint 114C exposed by service gateway 112C);
and communication interface circuitry (Rangasamy, see Figure 3, API exchange server 401 also comprise of communication units 402) to:
receive the network packet data (Rangasamy, see Col 20, lines 60-67, communications unit 402 may receive data from external devices such as customer devices 130. Similarly, figure 1 shows API exchange 101 receiving said service request 124A from customer device(s) 130);
transmit the request data to the at least one cloud service provider via the at least one cloud network (Rangasamy, see Figure 1, API exchange 101 transmitting service request 124’ to application instance 110C of cloud network 108C via the service gateway 112C); and transmit the response data to the at least one computing device (Rangasamy, see Figure 1, API exchange 101 transmitting/forwarding service response 124B’ to customer device(s) 130).
Claim 30 is rejected in the same scope as claim 22.
Claim 31 is rejected in the same scope as claim 23.
Claim 32 is rejected in the same scope as claim 24.
Claim 33 is rejected in the same scope as claim 25.
Claim 35 is rejected in the same scope as claim 27.
As per claim 36:
Rangasamy teaches a method implemented using circuitry (see Col 1, lines 25-41, discloses described techniques for creating bundles of application programming interfaces (API) provided by respective cloud service providers and mediating access to the bundles of APIs by customers), the circuitry to be communicatively coupled to at least one computing device (see Figure 1, API exchange 101 coupled to customer device(s) 130. Note: Examiner is reading said customer device(s) 130 as said computing device(s) 130), the circuitry also to be communicatively coupled, via at least one cloud network, to at least one cloud service provider (see Figure 1, API exchange 101 coupled to application instances 110C and 110D of cloud network 108C via service gateway 112C), the method comprising:
mapping, by the circuitry, received network packet data to at least one corresponding service of the at least one cloud service provider (see Col 10, lines 10-13, API exchange 101 maps the service request 124A received at port 107 to API endpoint 114C. Note: Examiner is reading said API endpoint 114C as said corresponding service especially since they are usable for accessing the API/application 110C of the cloud network 108C, please see Col 10, lines 50-55);
and generating, by the circuitry, request data for use in requesting providing of the at least one corresponding service (see Col 10, lines 11-17, after mapping the service request 124A to API endpoint 114C, a new service request 124A’ is generated which includes service data from service request 124A and includes layer 4 header and a layer 3 header which causes the new service request 124A to be received at the API endpoint 114C exposed by service gateway 112C), the received network packet data to be received from the at least one computing device (see Figure 1, service request 124A is received by the API exchange 101 from customer device(s) 130), the at least one corresponding service to be provided in response, at least in part, to the request data (see Col 10, lines 38-51, service instance of application 110C in response to receiving the service request 124A’ from the service gateway 112C may generate a service response 124B destined for customer port 107 of API exchange 101), the providing of the at least one corresponding service to result in generation of response data to be provided to the at least one computing device via the at least one cloud network (as shown figure 1, application 110C of the cloud network 108C sends the service response 124B to the customer device(s) via link 103C established between the service gateway 112C and the API exchange 101 and the link 102 established between API exchange 101 and customer device(s) 130 using API endpoint 114C, API exchange 106C and customer port 107. Note: each of the respective applications 110A-110D are configured to offer services upon receipt of service request from the respective service gateways 112A-112C, please see Col 7, lines 23-67);
wherein:
a plurality of services are comprised, at least in part, in the at least one cloud service provider (see Col 6, lines 35-60, each of cloud networks 108 includes one or more host servers that each executes an instance of at least one of applications 110A-110D. Applications 110 offer services, such as data storage, eCommerce, billing, social media and other services accessible using machine-to-machine communication over the corresponding cloud network 108);
the plurality of services comprise the at least one corresponding service (see Col 7, lines 23-67 each of the respective applications 110A-110D are configured to offer services upon receipt of service request from the respective service gateways 112A-112C);
the plurality of services are configurable to include at least one firewall service (see Col 7, lines 50-59, besides routing service requests between requesters (i.e., issuers of service requests) and internal API endpoints, each of service gateways 112 may also verify requesters are authorized to make requests, prevent access to internal API endpoints by unauthorized requesters, perform load balancing among multiple service instances for the applications 110, etc.);
select, based at least in part upon the network packet data, the at least one corresponding service from among the plurality of services (see Col 10, lines 25-37, API exchange 101 may proxy a transport-layer (e.g., TCP) session between API exchange 101 and customer 130 and transport-layer session between API exchange 101 and a service instance of application 110C. In this way, API exchange 101 creates a service-to-service path for service requests and service responses between customer device 130 and service instance for application 110C);
and implement, at least in part, one or more of the plurality of services (see Col 10, lines 25-37, as explained earlier, since a service-to-service path is created service response for each service request may be transmitted from a service instance to the client via the API exchange 101) ), and the request data is to be generated based at least in part upon application layer policy data of the API gateway circuitry (see Col 20, lines 1-8, API exchange 301 in response to receiving service request 325A, may apply policies 332 to authorize, throttle, or route a representation of service 325A of service request 325A to API endpoint 314A as service request 325A’. Note: Examiner is reading said service request 325A’ as the generated request. See figure 3, Col 21, lines 65-67, Col 22, lines 1-13, the storage 440 may store one or more modules or applications. Operating system (OS 431) as the operating module may be operated in the application layer and further interact with the API exchange application 422 comprising the policies 423, please see Col 22, lines 9-13, lines 22-47).
Rangasamy does not clearly teach the plurality of services correspond, at least in part, to application programming interface (API) calls for use, at least in part, in association with the circuitry;
the request data is for use in requesting calling of the at least one corresponding service.
Kamalakantha teaches the plurality of services correspond, at least in part, to application programming interface (API) calls for use, at least in part, in association with the circuitry (see paragraph [0011], disclose API gateway for intercepting hypervisor manager native API calls so that requests of those API calls may be validated in relation to various protection(s) and restriction(s) provided by a cloud service provide. A native API call relates to request for a user to access particular resource (i.e., virtual machine, VM-101), please see paragraph [0025]. Therefore, the API native call is related to a service);
the request data is for use in requesting calling of the at least one corresponding service (see Figure 1, paragraph [0025] API gateway 121 comprise of instructions 122 for intercepting a hypervisor manager native API call from a user with identity “USER1”, requesting a resize operation on a virtual machine with an identifier of “VM-101” and instructions 124 may determine the series of validation checks to perform. Instructions 124 may perform a validation check to determine whether the particular user identity USER1 (i.e., requesting entity) has permission to resize a computing resource (i.e., VM-101). Note: Said API call of the user/client is identified based on its signature (e.g., the function name and number, order and types of parameters of the API call), please see paragraphs [0019] and [0044])).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the interception and validation of native API calls by API gateway (as disclosed in Kamalakantha) into Rangasamy as a way of enabling the API gateway to handle various protection(s) and restriction(s) provided by a cloud service provider for the cloud computing environment before the native calls are passed to underlying hypervisor manager instance(s) of the cloud computing environment behind the API gateway (please see paragraph [0011] of Kamalakantha).
The combination of Rangasamy and Kamalakantha do not teach and the circuitry is configurable to:
provide application layer-related proxy services related to the plurality of services.
Pal teaches and the circuitry (see Figure 21, paragraph [0077], network channel process 2130 acting as dispatcher) is configurable to:
provide application layer-related proxy services related to the plurality of services (see Figure 21 and paragraph [0077], dispatcher 2130 for selectively directing requests from clients to particular proxy. System 2100 containing said dispatcher 2130 may enforce policies on the captured data at or near the application layer using library/storage channel disposition 2150. Upon receiving the request from the client, the dispatcher/network channel process 2130 may direct the request to one or more of the proxies for further processing to analyze and/or modify the network requests, please see paragraph [0078]).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the processing of processing of client requests at the application layer level (as disclosed in Pal) into Rangasamy and Kamalakantha as a way of enabling the channel process to further examine the static properties of the request before forwarding to the intended service (please see paragraphs [0083], [0087] and [0096] of Pal).
Rangasamy, Kamalakantha and Pal do not teach and the application layer policy data is dynamically changeable, at least in part, based upon resource availability and/or condition detection data.
Dukes teaches and the application layer policy data is dynamically changeable (see Col 1, lines 54-67. the policy control engine of the services module dynamically updates session policies applied for the subscriber session based on the identified application flows and a subscriber profile. Note: Said application flows are reassembled application-layer data from data packets in the subscriber session packet flow, please see Col 1, lines 54-60, and thus session policies are application layer policies), at least in part, based upon resource availability (Note: Limitation(s) is/are recited in alternate form and thus not addressed by the prior art) and/or condition detection data (Col 1, lines 60-67 disclose dynamically updating session policies applied for the subscriber session based on the identified application flows and a subscriber profile. Note: Examiner is reading said identified application flows and subscriber profile as said condition detection data).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to implement the updating of session policies (as disclosed in Dukes) into Rangasamy, Kamalakantha and Pal as a way of handling a single subscriber session from beginning to end with ongoing session policy updates based on individual application flows in high-availability environment that provides seamless transitioning of application flow processing (please see Col 2, lines 26-32 of Dukes).
Claim 37 is rejected in the same scope as claim 29.
Claim 38 is rejected in the same scope as claim 22.
Claim 39 is rejected in the same scope as claim 23.
Claim 41 is rejected in the same scope as claim 27.
As per claim 42:
Rangasamy teaches a computerized system to be communicatively coupled to at least one computing device (see Figure 1, Col 6, lines 16-22, API exchange system 100 comprising customer device(s) coupled to API exchange 101, service gateways and applications via respective cloud networks), the computerized system comprising:
at least one cloud service provider (see Figure 1, application instances 110C and 110D of cloud network 108C);
and network apparatus (see Figure 1, API exchange 101) to be communicatively coupled, via at least one cloud network, to the at least one cloud service provider (see Figure 1, API exchange 101 coupled to application instances 110C and 110D of cloud network 108C via service gateway 112C), the network apparatus also to be communicatively coupled to the at least one computing device (see Figure 1, API exchange 101 coupled to customer device(s) 130. Note: Examiner is reading said customer device(s) 130 as said computing device(s) 130), the network apparatus comprising:
application programming interface (API) gateway circuitry (see Figure 3, API exchange server 401 comprise of processor 412. Said processor 412 together with the service MAP 450 may match on the destination network address and the destination port of one or more packets of the service request 425A and specify a destination endpoint of service gateway 440B, see Col 23, lines 20-45) configurable to (1) map received network packet data to at least one corresponding service of the at least one cloud service provider (see Col 10, lines 10-13, API exchange 101 maps the service request 124A received at port 107 to API endpoint 114C. Note: Examiner is reading said API endpoint 114C as said corresponding service especially since they are usable for accessing the API/application 110C of the cloud network 108C, please see Col 10, lines 50-55) and (2) generate request data for use in requesting providing of the at least one corresponding service (see Col 10, lines 11-17, after mapping the service request 124A to API endpoint 114C, a new service request 124A’ is generated which includes service data from service request 124A and includes layer 4 header and a layer 3 header which causes the new service request 124A to be received at the API endpoint 114C exposed by service gateway 112C), the received network packet data being received from the at least one
computing device by the network apparatus (see Figure 1, service request 124A is received by the API exchange 101 from customer device(s) 130), the at least one corresponding service to be provided in response, at least in part, to the request data (see Col 10, lines 38-51, service instance of application 110C in response to receiving the service request 124A’ from the service gateway 112C may generate a service response 124B destined for customer port 107 of API exchange 101), the providing of the at least one corresponding service to result in generation of response data to be provided to the at least one computing device via the at least one cloud network and the network apparatus (as shown figure 1, application 110C of the cloud network 108C sends the service response 124B to the customer device(s) via link 103C established between the service gateway 112C and the API exchange 101 and the link 102 established between API exchange 101 and customer device(s) 130 using API endpoint 114C, API exchange 106C and customer port 107. Note: each of the respective applications 110A-110D are configured to offer services upon receipt of service request from the respective service gateways 112A-112C, please see Col 7, lines 23-67);
and communication interface circuitry (see Figure 3, API exchange server 401 also comprise of communication units 402) to:
receive the network packet data (see Col 20, lines 60-67, communications unit 402 may receive data from external devices such as customer devices 130. Similarly, figure 1 shows API exchange 101 receiving said service request 124A from customer device(s) 130);
transmit the request data to the at least one cloud service provider via the at least one cloud network (see Figure 1, API exchange 101 transmitting service request 124’ to application instance 110C of cloud network 108C via the service gateway 112C);
and transmit the response data to the at least one computing device (see Figure 1, API exchange 101 transmitting/forwarding service response 124B’ to customer device(s) 130);
wherein:
a plurality of services are comprised, at least in part, in the at least one cloud service provider (see Col 6, lines 35-60, each of cloud networks 108 includes one or more host servers that each executes an instance of at least one of applications 110A-110D. Applications 110 offer services, such as data storage, eCommerce, billing, social media and other services accessible using machine-to-machine communication over the corresponding cloud network 108);
the plurality of services comprise the at least one corresponding service (see Col 7, lines 23-67 each of the respective applications 110A-110D are configured to offer services upon receipt of service request from the respective service gateways 112A-112C);
the plurality of services are configurable to include at least one firewall service (see Col 7, lines 50-59, besides routing service requests between requesters (i.e., issuers of service requests) and internal API endpoints, each of service gateways 112 may also verify requesters are authorized to make requests, prevent access to internal API endpoints by unauthorized requesters, perform load balancing among multiple service instances for the applications 110, etc.);
select, based at least in part upon the network packet data, the at least one corresponding service from among the plurality of services (see Col 10, lines 25-37, API exchange 101 may proxy a transport-layer (e.g., TCP) session between API exchange 101 and customer 130 and transport-layer session between API exchange 101 and a service instance of application 110C. In this way, API exchange 101 creates a service-to-service path for service requests and service responses between customer device 130 and service instance for application 110C);
and implement, at least in part, one or more of the plurality of services (see Col 10, lines 25-37, as explained earlier, since a service-to-service path is created service response for each service request may be transmitted from a service instance to the client via the API exchange 101) ), and the request data is to be generated based at least in part upon application layer policy data of the API gateway circuitry (see Col 20, lines 1-8, API exchange 301 in response to receiving service request 325A, may apply policies 332 to authorize, throttle, or route a representation of service 325A of service request 325A to API endpoint 314A as service request 325A’. Note: Examiner is reading said service request 325A’ as the generated request. See figure 3, Col 21, lines 65-67, Col 22, lines 1-13, the storage 440 may store one or more modules or applications. Operating system (OS 431) as the operating module may be operated in the application layer and further interact with the API exchange application 422 comprising the policies 423, please see Col 22, lines 9-13, lines 22-47).
Rangasamy does not clearly teach the plurality of services correspond, at least in part, to API calls for use, at least in part, in association with the API gateway circuitry;
the request data is for use in requesting calling of the at least one corresponding service.
Kamalakantha teaches the plurality of services correspond, at least in part, to API calls for use, at least in part, in association with the API gateway circuitry (see paragraph [0011], disclose API gateway for intercepting hypervisor manager native API calls so that requests of those API calls may be validated in relation to various protection(s) and restriction(s) provided by a cloud service provide. A native API call relates to request for a user to access particular resource (i.e., virtual machine, VM-101), please see paragraph [0025]. Therefore, the API native call is related to a service);
the request data is for use in requesting calling of the at least one corresponding service (see Figure 1, paragraph [0025] API gateway 121 comprise of instructions 122 for intercepting a hypervisor manager native API call from a user with identity “USER1”, requesting a resize operation on a virtual machine with an identifier of “VM-101” and instructions 124 may determine the series of validation checks to perform. Instructions 124 may perform a validation check to determine whether the particular user identity USER1 (i.e., requesting entity) has permission to resize a computing resource (i.e., VM-101). Note: Said API call of the user/client is identified based on its signature (e.g., the function name and number, order and types of parameters of the API call), please see paragraphs [0019] and [0044])).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the interception and validation of native API calls by API gateway (as disclosed in Kamalakantha) into Rangasamy as a way of enabling the API gateway to handle various protection(s) and restriction(s) provided by a cloud service provider for the cloud computing environment before the native calls are passed to underlying hypervisor manager instance(s) of the cloud computing environment behind the API gateway (please see paragraph [0011] of Kamalakantha).
The combination of Rangasamy and Kamalakantha do not teach the API gateway circuitry is configurable to:
provide application layer-related proxy services related to the plurality of services.
Pal teaches the API gateway circuitry (see Figure 21, paragraph [0077], network channel process 2130 acting as dispatcher) is configurable to:
provide application layer-related proxy services related to the plurality of services (see Figure 21 and paragraph [0077], dispatcher 2130 for selectively directing requests from clients to particular proxy. System 2100 containing said dispatcher 2130 may enforce policies on the captured data at or near the application layer using library/storage channel disposition 2150. Upon receiving the request from the client, the dispatcher/network channel process 2130 may direct the request to one or more of the proxies for further processing to analyze and/or modify the network requests, please see paragraph [0078]).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the processing of processing of client requests at the application layer level (as disclosed in Pal) into Rangasamy and Kamalakantha as a way of enabling the channel process to further examine the static properties of the request before forwarding to the intended service (please see paragraphs [0083], [0087] and [0096] of Pal).
Rangasamy, Kamalakantha and Pal do not teach and the application layer policy data is dynamically changeable, at least in part, based upon resource availability and/or condition detection data.
Dukes teaches and the application layer policy data is dynamically changeable (see Col 1, lines 54-67. the policy control engine of the services module dynamically updates session policies applied for the subscriber session based on the identified application flows and a subscriber profile. Note: Said application flows are reassembled application-layer data from data packets in the subscriber session packet flow, please see Col 1, lines 54-60, and thus session policies are application layer policies), at least in part, based upon resource availability (Note: Limitation(s) is/are recited in alternate form and thus not addressed by the prior art) and/or condition detection data (Col 1, lines 60-67 disclose dynamically updating session policies applied for the subscriber session based on the identified application flows and a subscriber profile. Note: Examiner is reading said identified application flows and subscriber profile as said condition detection data).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to implement the updating of session policies (as disclosed in Dukes) into Rangasamy, Kamalakantha and Pal as a way of handling a single subscriber session from beginning to end with ongoing session policy updates based on individual application flows in high-availability environment that provides seamless transitioning of application flow processing (please see Col 2, lines 26-32 of Dukes).
As per claim 43:
Rangasamy in view of Kamalakantha and further in view of Pal and Dukes teaches the computerized system of claim 42, wherein:
the plurality of services comprise virtualized services (Rangasamy, see Col 6, lines 35-51, one or more host servers of cloud networks 108A-108C executes an instance of at least one of applications 110A-110D. The host servers may include virtual servers or other virtualized execution environment, please see Col 6, lines 46-51);
the network apparatus, the API gateway circuitry, and/or the at least one cloud service provider comprise one or more distributed computing systems (Rangasamy, see Figure 1, API exchange 100 includes distributed cloud networks 108A-108C, distributed service gateways 112A-112C and distributed applications 110A-110C);
and the API gateway circuitry is configurable for use in association with one or more of the following:
at least one firewall service (Rangasamy, see Col 7, lines 50-59, besides routing service requests between requesters (i.e., issuers of service requests) and internal API endpoints, each of service gateways 112 may also verify requesters are authorized to make requests, prevent access to internal API endpoints by unauthorized requesters, perform load balancing among multiple service instances for the applications 110, etc.);
at least one load-balancing service (Rangasamy, see Col 7, lines 50-59, besides routing service requests between requesters (i.e., issuers of service requests) and internal API endpoints, each of service gateways 112 may also verify requesters are authorized to make requests, prevent access to internal API endpoints by unauthorized requesters, perform load balancing among multiple service instances for the applications 110, etc.);
and at least one deep packet inspection service (Rangasamy, see Col 2, lines 34-43, The API gateway may also provide a centralized location for multiple API endpoints to perform endpoint-specific (or at least customer specific) requester verification, security and packet inspection, policy enforcement at the API level, data collection and analytics).
Claim 45 is rejected in the same scope as claim 27.
5. Claims 26, 34, 40 and 44 are rejected under 35 U.S.C. 103 as being unpatentable over Rangasamy (US Patent No. 11,228,573) in view of Kamalakantha (US PG Pub. No. 2017/0351536) and further in view of Pal (US PG Pub. No. 2017/0359308), Dukes and Lieberman (US Patent No. 10,860,433).
As per claim 26:
Rangasamy in view of Kamalakantha and further in view of Pal and Dukes teaches the network apparatus of claim 23, wherein:
the network apparatus is to forward the request data based at least in part upon forwarding data that corresponds to mapping of the received network packet data to at least one corresponding service (Rangasamy, see Col 23, lines 29-45, processors 412 apply service map 450 to map the destination API exchange of service request 425A to an API endpoint of service gateway 440B. A service map 450 may match on the destination network address and the destination port of one or more packets of the service request 425A and specify a destination endpoint of service gateway 440B).
The combination of Rangasamy, Kamalakantha, Pal and Dukes do not teach and the plurality of services comprise one or more microservices.
Lieberman teaches and the plurality of services comprise one or more microservices (see Col 5, lines 29-45, cloud-native application manager 106 of the compute services platform 105 receives a request to execute one of the cloud-native applications. The request is received from one of the user devices 102 over the network 104. One of the given cloud-native applications 110 executed in the compute services platform 105 utilizes multiple ones of micro-services 112 each of which is associated with a different set of one or more underlying databases 114, please see Col 5, lines 41-45. Similar teachings are also disclosed in Col 10, lines 17-21).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to implement the execution of micro-services in response to user request (as disclosed in Lieberman) into Rangasamy, Kamalakantha, Pal and Dukes as a way of providing multiple application services (please see Col 9, lines 45-49 of Lieberman).
Claim 34 is rejected in the same scope as claim 26.
As per claim 40:
Rangasamy in view of Kamalakantha and further in view of Pal and Dukes teaches the method of claim 39, wherein: the providing of the at least one corresponding service is associated with at least one uniform resource identifier (Rangasamy, see Col 10, line 67 and Col 11, lines 1-4, API endpoints and API exchange endpoints may be indicated in part using Uniform Resource Locators (URLs) or Uniform Resource Identifiers, in part using transport-layer ports, or by explicitly specifying a network address and transport-layer port for the API endpoint, for example);
the application layer policy data is dynamically changeable, at least in part, based upon at least one administrator instruction (Rangasamy, see Col 22, lines 43-47, a user interface module 435 may output a portal and receive input data from input devices 404 accessible by a customer or administrator of API exchange server 401 to specify and/or manipulate policies 432);
the request data is to be generated based at least in part upon policy data of the circuitry (Rangasamy, see Col 10, lines 14-37, API exchange 101 in response to receiving service request 124A from customer port 107, a new service request 124A’ is generated which includes service data from service request 124A and includes a layer 4 header and a layer 3 header that causes the service request 124A’ to be received at API endpoint 114C exposed by service gateway 112C. Note: Examiner is reading said layer 4 and layer 3 headers as said policy especially since it causes the service request 124A’ to be received at API endpoint 114C); the request data is to be forwarded based at least in part upon forwarding data that corresponds to the mapping of the received network packet data to at least one corresponding service (Rangasamy, see Col 23, lines 29-45, processors 412 apply service map 450 to map the destination API exchange of service request 425A to an API endpoint of service gateway 440B. A service map 450 may match on the destination network address and the destination port of one or more packets of the service request 425A and specify a destination endpoint of service gateway 440B).
The combination of Rangasamy, Kamalakantha, Pal and Dukes do not teach and the plurality of services comprise one or more microservices.
Lieberman teaches and the plurality of services comprise one or more microservices (see Col 5, lines 29-45, cloud-native application manager 106 of the compute services platform 105 receives a request to execute one of the cloud-native applications. The request is received from one of the user devices 102 over the network 104. One of the given cloud-native applications 110 executed in the compute services platform 105 utilizes multiple ones of micro-services 112 each of which is associated with a different set of one or more underlying databases 114, please see Col 5, lines 41-45. Similar teachings are also disclosed in Col 10, lines 17-21).
Thus, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to implement the execution of micro-services in response to user request (as disclosed in Lieberman) into Rangasamy, Kamalakantha, Pal and Dukes as a way of providing multiple application services (please see Col 9, lines 45-49 of Lieberman).
Claim 44 is rejected in the same scope as claim 40.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PRINCE AKWASI MENSAH whose telephone number is (571)270-7183. The examiner can normally be reached Mon-Fri 8:00am-4:00pm.
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, MICHAEL THIER can be reached at 571-272-2832. 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.
PRINCE AKWASI. MENSAH
Examiner
Art Unit 2474
/PRINCE A MENSAH/Examiner, Art Unit 2474
/Michael Thier/Supervisory Patent Examiner, Art Unit 2474