DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Remarks
This communication is considered fully responsive to the Amendment filed on 12/2/25.
Response to Arguments
Applicant’s 12/2/25 arguments with respect to claims have been considered but are moot in view of new ground(s) of rejection.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
It is noted that the Applicant has failed to point to the specification in order to show the support for such amendments that have been made to the claims.
Furthermore, a general search for amendments within the specification was not found. Specifically, multiple amendments added details to disclosed “receiving, by a multicloud gateway (MCG) implemented in a first cloud environment, a modified first request requesting a first operation to be performed in a second cloud environment, wherein the modified first request is generated by encoding a first request into a generic format; responsive to receiving the modified first request, generating, by the MCG, a first API call directed to the second cloud environment;” and “receiving, by the MCG, a modified second request requesting a second operation to be performed in a third cloud environment, wherein the modified second request is generated by encoding a second request into the generic format; responsive to receiving the modified second request, generating, by the MCG, a second API call directed to the third cloud environment” that is only generally disclose at a high level of generality in original IFW specification (see IFW original claims 3-4, 13-14 and 20).
That is, a general search within the specification for limitations in amendments was not found including the following:
Claims 1, 11 and 18 (claim 1 exemplary)
1. (Currently Amended) A method comprising:
receiving, by a multicloud gateway (MCG) implemented in a first cloud environment, a modified first request requesting a first operation to be performed in a second cloud environment, wherein the modified first request is generated by encoding a first request into a generic format;
responsive to receiving the modified first request, generating, by the MCG, a first API
call directed to the second cloud environment;
causing, by the MCG, the first API call to be communicated to the second cloud environment;
receiving, by the MCG, a modified second request requesting a second operation to be performed in a third cloud environment, wherein the modified second request is generated by encoding a second request into the generic format;
responsive to receiving the modified second request, generating, by the MCG, a second
API call directed to the third cloud environment; and
causing, by the MCG, the second API call to be communicated to the third cloud environment, wherein each of the first cloud environment, the second cloud environment, and
third cloud environment are provided by different cloud services providers.
Therefore, the Examiner submits that the amendments lack proper support within the specification. However, the Examiner will assume that these amendments have proper support in order to advance prosecution. The Applicant is requested to specifically point out the specific page and line and/or paragraph numbers and/or figures where such support for these amendments are disclosed within the specification.
Furthermore, applicant is put on notice that claim limitations disclosed only in original claims and not disclosed elsewhere in the original specification will be given broadest reasonable interpretation for examining purposes and future amendments to add additional information on such limitations may be treated as new matter and action taken accordingly.
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.
Claims 1-8, 11-17 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2022/0035689 to Raheja et al. (“Raheja”) in view of U.S. Patent Publication No. 2023/0086783 to Bruno et al. (“Bruno”) and further in view of U.S. Patent Publication No. 2021/0328834 to Bagepalli et al. (“Bagepalli”).
As to claim 1, Raheja discloses a method (Raheja: fig 1-6) comprising:
receiving, by a multicloud gateway (MCG) implemented in a first cloud environment, a first request requesting a first operation to be performed in a second cloud environment (Raheja: fig 1-6, [0006-137]: fig 2-6 ... hybrid multi-cloud gateway configuration system 340 automates translation of high-level gateway performance requirements into configuration files compatible with any number of gateway types implementing varied API policy enforcement platforms (receiving, by a multicloud gateway (MCG) implemented in a 1st 2nd ... n cloud environment(s)) [0062] ... gateway may receive API call from an external agent ... API may be deployed at one or more gateways such as Gravitec gateway 261 ... API or portions operate to facilitate communications between backend application 291 such as purchase order system or store locator system ... Gravitec gateway 261 receives API call requesting such data from external agent 205 (receiving, by a multicloud gateway (MCG) implemented in a first cloud environment, a first request requesting a first operation to be performed ...) [0127; 79] ... for example, a policy translator 343 may transmit a gateway configuration file enforcing portions of a high-level gateway operation policies in a format understood by Kubernetes type gateways to an Istio/Envoy service mesh 372 which may pass the gateway configuration file to a Kubernetes gateway 371 ... an other policy translator 3400 may transmit both a service mesh configuration file and gateway configuration file enforcing at least a portion of a high-level gateway operation policies in a format for the corresponding API policy enforcement platform understood by another mesh type gateway 381 (receiving, by a multicloud gateway (MCG) implemented in a first cloud environment, a first request requesting a first operation to be performed in a second cloud environment) [0080]).
Raheja did not explicitly disclose receiving, by a multicloud gateway (MCG) implemented in a first cloud environment, a modified first request requesting a first operation to be performed in a second cloud environment, wherein the modified first request is generated by encoding a first request into a generic format.
Bruno discloses receiving, by a multicloud gateway (MCG) implemented in a first cloud environment, a modified first request requesting a first operation to be performed in a second cloud environment (Bruno: fig 1-6, [0006-46]: fig 6 computer system 600 ... includes but not limited to remote or distributed cloud solutions local or on-premises cloud-based solutions (implemented in a 1st 2nd ... n cloud environment(s)) [0057] ... on the client-side a user/company devises a particular configuration for their API environment and this configuration will use one or more services (1st 2nd ... n operations) that may operate in any number of different languages (receiving ... a first request requesting ... a first operation to be performed ...) ... the user creates its configuration using a gateway configuration language (GCL) (a first modified request requesting) ... this language utilizes modules that follow a common structure (generic format) (receiving ... a first modified request requesting ... a first operation to be performed ...) [0018-19] ... an intermediary (see claim 8 – this intermediary is a gateway) is required in order to convert the gateway configuration language (GCL) to a specific language used by a relevant engine and this intermediary functions as a translator and translates the GCL to that of the relevant engine ... in an environment in which multiple different engines are used, it is necessary to include a different translator for each of those different engines (see with [0057] above & claim 8 - a multicloud gateway (MCG) implemented in a first cloud environment ... ) [0020-21] ... fig 5 ... step 510 one or more modules being described using the gateway configuration language (GCL) discussed above ... language processor reads GCL module(s) ... language processor functions as a parser used to read GCL module and generate an output, such as a data structure... step 530 outputs an internal model that is a representation of the data structure (see with [0057;18-21] above & claim 8 – receiving, by a multicloud gateway (MCG) implemented in a first cloud environment, a first modified request requesting a first operation to be performed in a second cloud environment, wherein the modified first request is generated by encoding a first request into a generic format) [0045]).
Raheja and Bruno are analogous art because they are from the same field of endeavor with respect to APIs.
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Bruno into the method by Raheja. The suggestion/motivation would have been to provide APIS, more specifically, gateway configuration language that is universally applicable to all different API engines and services (Bruno: [0002;18]).
Raheja did not explicitly disclose responsive to receiving the modified first request, generating, by the MCG, a first API call directed to the second cloud environment.
Bagepalli discloses responsive to receiving the modified first request, generating, by the MCG, a first API call directed to the second cloud environment (Bagepalli: fig 1-11, [0005-71]: ... each cloud (1st 2nd ... n cloud(s)) having different administrative or provisioning interfaces implemented with different APIs (... a 1st 2nd ... n API call(s) directed to the 1st 2nd ... n cloud environment(s)) ... multi-cloud management module includes several cloud adapters, each configured to receive and analyze non-cloud-specific message (responsive to receiving the modified first request ...) and then convert or translate the analyze non-cloud-specific message into a cloud-specific message compatible with a cloud management module of a cloud with which the cloud adapter is associated (responsive to receiving the modified first request, generating, by the MCG, a first API call directed to the second cloud environment) [0029]).
Raheja, Bruno and Bagepalli are analogous art because they are from the same field of endeavor with respect to cloud services.
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Bagepalli into the method by Raheja and Bruno. The suggestion/motivation would have been to provide a programmable infrastructure gateway for enabling hybrid cloud services in a network environment (Bagepalli: [0002]) and provide an infrastructure gateway that includes a plurality of cloud adapters conforming to a different cloud platform managed by different service providers (Bagepalli: [0036]).
Raheja, Bruno and Bagepalli further disclose causing, by the MCG, the first API call to be communicated to the second cloud environment (Raheja: fig 1-6, [0006-137]: fig 2-6 ... the hybrid multi-cloud gateway configuration system 340 automatically translates high-level gateway performance policies to variously formatted configuration files for different API policy enforcement platforms ... process may be triggered by API product manager 310 transmitting a selection of a particular gateway type with an API policy enforcement platform within the API development module 320 ... may indicate the type of gateway where the API will be deployed (causing, by the MCG, the first API call to be communicated to the second cloud environment) ... for example, API product manager 310 may indicate the API will be deployed on a Gravitec type gateway 261 or 362 or an Nginx/Envoy type gateway 363, a Kubernetes/envoy type gateway 371 or another type gateway 381 that supports service mesh capabilities (causing, by the MCG, the 1st 2nd ... n API call to be communicated to the 1st 2nd ... n cloud environment) [0065]);
receiving, by the MCG, a modified second request requesting a second operation to be performed in a third cloud environment, wherein the modified second request is generated by encoding a second request into the generic format; responsive to receiving the modified second request, generating, by the MCG, a second API call directed to the third cloud environment (Bagepalli: fig 1-11, [0005-71]: ...the multi-cloud management module enables a user to provision and configure computing resources from a plurality of heterogeneous enterprise-maintained and third-party cloud-based service offerings (... requesting a 1st 2nd ... n operation(s) to be performed in a 1st 2nd 3rd ... n cloud environment(s)), each cloud (1st 2nd 3rd ... n cloud(s)) having different administrative or provisioning interfaces implemented with different APIs (... a 1st 2nd ... n API call(s) directed to the 1st 2nd ... n cloud environment(s)) ... multi-cloud management module includes several cloud adapters, each configured to receive and analyze non-cloud-specific message (receiving, by the MCG, a modified second request ... wherein the modified second request is generated by encoding a second request into the generic format) and then convert or translate the analyze non-cloud-specific message into a cloud-specific message compatible with a cloud management module of a cloud with which the cloud adapter is associated (responsive to receiving the modified second request, generating, by the MCG, a second API call directed to the third cloud environment) [0029])); and
causing, by the MCG, the second API call to be communicated to the third cloud environment (Raheja: fig 1-6, [0006-137]: fig 2-6 ... the hybrid multi-cloud gateway configuration system 340 automatically translates high-level gateway performance policies to variously formatted configuration files for different API policy enforcement platforms ... process may be triggered by API product manager 310 transmitting a selection of a particular gateway type with an API policy enforcement platform within the API development module 320 ... may indicate the type of gateway where the API will be deployed (causing, by the MCG, the 1st 2nd ... n API call to be communicated to the 1st 2nd 3rd ... n cloud environment) ... for example, API product manager 310 may indicate the API will be deployed on a Gravitec type gateway 261 or 362 or an Nginx/Envoy type gateway 363, a Kubernetes/envoy type gateway 371 or another type gateway 381 that supports service mesh capabilities (causing, by the MCG, the 1st 2nd ... n API call to be communicated to the 1st 2nd 3rd ... n cloud environment) [0065]),
wherein each of the first cloud environment, the second cloud environment, and third cloud environment are provided by different cloud services providers (Bagepalli: abstract: ... a programmable integration framework allowing generation of various cloud adapters using a cloud adapter software development kit, a cloud adapter being generated and programmed to be compatible with a specific public cloud ... provided to different cloud service providers who manage disparate public cloud platforms, each copy of an infrastructure gateway programmed differently to generate corresponding cloud adapters compatible with respective public cloud platforms (each of 1st 2nd 3rd ... n cloud environment(s) are provided by different cloud services providers)).
Same motivation applies as mentioned above to make the proposed modification.
As to claim 2, Raheja, Bruno and Bagepalli disclose wherein the first API call is directed to a first endpoint associated with a service provided by the second cloud environment and the second API call is directed to a second endpoint associated with another service provided by the third cloud environment, the first endpoint being different than the second endpoint (Raheja: fig 1-6, [0006-137]: fig 2-6 ... API lifecycle management system identifies API service control plane system translator associated with a user-specified type of gateway as the translator of interest to operate in a policy enforcement platform ... for example ... user selects a Gravitec gateway 361 or 362 (wherein the first API call is directed to a first endpoint associated with a service provided by the 1st cloud environment) ... another embodiment, user selects a nginx/envoy type gateway 363 (wherein the first API call is directed to a first endpoint associated with a service provided by the 2nd cloud environment) ... in still another embodiment, user selects another mesh gateway type 381 including a proxy or gateway services as well as a container underlying orchestration for gateway, operating in tandem with another mesh service controller 382 (the first endpoint being different than the second endpoint) ... identifies the other policy translator 344 of interest (the second API call is directed to a second endpoint associated with another service provided by the third cloud environment) [0106]).
For motivation, see rejection of claim 1.
As to claim 3, Raheja, Bruno and Bagepalli disclose receiving, by a software-development-kit (SDK) component implemented in the first cloud environment, the first request to perform the first operation in the second cloud environment (Bagepalli: fig 1-11, [0005-71]: ... a programmable integration framework allows cloud provider 22 to add proprietary logic to build custom tailored cloud adapters any number of such programmable and non-programmable cloud adapters may be made available within infrastructure gateway 26 according embodiments ... cloud service provider 22 may use SDK to generate a custom cloud adapter (receiving, by a software-development-kit (SDK) component implemented in the first cloud environment ...) [0051] ... fig 11 block 162 hybrid cloud instruction issued from private cloud (implemented in the first cloud environment ...) ... block 164 configured cloud adapter in infrastructure gateway interpret hybrid cloud instruction block 166 instruction to cloud platform issued by cloud adapter, for example, cloud adapter 38(5) ... during operation an instruction received from hybrid cloud application 16 interpreted by hybrid cloud API 30 and translated by core application logic 34 into an appropriate cloud adapter function that may be interpreted by cloud adapter (see with [0051] - receiving, by a software-development-kit (SDK) component implemented in the first cloud environment, the first request to perform the first operation in the second cloud environment) [0054]);
generating, by a code generator included in the SDK component, a modified first request by translating the first request into a generic format (Bagepalli: fig 1-11, [0005-71]: fig 1 ... hybrid cloud solution vendor refers to a company or individual that develops or sells and/or maintains hybrid cloud applications e.g. 16 that can be used to interconnect private clouds e.g. 12 with public louds e.g. 14 ... user interface and or other portals e.g. web portal to help cloud service providers e.g. 22 manage delivery of cloud services and offerings to their customers [0021-22] ... at 102 a generic non-programmed infrastructure gateway 26 and associated SDK may be made available (generating, by a code generator included in the SDK component, a modified first request by translating the first request into a generic format) [0066]); and
transmitting, by the SDK component, the modified first request to the MCG (Bagepalli: fig 1-11, [0005-71]: fig 1 ... hybrid cloud solution vendor refers to a company or individual that develops or sells and/or maintains hybrid cloud applications e.g. 16 that can be used to interconnect private clouds e.g. 12 with public louds e.g. 14 ... user interface and or other portals e.g. web portal to help cloud service providers e.g. 22 manage delivery of cloud services and offerings to their customers [0021-22] ... at 102 a generic non-programmed infrastructure gateway 26 and associated SDK may be made available (generating, by a code generator included in the SDK component, a modified first request by translating the first request into a generic format and transmitting, by the SDK component, the modified first request to the MCG) [0034-36]).
For motivation, see rejection of claim 1.
As to claim 4, see similar rejection to claim 3 where the method is taught by the method.
As to claim 4, Raheja, Bruno and Bagepalli further disclose obtaining, by the SDK component, a specification of an API of the second cloud environment that provides a first service associated with the first operation (Bagepalli: fig 1-11, [0005-71]: fig 1 ... ... if infrastructure gateway 26 is made available to cloud provider 1 at 104, a custom adapter e.g. 38(5) may be generated using cloud service provider 1’s proprietary code and SDK provided with infrastructure gateway 26 (obtaining, by the SDK component, a specification of an API of the second cloud environment ...) [0066] ... the cloud management API can include various functions such as (a) provisioning computing resources in public cloud 14 for various users ... (... a specification of an API of the second cloud environment that provides a first service associated with the first operation) [0035]); and
generating the modified first request in the generic format based on the specification of the API of the second cloud environment (Bagepalli: fig 1-11, [0005-71]: fig 1 ... ... if infrastructure gateway 26 is made available to cloud provider 1 at 104, a custom adapter e.g. 38(5) may be generated using cloud service provider 1’s proprietary code and SDK provided with infrastructure gateway 26 (see with [0034-36] - generating the modified first request in the generic format based on the specification of the API of the second cloud environment) [0066]).
For motivation, see rejection of claim 1.
As to claim 5, see similar rejection to claims 3-4.
As to claim 5, Raheja, Bruno and Bagepalli further disclose the modified first request includes metadata identifying at least:
a cloud service provider of the second cloud environment (Bagepalli: fig 1-11, [0005-71]: fig 4 ... createSession (Account, account) ... listCloudTypes() ... getOrganization() ),
a type of the first operation (Bagepalli: fig 1-11, [0005-71]: fig 4 ... listCapabilities() ... listServiceOfferings() ... ),
a first endpoint in the second cloud environment to which the first request is to be directed (Bagepalli: fig 1-11, [0005-71]: fig 4 ... listPublicAddress (string vpcid) ... retrieveVPC (string vpcid)), and
cloudlink information associated with the first request (Bagepalli: fig 1-11, [0005-71]: fig 4 ... listPublicAddress (string vpcid) ... retrieveVPC (string vpcid)).
For motivation, see rejection of claim 1.
As to claim 6, see similar rejection to claims 3-5.
As to claim 6, Raheja, Bruno and Bagepalli further disclose wherein the cloudlink information includes a mapping of a tenancy of a user in the first cloud environment to an account of the user in the second cloud environment (Bagepalli: fig 1-11, [0005-71]: ... tenant and resource provisioning APIs provided in cloud management API 32 supports provisioning tenants and users’ information, provisioning resource domains for tenant, and generating and/or managing per tenant secret access keys, managing per-tenant resource usage limit and per-tenant resource usage metering, managing per-tenant resource monitoring and managing tenant relevant statistics, among other functions (see with fig 4 - cloudlink information includes a mapping of a tenancy of a user in the first cloud environment to an account of the user in the second cloud environment) [0048]).
For motivation, see rejection of claim 1.
As to claim 7, see similar rejection to claims 3-6.
As to claim 7, Raheja, Bruno and Bagepalli further disclose validating, by the MCG, a user that issues the first request (Raheja: fig 1-6, [0006-137]: block 606 gateway requests validation and routing instructions for received API call from service control plane ... upon receiving an API call request from external agent, gateway transmits request for routing policies to SLA monitor or rate limit service (validating, by the MCG, a user that issues the first request) [0128]);
obtaining, in response to successfully validating the user, cloudlink information with respect to the first cloud environment and the second cloud environment (Raheja: fig 1-6, [0006-137]: ... SLA monitor may determine whether rate limit is met or exceeded ... if rate limit has not been exceeded, proceed to block 614 for routing of requested call to backend application [0130] ... request may include an identification of the external agent placing the request, identification of the gateway transmitting the request and authentication credentials for the external agent (see with [0130] - obtaining, in response to successfully validating the user, cloudlink information with respect to the first cloud environment and the second cloud environment) [0128]); and
transmitting the first request to the second cloud environment (Raheja: fig 1-6, [0006-137]: ... SLA monitor may determine whether rate limit is met or exceeded ... if rate limit has not been exceeded, proceed to block 614 for routing of requested call to backend application (transmitting the first request to the second cloud environment) [0130]).
For motivation, see rejection of claim 1.
As to claim 8, Raheja, Bruno and Bagepalli disclose wherein the first API call to the first cloud environment and the second API call to the second cloud environment are each a REST API call (Bagepalli: fig 1-11, [0005-71]: representational state transfer (REST) based communication to interface with management portal 24 [0034] ... hybrid cloud API 30 may comprise a REST based API [0045]).
For motivation, see rejection of claim 1.
As to claim 11-17, see similar rejection to claims 1-7, respectively, where the device is taught by the method.
As to claim 18-20, see similar rejection to claims 1-3, respectively, where the medium is taught by the method.
Claims 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2022/0035689 to Raheja et al. (“Raheja”) in view of U.S. Patent Publication No. 2023/0086783 to Bruno et al. (“Bruno”), U.S. Patent Publication No. 2020/0014559 to Bagepalli et al. (“Bagepalli”) and further in view of U.S. Patent Publication No. 2020/0067905 to Deshpande et al. (“Deshpande”).
As to claim 9, Raheja, Bruno and Bagepalli disclose the method of claim 1.
For motivation, see rejection of claim 1.
Raheja did not explicitly disclose mapping, via a token-exchange service, an identity of a user in the first cloud environment to another identity of the user in the second cloud environment.
Deshpande discloses mapping, via a token-exchange service, an identity of a user in the first cloud environment to another identity of the user in the second cloud environment (Deshpande: fig 1-5, [0005-61]: fig 5 block 502 deploy a token service to a first cloud platform block 504 receive a first token request from an integration component (MCG) ... block 508 send the user information request to an identity provider associated with the first cloud platform ... block 512 generate a second token request that includes the received user information block 514 send the second token request to a token service provider associated with a second cloud platform ... block 518 send the received token to the integration component to enable integration component to send message to second cloud platform).
Raheja, Bruno, Bagepalli and Deshpande are analogous art because they are from the same field of endeavor with respect to single sign on (SSO).
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Deshpande into the method by Raheja, Bruno and Bagepalli. The suggestion/motivation would have been to provide SSO, a user can log in using a single identifier and password and gain access to multiple systems (Deshpande: [0002]).
As to claim 10, Raheja, Bruno, Bagepalli and Deshpande disclose receiving, by the MCG from the second cloud environment, a response to the first request (Deshpande: fig 1-5, [0005-61]: fig 5 block 502 deploy a token service to a first cloud platform block 504 receive a first token request from an integration component (MCG) ... block 508 send the user information request to an identity provider associated with the first cloud platform ... block 512 generate a second token request that includes the received user information block 514 send the second token request to a token service provider associated with a second cloud platform ... block 518 send the received token to the integration component to enable integration component (MCG) to send message to second cloud platform (receiving, by the MCG from the second cloud environment, a response to the first request)),
wherein the second cloud environment is configured to determine whether the user is permitted to issue the first request requesting the first operation based on the token-exchange service (Deshpande: fig 1-5, [0005-61]: ... the integration component (MCG) can send a message, including the token, to the second cloud platform and the second cloud platform can authenticate the user at the second cloud platform and process the message (... the second cloud environment is configured to determine whether the user is permitted to issue the first request requesting the first operation based on the token-exchange service) [0060]).
For motivation, see rejection of claim 9.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUNE SISON whose telephone number is (571)270-5693. The examiner can normally be reached 9:00 am - 5:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise can be reached at 571-272-3865. 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.
/JUNE SISON/Primary Examiner, Art Unit 2455